Policies

Policies add automated governance rules to Flex vaults. They enforce constraints on transactions before they can be approved — like spending limits, destination whitelists, and cooldown periods.

Note

Policies are only available on Flex vaults. Standard vaults rely on the full-signer MPC ceremony for governance.

How policies work

When a transaction is created in a Flex vault, it is evaluated against all active policies. Policies can:

• Block a transaction that violates a rule
• Require additional approvals beyond the vault threshold
• Enforce cooldown periods between transactions

Policies are additive — if multiple policies apply to a transaction, all of them must pass.

Policy types

Spending limits

Set maximum amounts that can be transferred in a single transaction or over a time window:

• Per-transaction limits
• Daily/weekly/monthly cumulative limits
• Limits by token or across all tokens

Address whitelists

Restrict transactions to a set of pre-approved destination addresses. Transactions to addresses not on the whitelist are blocked.

Cooldown periods

Enforce a mandatory waiting period between when a transaction is approved and when it can be signed. This gives team members time to review and flag suspicious activity.

Additional signer requirements

Require a higher number of approvals for transactions that exceed certain thresholds, beyond the vault’s default approval threshold.

Policy lifecycle

Policies follow an approval-based lifecycle:

PENDING → ACTIVE → DEACTIVATED
        → REJECTED

State	Description
Pending	Policy has been proposed and is awaiting signer approvals
Active	Policy is enforced on all transactions in the vault
Deactivated	Policy is temporarily disabled but can be reactivated
Rejected	Policy was rejected by vault signers

Creating a policy

An Initiator (or higher role) proposes a new policy. It enters the PENDING state and requires approval from vault signers (same threshold as the vault):

curl -X POST https://api.tholos.app/vault/{vaultId}/policies \
  -H "Authorization: Bearer $THOLOS_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Daily spending limit",
    "conditions": [...],
    "authorizedSigners": [1, 2, 3]
  }'

Approving a policy

Vault signers approve or reject the policy using an MPC challenge-response flow:

1. Get challenge — GET /policy/{id}/challenge
2. Approve — POST /policy/{id}/approve
3. Or Reject — POST /policy/{id}/reject

Once the threshold number of approvals is met, the policy becomes Active.

Editing a policy

Active policies can be edited without downtime. An edit creates a pending proposal while the current policy remains enforced:

1. Submit edit — POST /policy/{id}/edit
2. Approve edit — signers approve via POST /policy/{id}/edit/{editId}/approve
3. When the threshold is met, the edit is applied atomically

Deactivating and reactivating

• Deactivate — POST /policy/{id}/deactivate (requires Initiator role, then signer approvals)
• Reactivate — POST /policy/{id}/reactivate (same approval flow)

Key API endpoints

Operation	Method	Endpoint
Get policy	GET	/policy/{id}
Get approvals	GET	/policy/{id}/approvals
Get challenge	GET	/policy/{id}/challenge
Approve policy	POST	/policy/{id}/approve
Reject policy	POST	/policy/{id}/reject
Deactivate policy	POST	/policy/{id}/deactivate
Reactivate policy	POST	/policy/{id}/reactivate
Delete policy	DELETE	/policy/{id}
Submit edit	POST	/policy/{id}/edit
Get pending edit	GET	/policy/{id}/edit
Approve edit	POST	/policy/{id}/edit/{editId}/approve
Reject edit	POST	/policy/{id}/edit/{editId}/reject
Cancel edit	DELETE	/policy/{id}/edit/{editId}