Docs/t rex networkNew

Compliance Engine

Compliance, control, and security at every level of the stack. Includes OnchainID and AssetID.

Compliance, control, and security at every level of the stack.

What is the Compliance Engine?

The Compliance Engine is the model that makes T-REX Network safe enough for regulated financial assets while keeping it open enough to be a real public blockchain. It is not a single component. It is the defense-in-depth framework that runs continuously across every layer of the network — from individual smart contracts at the bottom to Ethereum settlement at the top.

The principle is simple: no single layer is asked to carry the full weight of compliance. Each layer adds its own check, its own control, its own form of accountability. Together they form an institutional-grade compliance posture without giving up the openness, auditability, and resilience that public blockchains provide.

The result is infrastructure that financial institutions can integrate without compromising on regulatory requirements, while remaining a public, auditable, standards-based chain — not a permissioned silo.

Five layers of compliance and control

1. Token protocol — compliance by design

At the foundation: ERC-3643, the open standard for permissioned tokens. Compliance is encoded directly in the token contracts. Every transfer is validated at the protocol level before it can execute:

  • Identity check — both sender and receiver must hold valid, claim-attested OnchainIDs (see below).
  • Eligibility rules — investor status, jurisdiction, accreditation, lockup periods, and other transfer restrictions are enforced by the contract itself.
  • Operational controls — issuers and transfer agents retain freeze, force-transfer, recovery, and rule-update capabilities for regulatory and operational needs.

If a transfer doesn't meet the rules, the protocol rejects it. This is the first and most fundamental line of defense: the asset itself refuses non-compliant operations.

The protocol-level enforcement relies on two foundational primitives — OnchainID for the identities involved, and AssetID for the assets themselves. Both are described below.

OnchainID — identities for every participant

OnchainID is the decentralized identity framework underpinning compliance on T-REX Network. It gives every participant in the ecosystem — investors, issuers, transfer agents, distributors, regulators, and increasingly AI agents acting as market participants — a verifiable, on-chain identity to which claims can be attached.

Key properties:

  • Identities are smart contracts, not wallet addresses. A single OnchainID can be linked to multiple wallets; compliance follows the identity, not the address.
  • Claims are attestations issued by trusted parties (KYC providers, accredited investor verifiers, regulators) and stored as references and hashes on the identity contract. The contract does not store personally identifiable information directly — PII remains off-chain, only verifiable attestations are on-chain.
  • Claims are revocable: if an investor's accreditation expires or jurisdiction changes, the claim issuer can revoke the attestation, and the compliance state updates accordingly.
  • The same identity model extends to AI agents as the network supports autonomous workflows. AI agents acting on regulated assets operate under verifiable, governable on-chain identities — not anonymous keys.

Without a valid OnchainID with the required claims, a wallet cannot receive or transfer ERC-3643 tokens that require those claims. Identity is the gate; the protocol is the enforcer.

OnchainID is built on the open standards ERC-734 and ERC-735 (for keys and claims) and is part of the broader ERC-3643 specification maintained by the ERC-3643 Association. For the technical details, see the protocol documentation at erc3643docs.erc3643.org.

To manage OnchainIDs in practice, see the T-REX | Identity dApp on the AppStore.

AssetID — identities for the assets themselves

If OnchainID identifies the participants, AssetID identifies the assets. Every token deployed through the T-REX Protocol receives an AssetID by default — a verifiable on-chain identity for the asset itself.

AssetID can carry signed, attested credentials such as:

  • Legal identifiers — the issuer's Legal Entity Identifier (LEI), the financial instrument's International Securities Identification Number (ISIN), the Digital Token Identifier (DTI).
  • Asset data — Net Asset Value, pricing references, ratings.
  • Legal documents — offering memorandums, fund prospectuses, terms and conditions.
  • Certifications and attestations — audit reports, regulatory approvals, third-party verifications.

Any of this data can be signed and attested by the issuer or by authorized third parties — auditors, regulators, transfer agents — ensuring authenticity without requiring trust in any single intermediary.

AssetID makes tokens self-describing and self-attesting assets, not opaque on-chain instruments. For distributors, custodians, regulators, and counterparties, it is the answer to "what exactly is this token, who issued it, and what does it represent?" — verifiable cryptographically rather than through external documentation chains.

Like OnchainID, AssetID is managed through the T-REX | Identity dApp for hands-on operations, and is part of the open ERC-3643 specification.

Why identity-as-compliance matters

The combination of OnchainID and AssetID is what makes ERC-3643 fundamentally different from generic token standards:

  • Compliance follows the verified identity, not the wallet. Lost a wallet? The investor's identity is intact, and recovery is supported by the protocol.
  • Identity is portable across chains and venues. The same OnchainID works wherever the protocol is deployed.
  • Identity is revocable. Compliance state can update in real time as eligibility changes.
  • Assets are verifiable. AssetID makes the difference between "this token claims to represent X" and "this token's representation of X is cryptographically signed by Y."

