Approval policy
Also called: Transaction policy, Quorum approval, Four-eyes principle
Rules that decide, before anything is signed, whether a transfer goes straight out, waits for people to approve it, or is refused.
Keys protect funds from outsiders. Policies protect them from mistakes and from insiders: they decide which transfers can be signed at all. A good policy engine looks at the amount, the destination, the wallet, recent outflows and who is asking.
Common rules:
- Small payouts from your API key go through automatically.
- Anything over a limit, or to a new address, needs two people.
- Treasury wallets can send only to saved addresses.
- Whoever proposed a transfer can't approve it (the four-eyes principle).
On Valtu
Every transfer is checked against your workspace's policies before signing, and the outcome is allow, require approval from a named group, or deny, with the reason naming the rule. A policy can use the USD amount, the destination, the wallet, recent outflows and who's asking. The proposer can never approve their own transfer. Approvers confirm with passkeys, bound to the exact amount and destination. Valtu never approves or co-signs your transfers, and with team signing on the enclave checks the approvals itself. POST /v1/transfers/preview shows what your policies would do. More in how a payout gets signed.
Related terms
Keep reading.
More in key security: HSM · Remote attestation · Enclave measurement · Reproducible build · Key ceremony · Shamir secret sharing · MPC wallet. The whole glossary.
Put it into practice.
Every workspace starts on testnets with free test coins: same dashboard, same API. Go live when your team is ready.