ERC-8319: Regulatory Compliance Protocol

[jay-oraclizer]

Add ERC: Regulatory Compliance Protocol

---

ERCS/erc-8319.md

---

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

1. The action taxonomy: are the six actions and their reversibility/ownership semantics complete and correctly distinguished?

2. 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?

3. 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.

4. 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.

[jay-oraclizer]

An ethresear.ch exchange raised a scope question for ERC-8319: does universal reachability of CONFISCATE in the checked model become a requirement for conforming implementations? No. The mechanization verifies one regulatory state machine; ERC-8319 standardizes the legal meaning, reversibility, and ownership effect of regulatory actions. It mandates neither a transition graph nor an implementation, and it confers no enforcement authority. The follow-up states this boundary explicitly, in part because that exchange asked for it.

[blockbird]

I love this discussion here and the way it is laid out makes it super relevant to many areas, including privacy.

Regarding your question whether the six actions are complete and correctly distinguished. As dispositive actions they are, and separating them by reversibility and ownership, with the Isabelle/HOL proof that CONFISCATED is terminal, is worth having:

A regulator-mandated freeze (temporary, reversible, ownership unchanged) and a court-ordered confiscation (permanent, irreversible, ownership transferred) are, at the contract level, the same call

What the six share is the gap: every action, and every one of the five states, is dispositive. None records that an asset is adverse or under review while the holder keeps full control and it stays transferable. So the only slot for “something here is wrong” is a dispositive action, and FREEZE or RESTRICT get pressed into a recording role, whether or not anyone has authority to freeze.

This is not the off-chain report filing you put out of scope. On-platform monitoring stays in, and it is requirement (2): blank across all four columns of the coverage matrix, its body requiring “continuous monitoring of transactions to identify potential illicit activity.” Monitoring’s output is a suspicion signal, and no action or state can carry it. Unlike KYC or audit support, suspicion standing is a per-asset status in the same object space as the disposition states, and is what downstream enforcement keys off, so its absence is a gap rather than a scoping choice.

The record-versus-freeze line is structural in the regimes the 31 requirements draw on. Filing a Suspicious Activity Report under 31 U.S.C. 5318(g) neither requires nor authorizes freezing; FATF keeps the reporting duty (Recommendation 20) separate from freezing, which lives under provisional measures (R.4) and targeted financial sanctions (R.6). Freezing rests on a separate and specific authority, not on the act of recording suspicion. One caution I want to state rather than bury: this supports the taxonomy point, not writing suspicion to public state. The SAR model depends on confidentiality, since tipping-off rules bar notifying the subject (5318(g)(2)), so a public flag can itself be the tip-off; whether a flag is public or private belongs in the open question below. In the EU, reporting carries a duty to refrain from executing the specific suspicious transaction pending the FIU (Directive 2015/849 Art. 35), unless refraining would tip off, in which case the entity executes and informs the FIU immediately after (Art. 35(2)). That is a transaction-scoped hold, not an account freeze.

Concretely, this is a non-dispositive status, not a new action: because it enforces nothing it gates no transition, so it is a label over an asset or address rather than a sixth state. It reuses the reversibility, ownership, and finality vocabulary already in the taxonomy, is defined over the holder-retaining dispositions, and is realized through existing mechanisms, consistent with “RCP defines no on-chain interface and introduces no code dependency.”

I also want to address some potential concerns upfront:

Does RESTRICT not already cover it? Unfortunately not: RESTRICT sets the enforcement state to RESTRICTED, which any canTransfer-style consumer reads as transfer-limited. A reason-code inside a state that already means “constrained” still cannot say “unconstrained, under watch.”

Can we not use EAS or ERC-8106 instead? Those are the realization layer; the meaning is what RCP would name. ERC-8106 is the precedent: it already puts non-enforced flags on-chain (“Compliance flags are informational, not enforced”), but its flags are per-transfer events rather than a persistent status, and its enum encodes transfer topology, not adverse taint. Naming FLAGGED as a meaning is what lets an ERC-8106 event, an EAS attestation, and an ERC-1643 document be read as one concept across token types.

