> 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/from-digital-twin-to-primary-register.md).

# From digital twin to primary register

A security is only as trustworthy as its register. This page describes the problem the protocol is built to solve, why the first generation of tokenized securities did not solve it, what changes when the on-chain record leads, and how that record relates to the legal register of an asset.

## The reconciliation problem

In conventional markets, the register of a security is maintained by a central securities depository and a chain of intermediaries: custodians, transfer agents, sub-registrars. Each keeps its own books. Each reconciles them with the others, continuously.

Reconciliation is not a flaw in this system. It is the system. No single party holds an authoritative, real-time view of who owns what, so every party checks its copy against everyone else's. Most of the cost, the latency and the operational risk of post-trade processing come from there.

## What the digital twin added

The first generation of tokenized securities deployed a token as a digital twin of an off-chain cap table. The record stays with the transfer agent, and the token mirrors it. The off-chain book leads and the token follows.

This adds a ledger. It does not remove one. The on-chain ledger has to be reconciled against the off-chain record like any other book. The blockchain is useful for distribution and settlement and authoritative for nothing. When the two disagree, the off-chain record wins, and someone reconciles them.

## The inversion

T-REX is designed for the opposite relationship: the on-chain record leads. A transfer happens on-chain, under the rules of the asset, and everything else follows from it. The protocol is built so that the contract can be the register itself, the primary record of ownership, with off-chain systems such as reporting, tax, investor servicing and regulatory filing consuming it.

```mermaid
flowchart TB
    subgraph TWIN["Digital twin: the off-chain book leads"]
        direction LR
        A1["Off-chain register"] -->|"mirrored to"| A2["Token"]
        A2 -.->|"reconciled against"| A1
    end
    subgraph TREX["T-REX: the on-chain record leads"]
        direction LR
        B1["Token on the reference chain<br/>complete, enforced record"] -->|"read or replicated by"| B2["Off-chain systems and registers"]
        B1 -->|"authorizes"| B3["Satellite chains"]
        B3 -->|"settle back to"| B1
    end
```

|                                     | Digital twin                                                          | T-REX                                                                                                         |
| ----------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Which record leads**              | The off-chain book. The token is updated to match it.                 | The on-chain record. Off-chain records are derived from it.                                                   |
| **The token is**                    | A representation of a position recorded elsewhere                     | The position, as recorded and enforced on-chain                                                               |
| **Compliance**                      | Checked off-chain, or detected after the fact and unwound             | Evaluated before the transfer is recorded. A non-compliant transfer is not recorded.                          |
| **More than one chain**             | One mirror per chain. No mirror sees the others.                      | One register that records the positions of every chain                                                        |
| **Servicing and corporate actions** | Run from the off-chain record                                         | Run against the on-chain record                                                                               |
| **Reconciliation**                  | Between two books that both move, continuously, by people and systems | None between books that both move. Executions on satellites are settled back to the register by the protocol. |

## Primary register, or alongside a legal register

T-REX is designed to be the primary register of an asset, and it is capable of being the sole legal record of ownership. Whether it is, for a given asset, is not decided by the protocol. It depends on the jurisdiction, on the type of asset and on the rules that apply to the Issuer. Some legal frameworks accept an on-chain register as the register of a security. Others require the legal register to be kept by a designated party or in a designated form.

The protocol serves both configurations. The contracts are the same in both and do not know which one an asset uses.

|                                | T-REX as the primary register                  | T-REX alongside an off-chain legal register                                             |
| ------------------------------ | ---------------------------------------------- | --------------------------------------------------------------------------------------- |
| **Legal record of ownership**  | The on-chain register                          | A register kept off-chain, as the applicable rules require                              |
| **Which record leads**         | The on-chain register                          | The on-chain register. The off-chain register replicates what happens on T-REX.         |
| **How the two relate**         | Off-chain systems read the register            | Each on-chain event is carried into the off-chain register                              |
| **Eligibility and compliance** | Enforced on-chain, before every transfer       | The same                                                                                |
| **View across chains**         | One register for every chain the asset reaches | The same                                                                                |
| **Reconciliation**             | None between books                             | One-directional. The off-chain register follows the chain. It does not move on its own. |

In the second configuration the token is, in legal terms, a mirror: the legal record sits off-chain. It is still not the first-generation digital twin, because the direction is reversed. Transfers do not originate in an off-chain book and get copied to a token. They happen on T-REX, under enforced rules, and the off-chain register records them.

Some changes originate outside the chain in either configuration: a court order, a succession, the correction of an error. The Token Agent applies them on-chain with the servicing operations of the register (forced transfer, recovery, mint, burn), so the on-chain record and the legal position stay identical.

Which configuration an asset uses is the Issuer's decision, set out in the asset's legal documentation and under the law that governs it. These docs describe the protocol, which is the same in both. Where they say "the register", they mean the on-chain record on the reference chain.

## What follows from the inversion

If the on-chain record leads, five things have to be true. Each one shapes a part of the protocol.

**1. The register refuses what it may not record.** A register cannot hold an entry that should not exist and clean it up later. Every change of ownership passes an eligibility gate and a compliance gate before the balance moves. An ineligible holding never comes into existence. See [Eligibility and compliance: the two gates](/the-primary-register/eligibility-and-compliance-the-two-gates.md).

**2. The register knows holders, not only addresses.** Rules about a security are rules about persons and institutions: who may hold, how many holders, how much each. The register attributes every address to an identity, an ONCHAINID. The identity is a smart account that holds tokens itself, and any number of wallets can be linked to it. Two addresses of one identity are one holder.

**3. The register sees the whole distribution.** Many rules depend on the total distribution of the asset, not on one transfer. One reference chain records every position, including the positions that are active on other chains. See [The register as an on-chain CSD](/the-primary-register/the-register-as-an-on-chain-csd.md).

**4. The register can be serviced.** A register of securities supports issuance and redemption, freezes, transfers ordered by an authority, recovery of a lost position, and the corporate actions of the asset. These are role-gated operations executed directly against the on-chain record.

**5. The register lasts.** The assets it records outlive many versions of the software. The protocol is assembled from open standards, governed through one access model, and upgradeable without storage risk. See [Standards foundation](/start-here/standards-foundation.md).

## What the register is not

* **Not a copy that waits for an off-chain book.** No off-chain system has to write first for a transfer to happen. Where an off-chain legal register exists, it follows the chain.
* **Not a wallet allowlist.** Eligibility is evaluated on the identity behind an address, from claims signed by Claim Issuers, at the moment of each transfer.
* **Not a store of personal data.** What sits on-chain is a signed claim about an identity. The personal data behind the claim stays off-chain with the Claim Issuer.
* **Not bound to one chain.** The golden copy is on one chain. The asset circulates on many.


---

# 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/from-digital-twin-to-primary-register.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.