> 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/the-register-as-an-on-chain-csd.md). # The register as an on-chain CSD In the vocabulary of market infrastructure, T-REX performs the role of a central securities depository (CSD), implemented as a set of smart contracts rather than as an institution. This page maps the functions of a depository to the contracts that perform them, and explains why a register has to be global to enforce the rules of a security. > **A functional comparison.** The comparison describes what the contracts do. It is not a statement about regulatory status, and it does not mean that the on-chain register is the legal register of every asset. Whether an arrangement built on the protocol is a depository, a register or a transfer-agent system in law depends on the jurisdiction and on how the Issuer and its service providers set it up. Where the legal register is kept off-chain, it replicates this one. See [From digital twin to primary register](/the-primary-register/from-digital-twin-to-primary-register.md). ## What the register does | Function of a depository | How the protocol performs it | Where | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | | **Keep the complete record of ownership** | The token records every position: free, frozen and bridged. The compliance keeps the total position of each identity, over all its addresses and all chains. | `Token`, `ModularCompliance` | | **Know the holders** | Every holder is an ONCHAINID carrying claims signed by Claim Issuers. Every holding address resolves to one identity. | `IdentityFactory`, `TREXRegistry` | | **Admit only eligible holders** | Eligibility is checked on the recipient's identity before a position is credited. | `TREXRegistry` | | **Enforce the terms of the offering** | Rules are compliance modules, evaluated at the moment of transfer against the complete distribution of the asset. | `ModularCompliance`, compliance modules | | **Settle** | On the reference chain, the transfer is the settlement: the record changes in the transaction that transfers. For an execution on a satellite, the register records the change of ownership when the execution is settled back. | `Token`, `ModularCompliance` | | **Give one real-time view** | Issuers, transfer agents, regulators and applications read the register directly: balances, positions, supply, events. No other book moves independently of it. | Read functions and events | | **Service the asset** | Issuance, redemption, freezes, transfers ordered by an authority, recovery of a lost position, halts. Each is a role-gated operation executed against the on-chain record. | `Token`, roles in the `TREXAccessManager` | | **Support corporate actions** | Distributions, votes and redemptions are run by applications that read the register. The register gives them each identity's total position, so an action reaches a holder's whole position wherever it is active. | `ModularCompliance.positionOf(identity)`, applications | ## Compliance by construction In a conventional chain of intermediaries, a transfer that breaches a rule is detected by a control, then reversed. On T-REX there is nothing to reverse. A transfer that would breach a rule does not fail an external check. It is a transfer the register does not record. This is a stronger guarantee than monitoring. There is no window in which a non-compliant state exists and has to be caught and unwound. ## Why the register has to be global Many of the rules that govern a security are functions of its total distribution, not of a single transaction: * a cap on the number of investors in a country; * a ceiling on what one investor may hold; * a restriction on the jurisdictions into which the asset may circulate. A rule of this kind can only be enforced by a system that knows the complete distribution of the asset at the moment it decides. A mirror deployed on one chain cannot enforce it, because it does not know what is happening on the other chains. A primary register can, because the positions of the other chains are recorded on it. ### An example An Issuer caps the holding of any single investor at 1,000 units, with the `MaxBalancePerIdentityModule`. One investor holds the asset in three places. | Where | Amount | How the register sees it | | ---------------------------------------- | ------ | ------------------------------------------------- | | In its ONCHAINID, on the reference chain | 600 | Free balance of the identity's own address | | In a linked wallet on satellite A | 300 | Bridged position, recorded on the reference chain | | In a linked wallet on satellite B | 0 | No position | A seller on satellite B wants to transfer 200 units to the investor's wallet on that chain. * **A token that sees only satellite B** finds a recipient holding nothing and lets 200 through. The investor ends at 1,100, above the cap. * **The register** reads the position of the identity: 900. The rule allows 100 more. The validation is issued for at most 100, or refused if the seller asked for a minimum above 100. The same holds under concurrency. If two sellers each request a validation for 100 units to that investor at the same time, the first validation reserves its 100 against the investor's identity as soon as it is issued. The second request finds no room left and is refused. Neither transfer has executed yet, and the cap already holds. ## Who does what around the register | In conventional infrastructure | In T-REX | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Central securities depository | The protocol on the reference chain: `Token`, `TREXRegistry`, `ModularCompliance` | | Issuer | The Issuer: configures eligibility and rules, holds the admin role of its token suite | | Transfer agent, registrar | Token Agent and Registry Agent: role-gated operations on the register | | KYC, AML and accreditation providers | Claim Issuers: sign claims on identities | | Custodian | Operates addresses that hold positions, under the same gates as any holder. A custody account is recorded under the identity it belongs to: linked by that identity, or registered for the asset by the Issuer's agent when the account cannot link itself. An omnibus wallet is recorded under the identity of the entity that operates it. That entity is the holder on the register | | Trading venues | Venues and applications: eligible participants, on the reference chain or on a satellite | | Reconciliation between books | None between books that move independently. Executions on satellites are settled back to the register by the protocol. A legal register kept off-chain, where one is required, replicates the on-chain register. | | Regulator, auditor | Reads the register directly | Actor names are defined in [Actors and roles](/start-here/actors-and-roles.md). ## What the register does not do * **It does not verify investors.** Claim Issuers do, off-chain, and sign the result. The register checks the claims. * **It does not write the rules.** The Issuer chooses the claim topics, the trusted Claim Issuers and the compliance modules of its asset. * **It does not hold personal data.** Claims are signed attestations. The data behind them stays with the Claim Issuer. * **It does not finalize transactions on other chains.** Each chain finalizes its own transactions. The register records the resulting change of ownership. See [Technical finality and legal finality](/the-primary-register/technical-finality-and-legal-finality.md). --- # 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/the-register-as-an-on-chain-csd.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.