The piece I can’t settle from the text, and the one that decides whether the meaning is well-formed: what is the flag’s subject, and does it propagate on transfer? Requirement (2) is address- and transaction-scoped, which argues for an address-level flag; Traceability seems to want one that travels with the asset, and for a fungible balance that is undefined without a taint rule (FIFO, pro-rata, a haircut) or flagging whole-asset or NFT subjects only. Do you intend a flag on the asset, the holder address, or the pair? And if it propagates, how does a partial transfer divide it?

If that is the right category to add, I am happy to draft the concrete taxonomy entry and the requirement (2) note.

[jay-oraclizer]

Thank you. I agree with the core distinction: a monitoring or suspicion signal must not be represented as FREEZE or RESTRICT. Those are dispositive actions with effects on transfer or ownership, while recording suspicion neither requires nor authorizes either one. And as you note, a public flag can itself be the tip-off, so public state cannot be the default.

Your point is visible in the text itself: the Motivation quotes FATF’s “flag for further analysis,” yet the controlled vocabulary names only dispositions. The conformance rule already forbids lending an action’s name to an operation without its legal effect, but a prohibition is not a home. You are also right that RESTRICT cannot host it: to any canTransfer-style consumer, RESTRICTED already means transfer-limited.

Structurally, the taxonomy is intentionally a closed set of six dispositive actions, so this would not become a seventh entry; as you frame it, it is a status, not an action. It belongs beside the taxonomy as a separate non-dispositive review-status vocabulary, reusing the reversibility and ownership attributes as you propose, but not membership in the action list. And since the taxonomy is RCP’s normative anchor while the 31 requirements are its descriptive reference base, Requirement (2) shows the boundary needs stating, not that RCP must standardize a persistent status.

Where I am not yet persuaded is that the status is necessarily per-asset. Requirement (2) mixes transaction, customer, and relationship context; the EU example is transaction-scoped. An NFT can carry an asset-level status, but a fungible balance cannot without lot identity and a propagation rule, and the taint rules you list are substantive legal semantics no regulator has settled across jurisdictions. RCP has named only distinctions the cited authorities have already drawn, so that choice should stay outside the base vocabulary. Hence my answer to your closing question: no subject by assumption; the record carries its subject explicitly.

On prior art, your division is right: EAS and ERC-8106 are realization layers, and the meaning is what RCP would name. ERC-8328 may be an even closer realization test (typed subjects, claimed authority, evidence commitments, correction provenance), yet it too leaves the meaning undefined.

So yes, I would gladly take you up on that offer. Posting it here in the thread rather than as a PR would let it be discussed in the open. To make it easy to fold into the ERC later, it would help if the draft covered:

• the Requirement (2) note: monitoring output is non-dispositive and creates no enforcement authority;
• an explicit tagged subject: TRANSACTION, ADDRESS, ASSET, ASSET_ADDRESS, or CASE;
• no derived propagation by default, unless a separate profile defines a rule;
• the core fields: claimed authority, evidence reference, visibility, expiry, correction or revocation, plus an explicit rule that the status alone neither blocks transfer nor authorizes any disposition;
• a short comparison against ERC-8106 and ERC-8328.

None of this is a gate. A partial draft is completely fine, and I am happy to iterate on it here with you.

Two things worth keeping in mind: if consumers mechanically deny transfers on a visible status, a non-dispositive label becomes a de facto restriction, so visibility is part of the semantics; and I would leave the name open for now, since a machine signal, UNDER_REVIEW, and CLEARED may be three different facts rather than one FLAGGED boolean.

Thanks again for offering to take this on. I look forward to the draft.

[blockbird]

Requirement (2) is satisfied by a record. Monitoring output is non-dispositive:
it records that something warrants attention, confers no authority to freeze,
restrict, seize or alter ownership, and is a precondition for none of them.
Where a jurisdiction also mandates a hold, as 2015/849 Art. 35 does, that hold
is a separate dispositive action.

