> 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/cross-chain-the-distributed-register/t-rex-lite.md). # T-REX Lite T-REX Lite is the token that represents an asset on a satellite chain. It is deliberately simple. It holds balances and executes transfers that the reference chain has authorized, and it does nothing else. This page describes what it is, what it must do for the register to stay correct, and what that means for whoever integrates with it. ## What it is, and what it is not On an EVM satellite, T-REX Lite is a plain ERC-20 token with two differences. * **Its supply is driven from the reference chain.** Tokens are minted and burned on messages that arrive through the ERC-7786 gateway, or burned by a holder's own action: a recall, or a transfer whose recipient is on another chain. * **Its transfers are conditional.** A transfer executes only if a compliance validation for it exists. Validations come from the reference chain through the trusted gateway and are kept in a compliance contract linked to T-REX Lite. Each transfer consumes its validation and sends a settlement notification back to the reference chain. | T-REX Lite holds | T-REX Lite does not hold | | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- | | The balances of the wallets on its chain | Identities, claims or wallet links | | In its linked compliance contract: the validations delivered to it that are not yet consumed | The eligibility configuration of the asset | | The addresses of its peers: the token on the reference chain, and the asset's T-REX Lite on other satellites | Compliance modules or positions | | | Any knowledge of the distribution of the asset | T-REX Lite is not an ERC-3643 token. It has no registry and no rules of its own. The ERC-3643 token, with its two gates, is on the reference chain. T-REX Lite executes that token's decisions. The compliance contract linked to it decides nothing: it stores the decisions it received. The balances it holds are the executable representation of positions that the register records as bridged. For every wallet on the satellite, the balance on T-REX Lite and the bridged position on the reference chain describe the same tokens. ## Why it is thin Concentrating the protocol on the reference chain leaves only a small execution layer to port to each new ecosystem. * **It can exist where smart contracts are limited.** A chain that can hold balances, check a stored authorization and send a message can host it. * **There is one place where rules are decided.** No rule has to be reimplemented, kept in sync or audited per chain. * **A satellite cannot weaken the asset.** Whatever a satellite's own capabilities, a transfer that the rules refuse receives no validation and does not execute. ## Its obligations The register stays correct as long as T-REX Lite does five things. They are the specification of any implementation, on any chain. | Obligation | What it guarantees | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Accept messages only through the trusted gateway, from its peers.** A validation or an instruction counts only if its author is the asset's token on the reference chain. A proof of burn counts only if its author is the asset's T-REX Lite on another satellite. | Nobody else can authorize a transfer or create tokens on the satellite. | | **Execute a transfer only against a validation, and consume it.** The sender, the recipient and the spender match the validation. The amount is inside its range. The execution happens strictly before its expiry. A validation is used once. | No transfer happens that the reference chain has not authorized, and none happens twice. | | **Report every execution.** After a transfer, it sends a settlement notification naming the validation and the exact amount. | The register records the change of ownership. | | **Create and destroy only on instruction, or with proof.** It mints on a mint instruction from the reference chain, or on a proof of burn from another satellite. When it burns, it sends the proof of it. | The balances on the satellite always equal what the register records as bridged there. | | **Refuse everything else.** A transfer with no matching validation does not execute. | A holder cannot move tokens outside the rules by acting on the satellite. | ## The messages ### What it receives | Message | From | What T-REX Lite does | | ------------------------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Compliance validation** | The reference chain | Stores it in its compliance contract until it is consumed or expires. | | **Mint instruction** | The reference chain | Creates the balance of a position that the reference chain records as bridged to a wallet on this chain. Sends nothing back. | | **Recall instruction** | The reference chain | Destroys the balance an agent recalls and answers with a burn proof. If the wallet no longer holds the amount, it answers that the recall failed. | | **Proof of burn** | T-REX Lite on another satellite | Mints the burned amount to the recipient of a transfer that started on that satellite, and reports the mint to the reference chain. | A validation carries everything T-REX Lite needs to check a transfer. | Field | Meaning | | ------------------------ | ------------------------------------------------------------------------------------ | | `validationId` | The identifier of the validation. Unique for the asset, used once. | | `from`, `to` | The sender and the recipient, as interoperable addresses. | | `spender` | The party allowed to execute for the sender. Empty when only the sender may execute. | | `amountMin`, `amountMax` | The range the executed amount must fall in. | | `token` | The address of the asset on the reference chain, its identifier everywhere. | | `expiry` | The time before which the transfer must execute. | | `reconciliationWindow` | How long the reference chain keeps the reservation after the expiry. | ### What it sends | Message | To | When | | --------------------------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Settlement notification** | The reference chain | After each transfer it executes: the validation, the wallets and the exact amount. | | **Burn proof** | The reference chain | After a burn for a recall: the wallet that was burned, the amount, and the address on the reference chain to credit. | | **Proof of burn** | T-REX Lite on another satellite | After the burn that starts a transfer to a recipient on that satellite. | | **Recall failure** | The reference chain | When a recall instruction finds less than the amount in the wallet. `[[TBC: the message that reports a failed recall]]` | ## How a transfer executes A transfer on T-REX Lite is the ERC-20 call a wallet already knows: `transfer` by the holder, or `transferFrom` by the spender the validation names. ```mermaid sequenceDiagram participant RC as Token on the reference chain participant G as ERC-7786 gateway participant L as T-REX Lite participant C as Compliance contract of T-REX Lite participant S as Sender or spender RC->>G: compliance validation G->>L: deliver L->>C: author is the peer, store the validation S->>L: transfer, or transferFrom L->>C: a validation matches: parties, amount in range, not expired C->>C: consume the validation L->>L: move the balances L->>G: settlement notification G->>RC: deliver ``` What T-REX Lite does and reports depends on where the recipient is. | The recipient is | What T-REX Lite does | What is reported | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | On the same satellite | Moves the balance from the sender to the recipient. | One notification, with both wallets. | | On another satellite | The sender's chain consumes the validation and burns. It sends a proof of burn to the recipient's chain, which mints the same amount. | One notification per chain, the burn and the mint, for the same amount. | | On the reference chain | Burns the sender's balance. | One notification, with both wallets. The register credits the recipient on the reference chain. | In a transfer between two satellites, the burn always comes first, and the validation is consumed on the chain where the transfer starts. The receiving chain does not check the validation again: without it, the burn it has the proof of could not have happened. The register completes the transfer when both notifications have arrived and agree on the amount. ## Recall A recall returns a position to the reference chain for the same owner. On T-REX Lite it is a burn. | Recall | Triggered by | What T-REX Lite does | | ------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | By the holder | The holder, on T-REX Lite | Burns the amount from the holder's wallet and sends a burn proof. The reference chain converts the position from bridged to free. | | Forced | A recall instruction from the reference chain, ordered by an agent | Burns the amount from the named wallet and sends a burn proof. If the tokens are no longer in that wallet, it reports the failure. | A recall does not look at validations. It can burn tokens that an open validation was issued for. That validation can then no longer execute. It expires and is discarded on the reference chain. A forced recall can cross a transfer in flight: the holder executes a validated transfer just before the recall instruction arrives. The recall then fails for lack of tokens, T-REX Lite says so to the reference chain, and the reference chain receives the settlement of the transfer that did execute. ## Its address and its deployment A token and its T-REX Lite are peers, identified to each other by address. * **Deployment.** T-REX Lite is deployed on a satellite by the T-REX Lite factory of that chain, on a message that arrives through the ERC-7786 gateway. * **On an EVM satellite**, T-REX Lite sits at the same address as the token on the reference chain. Deterministic deployment makes this possible although the two are different contracts. An asset has one recognizable address on every EVM chain it reaches. * **On a non-EVM satellite**, the address has the form of that chain. The Issuer registers it as the token's peer. ## For integrators | If you are | What to know | | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A wallet** | T-REX Lite shows balances and takes transfers like any ERC-20 token. A transfer needs a validation first. The holder's identity requests it on the reference chain, or an agent does it for the holder. Without a validation, the transfer reverts. | | **A venue or an application** | You execute a holder's transfer with `transferFrom`, as the spender named in a validation. Whether you are accepted as a spender is decided on the reference chain, by the asset's spender policy, when the validation is issued. | | **An indexer** | Balances on T-REX Lite are positions the register records as bridged. Ownership is recorded when the settlement reaches the reference chain. See [Technical finality and legal finality](/the-primary-register/technical-finality-and-legal-finality.md). | | **An implementer on a new chain** | The five obligations above and the message formats are the specification. The guide is under Build: Implement T-REX Lite on a new chain. | A recipient cannot move on a satellite what the register has not yet recorded as its own. An onward transfer needs a new validation, and a validation is capped at the position the register records for the sending wallet. --- # 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/cross-chain-the-distributed-register/t-rex-lite.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.