> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockops.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Define treasury policies

> Turn a written treasury policy into limits, destination rules and approval thresholds the platform enforces on every withdrawal.

A treasury policy is only as good as its enforcement. This solution maps the clauses a treasury or risk committee typically writes (who can pay whom, how much, and with whose sign-off) onto the controls the platform evaluates on every withdrawal request, before anything is signed.

## What you'll need

* Your written treasury policy or the decisions it would contain.
* Owner or admin access to the console with dual control enabled.
* The addresses of approved counterparties.

## Components to configure

| Policy clause                                               | Platform control                                                                                       |
| :---------------------------------------------------------- | :----------------------------------------------------------------------------------------------------- |
| "Funds may only be sent to approved counterparties."        | **Only allow whitelisted addresses** with the **Address Book**.                                        |
| "A new counterparty must be approved before first payment." | **New address timelock**: an address added to the whitelist becomes usable only after the hold period. |
| "No single payment above X without approval."               | **Require approval to withdraw** with **Require above amount** X and an approval group.                |
| "No more than Y per transaction / Z per day."               | **Spend limit**: **Per transaction** and **Per day**.                                                  |
| "Policy changes require two administrators."                | **Dual control**.                                                                                      |
| "If records and chain disagree, stop."                      | **On balance drift**: block, or alert only.                                                            |
| "In an incident, halt all outflows."                        | **Freeze withdrawals** under **Emergency**.                                                            |

## Steps

<Steps>
  <Step title="Enable dual control first">
    Turn on **Dual control** before configuring anything else, so the rest of the configuration (and any later loosening) needs a second administrator.
  </Step>

  <Step title="Build the address book and enforce it">
    Add every approved counterparty to the **Address Book** with a label your auditors will recognise, then enable **Only allow whitelisted addresses**. Set the **new address timelock** to the notice period your policy requires for new counterparties.
  </Step>

  <Step title="Set the limits">
    Set **Per transaction** and **Per day** to your policy's ceilings. Requests above either are rejected outright, before any approval logic; approvals cannot override a limit.
  </Step>

  <Step title="Set the approval threshold">
    Enable **Require approval to withdraw**, set **Require above amount**, and choose the approval group and **Approvers needed**. Below the threshold, withdrawals proceed automatically inside the limits; above it, they wait.
  </Step>

  <Step title="Decide the drift behaviour">
    Choose whether a discrepancy between the platform ledger and chain state blocks withdrawals or only alerts. Regulated treasuries generally block.
  </Step>

  <Step title="Test against the sandbox, then document">
    Replay each policy clause as a sandbox withdrawal and record the outcome (rejected, held, or allowed) as your control-test evidence. The audit log records each configuration change with the two administrators who made it.
  </Step>
</Steps>

## Considerations

* The order of evaluation is: scope of the key → freeze → destination rules → limits → approval → signing. A request stops at the first control it fails and the reason is returned to the caller.
* Limits are evaluated against the platform's ledger of outbound value in the asset's units; keep them per asset in mind when a treasury holds several.
* Loosening a rule takes effect for new requests only; a withdrawal already held for approval is evaluated under the rules in force when it was requested.

## Related

* [Build programmable approval policies](/solutions/compliance/build-programmable-approval-policies)
* [Policies & approvals](/wallets/policies-and-approvals): every control in detail.
* [Automate payments](/solutions/payments/automate-payments)