The rule: a review status alone MUST NOT block or condition transfer, and MUST
NOT authorize any disposition. An implementation that gates transfer on one has
performed a disposition and MUST record it as one. That separation is the point
of the vocabulary rather than a limitation on it. Signal and enforcement are one
rail today, so only a party that can already freeze is able to record anything,
and what it records stops at its own venue. Split them and one signal reaches
many enforcers, each applying its own regime at the point of movement.

Records are append-only. A subject’s current standing is the terminal unexpired
record in its correction chain.

Every record carries a tagged subject, one of TRANSACTION, ADDRESS, ASSET,
ASSET_ADDRESS or CASE, where ASSET_ADDRESS is the holding. An untagged record is
malformed.

Nothing propagates by default. A status on an address derives none on an asset,
a holding derives none on the asset, and a transaction derives none on its
parties. A profile MAY define propagation, and MUST then define the
partial-transfer division rule: FIFO, pro rata, haircut, or whole-subject only.

Four values, names provisional. SCREEN_HIT is an automated signal. UNDER_REVIEW
is an open human review. CLEARED and ADVERSE are the two outcomes of a closed
one. CLEARED earns its place by being a positive record rather than an absent
flag, so a repeat screen does not reopen a settled question. ADVERSE is there on
the same argument: someone looked, and the finding is worth keeping.

Fields: subject and subjectType, the value, a claimed authority held separate
from the recorder as ERC-8328 does, an evidence commitment and reference,
visibility, a validity window after which a record is stale rather than false,
and a correction or revocation link.

Visibility is required, carries defined values, and MUST NOT default to public
for SCREEN_HIT or ADVERSE. One is unreviewed machine output. The other is the
tip-off that 5318(g)(2) exists to prevent.

ERC-8106 sets the precedent but cannot carry the record. “Implementations SHOULD
NOT revert transactions solely based on compliance flags” leaves denial
permitted, and ComplianceObserved is transfer-scoped with no field for a subject
or a standing. ERC-8328 can carry it: it splits recorder from claimed authority,
commits evidence, and keeps a correction chain. What it lacks is a visibility
field and a core validity window, since expiresAt appears only inside payload
profiles, and none of its fifteen event types names a review standing. They are
dispositions, KYC decisions, policy changes and corrections. ADDRESS, ASSET and
CASE map to existing SUBJECT_ constants, while TRANSACTION and ASSET_ADDRESS
would need custom ones.

Some reviews close without a finding: withdrawn, duplicate, or nothing to
determine. This set gives them nowhere to go, so they sit in UNDER_REVIEW and
look open when nobody is working them. Own value, or does CLEARED take them with
the evidence reference carrying the difference?

[jay-oraclizer]

@blockbird, thank you for working this through. The gating rule closes a real hole in RCP: our conformance text catches a status that borrows an action’s name, but not one that produces the effect without the name. ERC-8106 leaves the same opening from the other side: its SHOULD NOT does not prohibit denial, while ComplianceObserved is transfer-scoped and has no field identifying a persistent standing or a tagged subject. At RCP’s layer, a review status confers no enforcement authority, is not a precondition for any disposition, and neither blocks nor conditions transfer. If a conforming standard, implementation, or tool uses one to gate transfer, the resulting disposition has to be represented as the separate, observable RCP action it actually is. The status stays a status.

One thing about reach, though. RCP names what enforcers interpret, not how the record gets to them; distribution, access, and reliance sit with the carrier or profile, especially where disclosure is itself the tip-off.

On your last question, the machine-signal, open-review, closed-outcome shape holds, but the closed outcome needs a third value. A case closed without a determination did not clear anyone, and an evidence reference can’t preserve that for consumers that stop at CLEARED. That is the same argument you made for CLEARED being a positive record rather than an absent flag. Names can wait.

Validity creates one tension. If every record expires the same way and current standing is the terminal unexpired record, an expired CLEARED becomes indistinguishable from never screened, reopening the question it was meant to settle. Expiry has to mean different things for different values. A machine hit going stale is not a determination losing current force, and if a determination can expire the profile has to define the consequence without erasing the history. Revocation, supersession, and reopening on new evidence are different events.

