T3RRA
For Regulators & Supervisors

Open standards. Continuous supervision. Sovereign authority.

L3RS-1 brings tokenized real-world assets into the supervisory perimeter through protocol-level compliance, identity attestation, and Travel Rule continuity — with the regulator's authority intact.

If you sit on the digital-assets policy desk of a central bank running a tokenization sandbox, the regulated-tokenization unit of a securities regulator reviewing tokenized real-world-asset frameworks, or the supervisory function coordinating Travel Rule and AML enforcement on cross-border digital instruments — this document is written for you. The objective is to explain what L3RS-1 is, what its operator T3RRA does, and how the architecture is designed to preserve and amplify the supervisory authority that already exists in the jurisdictions where these instruments are issued, held, and traded.

For most regulators and supervisory authorities, the institutional concern with tokenization is not novelty — it is perimeter. Conventional tokenization platforms operate compliance as vendor policy. A token may carry transfer restrictions on one chain but lose them on another. Identity may be verified by the platform but not directly by the regulator. Travel Rule data may be retained inside a vendor database where supervisory access depends on the operator's continued cooperation, jurisdictional standing, and operational continuity. The supervisory perimeter, in such designs, depends on the continued operation, jurisdiction, and good faith of a single private operator — a structural fragility that no settled capital-markets infrastructure has ever been built to tolerate.

Compliance is a protocol property — not a vendor promise.

L3RS-1 is an open Layer-3 Regulatory Settlement Standard. It is owned and governed by the L3RS Foundation, a separately constituted body. T3RRA is the operator of one certified implementation. Other certified implementations are in production with other operators. Compliance rules, transfer permissions, identity attestations, and lifecycle behavior live in on-chain contracts — the ComplianceModule, the PolicyRegistry, and the IdentityAttestation registry — that execute deterministically, that are inspectable by any party including the supervisor, and that are designed so operator actions are constrained by the published policy configuration and auditable by authorized supervisory parties.

The architecture was deployed inside the Bank of England's CBDC sandbox in 2020 and has been refined across six years of production deployment in AgriDex, Fiat-on-Chain, and Cleverjet before publication as an open standard in February 2026.

T3RRA does not seek to substitute for regulation. T3RRA seeks to make regulation enforceable at the protocol level — with the supervisory authority of every jurisdiction in which a Built-on-L3RS-1 instrument is issued, held, or transferred remaining undiminished by the architecture.

L3RS-1 is designed to be supervised — not to escape supervision.

Zurab Ashvil · Founder · T3RRA Ltd

To Regulators & Supervisors

What you retain. What the standard provides.

Designed for central banks, securities regulators, supervisory authorities, and financial intelligence units evaluating tokenization architectures for permissioned operation, sandbox admission, or supervisory integration within their jurisdictions.

The regulator's authority is not diminished by the architecture. The standard is the means by which that authority is exercised on tokenized instruments.

You Retain

Jurisdictional authority

Which instruments may be issued, by whom, to whom, under what terms, and which transfers are permitted — remain determinations of the regulator, not the operator. L3RS-1 implements the rules; it does not write them.

You Retain

Enforcement authority

Licensing, examination, sanction, freeze, recall, and revocation powers remain with the supervisor. ComplianceModule configurations can be modified to give effect to a regulator's order through documented governance procedures.

The Standard Provides

Open architecture

A foundation-governed rulebook, owned by no single company, available to any certified operator. The architecture is published, the test vectors are public, and the conformance criteria are auditable. No vendor capture, no captive standard.

The Standard Provides

Protocol-level compliance

Identity attestation, transfer permissions, jurisdictional eligibility, and Travel Rule data execute deterministically in on-chain contracts. Compliance is enforced at the protocol layer, where bypass attempts become visible, rule-based, and subject to deterministic rejection under the configured policy.

What Supervision Means Here

L3RS-1 does not ask supervisors to trust the operator. It makes the architecture inspectable, the compliance enforceable, and the lifecycle auditable — on-chain.

Visibility · What Supervisors See

Every transfer, every identity attestation, every compliance gate, every jurisdictional check — written to chain, addressable by any party with the cryptographic right to read it. No vendor database between the regulator and the transaction.

Action · What Supervisors Can Do

Freeze, recall, sanction, and revocation powers can be implemented through ComplianceModule configuration under documented governance. The supervisor acts through the standard, not around it.

The supervisor is not the user of a vendor's reporting product. The supervisor is the party in whose interest the protocol was architected.

Why regulators engage.

Beyond the mechanism, the public-interest case for engaging with L3RS-1 rests on five structural properties that conventional tokenization architectures do not deliver in combination — and one institutional clarification of what the standard does not preempt.

The Five-Point Public-Interest Case
01

Tokenization brought into the supervisory perimeter

