Open-transfer model with reactive enforcement

Two places to put the check

Every regulated-transfer design has to decide where the rule is evaluated. Before the transfer, so a non-compliant transfer cannot execute at all. Or after it, so transfers are unconstrained and the issuer intervenes on specific addresses once there is cause. That single placement decision produces almost every downstream difference between the two models.

The open model treats the token as ordinary and the enforcement as exceptional. The permissioned model treats every transfer as something to be authorised. Neither is a compliance outcome by itself. Both are design patterns that a legal team then has to sign off against a specific obligation in a specific jurisdiction.

What USDC actually implements

Circle publishes the contract. In the stablecoin-evm repository, transfers are standard ERC-20 transfer and transferFrom calls with no allowlist consulted, and a separate privileged blacklister role can add an address to a blacklist that blocks it from sending or receiving.¹ There is no identity check in the transfer path, which is exactly why the token composes with anything that speaks ERC-20.

The consequence is legible and worth stating plainly to a board. The issuer holds a freeze capability over any holder, which is a real centralization surface and belongs on the admin capability matrix. And the freeze cannot reach value that has already left the address. Both facts are properties of the same design choice.

What the permissioned model does instead

EIP-3643, the T-REX standard, describes itself as an institutional grade security token standard providing interfaces for the management and compliant transfer of security tokens, using an automated on-chain validator system built on on-chain identities.² The maintaining association's documentation sets out the same architecture: an identity registry recording who is eligible, and a compliance contract encoding the rules, both consulted before a transfer can settle.³

That closes the enforcement window. A transfer to an ineligible address does not partially happen. The price is that the token now reverts in any context that does not know about the registry, which rules out permissionless pools, generic lending markets and most bridges.

Choosing between them without regretting it

Write down the venues the token has to reach before picking the model, not after. If the answer includes a permissionless automated market maker or a lending market you do not control, the permissioned path is closed and the open model with reactive enforcement is the design you are choosing, along with its window. If the answer is a defined set of institutional counterparties on a venue you integrate with, the permissioned path costs little and removes the window entirely.

The pattern we see across the 100+ projects we have advised is the decision arriving backwards: a token standard selected on the strength of a demo, then a distribution plan written against venues that standard cannot enter. Fixing that after deployment means a migration. Deciding it in an afternoon, before any contract exists, costs an afternoon.

One boundary worth holding. Neither model makes a token compliant, and describing either as compliant with a named regulation is a claim we do not make. They change what enforcement is mechanically possible. Whether that satisfies an obligation is your legal team's determination, and nothing here is legal advice.