Transfer restrictions are the part of tokenization that genuinely works. The rule travels with the asset, enforced at the moment of transfer, instead of living in a side agreement that nobody reads at the moment it matters. It is the clearest operational gain the format offers.
The gain stops at a specific place: the token can enforce a rule about who may hold it, but it cannot establish who anybody is. That has to be asserted by an institution that checked, and those assertions do not travel.
Two different things called compliance
It is worth separating them, because they fail differently.
- The rule. Only holders meeting a test may hold this. Machine-readable, deterministic, and enforceable by the token on any network where it can refuse a transfer.
- The evidence. That this particular person meets the test. Established by documents, checks and human judgement, held by whichever institution did the work.
Tokenization solved the first and inherited the second unchanged. A holder verified by one institution generally has to be verified again by the next, producing the same documents, paying for the same checks, and waiting again.
Why the obvious answers do not work yet
The shape of a solution is easy to describe: an institution that has verified someone issues a signed, verifiable statement — this person is eligible under this definition, checked on this date, valid until this one — which the holder presents elsewhere without revealing the underlying documents. The technology for this exists and has for years.
What does not exist is the part that makes it useful:
- Agreement on the definition. “Professional investor” is not one test; it is a dozen similar tests in a dozen regimes, with different thresholds and different evidence.
- Willingness to rely. An institution accepting another institution’s check is accepting its liability. Regulators generally permit reliance only on narrow terms, and firms are understandably reluctant to depend on someone else’s file when the consequence of it being wrong falls on them.
- Revocation. Eligibility expires and is withdrawn. Any credential that can be presented must also be checkable as still valid, which means a live service, which means somebody operating and funding it.
- Privacy. A credential that reveals which institution verified you, when, and for what, leaks a great deal about a holder across the venues where it is presented.
Every one of these is an institutional and legal problem with a technical component, which is the wrong way around for a problem to be solved quickly.
What can be built in the meantime
Treating the gap as permanent for now produces better designs than waiting for it to close.
Make the rule explicit and publishable. State, with the asset, exactly what the eligibility test is and which networks can enforce it. An issuer who cannot answer that has a restriction in name only.
Keep the evidence where the liability is. The institution that carries the regulatory consequence should hold the file. Software should hold the outcome — eligible or not, under which definition, as at which date — and be able to show its history.
Design for re-verification rather than against it. If a holder will be checked again at the next venue, the useful thing is to make that check fast: consistent definitions, clear expiry, and a record of what was established the first time, even if the next institution redoes the work.
Expect the restriction to outlive the venue. Enforcement at the token survives the asset moving somewhere its issuer did not anticipate. Enforcement at the venue does not.
Why this is on the open list
Portable eligibility is the difference between a tokenized interest that can change hands and one that is issued and then sits. It is not something any single participant can supply: it needs an accepted definition, a regime that permits reliance, and enough institutions willing to accept each other’s work. We can be ready for it. We cannot provide it, which is why it appears on the open problems list rather than the roadmap.