> 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/guides/journeys/j4.-cross-chain-journey-distribute-and-reconcile.md).

# 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

| # | Stage                            | Flow                                                                                                               | Who acts                   | Outcome                                                                                                            |
| - | -------------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| 1 | Open the asset on a satellite    | [33 Open an asset on a satellite](/guides/cross-chain/33.-open-an-asset-on-a-satellite.md)                         | 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 | [30 Delegate a position out to a satellite](/guides/cross-chain/30.-delegate-a-position-out-to-a-satellite.md)     | Investor                   | The Investor's own wallet on the satellite holds the position. Ownership is unchanged                              |
| 3 | Transfer on the satellite        | [31 Transfer on a satellite](/guides/cross-chain/31.-transfer-on-a-satellite.md)                                   | Investor                   | The transfer is authorized on the reference chain, executed on the satellite and recorded on the register          |
| 4 | Transfer to another satellite    | [34 Transfer between two satellites](/guides/cross-chain/34.-transfer-between-two-satellites.md)                   | Investor                   | The position leaves one satellite and arrives on another, under one authorization                                  |
| 5 | Bring a position back            | [32 Recall a position to the reference chain](/guides/cross-chain/32.-recall-a-position-to-the-reference-chain.md) | Investor, or a Token Agent | The position is free again on the reference chain, for the same owner                                              |
| 6 | Release what did not execute     | [35 Discard or resolve a validation](/guides/cross-chain/35.-discard-or-resolve-a-validation.md)                   | Validation Keeper          | Reservations of transfers that never settled are given back                                                        |
| 7 | Respond to an alarm              | [36 Handle a late reconciliation or a halt](/guides/cross-chain/36.-handle-a-late-reconciliation-or-a-halt.md)     | Issuer                     | The cause is established and the register is brought in line                                                       |

## Overview

```mermaid
flowchart LR
    S1["1. Open a satellite<br/>33"] --> S2["2. Delegate out<br/>30"]
    S2 --> S3["3. Transfer on the satellite<br/>31"]
    S3 -.-> S4["4. Transfer to another satellite<br/>34"]
    S3 --> S5["5. Recall<br/>32"]
    S4 -.-> S5
    S3 -.-> S6["6. Discard or resolve<br/>35"]
    S4 -.-> S6
    S6 -.-> S7["7. Alarm<br/>36"]
```

## 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](/cross-chain-the-distributed-register/movement-types.md).
* **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](/guides/cross-chain/31.-transfer-on-a-satellite.md).
* **The satellite is not an EVM chain.** The Issuer registers the peer explicitly: [Non-EVM satellites](/cross-chain-the-distributed-register/non-evm-satellites.md).
* **The Issuer wants another messaging provider.** It sets another route for that chain, among the trusted gateways: [Messaging providers](/cross-chain-the-distributed-register/messaging-providers.md).
* **A satellite is compromised.** The response is in [Emergency behavior](/security-and-trust-model/emergency-behavior.md).

## Related journeys

* [J1 Issuer journey: launch an asset](/guides/journeys/j1.-issuer-journey-launch-an-asset.md) : the asset before it is opened on a satellite
* [J2 Investor journey: from onboarding to secondary transfer](/guides/journeys/j2.-investor-journey-from-onboarding-to-secondary-transfer.md) : how the Investor came to hold a position
* [J3 Transfer agent journey: operations on a live asset](/guides/journeys/j3.-transfer-agent-journey-operations-on-a-live-asset.md) : what agents do on the reference 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/guides/journeys/j4.-cross-chain-journey-distribute-and-reconcile.md?ask=<question>&goal=<user_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.