There’s a second structural point (two authorities, two open cases on the same address). The case identifies the review chain; the tagged subject identifies what the review is about. If one field has to choose between CASE and ADDRESS, ASSET, ASSET_ADDRESS, or TRANSACTION, concurrent cases collapse into one chain. So case-scoped standing and an explicit subject are both needed, and an untagged record cannot carry the status at all. Exact fields stay with the carrier or profile. Propagation is off by default; if a profile defines it, the partial-transfer division rule belongs there too.

I also owe you a correction. Last time I said Requirement (2) showed the boundary needed stating, not that RCP had to standardize a persistent status. I don’t think that holds now. Your draft pulls the meaning apart from the record design, and once it is apart the meaning is standardizable. RCP can take the non-dispositive, case-scoped vocabulary and the conformance, propagation, and validity boundaries above. Names can come later.

What doesn’t belong here is the record machinery: fields, append-only structure, correction chain, and encodings. The append-only model, recorder/claimed-authority split, evidence links, and correction or revocation links all make sense one layer down. ERC-8328 is the closer carrier, though not complete as written, and extending a carrier is separate work rather than an ERC-8319 dependency. RCP has no interface and shouldn’t grow one. SCREEN_HIT and ADVERSE cannot default to public. More fundamentally, visibility is a disclosure policy, not confidentiality, so sensitive standing may need to stay off a public chain entirely rather than sit on one marked private.

I’m leaving the current PR alone until it merges as Draft. After that, I’ll put the semantics into a follow-up PR as a non-dispositive review-status subsection with the conformance and privacy notes. I’ll credit your post in the PR description and change record. The taxonomy, transition model, and proofs don’t move.

[Etherow911]

I run Mirror AI - a compliance intelligence platform that tracks regulatory obligations across jurisdictions. I’ve been following ERC-8319 and have some data I think is worth sharing.

The Gap

The RCP’s six-action taxonomy covers FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, and RECOVER. It maps them to tokenized assets like bonds, real estate, and stablecoins. But governance tokens - a distinct asset class with ~$4.5B+ in market cap across top protocols - aren’t addressed at all.

This matters because governance tokens don’t fit any single regulatory bucket. They’re not pure securities, not pure utilities, not pure commodities. Their classification - and therefore which RCP actions apply to them - varies dramatically by jurisdiction.

A Concrete Example: UNI

I completed a systematic classification analysis of UNI (Uniswap’s governance token) across AU, EU, and US frameworks. The results:

Jurisdiction	Framework	Classification	Certainty	Applicable RCP Actions
Australia	Corps Act s92	Security	95%	FREEZE, RESTRICT, CONFISCATE
Australia	Corps Act s761D	Derivative	92%	FREEZE, RESTRICT, CONFISCATE
EU	MiCA	Other Crypto-Asset	80%	RESTRICT, RECOVER
EU	MiCA	Utility Token	55%	RESTRICT only
US	SEC-CFTC (Mar 2026)	Application-level token	50%	All six
US	SEC v. Howey (legacy)	Security	50%	All six

Same token. Six different regulatory answers. Three different sets of applicable RCP actions.

The Score Trap Problem

The more fundamental issue is what I call the “Score Trap”: jurisdictions with extensive regulatory guidance (Australia, ~795 relevant documents) can produce the same overall risk score as jurisdictions with minimal guidance (EU, ~33 relevant documents), despite vastly different regulatory surfaces. A governance token’s compliance posture is as much a function of regulatory attention as of the token’s actual characteristics.

What This Means for RCP

The RCP framework standardises vocabulary for enforcement actions. That’s valuable. But it currently assumes a single regulatory answer per token. Governance tokens prove this assumption is wrong - classification depends on where you’re standing.

What I’ve Prepared

I’ve put together three documents that I’d like to contribute:

1. A governance token classification annex - Full classification profiles for 6 tokens (UNI, AAVE, CRV, ARB, INJ, TIA) across AU, EU, and US frameworks, with certainty scores and applicable RCP actions per jurisdiction. Includes the proposed Section 7: Jurisdiction-Conditional Actions for the RCP specification.

