Vault Access Control
Orion vaults support three optional access-control slots. Each slot is an independent smart contract. Managers use them to restrict who may deposit, who may hold vault shares, and who may transfer shares between wallets without changing core vault logic. address(0) on a slot means that dimension is permissionless.
Three access-control slots
| Slot | Protocol interface | Checked when |
|---|---|---|
| Deposit | IOrionDepositAccessControl | An address calls requestDeposit |
| Holder | IOrionHolderAccessControl | Shares are minted to an account or transferred to an account |
| Transfer | IOrionTransferAccessControl | Shares are transferred from an account (P2P transfers) |
Redemptions are not gated by access control.
Configuring access control
Set all three addresses at vault creation (depositAccessControl, holderAccessControl, transferAccessControl). The manager may update any slot later via setDepositAccessControl, setHolderAccessControl, and setTransferAccessControl.
A single contract may implement one, two, or all three interfaces. Pass the same address to multiple slots when the policy should apply uniformly (e.g. whitelist on deposit, hold, and transfer).
Deploying a controller
Implementations live in protocol-plugins (contracts/access_controllers/, contracts/strategies/). Deploy with that repo’s CLI: copy .env.example to .env in protocol-plugins and set PRIVATE_KEY and SEPOLIA_RPC_URL. Then, for example:
PLUGIN=whitelist OWNER=0x... pnpm deploy:sepolia
WhitelistAccessControl can be passed to deposit, holder, and transfer. Stateless gates such as manager-only and non-transferable are safe to reuse network-wide; whitelist instances are typically per-manager.