We are sharing an Informational EIP for discussion ahead of opening a PR to ethereum/ERCs: the Regulatory Compliance Protocol (RCP). 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 is offered as an Informational reference, not 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. For an Informational EIP none of this is a normative attachment (EIP-1 requires no formal verification); 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. As an Informational EIP it does not represent Ethereum community consensus. 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 Informational framing and scope: is a shared, citable vocabulary the right deliverable, and is the boundary with Standards Track work 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 to ethereum/ERCs shortly, with this thread as its discussions-to link, and will add the PR link here once it is open.