TL;DR
- On today’s token standards, a regulator’s freeze and a court’s confiscation come down to the same on-chain call. ERC-TRUST records the legal effect of the six regulatory actions (their reversibility and ownership effect) as distinct, typed, first-class objects that an auditor or a regulator can actually point to.
- It also closes the regulatory dynamics within a declared domain (reversal, terminality, rejection, custody), leaves typed authorizations and canonical receipts with provenance, and requires an evidence chain that runs from the abstract model down to deployed bytecode. That last axis is absent from existing Final ERCs.
- The form is an ERC-7943 conformance extension over an ERC-20 base. The public machine surface is kept minimal and precise so any third implementer can reproduce and verify it, and the weight of the design lives in the depth of the conformance and evidence stack beneath it.
- The reference trust model is an immutable minimal kernel with versioned, fail-closed adapters. ERC-3643 is an optional interoperability profile, and Diamond, a full standalone suite, and wrapper-first were considered and set aside with reasons.
- The normative design is frozen. A Solidity implementation, TRUST-specific formal verification, and third-party audits are later stages, and this article does not claim any of them as done.
On the token standards deployed today, a regulator-ordered freeze (temporary, reversible, ownership preserved) and a court-ordered confiscation (permanent, irreversible, ownership transferred) come down to the same contract call. ERC-7943’s forcedTransfer and ERC-3643’s forced transfer move the asset, but say nothing about whether the move can be undone or where ownership goes. Two legally opposite acts are indistinguishable anywhere on-chain, in any form a standard, an auditor, or a regulator could cite.
Making that distinction legible on-chain is where the ERC-TRUST enforceability architecture begins. Where the Regulatory Compliance Protocol (RCP), proposed as ERC-8319, defined the legal effect of the six regulatory actions as a vocabulary, ERC-TRUST carries that meaning into a token’s execution: each action’s legal effect becomes typed state and observable outcome, tied by evidence all the way to what is deployed. RCP settled the “what”; this ERC-7943 conformance extension fills in the “how” as normative rules and conformance.
The name states what the standard is for. ERC-TRUST stands for Typed Regulatory Uniformity for Security Tokens: a comprehensive and adaptable execution standard for regulatory actions on security tokens. The words map onto the design directly: actions are typed so each carries a distinct legal effect, uniformity is the guarantee that independent implementations reproduce the same result, and the standard stays adaptable because policy lives in versioned adapters while the action semantics stay fixed.
What follows sets out what the design newly creates, where the standard’s boundary and form sit, how it fits with existing systems, and, in one place, what can be claimed today and what remains ahead.
The moment a reversible freeze and an irreversible confiscation are seen to collapse into one generic call.
What This Design Newly Creates On-Chain
Start with what this actually adds. The layers existing ERCs already provide, ERC-20 balances and ERC-7943’s permission views and freeze and forced-transfer primitives, are reused as they are. On top of them, this ERC-7943 conformance extension builds four things.
First, actions with distinct legal effect. The six regulatory actions (FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER) become first-class objects with different values and different observability. Reversibility and ownership effect are bound to each, so a freeze and a confiscation can never collapse into the same thing. Inferring which regulatory act a bare forcedTransfer(from, to, amount) represents does not satisfy conformance. This is the core capability of the design.
Second, closed regulatory dynamics. Within a declared state and action domain, success, rejection, order effects, reversal, terminality, and custody are closed into one coherent model. What follows a FREEZE, and the fact that a CONFISCATE has no exit, are fixed by stated rules rather than argued in prose. “Closed” here means mathematical completeness within the declared scope, not completeness across every jurisdiction’s law, and that bounded completeness is the strength of the model.
Third, auditable typed authorization and receipts. Every regulatory action runs as a typed record bound to domain, subject, authority, policy, and provenance, with scoped delegation, replay protection, and a canonical receipt that links action, authority, policy, and pre/post observation. An indexer reads that receipt instead of guessing the regulatory act from a generic event.
Fourth, model-to-deployment assurance. Connecting the abstract model, concrete verification, and deployment artifacts into a single evidence ladder is a design obligation. Normative statements descend to state, authority, and observation, and are then traced through Solidity and bytecode to the deployed artifact. Existing Final ERCs do not require this model-to-deployment evidence, and it is the fourth axis ERC-TRUST purely adds.
These four are the net increment over what ERC-20, ERC-7943, and ERC-3643 already provide. If the standard only re-described the existence of freeze, allowlist, or forced transfer, there would be nothing to add. What it adds is not a count of features but the distinction of legal effect, the closure of regulatory dynamics, and evidence that the meaning survives all the way to deployment.
Figure 1: Six regulatory actions mapped to typed observables, separated from reversal labels, with the three-way outcome model
The six regulatory actions are the product-facing command set, and they do not map one-to-one onto the composition model’s seven transition labels (FREEZE, UNFREEZE, SEIZE, RELEASE, CONFISCATE, RESTRICT, UNRESTRICT). UNFREEZE, RELEASE, and UNRESTRICT are reversal commands, not RCP action identities, and RECOVER and LIQUIDATE belong to the transfer and settlement layer. Treating the six and the seven as the same would break the very distinction the standard promises, so keeping them apart is central to the norm. Outcomes split cleanly into three: Applied (exactly one canonical transition, with the nonce and action consumed; here Applied means the declared code-level state effect took hold, not legal or economic completion), Rejected (an authorization, transition, or policy precondition denied), and OperationalFailure (a contract-detectable module outage, revert, or version mismatch). The three are disjoint, and on rejection or failure the observable state is preserved.
A margin note separating the six actions from the seven transition labels, and fixing the outcomes as three disjoint cases.
The Standard’s Boundary and Form
How much of this capability belongs in the standard is set by a dual-use rule. The normative surface carries only what Oraclizer’s full-enforcement product actually uses and what independent issuers, tokens, adapters, and indexers also need in order to coordinate; product-only conveniences stay in the product layer. So Oraclizer’s evidence-only and policy-precheck modes work without this standard, and when Oraclizer claims full on-chain enforcement of the six actions or conformance to it, that path must terminate at a single standard endpoint, a native token or a verified profile adapter. This is where the standard’s neutrality and the product’s core enforcement claim are bound to the same evidence chain.
Keeping the public machine surface minimal and precise is a deliberate strength, not a limitation. The smaller and more precise the surface, the easier it is for a third implementer to reproduce the same actions, rejections, and receipts, and the easier that surface is to verify mechanically. The real weight of the standard comes not from the size of the surface but from the depth of the conformance vectors and model-to-deployment evidence beneath it. If only one internal product ever read these receipts, a library would be enough; a public standard is needed precisely because independent implementers must reproduce the same meaning, and this precise surface is what makes that reproduction possible.
Figure 2: A minimal, precise normative surface over a deep conformance and evidence stack, with external truth and the reused base outside it
An ERC-7943 conformance extension, by design
The form is an independently numbered ERC-7943 conformance extension. It is a standalone ERC with its own number, Specification, Security Considerations, and conformance surface, and it does not redefine ERC-20 or ERC-7943; on top of them it adds only RCP action identity, regulatory dynamics, typed authorization, receipts and provenance, and a verifiable conformance boundary. Following EIP-1, it stays a single focused proposal and uses requires only where another EIP’s concept is needed to understand or implement it. What it references is the base token and the meaning of the regulatory actions, not their code, so this ERC-7943 conformance extension relates to RCP by reference, not by inheritance or import.
The reference implementation’s trust model is an immutable minimal kernel with versioned, fail-closed policy and identity adapters. Action semantics, case transitions, authorization consumption, and receipt emission sit inside the immutable kernel and stay fixed while the deployed code stands; policy and identity are separated into read-only adapters. Because regulatory policy changes with jurisdiction and time while the legal meaning of the six actions and the receipt structure must hold, a policy change swaps a versioned module rather than touching the kernel, and that separation keeps a policy change from invalidating the kernel’s proofs.
The standard does not mandate an implementation architecture, so a proxy deployment can be conformant if it proves its conditions, but the reference default excludes proxies to keep that proof burden off the default path. Diamond (ERC-2535) adds selector routing, facets, cut authority, storage-namespace collisions, and delegatecall targets on top of a small surface, so its cost is out of proportion and it was set aside; inheriting ERC-3643’s GPL implementation and a wrapper-first approach were set aside as well, for licensing-and-surface and custody-and-bypass reasons. These are earlier-exploration options, not premises of the current design. One boundary is held fixed: the legal meaning and distinguishability of the six actions is the standard’s identity, so no architecture may erase or merge them into something unobservable.
Figure 3: Standard-form and reference-architecture candidates with their verdicts
Compatibility and Interoperability, in Three Questions
Two words are worth separating first. Compatibility means this extension implements ERC-7943’s interface directly, so existing integrators interact through the same calls. Interoperability means an ERC-3643 token is left in place and this extension binds to its authority model. The two behave differently, so three questions make the practical picture clear.
Do existing ERC-20 and ERC-7943 systems keep working without knowing about this standard? Yes. Because it sits on top of the base, the base token’s balances and transfers and ERC-7943’s permission views work as before for wallets and protocols that never heard of it. The reverse is not automatic: an already-deployed immutable ERC-7943 token does not start supporting this standard on its own. Native conformance holds for newly deployed or upgradeable tokens, and existing tokens join through the profile paths below.
Can a token, adapter, or indexer that does know this standard reproduce the same capability and results? Making that reproducible is the reason for a public standard, and the core of its value. A conforming implementation represents each supported action as a distinct, separately observable operation, and lets its per-action capability be queried mechanically. Because the same action record is the shared input to the authorization hash and the receipt hash, different implementations leave the same rejections, terminality, and receipts for the same typed action. Unsupported actions are declared false or unsupported rather than faked by a name that always reverts.
How does an ERC-3643 environment attach as an optional profile? ERC-3643 is not a required dependency; it is an optional profile that leaves the token in place and binds in order of smallest bypass surface. A Compliance binding provides ordinary-transfer eligibility and policy precheck, but not full enforcement on its own, because in ERC-3643 a forced transfer bypasses the Compliance precheck (in ERC-3643, mint and forcedTransfer only require the receiver to be verified and skip the Compliance rules). An Agent adapter path offers a subset of typed freeze, forced transfer, and recovery, provided the adapter holds exclusive authority and the owner cannot route around it; upgrade and migration move toward the native surface but require carrying over and re-verifying state, authority, and history. None of these is an automatic conversion, and a profile declares its supported subset and unsupported paths honestly in a manifest. Every native, compatibility, and interoperability path runs through the same canonical kernel, so any path where a legacy selector bypasses authority, replay protection, action identity, or receipts falls outside full conformance.
What We Can Claim Today, and What Comes Next
The formal ground is stated plainly. The regulatory-action composition model this design rests on was already machine-checked in Isabelle/HOL in the earlier ERC-8319 work, and this design uses it as an input. The practical value of that verification is concrete: the most draining part of a standards debate is hidden exceptions and combinatorial contradictions, and moving questions such as “what remains after a FREEZE followed by a SEIZE?” or “can an ordinary transfer route around enforcement?” from prose into transition tables, theorems, and runnable counterexamples means a reviewer can check the rules directly instead of trusting the designer’s reading. That is the kind of defensibility this aims for.
On that ground, public claims are staged. What can be said now reaches as far as the composition model being machine-checked. TRUST-specific abstract semantics and the compatibility mapping, a pilot’s limited implementation properties, and verification bound to source, bytecode, and deployment are each later stages, and each claim points only at its own stage’s evidence. This discipline does not lower the value of the design; it states exactly where the work stands and ties each claim to reproducible evidence. For the same reason, the standardization path does not make a paid third-party audit a required gate: EIP-1 asks for a sufficient Security Considerations section, and ERC-7943 itself reached Final without a formal audit, its reference code marked “not audited” (ERC-7943). An external audit is placed honestly at the point where a production deployment handling real assets triggers it.
Open Questions and Remaining Limits
Freezing the design fixed the questions to verify, and those are closed from here through formalization and implementation. The hardest is expressing SEIZE’s custody and retained ownership non-vacuously over a fungible balance: without equating an ERC-20 balance with legal title, the custodian and a declared prior-holder reference have to be kept as a case and recoverable even from a commingled balance. LIQUIDATE and RECOVER have to keep external facts (an actual sale, a debt discharge, a rightful owner) out of token events while still fixing action identity and the Applied condition. Implementation then has to show that ERC-7943’s sensitive selectors can carry typed context while satisfying the official behavior and usable interoperability, and that converging every path on one kernel leaves the supported paths genuinely usable. These close only when the abstract model is shown to be non-vacuous and a real implementation is shown to refine it.
Some judgment stays outside formal evidence: whether each action’s legal meaning fits a jurisdiction, whether an authority is legitimate, whether an off-chain determination is true. Formal verification does not replace these; it closes what a machine can close so that people can focus on what they have to decide. On timing, ERC-7943 states that additional features may be added as extensions and gives a legal-proof example, which is grounds that the space for a follow-on like this is open, not a claim of ownership over it. We have not confirmed the ERC-7943 authors’ follow-on plans, and absence of evidence is not evidence of absence.
Closing
What ERC-TRUST sets up, as an ERC-7943 conformance extension, is an enforceability architecture that makes regulatory enforcement legally legible and machine-verifiable on-chain: the legal effect of the six actions becomes a distinct, first-class object, the regulatory dynamics close within a declared domain, and the meaning is carried by evidence from model to deployment. Keeping the public surface minimal and precise is the means that lets independent implementers reproduce and verify it, while the real depth lives in the conformance and evidence stack beneath. The normative design has reached this point; next is showing, with evidence, that the meaning is non-vacuous and that real code preserves it. The open question we leave for the reader: to insulate a standard from regulatory change, what has to stay fixed and what has to remain revisable? We chose to fix the legal concepts, reversibility and ownership effect, and to keep the dated requirements base revisable.
References
- Kim, J., Viglione, R., Spuller, D. (2026). ERC-8319: Regulatory Compliance Protocol (Pull Request #1848, ethereum/ERCs). https://github.com/ethereum/ERCs/pull/1848
- Kim, J., Viglione, R., Spuller, D. (2026). ERC-8319: Regulatory Compliance Protocol (discussion thread). Ethereum Magicians. https://ethereum-magicians.org/t/28917
- Lo Buglio, D., et al. (2026). ERC-7943: uRWA – Universal Real World Asset Interface. https://eips.ethereum.org/EIPS/eip-7943
- Tokeny, et al. (2021). ERC-3643: T-REX – Token for Regulated EXchanges. https://eips.ethereum.org/EIPS/eip-3643
- Mudge, N. (2020). ERC-2535: Diamonds, Multi-Facet Proxy. https://eips.ethereum.org/EIPS/eip-2535