2. UAE VARA coverage - Full mapping of all 6 VARA enforcement powers onto the RCP taxonomy. VARA’s regulations (Custody Services Rulebook, Virtual Assets Regulations 2023, Technology and Information Rulebook) support all six RCP actions. I’ve also identified 9 new compliance requirements (32-40) for the RCP framework based on VARA’s rulebooks.

3. Score Trap data - Jurisdiction scores across 6 topics and 15+ jurisdictions that quantify the fragmentation RCP is trying to solve. Based on 446 compliance documents and 20,000+ regulatory obligations tracked by Mirror AI.

Happy to open a PR against the proposal branch or share the full documents. Keen to hear what the authors and community think.

[jay-oraclizer]

@Etherow911, thanks for the jurisdictional work behind that table. Comparing one asset across three regulatory regimes takes real time.

Jurisdictional variation is real, and it’s already a premise of the draft. The Rationale says there is no single global rulebook for digital asset regulation, and that participants may map jurisdiction-specific legal requirements to common technical primitives “without asserting a single, global compliance truth.” The Security Considerations likewise leave conflicts among authorities to the relevant off-chain legal process. So RCP doesn’t assume one regulatory classification per token.

RCP isn’t scoped to a particular asset class either. The draft refers to tokenized assets throughout, and the six actions aren’t assigned to bonds, real estate, stablecoins, or any other category. If a competent authority lawfully orders one of those actions in relation to a governance token, the vocabulary already defines what that action means. Classification matters at a different layer, where it can affect which legal obligations and which of the 31 requirements are relevant in a jurisdiction, as Requirement 30 recognizes. But classification alone neither selects nor authorizes an action. That depends on the applicable law, the facts, a competent authority, and legal process.

One correction to the table. The March 2026 SEC interpretation doesn’t use “application-level token” as a category and doesn’t classify UNI. Its five categories are digital commodity, digital collectible, digital tool, stablecoin, and digital security, and it describes governance rights as something a digital commodity may carry. It also distinguishes the asset from the transaction: a non-security crypto asset may still be offered and sold subject to an investment contract; the investment contract, not necessarily the asset itself, is the security. A per-token verdict can lose that distinction.

You’re right, though, that the examples and the coverage matrix lean toward securities and RWA framing. That’s a presentation bias, not a limit on scope.

So per-token legal verdicts and certainty percentages can’t become normative text in this proposal. Before treating them as evidence, I’d want to see the factual basis, the provisions and legal tests applied, and the method behind each percentage. The underlying problem you’re pointing at is real, though. Carrying an externally determined, jurisdiction-specific legal conclusion into the applicable requirement set is a separate applicability layer. This draft doesn’t standardize it, and I’m not proposing to write it. A properly sourced annex and the Score Trap data could be useful as independently authored companion analysis. They just wouldn’t become RCP classifications or action recommendations.

VARA is the contribution I could use directly, since the scope note already identifies it as a regime not yet incorporated. For now, please share the materials in this thread rather than opening a PR against the proposal branch. The current proposal will remain unchanged until it is merged as Draft. Here’s how I’d split the work: I’ll make the overlap assessment against the existing 31 requirements myself, so what I’d ask of you is the source material, meaning the effective rulebook and version, the exact provisions, and the relevant original text. You can also flag whether you read each item as supporting an existing requirement or as genuinely distinct. If a provision really does establish something distinct, it’d be a new requirement rather than added support for an old one. Partial is fine. One rulebook documented precisely beats nine summarized items.

[Etherow911]

@jay-oraclizer,

I owe you an apology. Three mistakes in my initial analysis:

1. I invented “application-level token” as a SEC category. It doesn’t exist. The SEC-CFTC March 2026 taxonomy has five categories: digital commodity, digital collectible, digital tool, stablecoin, digital security. When UNI/AAVE/CRV didn’t fit any, I invented a label instead of flagging the gap. That was lazy and I’m sorry.

2. I mischaracterized RCP. I said it assumes a single regulatory answer per token. That was wrong - the framework is jurisdiction-agnostic by design. I projected my own classification failure onto the spec.

