Skip to content

Smart Contracts

The TRASH Protocol contracts adhere to the EIP-1967 Transparent Proxy pattern, ensuring upgradeability while maintaining decentralized control. All contract upgrades must be approved through multisig stakeholder consensus, guaranteeing that changes are made with the agreement of multiple trusted parties.

Permissions Contract for Access Control

The protocol uses a centralized Permissions Contract to manage and store authorized addresses for different roles within the system. This contract governs roles like Governance, Ecosystem Operators, and Store Owners, ensuring that only authorized entities can perform critical functions within the protocol.

  • Permissions Contract: Centralizes role-based access control, storing the addresses associated with each key role in the system.
  • Single Source of Truth: The Permissions Contract is the sole source for determining which addresses have permission to perform actions like minting tokens, managing stores, or overseeing governance.

Roles and Permissions

The Permissions Contract defines the addresses permitted to execute various actions, such as minting tokens, approving rewards, and managing stores. Any contract interacting with the protocol references the Permissions Contract to validate permissions based on roles.

  • Governance: Responsible for managing protocol upgrades, adding new merchants, and approving store-related $TRASH reward alterations or additions.
  • Ecosystem Operators: Authorized to interact with core protocol features, such as minting tokens and managing store operations.
  • Store Owners: Manage store-specific operations, including inventory management and overall store functionality.

Permissions Contract Overview

The Permissions Contract manages the addresses associated with various roles, centralizing all role-based control into one place. This simplifies permission management and ensures any changes to the addresses can be made in a single location.

  1. Permissions Contract:

  2. Stores the addresses of Governance, Ecosystem Operators, and Store Owners.

  3. Any contract that needs to verify permissions can query the Permissions Contract directly.

  4. When a role needs to be updated (e.g., a new governance authority), the change is made directly in the Permissions Contract, and all downstream contracts automatically reflect the update without further modifications.

  5. Role Management:

  6. Governance: Handles protocol upgrades, adding merchants, and approving store $TRASH reward alterations or additions.
  7. Ecosystem Operators: Manage core protocol functions, including minting tokens and operating stores.
  8. Store Owners: Oversee store-specific functions such as inventory management and store operations.

Interaction with the Permissions Contract

All contracts within the protocol reference the Permissions Contract to verify permissions and roles before allowing any privileged actions. This ensures that:

  • Permission Validation: Each contract queries the Permissions Contract to confirm whether the caller has the required role (Governance, Ecosystem Operator, Store Owner) before executing actions such as minting tokens, managing stores, or approving rewards.
  • Centralized Role Updates: Any changes to the roles or authority addresses are handled centrally in the Permissions Contract. This eliminates the need for individual contract updates whenever a new authority is added or removed.

Roles in the Protocol

  • Governance: Responsible for overseeing protocol upgrades, adding merchants, and approving changes to $TRASH rewards for stores.
  • Ecosystem Operators: Authorized to mint tokens, manage store operations, and interact with other core functions within the protocol.
  • Store Owners: Handle store-related operations, including inventory and managing store activity.

Upgrading and Managing Authorities

  • Multisig Consensus for Upgrades: Contract upgrades are managed by a multisig governance structure, ensuring that no single entity can unilaterally upgrade or modify the protocol without broad stakeholder consensus.
  • Centralized Updates: If governance members, ecosystem operators, or store owners need to be updated, the Permissions Contract handles these changes. All contracts that rely on these permissions dynamically reference the updated roles, removing the need for redeployment or modification of individual contracts.

Conclusion

The TRASH Protocol uses a centralized Permissions Contract to manage access control for key roles, including Governance, Ecosystem Operators, and Store Owners. This streamlined approach simplifies role management, ensuring that any updates to the permissions are handled in one place. The Permissions Contract guarantees that role-based access control is maintained across the entire protocol while allowing for secure and decentralized governance.

Key Registries

  • GovernanceRegistry: Stores the address of the governance authority responsible for overseeing upgrades, adding new merchants to the protocol and approving $TRASH rewards.
  • EcosystemOperatorsRegistry: Maintains a list of addresses that are permitted to interact with core protocol features such as minting tokens or managing store operations.

Base Sepolia

sepolia basescan: opens in this tab

Infrastructure

Name Registry Key Proxy Address ProxyAdmin Address Implementation Address
Coordinator COORDINATOR 0xfDdB8D91580402B29B159BEa1bCCB7e0410130bB 0x8909d143F6A11313a97d8d8e0BB8457D343Ac19f 0xD600E6e6b470627B4523AA8b64F773F52493866d
Inventory STORE_INVENTORY 0xb75BC142Ce42Ab90E1af4066AfCFcE4Ed022AEbD 0x043A6e952F4e4aF67B95C7016C45010Bf2ed9713 0x8CB0acDd9f6d62ad704940EF2d2A24228854a5d7
Permissions PERMISSIONS_REGISTRY 0x20e7fBEC82378c0aD1d243C331a9aFd67Bd6AE31 0x2811D8a2d5853674dC7834ca69Da7F9b0D1B6cac 0x3F34201E4735f559980aa9d2Ab375f4FdA1a3B21
RegistryStore - 0x4da62C0867a514fC685eB03d7Dc1C4BFc5757b10 0x3779E19EB282224f02a0759825c34f31c803ba06 0x5F6e9fEEe89402D2E93675894a3615eC3ba9bAc0
RewardRegistry REWARDS_REGISTRY 0x1afa8cC49082EA0f6571Ad711b180822923c606F 0xb398673e05d5723c3321eB132C5c6ec85Bf252fB 0x3934c42d331b9bc10437d2394870281ece36aD98
SplitsRegistry SPLITS_REGISTRY 0x9A0872967B68D9f2B67553721A5990D57bA5248F 0x8a68104b629c46e945f6932333c0435a1DEe8903 0x997aCc4d7C2D2fb3A48d043DFc0e34C7Bf2aC002
StoreAuthorizationRegistry STORE_AUTHORIZATION 0xb1758Dc40012c05810b5A9DCc9BE9d6903545bde 0x98d0916446748ceF9326dfF77692C8474a575C04 0xb712F38E422DE31De4aCeCe9926F2aD7d3A20770
StoreRegistry STORE_REGISTRY 0x4d3fC6C25DE1E6816487f5A9f4A12009D8E50221 0x488c362Ad2126a285D78C910B364ABdAe5237752 0x0766F43B3aEc476260B6Fa663Ac56E102dc98354

Tokens

Name Registry Key Proxy Address ProxyAdmin Address Implementation Address
NFT NFT 0x33E787F9629f592715b17CD58963B70b8E13c350 0x92F7C5537d434345Ad54835D7CBF1c23FAd278f4 0x5A5c45029871eDE070cbdade571Af0206672d4E9
Token TRASH_TOKEN 0x2D0bD7a6cEdB3C1cb017e0E084EE3d0d4E122981 0x19A1EC32A60Cb640A55901EfD9D92aefdC169A16 0xb5F0DF61c8A79d1CB1FD84059C11AFE96c190359