> 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/start-here/standards-foundation.md). # Standards foundation T-REX is assembled from open standards rather than bespoke mechanisms. A register for securities is long-lived infrastructure: it must be auditable, interoperable and free of proprietary lock-in, and it must outlive the team that wrote it. Standards that the whole ecosystem maintains serve that better than machinery only its authors understand. The protocol introduces new architecture, mainly in its cross-chain model, and builds it from existing primitives wherever they exist. This page lists each standard, what the protocol uses it for, and where it lives in the code. ## Core standards | Standard | What it is | Role in T-REX | Where it lives | | ------------------ | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **ERC-20** | Fungible token interface | The base every token stays compatible with, on the reference chain and on satellites, so wallets, venues and tooling work unchanged. | `Token`, T-REX Lite | | **ERC-3643** | Permissioned token standard | The token layer of the register. Conditions every transfer on eligibility and compliance validation. | `Token`, `TREXRegistry`, `IdentityRegistryStorage`, `ModularCompliance`; interfaces in `contracts/ERC-3643/` | | **ERC-734** | Key management for identities | Keys with purposes (management, action, claim signing and others). The authorization model of an identity. | `KeyManager`, with the key registry in `ERC734Validator` | | **ERC-735** | Claim holding | How signed claims are stored on an identity and verified against it. Installed as a module, reached through the account's fallback handler. | `ERC734Validator` | | **ERC-7579** | Modular smart accounts | An ONCHAINID is an ERC-7579 account: it holds assets and executes calls like any smart account. Validation, execution rules, claims and recovery are modules. | `Identity`, `SmartAccount`, `ERC734Validator`, `KeyApprovalModule`, `RecoveryModule` | | **ERC-4337** | Account abstraction | An identity validates user operations through its installed validator, so its owner transacts through it directly, with bundlers and paymasters. | `Identity`, `ERC734Validator` | | **ERC-7913** | Signer representation and verification | One verifier interface for every signature scheme: ECDSA accounts, ERC-1271 contracts, passkeys and WebAuthn, RSA, and schemes added later. | `ERC734Validator`; trusted verifiers listed in `IdentityFactory` | | **ERC-7930** | Interoperable addresses | A chain-aware address format for EVM and non-EVM chains. Used to link wallets to identities, to account bridged positions per satellite wallet, and to name chains and spenders in cross-chain messages. | `IdentityFactory`, `Token` (bridged ledger, `WalletKeyLib`), `MessageTypesLib` | | **ERC-7786** | Cross-chain messaging interface | A transport-agnostic interface over messaging providers. Every message between the reference chain and a satellite goes through it, so no provider is a protocol-level dependency. | `TREXMessaging` (inherited by `Token`), `TrustedGatewayRegistry`, `IdentityFactory` (cross-chain wallet links) | | **ERC-712** | Typed structured-data signing | A standard, wallet-legible form for everything a party signs: claims, proof of wallet ownership when linking, token permits. Claim revocation is keyed to the signed digest. Each identity has its own signing domain, so a signature cannot be replayed against another identity. | `ERC734Validator`, `IdentityFactory`, `Token` | | **ERC-7201** | Namespaced storage layout | Every upgradeable contract keeps its state in a collision-free storage region, so layouts evolve across upgrades without storage-collision risk. | All upgradeable contracts in both codebases | | **ERC-165** | Interface detection | A contract address can only be wired into the protocol if it declares the expected interface. Used at every level to keep configuration sound. | Throughout | | **Beacon proxies** | Upgradeability pattern (ERC-1967) | A beacon holds the current implementation for a family of proxies. Upgrading the beacon upgrades every proxy that points to it. | Token suites through `TREXImplementationAuthority`; identities through `IdentityFactory` | | **CREATE3** | Deterministic deployment | The deployed address depends only on the deployer and a salt, not on the bytecode. An asset or an identity has the same address on every EVM chain, even though the reference-chain `Token` and T-REX Lite are different contracts. | `TREXFactory`, `IdentityFactory` | ## Supporting standards and components | Standard or component | Role in T-REX | Where it lives | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | **ERC-1271** | Signature validation by contracts. Lets a smart-contract wallet prove ownership when it links to an identity, and lets an identity validate signatures. | `IdentityFactory`, `ERC734Validator` | | **ERC-2612** | Permit: ERC-20 approvals by signature. | `Token` | | **ERC-5267** | Discovery of a contract's ERC-712 domain. Used to compute claim digests against the issuer's domain. | `Identity`, `ERC734Validator` | | **ERC-173** | The `owner()` view. On suite contracts it returns the suite's AccessManager, so tooling that expects an owner keeps working. | `Token`, `TREXRegistry`, `IdentityRegistryStorage`, `ModularCompliance` | | **UUPS proxies** (ERC-1822, ERC-1967) | Upgradeability for contracts that are not part of a beacon family. | Compliance modules (`ModuleProxy`), `UtilityChecker`, `IdentityUtilities` | | **OpenZeppelin AccessManager** | One role and policy engine for every privileged function. Not an ERC, but the standard OpenZeppelin component for it. | `TREXAccessManager` for token suites; one `AccessManager` for the network contracts and the identity layer | | **Ethereum Attestation Service** | An external attestation system. An adapter resolves EAS attestations as claims, so credentials issued outside the protocol count toward eligibility. | `EASClaimIssuer` | Several of these standards are recent: ERC-7579, ERC-7786, ERC-7913 and ERC-7930 in particular. T-REX uses the OpenZeppelin Contracts 5.7 implementations of them rather than its own. ## How the standards divide across the layers ```mermaid flowchart LR subgraph IDL["Identity layer"] direction TB A["ERC-734 · ERC-735"] B["ERC-7579 · ERC-4337 · ERC-7913"] C["ERC-7930"] end subgraph TKL["Token and register layer"] direction TB D["ERC-20 · ERC-3643"] E["ERC-7930"] F["ERC-7786"] end subgraph INF["Shared infrastructure"] direction TB G["ERC-7201 · beacon proxies · CREATE3"] H["ERC-165 · ERC-712 · AccessManager"] end IDL --- INF TKL --- INF ``` * **The identity layer** is built on ERC-734, ERC-735, ERC-7579, ERC-4337, ERC-7913 and ERC-7930: a portable, multi-signer, cross-chain-aware smart-account identity. * **The token and register layer** is built on ERC-20, ERC-3643, ERC-7930 and ERC-7786: a compliant, globally accounted, cross-chain register. * **ERC-7201, beacon proxies and CREATE3** are infrastructure shared by both layers. * **ERC-165 and ERC-712** are cross-cutting. ERC-165 guards configuration at every level. ERC-712 applies wherever a party signs. ERC-7930 appears in both layers, and that is what ties them together across chains: the same address format identifies a wallet when it is linked to an identity and when a position is accounted on a satellite. ## What the choice of standards replaces Several of these standards replace mechanisms that earlier T-REX and ONCHAINID versions implemented themselves. | Before | Now | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | A monolithic ERC-734 and ERC-735 identity contract, a container of keys and claims | An ERC-7579 modular account that holds assets and transacts, with ERC-734 keys at account level and ERC-735 claims as a module | | ECDSA keys only | Any signer that has an ERC-7913 verifier, passkeys included | | Wallets registered token by token, by chain-native address | Wallets linked once to an identity, by ERC-7930 interoperable address | | A custom proxy and implementation-authority arrangement | Standard beacon proxies | | Sequential storage slots | ERC-7201 namespaced storage | | Per-contract owners and agent lists | Roles in an OpenZeppelin AccessManager | | CREATE2 deployment | CREATE3 deployment | The full list of changes is in [Coming from ERC-3643 v4](/start-here/coming-from-erc-3643-v4.md). How the token layer relates to the standard is in [T-REX and ERC-3643](/the-primary-register/t-rex-and-erc-3643.md). > **A note on CREATE3.** The same address on every chain holds for chains that follow the canonical CREATE2 address derivation, and requires the factory itself to sit at the same address on each of them. Chains that derive addresses differently, zkSync Era for example, produce different addresses. The `IdentityFactory` checks the derivation when its beacon is initialized and refuses to initialize on a chain where it does not hold. --- # 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/start-here/standards-foundation.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.