Comparative Architectural Analysis: ERC-3643 Permissioned Suite vs ERC-20 with Transfer Hooks

Contenuto a esclusivo scopo didattico e informativo. Non costituisce sollecitazione al pubblico risparmio né consulenza finanziaria personalizzata.

Teaching note. No instrument, issuer, or venue is identified. Progetto editoriale indipendente — non è un servizio di Valoris Institutional RWA Infrastructure / TaaS.

1. Question

Where does a permissioned transfer check live: inside a generic fungible token, in an external wrapper, or in a suite that separates identity from the balance?

This note compares two designs used in institutional classrooms:

• ERC-20, including variants that add a transfer hook or an allowlist inside the token;
• ERC-3643 (T-REX family), which splits the token, an identity registry, and replaceable compliance modules.

The comparison is architectural. It does not rank vendors and it does not describe a placement.

2. Two control planes

ERC-20 (hook or wrapper)
  holder ──transfer()──► token contract ──balance write──► recipient
                         optional hook / allowlist lives here

ERC-3643
  holder ──transfer()──► token
                           │  canTransfer?
                           ▼
                     compliance modules
                           │  isVerified?
                           ▼
                     identity registry ──claims──► ONCHAINID

ERC-20 standardises the balance and the transfer entrypoint. A hook can reject a recipient, but the decision data (who is verified, under which rule) usually sits in the same contract or in an ad-hoc wrapper. Readers of the token cannot see a stable boundary between "balance" and "permission".

ERC-3643 draws that boundary on purpose. The token asks a compliance contract before it moves a balance. The compliance contract asks an identity registry. The registry points at an identity contract that holds claims. Changing a rule means replacing or updating a module, not rewriting every balance.

3. Identity is not the token

The decoupling is the part that matters for a permissioned ledger:

Plane	Holds	Does not hold
Token	Balances, supply, agents allowed to force a transfer or freeze	The legal identity of the holder
Identity registry	Address → identity contract, plus a verified flag	The economic terms of an issue
ONCHAINID (or equivalent)	Claims issued by named parties	A trading session or a market credential
Compliance modules	Predicates: jurisdiction of the claim, holder caps, freeze	The claim store itself

A claim is an attestation. It is not a login to a trading venue, and it is not an instruction to acquire anything. Revoking a claim blocks a future transfer at the compliance layer. It does not rewrite history that has already settled inside the rules then in force.

4. What the hook version still leaves outside

An ERC-20 with a beforeTransfer hook can imitate a gate. The imitation is local:

• the allowlist is often a mapping on the token, with no separate registrar;
• there is no standard place for a third party to publish a claim;
• upgrading the rule means upgrading the token or the wrapper that every holder already points at.

That can be enough for a closed pilot with one operator. It is a weak fit when the classroom question is "who is accountable for the identity register, as distinct from the person who can pause the token?"

5. Gas cost, as a structure not a quote

A plain ERC-20 transfer writes two balances and emits an event. The permissioned path adds work before that write:

1. an external call from the token to the compliance contract;
2. a further call from compliance to the identity registry;
3. storage reads on the claim or on the verification cache.

Each external call and each cold storage read costs more gas than the balance update alone. A registry that caches a boolean isVerified avoids re-reading every claim on every transfer; the cache must be invalidated when a claim is added or revoked, and that invalidation is itself a state write paid by the registrar, not by the token holder.

No figure in this note is a measured quote for a deployment. Gas changes with the client, the module count, and whether the verification flag is warm. The architectural point is stable: the permissioned suite spends gas on an explicit check that ERC-20 does not have, and it spends that gas in contracts that can be named and replaced.

6. Limits

This paper does not specify bytecode, a compiler version, or a production parameter set. A retrospective on compartment segregation under Luxembourg securitisation law is a separate methodology case, published with the educational flag set.

Contenuto a esclusivo scopo didattico e informativo. Non costituisce sollecitazione al pubblico risparmio né consulenza finanziaria personalizzata.

Progetto editoriale indipendente — non è un servizio di Valoris Institutional RWA Infrastructure / TaaS.