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

• 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. How the token layer relates to the standard is in T-REX and ERC-3643.

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.