Cross-chain: the distributed register
A register that aspires to be the book of record of a security cannot confine the asset to one chain. Investors, venues and applications live on many chains, and an asset has to reach them. But reaching many chains must not split the register into partial registers that no longer know the complete distribution of the asset, because the rules that govern a security are functions of that distribution.
The cross-chain architecture of T-REX resolves this tension. An asset is active on many chains, and one register knows who owns what on all of them.
The design rests on three ideas.
One chain decides. The reference chain, the T-REX Ledger, holds the identities, the rules and the complete record of ownership, including the positions that are active elsewhere.
The others execute. Each satellite chain runs T-REX Lite, which holds balances and executes only the transfers the reference chain has authorized.
Authorization comes first. Compliance is a precondition established on the reference chain before a satellite acts, not a reconciliation performed afterward.
The two kinds of chain, what lives on each, how they are connected, and how an asset is opened on a satellite.
The token on a satellite: what it holds, what it does not, and the obligations it has toward the register.
The validation object: what it contains, how it is requested, how its amount is decided, and what issuing it writes.
The states of a validation from issuance to settlement, expiry, discard, late reconciliation and the emergencies.
Transfer, delegation-out and recall: which change ownership, and how each completes.
The three elements of messaging, the two levels of trust, and what the token checks when it sends and receives.
Chainlink as the default transport, how another provider is connected, how an Issuer chooses, and what happens when a provider fails.
What is the same and what differs on a satellite that is not an EVM chain.
Last updated