Policy Engine
The Policy Engine is a core safety layer in The Vault. Every withdrawal is evaluated against the profile’s approval policies before reaching the MPC signing layer. If no policy allows the transfer, it is blocked — no signing session is opened and no mobile notification is sent.
Why Policy Matters
In a traditional custodial system, the custodian’s internal controls prevent bad transactions. In self-custody, those controls must be embedded in the platform. The Vault’s policy engine is that layer: it enforces rules defined by your risk and compliance team, automatically, on every transfer.
The Vault operates on a default-deny basis. If no policy matches and allows a transfer, it is rejected. You must define policies to permit withdrawals.
How Policies Work
A policy is an ordered Allow or Reject rule with a set of match conditions. When a transfer is submitted, the engine evaluates policies in priority order and the first matching policy decides the outcome — Allow (optionally requiring a number of approvals) or Reject. A transfer that matches no allowing policy is denied.
Each policy matches on any combination of:
| Condition | Options |
|---|---|
| Initiator | Any user, or a specific user |
| From | Any wallet, a specific wallet, or a wallet group |
| Blockchain | Any, or a specific network |
| Token | Any, or a specific asset |
| To | Any address, a whitelisted address, a specific address, or an address group |
| Amount less than | A threshold value in a chosen currency (USD/EUR or the native asset) |
The action is Allow or Reject. An Allow policy can also require a number of approvals — mobile signer confirmations — before signing proceeds.
Policies are created in the dashboard under Policies → Approval Policies. Because rules are evaluated in priority order with first-match-wins, order matters: put narrower/higher-priority rules above broader ones.
Amount Currency and Valuation
The Amount less than threshold can be set in a fiat currency (USD/EUR) or in the native asset. Fiat thresholds are compared using a price valuation from the wallet service (configurable provider — e.g. CoinGecko or a static price source); the valuation used for a given transfer is recorded with it.
Changing and Deleting Policies
Every change to a profile’s policies — creating one, reordering them, or deleting one — is confirmed from an enrolled mobile signer device before it takes effect. A dashboard session on its own cannot change what the policy engine enforces.
- A policy’s terms cannot be changed in place. There is no edit operation: changing what a rule says means withdrawing it and creating the replacement, each step confirmed on the device.
- Deleting a policy deactivates it. The rule stops applying immediately, and the record is kept so the history of what was in force stays reconstructable.
- One confirmation per operation. Reordering twelve policies is a single confirmation on the device, not twelve.
Policy Set Integrity
What the device signs is the resulting set of active policies, not the text of one rule: its content, its order, and how many policies it contains. Every transfer is checked against that signature before it is evaluated.
Every policy change made through the platform is confirmed on a device, so this signature is not a second check on that path — it is a check on the stored set itself. If the active set ever differs from the state a device last signed — a rule missing, replaced, reordered or added with no confirmation behind it — the Vault blocks transfers for that profile instead of evaluating them against the set it finds. A set that was not confirmed cannot be made to look confirmed either: the signing key never leaves the mobile device.
A profile in that state cannot transfer until it is resolved with support — the block is deliberate and is not cleared by retrying.
Versioning and Audit
Policy changes are versioned and browsable in the dashboard, and every policy decision (allow/reject, with the matched rule and reason) is written to the audit log — giving compliance teams a full record of what rules were in effect and why any transfer was blocked. The signed set is versioned too, and its history is append-only.