> 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/audits-and-verification.md). # Audits and verification This page lists how the code of the protocol is verified: independent audits, the test suites in each repository, the formal specifications, and mutation testing. It also says what each of them covers and what it does not, and how to report a vulnerability. ## Audits | Component | Version | Auditor | Report | | --------- | ------- | ----------------- | -------------------------------------------------------------------- | | ONCHAINID | 3.0.0 | OpenZeppelin | [ONCHAINID Audit](https://www.openzeppelin.com/news/onchainid-audit) | | T-REX | 5.0.0 | Audit in progress | Linked here when it is published | ### ONCHAINID 3.0.0 | | | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Auditor** | OpenZeppelin | | **Period** | 27 July to 7 August 2026 | | **Report published** | 29 September 2026 | | **Audited commit** | `d2096509` | | **Fixes merged at** | `4fda205` | | **Findings** | 39 issues, 36 resolved. 1 critical, resolved. 2 high, resolved. 9 medium, 7 resolved. 20 low, 19 resolved. 7 notes, resolved. | **In scope:** the identity account (`Identity`, `SmartAccount`, `KeyManager`), the `IdentityFactory`, the validator and executor modules, the `EASClaimIssuer`, the `ReputationRegistry`, `IdentityUtilities` and its proxy, the interfaces and the libraries. **Out of scope:** * The deployment script and the access policy it configures. The contracts authenticate a caller against a role. Which accounts hold each role is a deployment decision. * The recovery logic. `RecoveryModule` was reviewed as an integration wrapper. The social recovery executor it inherits from OpenZeppelin was not reviewed in this audit. * Tests and third-party dependencies. **Findings not marked as resolved in the report.** The report gives the detail and the team's response for each. | Finding | Status | What it means for a deployment | | -------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Claim digests are computed from the issuer's current signing domain | Acknowledged | The signing domain of identities must never change in an upgrade. Every stored claim is verified against it. The protocol treats it as a constant. | | The cross-chain confirmation of a wallet link applied fewer checks than the local path | See the report | Wallet links from other chains rely on a gateway that Network governance trusts for the origin chain. | | A module that needs one operation on the identity holds the `MANAGEMENT` purpose over every target | See the report | A recovery module installed on an identity has full management authority once a recovery executes. Guardians are chosen accordingly. | The report describes the code at the audited commit. Several behaviors it describes were changed by the fixes. These docs describe the code after the fixes. ### T-REX 5.0.0 The audit of T-REX 5 is in progress, on the code of the `develop` branch. The report is linked here when it is published, with its scope, its commit and its findings. Until then, treat the T-REX 5 contracts as not yet audited. `[[TBC: auditor, period, audited commit and report link of the T-REX 5 audit]]` ## Test suites Both repositories are tested with Foundry. ### T-REX | Suite | What it covers | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Unit** | Each contract and library in isolation: access, compliance, messaging, registries, token, proxies. | | **Integration** | A complete suite wired as in production: deployment through the factory, eligibility, compliance modules, the bridged ledger, validations, settlement, late reconciliation, stuck validations, route changes. | | **Standard** | The ERC-3643 surface alone, against the standard base contracts, without any T-REX extension. It pins the behavior of the standard layer independently. | | **Fuzz** | Randomized inputs on the token, the bridged ledger, the amounts a rule allows, authorization, address derivation and interoperable-address parsing. | | **Invariant** | Stateful fuzzing: random sequences of operations, with the invariants checked after each one. | The invariant suites assert the following. The identifiers on the right are those of [Invariants](/security-and-trust-model/invariants.md). | Invariant in the test suite | In these docs | | -------------------------------------------------------------------------------------------------- | ------------- | | The supply equals what was minted less what was burned | S1 | | The balances add up to the native supply | S2 | | Frozen never exceeds the balance | S3 | | The compliance stays bound to its token | G6 | | No transfer succeeds while paused | G3 | | No transfer lands on an unverified recipient | G1 | | The supply is conserved across free, frozen, bridged and in transit, and the token holds no escrow | S4, S6 | | The bridged total equals the positions plus the amounts in transit | S5 | | A position equals what the identity's addresses hold | L1 | | Positions add up to the supply, and the gap is zero when no agent touches the registry | L2, L3 | | Pending amounts equal the open validations | L4 | | A wallet's reservation equals its open validations | L5 | The ledger suite exercises mints, burns, transfers, forced transfers, the issuance of validations to another identity, to the same identity and to the reference chain, settlement in time and late, the keeper's discard, and an investor revoking a wallet. ### ONCHAINID | Area | What it covers | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Account** | Module installation, execution paths, the per-target authorization rule, the proxy. | | **Keys and claims** | The key registry, the claim registry, signature verification for every signer type, WebAuthn. | | **Factory** | Identity types and policies, creation by the account and for another account, wallet linking on the reference chain and from other chains, revocation, the beacon. | | **Modules** | The execution queue, recovery. | | **Claim issuers, reputation, utilities** | The EAS adapter, the reputation registry, the topic schema registry. | | **Regression** | Tests that reproduce findings of the audit and assert the fixed behavior. | ## Formal specifications The T-REX repository contains specifications written for the Certora prover, for three contracts. A specification states a property for all inputs, where a test samples some. | Contract | Properties specified | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Token` | A mint and a burn change the supply and the balance by exactly the amount. A transfer leaves the supply unchanged. Frozen never exceeds the balance. A freeze beyond the balance and an unfreeze beyond the frozen amount revert. A transfer reverts while paused, from or to a frozen address, and beyond the free balance. Every privileged function reverts for a caller the authority denies. | | `ModularCompliance` | The set of modules is bounded at 25. Only the bound token can notify a transfer, a mint or a burn. Every privileged function reverts for an unauthorized caller. | | Identity registry | When eligibility checks are disabled, every address is verified. The switch cannot be disabled twice nor enabled twice. Every privileged function reverts for an unauthorized caller. | \[\[TBC: results of the prover run for these specifications]] The specifications model calls into other contracts permissively and the access manager with no execution delay. The properties that span several contracts, such as the two gates holding end to end, are covered by the invariant suites. ## Mutation testing The T-REX repository is set up for mutation testing with Gambit. Mutation testing changes the code in small ways, one at a time, and runs the test suite against each change. A change that no test catches points to a gap in the tests. \[\[TBC: mutation score and date of the last run]] ## Reproducing the verification | To | Run | | ------------------------------------- | -------------------------------------------------------------- | | Build | `forge build` | | Run the tests | `forge test` | | Measure coverage | `npm run coverage` | | Run the formal specifications (T-REX) | `npm run verify`, with access to the Certora prover | | Run the mutation tests (T-REX) | `npm run test:mutation:generate`, then `npm run test:mutation` | ## Verifying a deployment An audit covers code. A deployment adds configuration, and the configuration is on-chain and readable. | Check | Read | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Which code a suite runs | `TREXImplementationAuthority.currentVersion()` and `implementations()`, or the suite's own beacons for an isolated suite | | Which code identities run | `Identity.version()`, and the implementation behind the factory's beacon | | Who can do what on a suite | The roles in its access manager. See [Access management: roles and domains](/governance-and-infrastructure/access-management-roles-and-domains.md). | | Which gateways are trusted | `TrustedGatewayRegistry.isTrusted(gateway)` | | Which rules an asset applies | `ModularCompliance.getModules()` | | Whom an asset trusts for claims | `TREXRegistry.getTrustedIssuers()` and `getClaimTopics()` | ## Reporting a vulnerability Send a report to `security@trex.network`. Do not open a public issue for a security finding. There is no bug bounty program. --- # 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/audits-and-verification.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.