Instruments issued under L3RS-1 carry on-chain identity attestation, jurisdictional eligibility, and Travel Rule data at the protocol level. The instruments are designed to remain inside the supervisory perimeter through identity attestation, jurisdictional eligibility, Travel Rule continuity, and protocol-level transfer controls.

02

Compliance enforced at the protocol layer

Identity, transfer permissions, sanctions screening, and jurisdictional rules execute deterministically in on-chain contracts. Policy updates are not discretionary operator edits — they are governed changes linked to legal authority, documented procedures, auditable logs, and jurisdiction-specific permissions.

03

Cross-border Travel Rule continuity

FATF Recommendation 16 originator and beneficiary data is bound to the instrument at the protocol layer and travels with every transfer across every chain. The Travel Rule does not lose continuity when an instrument crosses a chain boundary, a custodian boundary, or a jurisdictional boundary.

04

Open governance, no vendor capture

L3RS-1 is owned by the L3RS Foundation, not by T3RRA or any other operator. Multiple certified operators run the standard in production. The architecture is published; the test vectors are public; the conformance criteria are auditable. No regulator is asked to depend on the continued operation, jurisdiction, or commercial choices of a single private firm.

05

Coordination across jurisdictions

Identity attestations carry their issuing-jurisdiction credentials with them. Where two supervisors agree on equivalence, an attestation issued in one jurisdiction may be honored in the other — reducing duplicative onboarding without diluting either authority. Where they do not agree, the protocol enforces the more restrictive rule.

What L3RS-1 Does Not Preempt

L3RS-1 does not preempt the licensing, supervisory, examination, sanction, or enforcement authority of any regulator. It does not displace existing securities, banking, AML, sanctions, tax, or consumer-protection law. The standard is the mechanism for exercising regulatory authority on tokenized instruments — not a replacement for it.

What Supervisors Gain

Continuous on-chain visibility into the instruments under their authority. Cryptographically verifiable compliance state. Deterministic enforcement of transfer rules. Reduced reliance on operator self-reporting and on vendor database integrity. Coordination instruments for cross-border supervision built into the protocol.

Architectural models.

Tokenization architectures considered by central banks and supervisors today reflect different design choices about where compliance lives, who owns the standard, and what authority the supervisor must delegate. The institutional question is not which deployment is largest. It is what each architectural model would mean for the supervisor: where compliance is enforced, who owns the standard, and whether the supervisory perimeter remains intact across the life of the activity. For regulators, the core question is structural: whether compliance is a protocol property the architecture is designed to enforce, or a vendor policy that depends on the continued operation, jurisdiction, and good faith of a single private firm.

The Architectural Landscape

Token standards on a public chain

Open token specifications deployed on a public chain by individual platforms. Compliance is implemented per deployment.

The supervisor depends on each platform's policy enforcement, not on a unified protocol-level guarantee across deployments.

Bank consortium networks

Permissioned networks operated jointly by a group of regulated banks. Compliance is implemented as consortium policy.

The supervisor depends on the consortium's collective governance and the network's continued operation as a permissioned environment.

Single-operator chains

Public or private blockchain networks operated by a single private firm, often alongside that firm's own products. Compliance is implemented on the operator's chain.

The supervisor depends on the operator's continued operation, jurisdictional standing, and commercial choices.

Regulated platforms

Tokenization platforms operated by a single regulated vendor under that vendor's commercial offering. Compliance is implemented as platform policy.

The supervisor depends on the vendor's database integrity, jurisdiction, and operational continuity.

Open supervisory standards · L3RS-1

A foundation-governed open standard with multiple certified operators. Compliance is implemented as a protocol property, enforced on-chain.

The supervisor depends on the architecture and the Foundation's governance, not on any single operator's commercial fortunes or jurisdictional position.

The Pattern

Each conventional model places compliance in a vendor's product, a single firm's chain, a consortium's network, or platform-specific deployments of a token standard. L3RS-1 is structured differently: compliance is enforced at the protocol layer, the standard is owned by a foundation, and multiple certified operators run the architecture in production. That is the difference between supervising a vendor and supervising a market.

How regulatory engagement works.

Engagement with L3RS-1 is structured as a supervisory architecture review and a permissioned operational pilot — not as a commercial procurement. The standard is open. The Foundation is the standards body. T3RRA is one certified operator. The objective of engagement is supervisory effectiveness; the deliverable is a regulator capable of supervising tokenized real-world-asset activity within its own jurisdiction at the same standard it applies to conventional capital-markets activity.

01

Architecture briefing

Closed working session. The standard's structure, the Foundation's governance, the operator separation, and the supervisory access model are reviewed in detail.

02

Sandbox / pilot

A supervised tokenization pilot is conducted within the regulator's jurisdiction. ComplianceModule and IdentityAttestation contracts are configured for the supervisor's requirements.

03

Supervisory integration

The supervisor's reporting, monitoring, and enforcement workflows are integrated with the on-chain data layer. Read access, alerting, and policy-modification procedures are established.