3. I oversold the VARA mapping. I skimmed the Regulations, grabbed regulation numbers, and slapped RCP labels on them without actually reading what the provisions mean in context. Below is the revised version.

---

VARA: What the Framework Actually Does

VARA regulates Virtual Asset Service Providers (VASPs) in the Emirate of Dubai under Law No. (4) of 2022. Eight licensable activities: Advisory, Broker-Dealer, Custody, Exchange, Lending/Borrowing, VA Issuance, VA Management/Investment, VA Transfer/Settlement.

The framework operates through the Virtual Assets and Related Activities Regulations 2023 (as amended 19 May 2025) plus 11 Rulebooks (4 general, 7 activity-specific).

Enforcement Powers - What VARA Can Actually Do

RCP Action	Does VARA have this power?	What the text actually says	In plain language
FREEZE	YES	IX.C.2.f: “requiring a VASP or Entity to immediately cease or suspend any VA Activity, Marketing or other business activity, either for a specified or indefinite period of time.”	VARA can order a VASP to stop operating. Customer assets stay in place but can’t be transacted. Temporary. Ownership retained.
RESTRICT	YES	IV.B.2.a.i: “vary a Licence in any way, including by adding a VA Activity, removing a VA Activity or varying the description of a VA Activity, or by varying any limitations.” I.B.3.a.vi: “take or refrain from taking any other actions.”	VARA can narrow what a VASP is allowed to do. Keep operating, but fewer activities. Configurable.
CONFISCATE	NO - only fines	IX.C.2.j: “imposing fines or other civil penalties in accordance with Schedule 3.” Schedule 3: fines up to AED 50M or 15% annual revenue. If unpaid, VARA can refer to courts (Schedule 3 No.5).	VARA can fine you. They cannot directly take your crypto. Confiscation requires going to court. A fine penalizes; confiscation takes property. Different legal concepts.
SEIZE	NO - monitoring only	IX.C.2.k: “undertaking additional supervision, monitoring or reporting requirements.” IX.A-B: investigation/examination powers over records and information.	VARA can demand records and put you under enhanced scrutiny. They cannot take custody of or control client assets. Oversight is not seizure.
LIQUIDATE	NO - licence revocation only	IV.B.2.a.ii: revoke Licence if VASP “is Insolvent or subject to Insolvency Proceedings.” Schedule 4 defines insolvency as including winding up, receivership, bankruptcy.	VARA can revoke your license if you go bankrupt. The actual liquidation is a separate court process. Licence revocation ≠ on-chain liquidation.
RECOVER	NO - VASP procedures only	Custody Rulebook III.C.3: VASPs must have policies for “recovery of affected Virtual Assets” in case of lost/stolen keys. IX.C.2.h-i: public admission/suspension announcement.	VASPs must have their own recovery plans. That’s a compliance requirement, not an enforcement power. VARA cannot compel return of assets to victims.

What VARA Actually Does That’s Novel

These are the provisions worth RCP’s attention that I should have led with:

1. Conflict-of-laws rule (Regulation IV.A.4)
“If a VASP carries out any VA Activity for which it is Licensed by VARA to carry out in the Emirate in any jurisdiction outside of the Emirate… VASPs are obligated to meet the higher of the two regulatory standards at all times.”

This is unusual. Most regulators say “you must comply with our rules.” VARA says “you must comply with the stricter of our rules or the foreign jurisdiction’s rules.” It creates a genuine compliance burden for multi-jurisdictional VASPs that most frameworks don’t address.

2. Mandatory registration for large proprietary traders (Regulation IV.A.7)
Any entity trading its own portfolio at or above $250M equivalent in a rolling 30-day period must register with VARA. Not a full license - just registration. This is a transparency/surveillance mechanism for institutional-scale traders.

3. Critical Service Provider designation (Regulation IV.A.9-11)
VARA can designate technology providers, infrastructure operators, or other service providers as “critical or systemically important” and subject them to direct supervision. Most regulators regulate VASPs, not the tech companies that serve them. VARA explicitly extends its reach to service providers that are systemically important to market integrity.

