J4. Cross-chain journey: distribute and reconcile
This journey follows an asset and one of its holders across chains. It involves two personas: the Issuer, which opens the asset on a satellite, and the Investor, which takes its position there, transfers it and brings it back. It starts with an asset that lives on the reference chain only. It ends when positions have moved on satellites and the register on the reference chain has recorded every change of ownership. Throughout, the reference chain holds the complete register: a satellite executes only what the reference chain authorized.
Stages
1
Open the asset on a satellite
Issuer
The token and its T-REX Lite on that chain can exchange messages, and the compliance can authorize transfers there
2
Take a position to the satellite
Investor
The Investor's own wallet on the satellite holds the position. Ownership is unchanged
3
Transfer on the satellite
Investor
The transfer is authorized on the reference chain, executed on the satellite and recorded on the register
4
Transfer to another satellite
Investor
The position leaves one satellite and arrives on another, under one authorization
5
Bring a position back
Investor, or a Token Agent
The position is free again on the reference chain, for the same owner
6
Release what did not execute
Validation Keeper
Reservations of transfers that never settled are given back
7
Respond to an alarm
Issuer
The cause is established and the register is brought in line
Overview
What the persona sees and does
1. Open the asset on a satellite. A token opens no chain by default. The Issuer decides on which chains its asset is distributed, and opens each one: it chooses the route its messages take, among the gateways Network governance trusts, sets the time windows that govern validations, and has T-REX Lite deployed on the satellite. It grants the keeper role to the keeper that the T-REX Network runs. Nothing on the satellite needs its own eligibility or compliance configuration: those stay on the reference chain.
2. Take a position to the satellite. The Investor holds a position on the reference chain and wants to use it on a satellite. It links its wallet of that chain to its identity, then delegates part of its free balance out to that wallet. The register still records the Investor as the owner of the same tokens, now marked as bridged to that wallet, and T-REX Lite creates the matching balance on the satellite. Ownership did not change, so this is not a transfer.
3. Transfer on the satellite. To send tokens to another holder on the satellite, the Investor first asks the reference chain, through its identity, to authorize the transfer. The compliance checks the recipient's eligibility and the rules of the asset against the complete register, reserves the amount and sends a validation to the satellite. The Investor then makes an ordinary ERC-20 transfer on T-REX Lite, which executes only against that validation. The satellite reports the execution, and the register records the change of ownership. A transfer the rules refuse is never authorized, so it never executes.
4. Transfer to another satellite. The same request can name a recipient on another satellite. The reference chain authorizes once. The sending chain burns and sends a proof of the burn to the receiving chain, which mints. Each chain reports its own half, and the register records the change of ownership when both reports have arrived.
5. Bring a position back. The Investor recalls its position from the satellite: T-REX Lite burns it and sends the proof, and the position becomes free again on the reference chain. An agent of the asset orders a recall when it has to act on a position that is active on a satellite, since freezes, burns and forced transfers happen on the reference chain.
6. Release what did not execute. A validation reserves room on the register from the moment it is issued. When the Investor never executes the transfer, or one of two satellites never reports, the reservation has to be given back. The Validation Keeper, run by the T-REX Network under a role the Issuer grants, discards expired validations and resolves the stuck ones. The Investor sees its reserved amount become available again.
7. Respond to an alarm. Three events call for the Issuer: a settlement that arrives after its validation was discarded, a transfer between two satellites resolved with one report missing, and a settlement the register cannot account for, on which the token pauses itself. What executed on a satellite is final, so the register is brought in line with it and the Issuer resolves any breach of its rules afterward.
Where journeys diverge
The recipient is on a satellite and the sender is on the reference chain. A one-step path exists for it, and for a mint by an agent directly to a satellite wallet: see Movement types.
The recipient of a transfer on a satellite is on the reference chain. The same flow as stage 3 settles to an address of the reference chain: 31.
The satellite is not an EVM chain. The Issuer registers the peer explicitly: Non-EVM satellites.
The Issuer wants another messaging provider. It sets another route for that chain, among the trusted gateways: Messaging providers.
A satellite is compromised. The response is in Emergency behavior.
Related journeys
J1 Issuer journey: launch an asset : the asset before it is opened on a satellite
J2 Investor journey: from onboarding to secondary transfer : how the Investor came to hold a position
J3 Transfer agent journey: operations on a live asset : what agents do on the reference chain