> 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/the-primary-register/technical-finality-and-legal-finality.md). # Technical finality and legal finality In a register that spans several chains, "final" means two different things. Keeping them apart removes most of the confusion about cross-chain transfers of regulated assets. * **Technical finality** is a property of a chain. A transaction is final when the chain it ran on will not revert it. Every chain provides this for its own transactions, and only for them. T-REX does not provide it for any other chain. * **Legal finality** is a property of the legal register of the asset. A transfer of ownership is legally final when that register records it, under the law that governs the asset. The protocol connects the two through its register on the reference chain. A transfer executed on a satellite is technically final there first. It is recorded as a change of ownership when it reaches the register on the reference chain. * Where that register is the legal register of the asset, which is what T-REX is designed for, the record on the reference chain is the moment of legal finality. * Where the legal register is kept off-chain, it replicates the register on the reference chain, and legal finality follows the rules of that legal register. In both cases one thing holds: an execution on a satellite is never, by itself, the record of a change of ownership. The two configurations are described in [From digital twin to primary register](/the-primary-register/from-digital-twin-to-primary-register.md). ## On the reference chain, execution and record coincide A transfer on the reference chain changes the register in the transaction that executes it. There is no second step. When that transaction is final on the reference chain, the change of ownership is recorded. Where the register is the legal record of the asset, the transfer is legally final at that point. How fast the reference chain finalizes its own transactions depends on the chain that hosts the T-REX Ledger. Nothing in the protocol depends on it. ## On a satellite, there is a gap A transfer on a satellite is authorized on the reference chain, executed on the satellite and then settled back to the reference chain. Between execution and settlement, the satellite and the register hold different views. ```mermaid sequenceDiagram participant S as Sender participant MC as Register on the reference chain participant L as T-REX Lite on the satellite S->>MC: request a validation MC->>MC: gates pass, movement reserved MC-->>L: validation delivered S->>L: transfer L->>L: validation consumed, balances move Note over L: technically final when the satellite finalizes rect rgba(128, 128, 128, 0.15) Note over MC,L: the gap: executed on the satellite, not yet recorded on the register L-->>MC: settlement notification end MC->>MC: ownership moves, reservation released Note over MC: ownership recorded ``` | Moment | On the satellite | On the register | | ----------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Validation issued** | Nothing has happened. | The movement is reserved: it counts as executed, at its maximum amount, for every distribution rule. Ownership has not moved. Status `Pending`. | | **Transfer executed** | T-REX Lite balances change. The transaction is final when that chain finalizes it. | Nothing changes until the settlement notification arrives. The sender's identity is still the recorded owner. | | **Settlement recorded** | No change. | Ownership moves from the sender's identity to the recipient's. The reservation is released. Status `Settled`. | ## Why the gap never holds a non-compliant state The register does not learn about a satellite transfer after the fact and then judge it. It decides first. * **Compliance is a precondition.** Both gates run on the reference chain, against the global position set, before the validation exists. T-REX Lite executes only against a validation. * **The validation is exact and single-use.** It names the sender, the recipient, an optional spender, an amount range, the asset and an expiry. It is consumed by the execution and cannot be used twice. * **The reservation protects the rules under concurrency.** From issuance, the movement counts as executed at its maximum amount. Two validations competing for the last room under a cap cannot both be issued. * **The settlement is checked against what was issued.** The register accepts a settlement only for the asset, the wallets and the chain of the validation, and only for an amount inside its range. * **Unsettled tokens cannot move onward.** Any onward movement needs a new validation, and a validation is capped at the position the register records for the sending wallet. A recipient cannot transfer on a satellite what the register has not yet recorded as its own. During the gap, the register shows the truth of the record: the sender's identity still owns the position, and the pending amounts are visible through `pendingOutOf` and `pendingInOf`. ## When settlement is late, or never comes A validation carries two deadlines. The satellite enforces the first. The reference chain applies the second. | Deadline | Meaning | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `expiry` | The satellite executes strictly before it. | | `releaseAt` | `expiry` plus the reconciliation window of the chain. Before it, the register keeps the reservation. After it, the reservation may be released. | The reconciliation window is set per satellite chain. It covers that chain's worst-case time to finalize and to deliver its notification. A transfer executed just before `expiry` therefore settles before the reference chain gives up on it. A genuine execution never races a rollback. What happens next depends on what arrives. | Situation | What the register does | Status | | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | The settlement arrives, at any time before a discard | Records the change of ownership and releases the reservation. | `Settled` | | Nothing has arrived by `releaseAt` | Nothing on its own. The status reads as expired. A rollback is never automatic. | `Expired` | | The Validation Keeper discards an expired validation | Releases the reservation. Issuance continues as if the validation had never existed. | `Discarded` | | A settlement arrives after the discard | Applies it anyway and signals it with `LateReconciliation`. If the executed amount now breaches a rule, the register pauses the issuance of validations for that chain until the `COMPLIANCE_MANAGER` lifts the pause. | `LateReconciled` | | A settlement arrives twice, or for a validation that was never issued | Applies nothing. The token pauses itself until an agent has investigated. | Unchanged | The principle behind the fourth row: the register records what happened. A late settlement reports an execution that is already final on its chain. Refusing it would make the register wrong. The register records it, and contains the consequence by stopping further issuance for that chain when a rule is breached. ### Transfers between two satellites A transfer from one satellite to another has two executions: a burn on the sender's chain and a mint on the recipient's chain. Each sends its own settlement, a leg, under the same validation. * When the burn leg arrives first, the register takes the amount out of the sender's wallet position and holds it in transit. The sender's identity still owns it. Status `AwaitingMint`. * When the mint leg arrives first, nothing moves yet. Status `AwaitingBurn`. * When the second leg arrives, the register applies the pair: ownership moves, once. Status `Settled`. A validation with one leg received is never discarded, because one satellite has already executed its half. If the other leg never arrives, the Validation Keeper resolves it after a second reconciliation window: an amount held in transit returns to the wallet it was burned from, and the status becomes `Resolved`. If it was the mint leg that arrived, there is nothing to return on the reference chain, and the chain that owes the burn is paused for issuance. ## Movements that do not change ownership Delegation-out and recall move a position between the reference chain and a satellite. The owner is the same identity before and after, so there is no transfer of ownership to finalize. * **Delegation-out** is final on the reference chain at the instant it executes: the position moves from free to bridged, and the instruction to mint on the satellite is one-way. A delayed mint is a delay on that chain. It is never an inconsistency in the register. * **Recall** waits. The reference chain converts the position from bridged back to free only when it has received the proof that the satellite burned it. Acting earlier would leave the position live on two chains. ## What each participant relies on | Participant | Relies on | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Recipient on a satellite** | The tokens are usable on that chain once the transfer is final there. Ownership is recorded when the validation is `Settled`, which anyone reads with `statusOf(validationId)`. | | **Venue on a satellite** | A trade executes only against a validation, so eligibility and compliance are certain at execution. The record of ownership follows at settlement. | | **Issuer, transfer agent, regulator** | The register on the reference chain. It is the complete record of ownership at every moment, and the record that any legal register kept off-chain follows. | | **Application running a corporate action** | Positions as the register records them. A movement that is still pending belongs to the sender until it is settled. | --- # 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/the-primary-register/technical-finality-and-legal-finality.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.