Noon
  • ☀️Welcome to Noon's documentation
  • 📱Noon: The Basics
    • Introduction
    • The opportunity
    • How it works
    • How we stack up
  • 🖥️Noon: The Details
    • Our stablecoin: USN (& sUSN)
    • Should you hold USN or sUSN?
    • Return generation
    • Return distribution
    • Our rewards programme
    • Our governance token: NOON (& sNOON) [Coming soon]
    • Fees and other charges
    • Our deployment strategies
    • Risks & mitigants
  • 🔐Security
    • Transparency
    • Asset custody
    • Smart contract security
    • Smart contract audits
    • Contracts and addresses
  • 📚Additional Resources
    • Technical FAQ
    • Contact us
Powered by GitBook
On this page
  • Role-Based Access Control
  • Two-Step Ownership Transfer
  • Decentralization of Power
  • Role Distribution
  • Multi-Signature Recommendations
  • Data Security
  • Storage Safety
  • Monitoring and Alerts
  • Critical Events
  • Security Checkpoints
  • Clear Emergency Process

Was this helpful?

  1. Security

Smart contract security

This documentation outlines the security measures implemented in our smart contract system, focusing on access control, role management, and monitoring mechanisms.

Role-Based Access Control

Our contracts implement a robust role-based access control (RBAC) system using OpenZeppelin's 'AccessControl' pattern.

Key roles include:

- `DEFAULT_ADMIN_ROLE`: Super-admin with the ability to manage other roles
- `REBASE_MANAGER_ROLE`: Controls rebase operations
- `BLACKLIST_MANAGER_ROLE`: Manages blacklisted addresses
- `STAKING_VAULT_ROLE`: Special permissions for staking operations

Two-Step Ownership Transfer

We utilize OpenZeppelin's Ownable2Step pattern for secure ownership transfers, requiring the new owner to accept the transfer explicitly:

function transferOwnership(address newOwner) public virtual override(Ownable2Step, Ownable) onlyOwner {
    Ownable2Step.transferOwnership(newOwner);
}

Decentralization of Power

Role Distribution

To prevent single points of failure and reduce trust requirements, different roles should be assigned to separate trusted entities:

  1. Admin Role: System maintenance and emergency functions

  2. Rebase Manager: Handles rebase operations

  3. Blacklist Manager: Controls address restrictions

  4. Staking Vault: Manages staking operations

Multi-Signature Recommendations

Critical operations should be protected by multi-signature wallets:

  • Treasury management

  • Protocol parameter updates

  • Emergency functions

Data Security

Storage Safety

  1. Access Controls

    • Strict visibility modifiers

    • Internal function protection

    • State variable access restrictions

Monitoring and Alerts

Critical Events

Monitor these events for security:

event AdminChanged(address indexed oldAdmin, address indexed newAdmin);
event Blacklisted(address indexed account);
event WithdrawalDemandCreated(address indexed user, uint256 amount, uint256 timestamp);

Security Checkpoints

  1. Transaction Monitoring

    • Large transfers

    • Ownership changes

    • Role assignments

  2. Blacklist Operations

    • Address additions/removals

    • Blocked transaction attempts

  3. Withdrawal Operations

    • Request creation

    • Claim attempts

    • Failed transactions

Clear Emergency Process

  • Clear incident response plan

  • Emergency contact list

  • Recovery procedures

  • Revokation protocols


This documentation provides a comprehensive overview of the security measures implemented in your smart contract system while offering guidance for secure operations and maintenance. You can further customize it based on your specific needs or add more technical details as required.
PreviousAsset custodyNextSmart contract audits

Last updated 4 months ago

Was this helpful?

🔐