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.

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.

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.