ERC-8319: A Citable Regulatory Constitution for Tokenized Assets

TL;DR

The ERC-8319 Regulatory Compliance Protocol (RCP) has been submitted to Ethereum’s official standards repository, ethereum/ERCs, where it has cleared every automated check and now sits under editor review. RCP is a shared reference layer that defines the legal effect of six regulatory enforcement actions on tokenized assets (FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER), each with an explicit meaning for reversibility and ownership, and it organizes 31 requirements compiled from 15 financial regulators under five principles. The substantive milestone is that a long-prepared reference now holds a permanent, citable public identifier. We first framed it as an Informational EIP; the repository split and the definition of the ERC category carried it into the process as a Standards Track ERC, in the form of a conditional conformance that mandates no interface. Naming is a coordination problem, and a shared vocabulary resolves it only when it has a permanently citable home kept under the same process and license as the standards that consume it.

From a Draft to Ethereum’s Permanent Record

Last December we published our own draft of the protocol. It was a single document we hosted, and anyone who wanted to reference it had to take us at our word. This submission changes what the document is. It has entered the same public repository and the same review process that the token standards the whole industry stands on, such as ERC-20 and ERC-721, passed through. What matters here is not the act of publishing but that the basis of reference has changed. The ERC-8319 Regulatory Compliance Protocol is now an entry kept under the same process and the same license as the standards that will cite it, rather than a page we maintain.

The largest barrier to bringing tokenized capital markets on-chain has never been the technology. It has been the absence of a common language for describing regulatory compliance. Regulatory semantics is a separate discipline that sits outside most protocol engineers’ working knowledge, and until now the Ethereum process offered no neutral, citable reference for the legal effect of enforcement actions. Each standard named the same thing in its own way, or did not name it at all.

What ERC-8319 settles is exactly that reference. Why it was placed on the ERC side rather than as an EIP, and as a normative taxonomy rather than a concept note, is bound up with a classification principle that Ethereum’s standards governance has recently made explicit. The meaning of the milestone comes into focus when we trace that connection.

The Missing Vocabulary: One Function That Swallows a Legal Distinction

Deployed Ethereum security-token standards expose legally distinct enforcement actions through a single, overloaded control mechanism. Early security-token standards routed every privileged movement through one controllerTransfer function, and ERC-3643 does the same work through an operator-driven forced transfer. The consequence is that a regulator-ordered freeze (temporary, reversible, ownership preserved) and a court-ordered confiscation (permanent, irreversible, ownership transferred) become the same call at the contract level. An auditor reconstructing events, an indexer, or a counterparty assessing an asset’s state cannot tell a reversible action from an irreversible one by the call alone.

The problem is not that any one standard is defective. The problem is that the legal effect of an action is absent or undefined across standards. Even the recently standardized minimal enforcement primitive carries no legal effect by design, and that omission is deliberate and correct for a neutral primitive. One widely deployed standard defines its single forced transfer for three legally distinct purposes at once (reversing a fraudulent transaction, resolving a lost key, and responding to a court order) while placing the data that would distinguish them explicitly out of scope. A richer standard that exposes named operations such as freeze, forced transfer, and recovery still offers only its own function names, not a shared taxonomy, and none of them define the property that matters most: whether the action can be undone, and what becomes of ownership. That property is therefore expressed nowhere on-chain, and defined nowhere a standard, an auditor, or a regulator could cite.

This is not a projection but a fact observable in deployed code today, and that observation is RCP’s primary justification. RCP begins from a present defect, not a future convenience.

What the ERC-8319 Regulatory Compliance Protocol Defines: Meaning, Not an Interface

RCP fills this gap at the level of definition. It standardizes the meaning of the actions, not the functions a contract exposes. It defines no on-chain interface and introduces no code dependency; it specifies what a confiscation or a freeze means (its reversibility and its effect on ownership), not how a contract should implement it.

Figure 1: RCP layers legal meaning on top of existing standards, which relate to it by reference, not import. No interface is mandated and no code dependency is created.

A Closed Taxonomy of Six Actions

The normative anchor of the framework is a closed taxonomy of six regulatory actions. Each names a legal effect that its on-chain mechanism does not.

No regulator publishes a closed list of enforcement actions carrying these legal-effect properties. The taxonomy is not transcribed from any single authority; it is RCP’s own synthesis, drawn from a functional and legal analysis of the regulatory sources and offered as a reference open to correction. What a single overloaded transfer function cannot distinguish is not the calling convention but exactly these effects.

Regulatory Dynamics: A Machine-Checked State Model

The finality column induces a partial order over the deprivation actions, reflecting the graduated escalation the cited frameworks recognize (a freeze is provisional, a seizure is interim custody, a confiscation is final): \(FREEZE \prec SEIZE \prec CONFISCATE \approx LIQUIDATE\). RESTRICT and RECOVER sit outside this ladder, because one is a configurable, ownership-preserving limitation and the other is a restoration rather than a deprivation.

