> 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/non-evm-satellites.md). # Non-EVM satellites A satellite does not have to be an EVM chain. T-REX Lite is a thin execution layer, not a reimplementation of the protocol, so it can exist on chains very different from the reference chain, including chains with limited smart-contract capabilities. The complexity of the protocol is concentrated where it can be fully supported, on the reference chain, and what has to be ported to each new ecosystem is deliberately small. This page describes what makes that possible, what is the same on a non-EVM satellite, and what differs. ## What makes it possible Three choices in the protocol are what let a non-EVM chain take part. | Choice | Effect | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **The satellite decides nothing.** | No identity registry, no eligibility configuration and no compliance engine has to be rebuilt in another language or on another virtual machine. | | **Addresses are interoperable.** Every wallet, peer, spender and chain is named with ERC-7930, which carries the type of chain, the chain, and the address in that chain's own format. | The register records a position for a Solana account or an XRPL address as naturally as for an Ethereum address. | | **Messaging is an interface.** Every message goes through ERC-7786. | Any provider that reaches the chain can carry the messages, behind an adapter. | ## What is the same The register treats a non-EVM satellite exactly like an EVM one. | | On any satellite | | ------------------------------ | ------------------------------------------------------------------------------------- | | **Eligibility and compliance** | Decided on the reference chain, before execution. | | **Transfers** | Authorized by a validation, executed on the satellite, settled back. | | **Positions** | Recorded on the reference chain as bridged, per wallet. | | **Rules** | Evaluated over the identity's whole position, this chain included. | | **Supply** | One total supply, counted on the reference chain. | | **Obligations of T-REX Lite** | The same five. See [T-REX Lite](/cross-chain-the-distributed-register/t-rex-lite.md). | From the register's point of view, a movement is a movement between two interoperable addresses. Which chains they are on is carried in the addresses. It is not a difference in how the register treats the movement. ## What differs | | EVM satellite | Non-EVM satellite | | ------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | **Address of T-REX Lite** | The same address as the token on the reference chain, by deterministic deployment. | An address in the chain's own format. It cannot match. | | **The peer** | Known by default. | Registered by the Issuer with `setPeer`. Until it is, the chain is not open. | | **Linking a wallet** | By a message from the wallet on its chain, settled by the identity. | The same path. The signature path exists only for wallets on the reference chain. | | **Form of T-REX Lite** | A plain ERC-20 contract, with a linked compliance contract that stores the validations. | Whatever the chain offers: a program, a contract, or the chain's native token features. | | **Encoding of messages** | Native. | The implementation encodes and decodes the protocol's message format itself. | | **Messaging provider** | Any vetted gateway that serves the chain. | A vetted gateway whose provider reaches that ecosystem. | ### The peer has to be registered On an EVM chain the token knows where its T-REX Lite is: at its own address. On another kind of chain no such default exists. The Issuer registers the peer as an interoperable address of that chain. The token checks that the address is well-formed and that it belongs to the chain it is registered for. The chain becomes open when it has a route, a trusted gateway and a registered peer. ### Wallets are linked from their own chain An identity lives on the reference chain. A wallet on a non-EVM chain is linked to it by proving control where it lives: the wallet sends a link proposal from its own chain, through a gateway the identity layer trusts for that chain, and the identity accepts it on the reference chain. See [Wallet linking and the global identity registry](/identity-onchainid/wallet-linking-and-the-global-identity-registry.md). Once linked, the wallet is an address of the identity like any other. Its eligibility is the identity's eligibility. Nothing has to be verified again for that chain. ### Addresses must be canonical The register keys every satellite wallet by the hash of its interoperable address. For that to identify a wallet, a wallet must have exactly one encoding. The protocol accepts only the canonical form and refuses any other, so the same wallet can never appear under two keys. Whoever builds for a non-EVM satellite uses the exact interoperable address of each wallet everywhere: when linking it, when requesting a validation, and in the reports that T-REX Lite sends. ### The message format has to be spoken Protocol messages have one format, defined on the reference chain: an envelope with a type and a version, and a body whose structure depends on the type. An EVM implementation of T-REX Lite reads it natively. An implementation on another kind of chain decodes the validations and instructions it receives and encodes the settlement notifications and burn proofs it sends, in that same format. ## What a chain needs to host T-REX Lite A chain can be a satellite if it can do four things. | Capability | Used for | | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Hold balances of a token per account | The positions active on that chain | | Store an authorization and check a transfer against it: parties, amount range, deadline, single use | Executing only what the reference chain authorized | | Receive authenticated messages from the reference chain and from the asset's T-REX Lite on other satellites, and send messages to both | Validations, instructions and proofs of burn in. Settlements and proofs out | | Create and destroy token balances under the control of the implementation | Delegation-out, recall, transfers between chains | It does not need to run arbitrary logic, read identities or evaluate rules. ## What does not extend to non-EVM chains * **The reference chain's contracts.** Identities, registries, eligibility and the compliance rules live on the reference chain only. Nothing of them is deployed on a satellite, EVM or not. The compliance contract linked to T-REX Lite holds no rule: it stores the validations it received. * **The same address on every chain.** That property comes from deterministic deployment on EVM chains. On other chains, an asset and an identity's wallets have addresses in that chain's format. * **Signature-based wallet linking.** It proves control of an address on the reference chain and of nothing else. * **The EAS adapter.** It resolves attestations made to the identity itself or to a wallet on its own chain. --- # 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/non-evm-satellites.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.