We are sharing the Regulatory Compliance Protocol (RCP) for discussion. It is submitted as a Standards Track proposal in the ERC category: what it standardizes is an application-level convention, the shared meaning of the enforcement actions that token standards already expose, not an interface. RCP is a definitional framework that gives regulatory enforcement actions on tokenized assets an explicit, citable legal meaning. It brings together, as a single reference: a closed taxonomy of those actions, the legal semantics that distinguish them, the regulatory dynamics that govern how an asset moves between them, and a mapping of published regulatory requirements against existing standards. This thread is intended as its discussions-to venue, and we would value feedback before and during editor review.
The gap, observable today
Deployed security token standards expose legally distinct enforcement actions through a single, overloaded control function. ERC-1400 offers, through its controller component ERC-1644, one controllerTransfer for any privileged movement of tokens; a comparable operator function appears in ERC-3643. At the contract level, a reversible freeze and an irreversible confiscation are the same call, so an on-chain observer (an auditor reconstructing events, an indexer, a counterparty assessing an asset’s standing) cannot tell them apart. The property that matters most, whether an action can be undone, is neither expressed on-chain nor defined anywhere a standard or an auditor could cite. The issue is not that any individual standard is defective; it is that there is no shared, agreed vocabulary for these actions. This holds even at the frontier: ERC-7943, which recently reached Final, deliberately standardizes a neutral forcedTransfer that carries no legal effect (we return to it below).
What RCP is, and is not
RCP is a shared definitional layer that assigns explicit legal effect to regulatory enforcement actions on tokenized assets, expressed as a controlled, citable vocabulary: the layer of meaning that a standard’s mechanism, a freeze() or a forcedTransfer(), leaves unstated. It standardizes that meaning rather than an interface, and it is a framework in two parts. The normative anchor is a closed taxonomy of six regulatory actions (FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER), each defined by its reversibility, its effect on ownership, and its finality; the taxonomy names why a freeze (temporary, ownership-preserving, provisional) and a confiscation (permanent, title-extinguishing, final) are legally different events even when they are the same call on-chain. The descriptive base grounding that taxonomy is a set of 31 compliance requirements compiled directly from the published guidance of 15 financial regulatory authorities (FATF, BIS-IOSCO, ESMA, FINMA, MAS, and others) and organized under five principles (Traceability, Privacy, Enforceability, Finality, Tokenizability); the requirements record what regulators have already stated, not RCP’s interpretation of what they should want.
A standard references RCP without importing it, in three ways: to describe its coverage in common terms rather than standard-specific prose; to name the legal effect of its own operations (for example, that a given forced transfer is a CONFISCATE and not a RECOVER), so that a confiscation is recorded as a confiscation rather than as an indistinguishable transfer; and to declare which requirements it satisfies. In doing so it gives the ecosystem what it currently lacks: a neutral, permanent, citable regulatory reference inside the Ethereum process itself, maintained under the same process and license as the standards that would cite it.
What RCP is not: it defines no on-chain interface, mandates no implementation, confers no authority on anyone, and does not represent Ethereum community consensus. It introduces no code dependency; consistent with EIP-1, adoption is entirely at each standard’s discretion. The point is to give standards, tooling, and auditors a stable, citable definition of, for example, an irreversible confiscation, so that a future Standards Track standard can reference it rather than reinvent it.
Relationship to existing work
RCP is complementary to minimal enforcement primitives rather than competing with them. ERC-7943 (the uRWA universal Real World Asset interface) and the established ERC-3643 converge on a single neutral forced-transfer primitive that deliberately omits the legal motivation of an action. RCP supplies exactly that missing legal-effect vocabulary. A future Standards Track EIP could map RCP’s action taxonomy onto such a primitive, recording which legal effect a given forced transfer represents while leaving the on-chain mechanism unchanged. This gap is one the space has already recognized: ERC-7943 itself chooses the neutral name forcedTransfer precisely because names like confiscation or recovery describe specific motivations that a neutral primitive does not carry. That even a finalized, adopted interface leaves this legal effect unstated is what RCP is meant to address.
Formal grounding
The claim that RCP’s action semantics are precise rather than informal rests on a regulatory state machine, mechanically checked in Isabelle/HOL, over five states (ACTIVE, FROZEN, SEIZED, CONFISCATED, RESTRICTED). The model counts seven action labels rather than the six taxonomy terms: each reversible action has a distinct undo (UNFREEZE, RELEASE, UNRESTRICT), while RECOVER and LIQUIDATE are force transfers modeled in a separate layer and do not appear here. The diagram below is the checked model: of the 5 × 7 = 35 (state, action) pairs, 12 are valid transitions and the remaining 23 are rejected.
Figure 1: The regulatory state transition model over five states, mechanically checked in Isabelle/HOL. CONFISCATED (dark) is terminal and reachable from every non-terminal state.
Two properties are proved rather than asserted. First, confiscation is terminal (confiscated_terminal): once an asset is confiscated, the transition function is undefined for every action, so no action moves it.
∀a. δ(CONFISCATED, a) = ⊥
Second, confiscation is universally reachable (confiscate_universal): from any non-terminal state, CONFISCATE reaches CONFISCATED.
∀s ≠ CONFISCATED. δ(s, CONFISCATE) = CONFISCATED
Here δ is the transition function reg_transition and ⊥ its undefined case (None). Together these encode, as theorems, the reversibility ladder the taxonomy states in prose: a reversible FREEZE and an irreversible CONFISCATE are structurally different, not one call under two names. This is a narrow claim about the taxonomy’s internal consistency, not about consensus, liveness, or any cross-chain deployment, none of which this EIP assumes or requires.
The artifacts are public and independently checkable: the sources build from the GitHub repository (Oraclizer/formal-verification, ROOT included, sorry-free), and the write-ups are arXiv:2604.03844 and arXiv:2603.29278. None of this is a normative attachment (EIP-1 requires no formal verification of any proposal); we include it because it lets the taxonomy rest on a checked model rather than on our word for it.
Scope and neutrality
RCP confers no authority and creates no obligation. It documents regulatory positions that authorities have already published; it does not endorse or rank any enforcement action, authority, or jurisdiction. Every requirement quotes its source verbatim and names the issuing authority; where RCP synthesizes (the five-principle organization and the six-action taxonomy), the text marks the synthesis as RCP’s own and opens it to correction. Publication of this proposal should not be read as establishing regulatory compliance as a protocol-level objective of Ethereum. The authors build tokenization and compliance infrastructure and disclose that interest; RCP is offered as shared, vendor-neutral reference material, open to public correction. This EIP was developed in collaboration with Horizen Labs and, in an individual capacity, Dan Spuller (EVP of Industry Affairs, Blockchain Association), who contributed the policy considerations.
Where feedback would help most
-
The action taxonomy: are the six actions and their reversibility/ownership semantics complete and correctly distinguished?
-
The scope boundary: is the line between what RCP defines (the legal meaning of an action) and what a token standard defines (the interface that exposes it) drawn in the right place?
-
The coverage assessment of existing standards (ERC-20, ERC-7943, ERC-1400, and ERC-3643): it is offered as a starting point and we expect corrections from the standards’ maintainers.
-
Jurisdictional coverage: the requirements base is explicitly dated and non-exhaustive (the Japan FSA, the Republic of Korea FSC, and the UAE VARA, among others, are not yet incorporated); pointers to primary guidance from these regimes are welcome.
We will open the pull request shortly, with this thread as its discussions-to link, and will post the PR link here once it is open. Feedback before and during editor review is welcome.