This order takes concrete form as a dynamics, how an asset moves between regulatory states, and the internal consistency of that model is formalized as a state-transition system and machine-checked in Isabelle/HOL. Writing the partial transition function as \(\delta(state, action)\), two structural properties are worth stating. First, confiscation is terminal: because it transfers ownership permanently, \(\delta(CONFISCATED, a) = \bot\) for every action \(a\), so there is no outgoing transition. Second, confiscation is universally reachable: from any non-confiscated state \(s\), \(\delta(s, CONFISCATE) = CONFISCATED\). Undefined transitions are deliberate as well; a seizure does not relax directly to a freeze, because seizure is a strictly stronger constraint, and such a blank is a legally grounded refusal, not an omission. The mechanized source is developed without sorry, so the model is checkable end to end, and it is described in the companion paper [7].

This is where the regulatory vocabulary meets the work we have been building in formal verification. Making the definitions rest on checked ground rather than on our assertion is what separates a citable reference from a claim.

A Descriptive Reference Base: 31 Requirements, Five Principles

If the taxonomy is the normative axis that carries conformance meaning, the second axis is descriptive. Thirty-one requirements, compiled directly from the published guidance of 15 regulators (World Bank, FATF, BIS, IOSCO, ESMA, FINMA, and others), are organized under five principles (Traceability, Privacy, Enforceability, Finality, and Tokenizability) as a reference base against which a standard can describe its own coverage. This organization is descriptive, not normative; the requirements come from the regulators, and RCP’s contribution is to select, order, and classify them into a shared vocabulary. The requirement numbers are preserved from the original research for traceability, so they are not contiguous within each principle. The compilation is explicitly dated to the cited documents, deliberately non-exhaustive, and open to correction and extension through the discussion thread.

Where RCP starts: reading what regulators already published, then sorting it under five principles.

Why an ERC, and Why Standards Track

We conceived of this protocol as an Informational EIP for a long time. Its character, defining a conceptual framework rather than an interface, specifying the what and leaving the how to each implementation, seemed to fit the Informational classification. Through the submission itself, that understanding was adjusted on two levels.

Figure 2: The core and application axes, and where a controlled vocabulary lands. After the repository split, anything that is not a core-protocol change belongs on the ERC side.

The first is the repository split. The Ethereum improvement-proposal repository is divided in two: changes to the consensus or execution layer that require AllCoreDevs discussion live in ethereum/EIPs, while application-level standards and conventions live in ethereum/ERCs [7]. The rationale is that the two communities have fundamentally different needs; a core-protocol change demands uniform rollout and carries severe consequences if misspecified, while an application-level standard can be implemented flexibly across projects. A reference that standardizes the meaning of regulatory enforcement actions touches no consensus rule, so by definition it belongs on the application axis. A convention or definitional document like ours is no exception.

The second is the type within that axis. The conformance tooling in ethereum/ERCs admits only Standards Track as a type, and this has been invariant since the first commit of the repository split. And EIP-1 defines the ERC category as application-level standards and conventions [8]. RCP is exactly that convention: the shared meaning of enforcement actions that token standards already expose. So it became a Standards Track ERC. This was a matter of classification, not of labeling; the repository and the type named precisely the fact that what RCP standardizes is an application-level convention rather than an interface.

Conditional Conformance: Normative and Non-invasive at Once

Standards Track implies normative content, yet RCP’s design principle was non-invasiveness, mandating nothing of any standard. The two are reconciled through conditional conformance. The normative requirements of this specification (its MUST and MUST NOT) apply only to a standard, implementation, or tool that claims conformance to the RCP action vocabulary. Such a claimant must express each distinct RCP action it supports as a distinct, separately observable operation, and must not attach an RCP action name to an operation whose reversibility or ownership effect differs from the taxonomy. A standard that makes no such claim bears no obligation, and no on-chain interface is imposed on any implementation.

Three properties follow from that choice. Because the taxonomy defines legal effect rather than an implementation interface, standards can express the same action through different mechanisms; different jurisdictions can require different subsets of the requirements; and the conceptual framework can stay stable while implementations evolve. Because it is a controlled vocabulary and not a rule set, RCP is relatively insulated from regulatory change: even if a particular obligation shifts, the legal concepts it names (the reversibility and ownership effect of a freeze versus a confiscation) do not, and what may need periodic revision is the dated requirements base, not the normative taxonomy.

Why a Permanent, Citable Home Matters

