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.