Onchain compliance is enforced at three points: the token, deciding who may hold it; the pool or vault, deciding who may enter and exit; and the distribution channel, the branded entry point that decides who sees the product at all. A requirement lands at one of those three, and where it lands changes what the architecture has to do.
Key takeaways
- ERC-3643 puts the check before the transfer.
isVerifiedconfirms the receiver holds the required claims andcanTransfervalidates the offering's rules, both evaluated before execution rather than reported afterwards. - KYC gating proves that an address passed an identity check at some point. It does not prove who controls the address now, what the capital is doing after entry, or that the strategy stayed inside its mandate.
- Every permission carries a composability cost. A gated share is a share that a lending market cannot accept as collateral, and that cost should be priced deliberately rather than discovered later.
Just the basics
A regulated institution cannot simply send money to a smart contract and hope. It has rules about who it can transact with, who may own a product, the jurisdictions it must exclude, and the records it must be able to produce. Onchain, none of that is automatic. Someone has to decide where the check happens: inside the token itself, at the door of the fund, or at the application the investor logs into, and each of those answers produces a different system with different limitations, so the choice is worth making deliberately.
What's in this article?
- What is a compliance layer in onchain finance?
- Translating a compliance requirement into architecture
- Where can compliance actually be enforced?
- What does KYC gating prove, and what does it not?
- Can you prove capital stayed within mandate?
- The composability cost of permissioning
- What is genuinely unsettled?
- How does Railnet fit?
- What should you do next?
What is a compliance layer in onchain finance?
It is the set of checks that run before a transaction executes, plus the record the system produces afterwards. Both halves matter: a control that only blocks is not auditable, and a record that only reports is not a control.
The pre-execution half is well specified. ERC-3643 provides "a library of interfaces for the management and compliant transfer of security tokens, using an automated onchain validator system leveraging onchain identities for eligibility checks", and it has been Final since 2021. Its structure is worth learning even if you never deploy it, because it names the parts that any compliance design has to have somewhere.
An identity registry maps a wallet address to an identity contract and an ISO-3166 country code, maintained by agents who register and remove holders. A separate compliance contract holds the offering's rules, things like maximum investors per country, token caps per investor and the list of accepted jurisdictions, and returns a simple yes or no. Two functions run before a transfer: isVerified confirms the receiver holds the required claims from trusted issuers, and canTransfer validates the global rules.
The design decision embedded there is the separation of identity from policy: who you are is a durable fact attested by a claim issuer, while what you may do is a rule the issuer can change without reissuing anyone's identity. Systems that collapse the two into a single allowlist work until the policy changes, and then every holder has to be re-processed.
The standard also includes the parts nobody puts in a diagram. Agents can execute forced transfers that "bypass investor eligibility checks", along with freeze and recovery functions intended to support regulatory obligations. That capability exists because a transfer agent in traditional markets can also move a position without the holder's consent, on a court order or after a lost-key attestation, so bringing the compliance model onchain means bringing that power onchain too, and an allocator should know it exists before holding the token rather than after.
Translating a compliance requirement into architecture
Start from the obligation and work down to the enforcement point, rather than starting from a standard and hoping it covers the obligation.
- Name the obligation and the party who owes it. "Non-US investors only" owed by the issuer is a different system from "no counterparties on a sanctions list" owed by the platform. The second travels with every transaction; the first travels with the holder.
- Decide whether the rule is about holding or about doing. A rule about who may own the instrument belongs at the token, a rule about who may subscribe or redeem belongs at the vault, and a rule about who may see and access the product belongs at the distribution channel.
- Decide whether the check is pre-execution or post-hoc. Anything that must never happen has to be a pre-execution check, because an onchain transaction cannot be recalled, while anything that must be demonstrable belongs in the record, and the two are separate builds.
- Choose the enforcement point and accept its blast radius. A token-level restriction constrains every venue that touches the token, including venues you do not control. A vault-level gate constrains only that vault. Picking the narrowest point that satisfies the obligation is usually correct.
- Decide who can change the rule, and how fast. A compliance control that a single key can disable is a compliance control in name. Timelocks and role separation are part of the control rather than decoration around it.
- Decide what the record has to show, and to whom. An auditor, a depositary and a regulator ask different questions. Design the export before the first deposit, because reconstructing a position history after the fact is where onchain funds lose weeks.
- Price the composability you are giving up. Every restriction removes venues from the strategy's opportunity set. That is a real cost to the mandate's return profile and it should appear in the investment case rather than as a surprise during implementation.
Where can compliance actually be enforced?
Compliance can be enforced at the token, at the pool, or at the distribution channel, and most designs need two of the three; the common mistake is putting a rule at a broader point than the obligation requires.
| Enforcement point | Mechanism | What it can enforce | What it cannot | Blast radius |
|---|---|---|---|---|
| Token | Identity registry plus a compliance contract, with isVerified and canTransfer evaluated before every transfer |
Who may hold, jurisdictional exclusion, investor counts and caps per holder | What the holder's capital does once inside a strategy | Every venue that touches the token, everywhere |
| Pool or vault | Entry and exit gates. Morpho's V2 vaults expose four: receiveSharesGate, sendSharesGate, receiveAssetsGate and sendAssetsGate, restricting who may receive shares, send shares, receive underlying assets and deposit assets respectively |
Who may subscribe, who may redeem, who may receive the payout | Anything about the venues the vault allocates to | One vault, plus anyone holding its shares |
| Distribution channel | Role-based access on the branded entry point, which Railnet's documentation calls a conduit. Railnet's external access control supports global roles, roles scoped to a specific contract, and public roles, with permissions such as deposit and redeem query creation | Who may access this distribution channel, at what fee, under whose terms | Who may hold the underlying instrument if it moves elsewhere | One distribution channel |
Two details from those mechanisms change how a design should be written.
The first is abdication. Morpho's gates can be set permanently: a curator can abdicate a gate to the zero address so that the vault can never have that gate type imposed on it, or abdicate to a deployed gate contract to lock the vault into a non-modifiable access policy. The documentation is explicit that "this guarantee is only meaningful if the gate contract itself has immutable behavior". An immutable pointer to a mutable policy is not immutability, and that distinction is exactly the sort of thing a depositary will ask about.
The second is scoping. Railnet's access control encodes a scoped role as keccak256(abi.encodePacked(role, scope)), so granting a deposit permission globally lets the holder create deposit queries on every yield source, while the scoped version confines it to one. The admin role can never be made public. Granting broadly because it is easier is the single most common way a permission model becomes fiction.
What does KYC gating prove, and what does it not?
It proves that an address was associated with a verified identity at the time the claim was issued. That is a real and useful fact. It is also narrower than the sentence most product pages imply.
What a gate does establish: the holder passed an identity check performed by an issuer the offering trusts; the holder's jurisdiction is recorded in a form the compliance contract can evaluate; and the transfer that just occurred satisfied the offering's rules at the moment it executed. Under ERC-3643 those claims come from trusted issuers and are attested against an onchain identity, a stronger artefact than a database row at a platform because the check and the record are the same object.
What it does not establish, and here the honest list is longer:
- Current control of the address. A verified wallet can change hands. Key custody is a separate discipline from identity verification, and no gate observes it.
- Source of funds. Eligibility to hold and provenance of capital are different questions with different evidence.
- Behaviour after entry. Once capital is inside a strategy, the token gate has no further say. What the strategy then does with the money is a mandate question, not an identity question.
- That the offchain leg matched the onchain one. Where a product settles to fiat, the compliance surface extends into a banking relationship the chain cannot see. Ondo's USDY documentation is a plain example of that boundary: the issuing entity "can only redeem USD via bank wire to non-US bank accounts", with USDC redemption running through a separate entity.
There is also an operational consequence worth designing for. A compliance check can be the reason a transaction is waiting rather than the reason it failed. STEAM, Railnet's settlement model, handles this directly, with a state for a Query "awaiting an external condition (cooldown, oracle, KYC)". A system that cannot distinguish "blocked because ineligible" from "waiting on a check" produces support tickets and, worse, produces a record that cannot explain itself later.
Can you prove capital stayed within mandate?
This is the question institutions ask and the one the market answers least well: access control governs who gets in, while a mandate governs what happens next, and almost nothing in the standard toolkit speaks to it.
Concretely, a mandate says things like: no more than a set share in any one venue, no exposure to a named category, minimum liquidity maintained, no collateral below a stated quality. An identity registry cannot express any of that. A gate cannot either, because gates are about parties rather than positions.
The parts that do exist sit in allocation policy rather than compliance. Morpho's V2 vaults let a curator cap exposure to an abstract risk identifier rather than to a market, including relative caps such as a maximum share of the vault allocated to markets using a specific oracle, with potentially harmful curator actions protected by configurable timelocks between zero and three weeks. Role separation supports the same goal from the other side: a curator configures adapters, caps and fees, while an allocator moves assets only within those bounds. A limit encoded as a cap and enforced by the contract is a mandate control, whatever it is called in the documentation.
Proof, as opposed to enforcement, needs a continuous record rather than a snapshot. Under Railnet's accounting model every asset movement is recorded as a transfer between sectors following double-entry principles, with the total of accounted assets held constant across the transition. A ledger with that property can answer "what was the exposure on 14 March" without reconstruction, and that is the actual form of the auditor's question.
The honest position: pre-execution mandate enforcement is possible for anything expressible as a cap or an allowlist of venues, and it is not yet possible for the qualitative clauses that real mandates contain. Nobody in this market has solved "no exposure to strategies whose primary return source is protocol emissions" as a contract-level check, and it is more honest to treat that gap as an open engineering problem than as a feature waiting to be listed. If you are working through what your mandate can and cannot be encoded as, talk to the Railnet team.
The composability cost of permissioning
Every restriction removes the instrument from some venue's eligible set, and the removals compound. This is the cost that gets discovered during integration rather than during design.
A permissioned share token cannot be posted as collateral in a lending market that has no way to satisfy the transfer check, cannot be routed through an automated market maker whose pool contract is not a verified holder, and cannot be wrapped by a generic ERC-4626 adapter without the wrapper becoming the holder of record, an arrangement that usually defeats the point of the restriction. None of these is a flaw in the standard. They follow from the fact that a transfer restriction, by construction, restricts transfers.
The costs are not symmetrical across enforcement points, and that is why step four of the translation sequence matters. A token-level restriction is the most powerful and the most expensive, because it constrains every venue everywhere and forever, while a vault-level gate confines the cost to that vault's shares. A role at the distribution channel confines the cost to one channel and leaves the underlying instrument fully composable, so access control at the channel is the right answer more often than the compliance-first instinct suggests.
There is a second cost that is easier to underestimate. Permissioned instruments have smaller holder sets, so secondary liquidity is thinner and the exit assumption in the risk framework has to be revised downward. Ondo's OUSG illustrates the shape: tokens can be freely transferred between investors already onboarded to the relevant products, and instant redemption runs above a $5,000 minimum subject to daily limits, with larger amounts using the non-instant route. The universe of eligible transferees and the size of the instant path are both part of the liquidity profile, and both are consequences of the permission model rather than of market conditions.
For allocators, the scale of the permissioned market is now large enough that the tradeoff is a live portfolio question rather than a theoretical one: as of 27 July 2026, rwa.xyz tracked $16.20bn of distributed value across 85 tokenized Treasury funds.
What is genuinely unsettled?
Several important questions remain open, and they come up in every institutional diligence process without yet having a settled answer.
Start with the transfer agent. The identity registry performs the function, but whether the entity operating it carries the regulatory role, and in what jurisdiction, depends on the offering and is frequently negotiated rather than determined. The next is what forced-transfer power implies for the holder: a standard that includes agent-executed transfers bypassing eligibility checks, plus freeze and recovery, has moved a traditional intervention power onchain. The governance around when that power may be used is a matter of the offering documents, not the standard, and the quality of those provisions varies a great deal.
Then there is the perimeter. If a permissioned token is held by a vault, and the vault's shares are held by a second vault, the identity of the ultimate beneficial holder is several hops from the check, and whether the original restriction has been satisfied in substance is a live question with an answer that is architectural as much as legal. The larger version of it is whether the strategy itself, rather than the instrument, is the regulated object. Access controls govern the instrument. Regulators may look at the arrangement. Whether the arrangement itself is the regulated object is genuinely open in most jurisdictions.
The last of these, and the least discussed, is loss allocation. If an ineligible holder acquires a position because a claim issuer erred, the unwinding is a legal process with no onchain equivalent, and nobody has published a good answer, so allocators should ask the question during diligence rather than after.
How does Railnet fit?
Railnet is the operating layer for onchain asset management. It is vault infrastructure, the layer that holds a strategy with its state, settlement and access control, and that is where compliance is a configuration rather than a rewrite.
The architecture separates three concerns that are otherwise entangled. Yield sources are wrapped by adapters, and strategies are the allocation logic a manager builds. Branded entry points carry their own fees, compliance and access control, so the same strategy can be distributed to a retail-facing platform and to a permissioned institutional channel without duplicating the strategy. Access control is role-based and scopable, so a permission can be granted for one yield source rather than all of them, and the admin role can never be made public.
Compliance also appears where it belongs in the settlement model rather than only at the door. A Query awaiting a KYC condition sits in a defined waiting state alongside cooldowns and oracle waits, so a compliance delay is legible in reporting instead of appearing as a stalled transaction. Implementation detail is in the conduit compliance documentation and the access control reference.
What should you do next?
Write the obligation list before evaluating any standard. For each line, say who owes it, whether it concerns holding or doing, and whether it must be blocked or merely recorded. The resulting document determines the architecture, and it is short enough to produce in an afternoon.
Then decide the enforcement point for each line using the narrowest option that satisfies the obligation, and write down the composability you are giving up in each case. The risk dimension of the same choices is covered in a risk framework for onchain allocation.
See all questions on permissioned DeFi
FAQ
What is a DeFi compliance layer?
The set of checks that run before a transaction executes, plus the record produced afterwards. Both are needed, because a control that only blocks cannot be audited and a record that only reports prevents nothing. Enforcement lands at the token, the vault or the distribution channel, and the choice determines what the system can and cannot restrict.
How is compliance enforced onchain?
Through pre-execution validation. ERC-3643 evaluates isVerified on the receiver's claims and canTransfer on the offering's rules before a transfer completes, with identity held in a registry and policy held in a separate compliance contract. Vault-level gates and roles at the distribution channel apply the same idea at narrower scopes.
What does KYC gating actually prove?
That an address was associated with a verified identity when the claim was issued, and that the transfer satisfied the offering's rules at execution, but not who controls the address today, where the funds came from, or what the strategy does with the capital after entry. Those are separate controls.
Can a mandate be enforced onchain?
Partly. Anything expressible as a cap or an allowlist of venues can be encoded, including relative caps such as a maximum share allocated to markets using one oracle, with timelocks on changes. Qualitative mandate clauses have no contract-level equivalent yet, and no one in the market has solved that.
What does permissioning cost?
Composability. A restricted share cannot be posted as collateral in a market that cannot satisfy the transfer check, cannot be routed through pools whose contracts are not verified holders, and has a smaller set of eligible transferees, thinning secondary liquidity. Token-level restrictions carry the widest cost, roles at the distribution channel the narrowest.
Where should the check live: the token, the vault or the distribution channel?
At the narrowest point that satisfies the obligation. A rule about who may own the instrument belongs at the token. A rule about who may subscribe or redeem belongs at the vault. A rule about who may access this particular product belongs at the distribution channel, and that option leaves the underlying instrument composable.
What is still unresolved?
Who carries the transfer agent role when a contract performs the function, how far a compliance perimeter reaches through a composed position, whether the arrangement rather than the instrument is the regulated object, and who bears the loss when a compliance control fails. Ask about each during diligence; none has a settled market answer.
Talk to the team
Railnet works with asset managers and platforms distributing the same strategy through channels with different compliance requirements. If you are deciding where a control belongs, or what your mandate can be encoded as, talk to the team. There is no form to fill in first.