This is the foundation on which the next four layers of the Compliance Engine build.

2. Vetted AppStore applications

Every application listed on the T-REX AppStore — official or third-party — is reviewed before being made available. Vetting covers:

  • Technical compatibility with ERC-3643 and the wider T-REX stack.
  • Security review of smart contracts and integrations.
  • Compliance alignment with the ecosystem's identity and rule model.
  • Operational integrity of the provider behind the application.

Institutions interacting with the AppStore are not exposed to unreviewed tooling. The catalogue itself is a compliance and risk-management filter — and the contractual relationship for each application remains transparent between the provider and the end user. See T-REX AppStore.

3. Institutional validator consortium

The T-REX Ledger is operated by a Proof-of-Authority consortium of institutional validators: regulated, reputable entities co-signing and attesting to the canonical state of the network.

This is the layer that gives the chain the governance and accountability that regulated finance requires. Validators are known entities under operational oversight, not anonymous block producers. They provide:

  • Governance accountability — clear, attributable responsibility for network operations.
  • Regulatory confidence — institutions and regulators interact with named, audited operators.
  • Controlled evolution — protocol upgrades, parameter changes, and validator admission are governed transparently.

See T-REX Ledger for the governance model.

4. Distributed network of nodes

Above the validator layer, a distributed network of institutional node operators — broker-dealers, asset servicers, infrastructure partners, and other ecosystem participants — runs infrastructure at the network's edge. This layer provides:

  • Operational resilience — many independent operators rather than a handful of centralized providers.
  • Real-time policy enforcement — transactions can be screened against threat intelligence and risk rules at the RPC level before reaching the sequencer, allowing operators to enforce their own policies in addition to the protocol-level rules.
  • Distribution reach — each operator serves its own institutional client base, extending the network's reach without centralizing it.
  • Specialized integration — operators can offer differentiated services on top of a shared, neutral infrastructure.

The result is a network that scales horizontally and remains operationally resilient: no single operator is critical to the system's integrity, and each one contributes additional monitoring and control surface area.

5. Ethereum — settlement security & decentralization

At the top: Ethereum. The T-REX Ledger anchors its state to Ethereum Layer 1, inheriting the most decentralized, proven, and economically secured settlement layer in existence. State roots are periodically posted to Ethereum, giving the network:

  • Settlement assurance that no consortium of institutional validators could override unilaterally.
  • Independent auditability — anyone can verify the network's state against Ethereum.
  • A public, neutral bedrock — the chain is not owned by any institution. Even the validator consortium is bounded by Ethereum's guarantees.

This is what keeps T-REX a public chain rather than a private network with a marketing layer.

Real-time threat detection and policy enforcement

In addition to the structural layers above, T-REX Network integrates real-time security infrastructure that operates continuously across the stack:

  • Threat detection — proactive monitoring for exploits, anomalous patterns, and emerging on-chain risks.
  • Transaction policy enforcement — the ability to evaluate and act on transactions at the RPC and sequencer level before they are included on-chain.
  • Pre-execution risk screening — flagged transactions can be blocked or escalated before they affect the canonical state.

This adds a continuously updating, intelligence-driven dimension to the structural compliance layers — protecting institutional assets against threats that purely rules-based systems cannot anticipate.

Selective privacy where it matters

Compliance and confidentiality are not opposites. Public verifiability is essential for some flows; selective privacy is essential for others.

T-REX Network includes an optional privacy layer based on Fully Homomorphic Encryption (FHE), allowing sensitive amounts, balances, or positions to remain encrypted while still being processed by smart contracts — and while compliance rules continue to be enforced on the encrypted data.

Privacy is opt-in, not the default. Issuers and applications enable it where the use case warrants:

  • Institutional flows where transaction volumes or positions would be commercially sensitive.
  • Tranche-level confidentiality for specific investor classes.
  • Internal flows where transparency would leak market strategy.
  • Regulatory contexts where privacy is mandated by law or contract.

Authorized parties — counterparties, auditors, regulators — can decrypt the relevant data under controlled access mechanisms. Compliance does not depend on full public disclosure.

See T-REX Ledger — Privacy & Confidentiality for the full architecture.

Why this matters

The model is unusual in tokenization infrastructure today. Most projects make a binary choice: either a permissioned private chain optimized for institutional control, or a permissionless public chain with no native compliance posture. Both leave institutions with hard problems.

T-REX Network's answer is to put multiple layers of audited, accountable controls on top of a fundamentally public, decentralized, Ethereum-anchored base. The result is infrastructure that:

  • Satisfies the compliance, control, and security requirements of regulated finance.
  • Preserves the openness, auditability, and resilience of public blockchain infrastructure.
  • Avoids vendor lock-in and single points of failure at every layer.
  • Scales horizontally as more institutional participants join the network.

Audited. Serious players. Still a public chain.