> 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/security-and-trust-model/trust-assumptions.md). # Trust assumptions No system that records securities is trustless. Somebody decides who is eligible, somebody can freeze a position, somebody can change the code. What a protocol can do is make each of those powers explicit, give it to a named role, bound what it can do, and leave a trace when it is used. This page lists every party the protocol trusts, what for, and what limits that trust. The design follows one principle: trust is concentrated on the reference chain, where it can be seen and governed, and it is minimized everywhere else. ## Who is trusted for what ### The Issuer and its operators | Party | Trusted for | Bounded by | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **The holder of `ADMIN_ROLE` on a suite's manager** | Everything about the suite: which role gates which function, and who holds each role. | Nothing on-chain beyond the delays the Issuer configures. It is the root of the Issuer's authority. | | **`OWNER`** | The eligibility requirements and the compliance rules of the asset. | Changes are public and take effect for every holder at once. It cannot replace the compliance or the registry of a circulating token. | | **Agents** | Minting, burning, freezing, forced transfers, recovery, the pause. | Each power is a separate role. A mint and a forced transfer require an eligible recipient. A mint is subject to the rules. Every use emits an event. | | **Registry Agent** | Attributing an address to an identity for the asset. | It cannot make an identity eligible, and it cannot reinstate a wallet its owner revoked. | | **Validation Keeper**, run by the T-REX Network under the `VALIDATION_KEEPER` role the Issuer grants | Liveness: discarding expired validations and resolving stuck ones. | It discards only what is past its release time, and resolves only a transfer still missing a report a full second window later. It cannot assign a position to another identity. | The Issuer is trusted with its own asset and with nothing else. Roles are scoped to a domain, so no role of one Issuer reaches another Issuer's suite. ### Claim Issuers | Party | Trusted for | Bounded by | | ----------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **A Claim Issuer trusted by an asset** | The truth of what it attests about an identity, and revoking when it is no longer true. | Trusted per asset and per topic, by that asset's Issuer. It answers only for claims it signed itself. | | **A Claim Issuer with standing in the network** | Writing its own claims onto identities without a key grant. | The claim must be valid and attributed to itself. It gains no eligibility for any asset. The owner can remove the claim. | Eligibility is as sound as the Claim Issuers an Issuer chooses. This is the one place where facts from outside the chain enter the register. ### Network governance | Party | Trusted for | Bounded by | | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **`VERSION_MANAGER`** | The code of every shared suite: token, registry, storage, compliance, access manager. | A version upgrade is voted by Network governance and executes after a delay. Upgrades only move forward, and a version is published before it is activated. An Issuer avoids this trust with an isolated suite. | | **`INTEROP_MANAGER`** | Which gateways are sound enough to attest who sent a message. | It adds and removes gateways. It does not route any asset. Each Issuer chooses its routes. | | **Platform `OWNER`** | The references of the `TREXFactory`: which implementation authority, identity factory and trusted gateway registry every new suite is wired to. | Held by Network governance. It changes nothing in a suite that is already deployed. | | **Holders of `ASSET_DEPLOYER`**: the Issuers and tokenization providers granted access, and the `TREXFactory` | Deploying suites and creating the identity of a token, and so claiming an asset's address across chains. | Granted by Network governance. The role gates the deployment of an asset only: no authority over the factory, and none over a suite once deployed. | | **The roles that administer the identity layer** | The policy and the modules of each identity type, the trusted gateways and verifiers for wallet linking. | They cannot act on an existing identity. Identities are governed by their own keys. | | **Beacon upgrader of identities** | The code of every ONCHAINID. | A delay before an upgrade takes effect. The new implementation must name the same factory and the same key registry. | | **`REPUTATION_MANAGER`** | Which Claim Issuers can write claims without a grant. | It does not decide eligibility for any asset. | | **The governance of shared components** | The shared compliance modules, the attestation adapters and the gateway adapters that Issuers rely on. | An Issuer chooses which of them it binds, trusts or routes through. | These roles live in one access manager, the network's. Each governance role is held by a different multisig, with its own members and its own threshold, so no single group holds all of them. `ASSET_DEPLOYER` is the exception: it is held by each party that deploys suites. ### Cross-chain | Party | Trusted for | Bounded by | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A vetted gateway and the provider behind it** | Authenticity: a delivered message was sent by the account the gateway names. Delivery. This is the trust assumption of the interoperability solution itself: while it works as designed, no issue arises. | A settlement must match an issued validation: asset, wallets, chain, gateway, amount range, once. No message changes the supply. A message the register cannot account for halts the token. The network can remove a gateway at once. | | **T-REX Lite on a satellite** | Executing only against a validation, once, and reporting what it executed. | It decides nothing. A wallet obtains a validation only up to the position the register records for it. | | **A satellite chain** | Finalizing its own transactions within the assumed latency. | A per-chain reconciliation window, set conservatively. Beyond it, a settlement is applied late, flagged, and can pause issuance for that chain. | Satellites are not trusted for compliance. That is the point of the architecture. ### Identity | Party | Trusted for | Bounded by | | ------------------------------------------------------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------- | | **The Identity Owner** | Its own keys. | It controls its identity, its claims and its wallets, and nothing of any asset. | | **Guardians** | Restoring control of an identity whose keys are lost. | A threshold, a delay during which the owner can cancel, and an expiry. | | **Network governance, for a shared EAS adapter, and the attesters it accepts** | Which external attestations count as claims. | Only for the assets that list that adapter as a trusted issuer. | ### Modules and dependencies | Party | Trusted for | Bounded by | | ---------------------------------------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **The authority of a compliance module** | The code of that rule, for every compliance that binds it. | An Issuer chooses which modules it binds, and can deploy its own instance. A faulty module can always be removed. | | **The reference chain itself** | Ordering and finalizing the transactions of the register. | The properties of the chain that hosts the T-REX Ledger. The protocol adds none and assumes none beyond those. | | **OpenZeppelin Contracts** | The implementations of the standards the protocol is assembled from. | Open source, widely reviewed, pinned to a version. | ## What is not trusted * **Holders.** A holder cannot move tokens to an ineligible recipient, past a rule, or twice. * **Spenders.** A third party executes a transfer only within an allowance, and only if the asset's spender policy accepts it. * **Satellites, for anything about eligibility or rules.** * **A compliance module, for the availability of the asset.** A module that reverts can be removed without its cooperation. * **A Claim Issuer, for another issuer's claims.** * **The party that pays for an identity's deployment.** It holds no key on the identity it deployed. * **The factory, after deployment.** It keeps no role on a suite. ## Residual risks, stated Some risks are bounded and not removed. They are identified here and not left implicit. | Risk | Bound | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | A settlement arrives after the reconciliation window and after its validation was discarded. | It is applied, flagged, and pauses issuance for the chain if it breaches a rule. The window is governed configuration, set conservatively. | | A satellite exceeds its assumed worst-case latency. | The same. Governing the windows is part of the Issuer's and the network's responsibility. | | A trusted gateway attributes a message falsely. This depends on the trust assumptions of the interoperability solution behind it, and does not happen while that solution works as designed. | The matching checks, the halt on anomalies, and immediate removal from the registry. | | The signing domain of identities is changed by an upgrade. | It is kept constant by rule. Every stored claim is verified against it. | | The holders of the upgrade roles act maliciously or are compromised. | Delays, forward-only versions, isolated suites, and the governance of who holds the roles. | ## Governance is part of the model Privileged power across the protocol is expressed as roles in an access manager. That gives one auditable account of who can do what, and lets each role be held by whatever arrangement a deployment requires: an institution's process, a multisig, an automated system. The contracts do not decide who should hold the roles of the network, nor by what process they act. That is a question of governance, which the network answers, and it is as much a part of the security of the system as the code. --- # 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/security-and-trust-model/trust-assumptions.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.