A control at the interface is not a control

OpenZeppelin has published a survey of how financial institutions reconcile compliance obligations with a chain that is open by default. The answer in practice is that they build the gate themselves, in onchain identity and access control.

The mechanisms in use

• Identity registries holding verified claims — KYC-verified and similar — issued by a trusted party.
• Credentials verified off-chain and attested onchain.
• Identity separated from the holding account, so one identity can cover several addresses.
• Non-transferable tokens standing for verified status.
• Allowlists inside the token contract, permissioned liquidity pools, and modular compliance components that update without redeploying the core.

ERC-3643 is named as the industry standard for the identity layer.

The line worth keeping is about where enforcement sits. A control presented at the interface is convenience; a control enforced in the contract is binding regardless of which interface a counterparty uses. Anything gated only by the front end is gated only for people using the front end.

That distinction is the audit question underneath the compliance question. If a restriction exists to satisfy a regulator, the review has to establish which layer holds it — and an allowlist in the contract and a check in the dApp look identical in a screenshot.

OpenZeppelin states 900+ audits since 2015 and more than 10,000 vulnerabilities surfaced. Read that as scale of exposure to the pattern rather than as evidence for the argument.