For the complete documentation index, see llms.txt. This page is also available as Markdown.

FAQ

Short answers to common questions. Each answer names the page that gives the full one.

The protocol

What is the T-REX protocol? A set of smart contracts that records who owns a financial instrument, by identity, and enforces on every movement that the recipient may hold it and that the movement respects the rules of the asset. See Protocol at a glance.

How does it relate to ERC-3643? T-REX is the reference implementation of ERC-3643. Version 5 keeps the interfaces of the standard and adds identity-based ownership, modular compliance and cross-chain distribution around them. See T-REX and ERC-3643.

Is a T-REX token an ERC-20? Yes. transfer, approve, transferFrom and balanceOf behave as a wallet or a contract expects. A transfer also passes the pause, the freezes, the eligibility of the recipient and the rules of the asset, and reverts if one refuses. See The permissioned token.

Is the protocol tied to one chain? No. The protocol defines a reference chain by its role: it holds the register of every asset and every identity. Nothing in the contracts depends on which chain plays that role. See The T-REX Ledger and its satellites.

Is the code open source? Yes. Both codebases are published under GPL-3.0. See Changelog for the repositories.

Has it been audited? ONCHAINID 3.0.0 was audited by OpenZeppelin. The audit of T-REX 5 is in progress. See Audits and verification.

Identity and eligibility

Does every holder need an ONCHAINID? Yes. Ownership and eligibility are evaluated on an identity. A holder either holds tokens at the address of its ONCHAINID, or at a wallet linked to it. See An identity that is also an account.

Can one Investor use several wallets? Yes. Every wallet linked to an identity counts toward the same position, on any chain. A movement between two wallets of one identity changes no ownership. See 07 Link a wallet to an ONCHAINID.

Is personal data stored on-chain? No. A claim carries a topic, validity dates and a payload that is a hash or an encoded value. The verification itself stays with the Claim Issuer. See Claims: issuance, validity, revocation.

What is the difference between eligibility and compliance? Eligibility says whether an identity may hold the asset: it has the claims the asset requires, from Claim Issuers the asset trusts. Compliance says whether one movement is allowed now: the modules of the asset decide. A movement passes both. See Eligibility and compliance: the two gates.

What happens when a claim expires or is revoked? The holder keeps what it holds and can still send. It can no longer receive the assets that relied on that claim, until it holds a valid claim again. See 19 Revoke a claim.

What if a holder loses a wallet, or the keys of its identity? For a lost wallet, a Token Agent moves the balance to a new address of the same identity: 15 Recover a lost wallet. For lost identity keys, the Guardians of the identity give it a new key: 21 Recover access to an ONCHAINID.

Issuers

What does an Issuer need to launch an asset? A token suite, the claim topics it requires, the Claim Issuers it trusts, its compliance rules, and agents with their roles. See J1 Issuer journey: launch an asset.

Can an Issuer write its own compliance rule? Yes. A rule is a module bound to the compliance of the asset. See Write a compliance module.

Who can upgrade the contracts of an asset? For a suite on the shared beacons, the holder of the VERSION_MANAGER role of the network. For an isolated suite, the Issuer. See Upgradeability: beacons and versions.

What can an Issuer do to a position without the holder? Its agents can freeze an address or an amount, force a transfer, recover a balance to another address of the holder, burn, and pause the asset. Each is a separate role. See Lifecycle controls.

Can several assets share the same Investors? Yes. Identities and their wallet links are global, and an Issuer can wire several assets to one identity storage. Each asset keeps its own required topics, trusted issuers and rules. See IdentityRegistryStorage.

Cross-chain

Where is ownership recorded when tokens are on another chain? On the reference chain. A position that is active on a satellite is recorded there as bridged, per wallet. totalSupply counts the whole issuance, satellites included. See The balance model.

How does a transfer on a satellite work? The reference chain issues a validation for the transfer, after checking eligibility and the rules. The satellite executes only against that validation, and reports the execution. The register then records the change of ownership. See 31 Transfer on a satellite.

What if a message between chains is delayed or lost? A validation that is not executed expires and is discarded, and its reservation is released. A report that arrives late is applied and flagged. See 36 Handle a late reconciliation or a halt.

Which messaging provider does the protocol use? The protocol calls the ERC-7786 gateway interface and nothing below it. Chainlink is the default provider, and an Issuer can route a chain through any gateway the network trusts. See Messaging providers.

Developers

Where do I start? With the Quickstart: get the code, run the tests, and write a first test against a complete local suite.

Which packages do I install? @t-rex-network/t-rex for the token suite and @t-rex-network/onchainid for the identity layer.

How do I tell a holder why a transfer would fail? With UtilityChecker, before the holder signs. See Pre-flight checks with UtilityChecker.

Where are the contract addresses? In Deployments. The contracts of one asset are read from its token.

I integrate ERC-3643 v4 today. What changes? See Coming from ERC-3643 v4.

Last updated