04

Framework recognition

The regulator publishes guidance, equivalence, or formal recognition of L3RS-1 Built-on attestation for instruments under its jurisdiction.

What The Supervisor Receives
Read-access model

Cryptographic access to relevant on-chain supervisory data for instruments under the regulator's jurisdiction. Direct addressable access; no vendor database as the sole source of supervisory truth.

Policy configuration pack

Documented eligibility, sanctions, transfer, freeze, recall, and revocation procedures. Policy updates are governed changes linked to legal authority and jurisdiction-specific permissions — not discretionary operator edits.

Audit & conformance pack

Test vectors, compliance-state proofs, implementation documentation, and operator certification records. Conformance criteria are auditable by independent third parties.

Reporting integration

Alerting, event logs, lifecycle reports, and supervisory exception workflows configurable to the regulator's reporting framework.

Legal mapping

Instrument-level mapping to applicable securities, AML, sanctions, Travel Rule, custody, and consumer-protection requirements.

Worked Example · Central-Bank Sandbox

A central bank running a permissioned tokenization sandbox with on-chain supervisory access.

The central bank admits selected issuers to a permissioned sandbox under its own jurisdictional authority. ComplianceModule is configured to enforce the regulator's eligibility rules; identity attestations follow the regulator's approved KYC framework; Travel Rule data is bound to every transfer.

Rules & Eligibility

Regulator

Identity Framework

Regulator

Protocol & Enforcement

L3RS-1

Supervisory Authority

Regulator

The regulator writes the rules. L3RS-1 enforces them at the protocol layer. Authority and enforcement do not separate.

If T3RRA the operator fails.

L3RS-1 is the standard. T3RRA is one operator of one certified implementation. The standard is owned and stewarded by the L3RS Foundation, a separately constituted body, and is published in the open. The on-chain configuration of any instrument issued under the standard — the ComplianceModule, the PolicyRegistry, the IdentityAttestation registry — lives on chain and is designed to continue operating independently of T3RRA's day-to-day operational status, subject to the governing legal documents, the smart-contract configuration, and applicable regulatory requirements.

Supervisory authority is preserved by design. If T3RRA the operator were to fail, the supervisor's legal authority over instruments under its jurisdiction is not intended to depend on T3RRA's operational continuity. Certified Built-on-L3RS-1 technologies are already in production with operators other than T3RRA, and the standard is designed to permit migration to an alternative certified operator without rebuilding the standard, subject to the governing legal documents, the smart-contract configuration, and applicable regulatory requirements. The L3RS Foundation continues regardless of any single operator's status — the standard is the institutional asset; the operator is the implementation.

The First Ninety Days
Days 01–10

Architecture review

Founder-led briefing for the regulator's policy and supervisory teams. The standard, the Foundation's governance, the operator separation, and the supervisory access model are reviewed in detail. Closed session.

Days 10–30

Sandbox proposal

A bespoke proposal for a supervised pilot within the regulator's jurisdiction: scope, eligibility rules, ComplianceModule configuration, supervisory access framework, and reporting integration. Delivered as a working document for the regulator's counsel and technology team.

Days 30–90

Pilot live

Engagement live. ComplianceModule configured for the regulator's eligibility rules. Identity attestations issued under the regulator's approved KYC framework. First instrument issued and supervised. Lifecycle reporting begins.

L3RS-1 gives regulators and supervisors a tokenization standard with protocol-level compliance enforcement, foundation-governed standards, and continuous on-chain visibility — without delegating sovereign authority to any private operator.
To Begin A Supervisory Engagement
Zurab Ashvil

Zurab Ashvil

Founder & Chief Executive Officer, T3RRA Ltd

Original author of L3RS-1 · PhD Cybernetics & Applied Mathematics, Tbilisi State University, 1992 · Founder of TICEX (Tbilisi Interbank Currency Exchange), Georgia's first interbank FX market.

policy@t3rra.co · t3rra.co/regulators · 5 Stratford Place, London W1C 1AX

Active In Execution · May 2026

Why this is real.

An active 2026 mandate pipeline exceeding USD 2 billion in aggregate notional across real estate, infrastructure, private credit, and shipping issuers.

Central-bank-level regulatory dialogue active in Georgia, with the T3RRA strategic brief — sixteen iterations — under formal partner-level review at an international Tier 1 law firm.

Phase One reference implementation engaged with an international Tier 1 auditor for formal audit. Self-audit complete across four toolchains.

Financial Institutions Professional Indemnity cover in place with Relm Ins UK Ltd, an FCA-regulated specialty insurer (on behalf of Bridgehaven Specialty UK Ltd) — worldwide territorial scope, English law.

L3RS Foundation governance live, with three certified Built-on-L3RS-1 technologies in production: T3RRA, Fiat-on-Chain, Aurum.