> For the complete documentation index, see [llms.txt](https://docs.t-rex.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.t-rex.network/reference/token-suite.md). # Token Suite The token suite is the set of contracts that make one asset: its token, its eligibility registry, its compliance, and the factory, versions and access control around them. This section has one page per contract: every external function, who can call it, what it reverts with, and the events it emits. The Concepts explain why the contracts are built this way and the Guides show each operation end to end. These pages are the lookup tables behind them, written from the code of the `develop` branch of the T-REX repository. The contracts of the identity layer are in the Identity Suite section. ### The contracts | Page | Contract | Deployed as | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------ | | [Token](/reference/token-suite/token.md) | `Token` | One beacon proxy per asset, by the `TREXFactory` | | [TREXRegistry](/reference/token-suite/trexregistry.md) | `TREXRegistry` | One beacon proxy per asset | | [IdentityRegistryStorage](/reference/token-suite/identityregistrystorage.md) | `IdentityRegistryStorage` | One beacon proxy per asset, or one shared by several assets of an Issuer | | [ModularCompliance](/reference/token-suite/modularcompliance.md) | `ModularCompliance`, with its ledger | One beacon proxy per asset | | [Transfer validation](/reference/token-suite/transfer-validation.md) | The validation functions of `ModularCompliance` | Part of the compliance | | [Compliance modules](/reference/token-suite/compliance-modules.md) | `IModule`, `AbstractModuleUpgradeable`, the three shipped modules | One `ModuleProxy` per module, shared by every compliance bound to it | | [TREXFactory](/reference/token-suite/trexfactory.md) | `TREXFactory` | Once per network | | [TREXImplementationAuthority](/reference/token-suite/treximplementationauthority.md) | `TREXImplementationAuthority` | Once per network | | [Access manager and roles](/reference/token-suite/access-manager-and-roles.md) | `TREXAccessManager`, `RolesLib`, `AccessManagerSetupLib` | One manager per suite, or one shared by several suites of an Issuer | | [Messaging](/reference/token-suite/messaging.md) | `TREXMessaging`, `TrustedGatewayRegistry`, `MessageTypesLib` | Part of each token. One gateway registry per network | | [UtilityChecker](/reference/token-suite/utilitychecker.md) | `UtilityChecker` | Once per network, behind a proxy | | [Errors of the token suite](/reference/token-suite/errors-of-the-token-suite.md) | `ErrorsLib`, `ERC3643ErrorsLib` | | ### How to read a page Each function table has three columns. | Column | Content | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Function** | The name and the arguments, in the order of the code. Names in backticks are the names of the code. | | **Access** | Who can call it. A role name means the role of that name in the domain of the asset, checked by the suite's `TREXAccessManager`. "Anyone" means the function has no caller check. | | **Reverts with** | The custom errors of the function, and the condition of each when the name does not say it. | ### Conventions shared by every contract * **Access control.** Every restricted function asks the suite's access manager whether the caller holds the role mapped to that function. A caller without the role is refused with OpenZeppelin's `AccessManagedUnauthorized`. A batch function is authorized by the role of its single-item counterpart: `batchMint` asks for the role of `mint`. The mapping of functions to roles is in [Access manager and roles](/reference/token-suite/access-manager-and-roles.md). * **Ownership.** `owner()` of a suite contract returns its access manager, and `transferOwnership(newAuthority)` points the contract at another manager. No contract of a suite has a single owner key. * **Errors.** Custom errors are declared in `ErrorsLib` and, for the part that belongs to the standard, in `ERC3643ErrorsLib`. The errors of the ERC-20 base (`ERC20InsufficientBalance`, `ERC20InsufficientAllowance`) and of the pause (`EnforcedPause`, `ExpectedPause`) are OpenZeppelin's. * **Events.** Events are declared in `EventsLib` and in the ERC-3643 interfaces. Full signatures, with the indexed arguments, are in [Indexing: events and supply accounting](/build/indexing-events-and-supply-accounting.md). * **Addresses and wallets.** A function that takes an `address` concerns the reference chain. A function that takes a wallet as `bytes` takes an ERC-7930 interoperable address in canonical form, on any chain. A `chainKey` is the `bytes32` that `MessageTypesLib.chainKey(chainType, chainReference)` returns for a chain. * **Storage.** Every upgradeable contract keeps its state in an ERC-7201 namespace: see [Namespaced storage (ERC-7201)](/governance-and-infrastructure/namespaced-storage-erc-7201.md). * **Standard and extension.** Each suite contract is a standard ERC-3643 base (`contracts/ERC-3643/base/`) extended by the T-REX contract. The tables list both parts together, as an integrator sees them. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.t-rex.network/reference/token-suite.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.