Permissions

Permissions are the concrete form of the rule everything here rests on: the operator decides what to do, and the contract decides whether it's allowed. Each vault carries a fixed grant (the set of venue operations its strategy may call) and checks every proposal against it. A strategy has no standing authority of its own. What it can do is exactly what its vault grants, and nothing more.

The grant is enforced on-chain, so it holds however the vault is operated: through the runner, through the SDK directly, or by hand.

What can be granted

A grant is any subset of eight operations:

• Mint / redeem binary: open and close binary positions.
• Mint / redeem range: open and close range positions.
• Supply / withdraw PLP: add and pull protocol liquidity.
• PM deposit / withdraw: move quote capital in and out of the prediction-market manager.

Operations that can't move capital or take a position carry no permission and are always callable: a noop, refreshing the NAV snapshot, crystallizing fees.

Why it's a Layer 1 protection

Permissions sit in Layer 1, the capital floor the contract enforces, for two reasons.

• The vault owns the grant, not the strategy. It's set when the vault is created and lives on the vault, outside the strategy's reach. Swapping the strategy doesn't touch it, and a strategy can't widen its own authority.
• Changing it is governed. Widening or narrowing a grant is a timelocked upgrade with a depositor exit window, not a config edit. Depositors see the change coming and can leave first.

So a depositor doesn't have to read your code to know its blast radius. The grant is the boundary, and anything a strategy proposes outside it reverts.

Using them

Building a strategy? The Permissions reference has the bitfield, the SDK constants, how to encode a grant, and the ctx.vault.can* checks for reading it at runtime.