4. Anonymity-Enhanced Cryptocurrency prohibition (Regulation II.C.1)
“The issuance of Anonymity-Enhanced Cryptocurrencies and all VA Activity(ies) related to them are prohibited in the Emirate.” Privacy coins (Monero, Zcash shielded) are flatly banned. Not just regulated - banned.

5. Multi-signature reserve power (Custody Rulebook III.C.2.d)
“VARA reserves the right to require VASPs to use multi-signature approaches in specific situations, including for specific types of Virtual Assets.” Most regulators recommend multi-sig. VARA can mandate it.

How This Compares to AU, EU, and US

Feature	VARA (Dubai)	AU (ASIC)	EU (MiCA)	US (SEC-CFTC)
Explicit freeze power	Yes	Yes	Yes	Through courts
Licence variation	Yes	Yes	Yes	Registration-based
Direct confiscation	No (court-dependent)	No (court-dependent)	No	No
Conflict-of-laws rule	Yes	No	Partial	No
Critical service provider oversight	Yes	No	No	No
Large trader registration	>$250M	No equivalent	No equivalent	No equivalent
Privacy coin ban	Yes	No	No	No

What VARA Brings to RCP

Honest answer: VARA supports two RCP actions (FREEZE, RESTRICT) with explicit textual authority. The other four are not directly supported. However, VARA contributes novel compliance requirements (conflict-of-laws, critical service provider oversight, mandatory registration, privacy coin prohibition) that no other regime in RCP’s existing 31 addresses.

If VARA is added to RCP’s jurisdictional coverage, it should be noted that only FREEZE and RESTRICT have direct enforcement authority. The remaining four actions would require judicial process or are not available.

I should have led with this honest assessment instead of trying to force all six actions. The document count and score data are available if useful, but the VARA regulation text above is the primary source. Happy to refine further.

Source Documents (direct PDF links from Mirror AI)

1. VARA Virtual Assets and Related Activities Regulations 2023 (50pp, 19 May 2025)

2. VARA Custody Services Rulebook (31pp, 19 May 2025)

3. VARA Technology and Information Rulebook (7 Feb 2023)

4. VARA Virtual Asset Issuance Rulebook (19 May 2025)

5. VARA Administrative Order No. 01/2022 (Marketing Regulations)

6. DFSA Rulebook - Crypto Token (DIFC jurisdiction)

[jay-oraclizer]

@Etherow911, thank you for going back to the text and revising the mapping. That was the right move, and the distinctions you drew from it hold. A fine penalises; it doesn’t move title. A power to compel records isn’t a transfer of custody. Those are the kinds of distinctions the taxonomy exists to draw.

The taxonomy boundary: The six actions aren’t a checklist of what a regulator may do. They classify the legal effect left on an asset once a lawful order is carried out, so asking whether a given authority “has” each of the six doesn’t map directly onto the taxonomy.

That applies to the two you retained. Section IX.C.2(f) lets VARA require a VASP or other entity to cease or suspend an activity. It doesn’t say a customer asset is placed under a temporary, ownership-preserving hold, which is the effect FREEZE names. Varying a licence changes what the entity may do, and that’s again a different subject from applying RESTRICT to a token or asset.

On the five provisions, I don’t find a new requirement:

AEC prohibition: Requirement 30 already cites FATF for regulatory treatment that differs according to asset characteristics, so this is another jurisdictional instance of that principle.

Multi-signature: This overlaps with Requirement 7.

Registration thresholds, regulatory perimeter, and supervision: These are operational or jurisdiction-specific matters of the kind the scope note already sets aside.

Conflict of laws: This is the most interesting of the five, but it concerns which requirements apply in a particular jurisdiction. The draft leaves precedence among authorities to the relevant off-chain legal process, and it doesn’t standardize the applicability layer above that. I’m not proposing to write it here.

The authority table is only a key to the sources actually cited under the requirements. The draft therefore stays at 31 requirements drawn from 15 authorities, with VARA remaining where it already appears in the scope note.

I haven’t assessed the cross-regime comparison, since this conclusion doesn’t depend on it, and the document counts and scores aren’t needed for the requirements base.