Naming is a coordination problem. If each standard invents its own term for an enforcement action, or buries the distinction inside a standard-specific name, then descriptions of compliant behavior become incomparable across standards, and a future standard cannot reference an established definition of, say, irreversible confiscation. A controlled vocabulary resolves this only when it has a single, stable, permanently citable home kept under the same process and license as the standards that consume it. An external paper or a mutable web page is not that home. The EIP repository is, and the number ERC-8319 is now the permanent, citable public identifier for that reference. The ERC-8319 Regulatory Compliance Protocol therefore lives where the standards that would cite it live.

Figure 3: The Standards Track status flow and ERC-8319’s current position. The assigned number is permanent regardless of final status, and future standards can reference it by identifier.

This permanence has concrete use in relation to recent standards work. The uRWA universal real-world-asset interface, which recently reached Final, together with the established ERC-3643, converges on a single neutral enforcement primitive that deliberately omits an action’s legal motive. RCP does not compete with this approach; it complements it. It supplies the legal-effect vocabulary the primitive itself cannot express: the distinction between a reversible freeze and an irreversible confiscation. That even a Final, adopted interface does not specify this legal effect is not a flaw of the interface (the omission is deliberate and correct for a neutral primitive) but exactly the definitional gap RCP fills. Future Standards Track work can map RCP’s taxonomy onto such a minimal primitive, recording which legal effect a given forced transfer expresses while leaving the on-chain mechanism unchanged. RCP takes no position on when or how that market develops; it only ensures the vocabulary is already settled when a standard comes to address it.

What Is Left Open: Neutrality and Deliberate Edges

Being clear about what RCP does not do matters as much as what it does. RCP confers no authority and creates no obligation. It documents regulatory positions that authorities have already published, and it does not endorse, rank, or legitimize any particular enforcement action, authority, or jurisdiction’s legal regime. The publication of this proposal should not be read as establishing regulatory compliance as a protocol-level goal of Ethereum. It standardizes only the meaning of the terms used to describe enforcement actions, and it binds only the standards that claim conformance to that vocabulary. The policy perspective contributed by a co-author, foregrounding due process and privacy-first compliance, keeps that neutrality at the level of principle rather than code.

The edges are deliberately open too. RCP itself provides no cross-chain mechanism, and the portability of compliance status is left entirely to future Standards Track work. It also introduces no backwards-compatibility issues: because it defines no interface and creates no code dependency, existing standards such as ERC-20 and ERC-3643 remain exactly as usable as before. A standard relates to RCP by reference, not import, and a standard that chooses to reference it can describe its coverage in the shared vocabulary, name the legal effect of its own operations, or declare conformance to the action vocabulary. In each case RCP supplies a layer of legal meaning on top of the standard’s existing mechanism without changing, replacing, or constraining it.

Conclusion: A Completion, and a Beginning

A long-prepared reference has taken its place in Ethereum’s official record. Yet this is closer to a beginning than an end. The ERC-8319 Regulatory Compliance Protocol settles the what, what the legal effect of an enforcement action means. The how, how those actions are exposed on-chain and how they are made portable across chains, is left to the standards that choose to implement them. The shared vocabulary has to settle first, so that the implementation work built on top of it has a comparable and citable basis. Reverse that order, and each standard scatters back into its own terms.

For now, ERC-8319 is open to the community’s review. Public discussion is underway on the Ethereum Magicians thread, and editor review continues at ethereum/ERCs pull request #1848; participation and challenge are welcome. We leave one open question. For a controlled vocabulary to be insulated from regulatory change, what must stay stable and what must remain revisable? We chose to keep the legal concepts (reversibility and ownership effect) stable and the dated requirements base revisable. Whether that boundary holds is something the next few years, as standards and regulation evolve together, will answer.

References

1. Ethereum. (2015). EIP-1: EIP Purpose and Guidelines. https://eips.ethereum.org/EIPS/eip-1
2. Ethereum. (2023). EIP-7329: ERC/EIP Repository split. https://eips.ethereum.org/EIPS/eip-7329
3. World Bank. (2021). Distributed Ledger Technology and Secured Transactions. https://documents.worldbank.org
4. FATF. (2021). Updated Guidance for a Risk-Based Approach for Virtual Assets and Virtual Asset Service Providers. https://www.fatf-gafi.org
5. BIS-IOSCO. (2012). Principles for Financial Market Infrastructures. https://www.bis.org/cpmi/publ/d101a.htm
6. Kim, J. and Hong, J. (2026). A Regulatory Compliance Protocol for Asset Interoperability Between Traditional and Decentralized Finance in Tokenized Capital Markets. arXiv:2603.29278.
7. Kim, J. (2026). The Cross-Domain State Preservation Functor: A Mechanized Theory of Regulatory State Synchronization in Isabelle/HOL. arXiv:2604.03844.

Learn More

• Public discussion and review status: Ethereum Magicians thread and ethereum/ERCs PR #1848.
• The conceptual background, from the self-published draft stage: EIP-RCP: Why Tokenized Capital Markets Need a Regulatory Compliance Protocol