Modular Permissioning for Onchain Vaults

ETP issuers, structured-product teams, CASPs and fintechs face a recurring product-architecture tension.

Build on fully open vaults? Compliance teams ask how investor eligibility, sanctions screening, and per-client onboarding will be enforced onchain. Adopt a monolithic security-token architecture? Product teams worry about losing the composability and global distribution that make onchain vaults attractive in the first place.

Orion's answer is modular permissioning at the vault layer: access controllers that keep vaults open by default and apply policy only where the product requires it.

Access Controllers in the Vault Stack

In Permissionless Consensus for Robust Institutional Onchain Finance, we argued that institutional controls belong at the application layer rather than at consensus.

Building on that thesis, Orion now supports generalized access controllers as composable plugins: a product architecture that lets issuers and distributors operate on open infrastructure while enforcing policy where their offering requires it.

Permissionless by Default, Permissioned When Needed

An Orion vault begins with no access controllers attached. That default matters for product design: a strategy can launch globally composable, then tighten specific dimensions as distribution, regulation, or capacity constraints emerge.

When controllers are added, they apply only to the surfaces the manager selects. For example, a vault might:

• accept deposits from credentialed investors but restrict secondary transfers;
• cap total strategy capacity through deposit-level controllers while allowing existing holders to remain;
• run a manager-only rehearsal phase, then open deposits while keeping shares non-transferable;
• enforce per-client onboarding for a CASP white-label book without rebuilding the underlying vault architecture.

Three Permissioning Dimensions

Access policy on Orion vaults is expressed across three independent dimensions, each of which can carry its own controller:

Enforcement at the Share Layer

Vault shares are ERC-20 tokens. Orion enforces access policy at the lowest state-transition hook: this means that policy is bound to ledger state change, not to a single user-facing function name.

function _update(address from, address to, uint256 value) internal override {
    _checkAccessControllers(from, to, value);
    super._update(from, to, value);
}

Modular Policy Catalog

Access controllers are available as plugins in Orion's protocol-plugins library. Each plugin implements a narrow policy; vault managers compose them as needed. The catalog below is a summary of what can be implemented.

Compliance and identity

• Whitelist and blacklist: allow or deny specific addresses, including sanctions screening at deposit, holding, or transfer.
• Credential-based controllers: require a held credential (for example, an NFT representing onboarding status) before an action is permitted.
• Attestation-backed policies: verify onchain eligibility proofs issued under a defined schema.
• Signed authorization tickets: accept time-bound, revocable authorizations signed offchain and verified onchain.
• Namespace membership: restrict access to addresses within a defined identity namespace or subtree.

Product and capacity

• Manager-only access: limit participation to the vault manager during launch or rehearsal.
• TVL-cap deposit policies: stop new deposits once strategy capacity is reached.
• Non-transferable shares: allow holding while blocking secondary movement.

Controllers are composable: a distributor might combine a credential controller for client onboarding with a blacklist controller for sanctions screening and a TVL cap for strategy capacity. None of this requires embedding a single monolithic compliance module inside the vault contract.

Use Case: CASP White-Label, Per-Client Onboarding

A CASP or fintech distributing managed portfolios to heterogeneous clients faces a concrete permissioning problem. Each client may require different onboarding evidence, jurisdiction constraints, or capacity limits, while the underlying strategy architecture should stay consistent.

With modular access controllers, the distributor can:

• attach credential or attestation controllers that reflect per-client onboarding;
• enforce blacklist screening on deposits and transfers;
• cap deposit capacity per product sleeve;
• leave other vault surfaces open when policy allows.

The issuer retains a standard vault product; the distributor enforces client-level policy within that same architecture. Compliance and legal teams can review which controllers apply to which surface, rather than relying on offchain attestations that the chain does not enforce.

Rehearse Permissioning in the Digital-Twin Sandbox

Permissioning configuration is part of product feasibility, not an afterthought. In Orion's Digital-Twin Sandbox, vault managers and issuers can deploy vaults, attach access controllers, and walk through deposit and transfer policy on testnet before a live book is proposed.

That rehearsal answers whether a technical setup is feasible, scalable, and competitive under the institution's compliance and distribution constraints, a question a return backtest or a paper trading account cannot answer on its own.

References

• Orion Finance Research. Permissionless Consensus for Robust Institutional Onchain Finance.
• Orion Finance Research. Digital-Twin Sandbox: Paper Trading for Onchain Portfolio Management.
• Ethereum Improvement Proposals. ERC-3643: T-REX - Token for Regulated EXchanges.
• Morpho. Gates.
• Uniswap Labs. Uniswap v4 Hooks.