> ## 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.

# Build programmable approval policies

> Design approval tiers with M-of-N groups, route held withdrawals to approvers, and integrate approvals with your own workflow tools.

Approval is the control that puts a person between a request and a signature. This solution designs the approval tiers, creates the groups that staff them, and connects the "pending approval" moment to the tools your approvers already use, so a held withdrawal is seen and decided quickly.

## What you'll need

* The approval matrix your policy requires (which amounts, which approvers, how many).
* Approver accounts in the workspace with **Admin** or **Owner** roles.
* Optionally, a workflow or chat tool that can receive webhooks.

## Components to configure

| Component              | Role                                                                                                           |
| :--------------------- | :------------------------------------------------------------------------------------------------------------- |
| **Approval groups**    | Named sets of approvers with an M-of-N requirement.                                                            |
| **Approval threshold** | The amount above which a group must approve.                                                                   |
| **Approval events**    | `withdrawal.pending_approval` and `signing.pending_approval` notify your systems the moment a request is held. |
| **Console approvals**  | **Approvals → Pending Withdrawals**, where approvers act.                                                      |
| **Audit log**          | Who approved or rejected, and when.                                                                            |

## Steps

<Steps>
  <Step title="Design the tiers">
    Decide the amount bands and who approves each. A common shape: below X automatic within limits; X to Y one approver from *Treasury approvers*; above Y two approvers. Keep the number of distinct groups small; approvers who sit in many groups approve by habit.
  </Step>

  <Step title="Create the groups">
    Under **Approval groups**, create each group with **New group**, add its members, and set **Approvers needed**. Every member must already be a workspace user with a role that can approve.
  </Step>

  <Step title="Attach the threshold">
    Enable **Require approval to withdraw**, set **Require above amount** and select the group. A withdrawal at or above the amount moves to `pending_approval` after passing limits and destination rules; below it, no approval is requested.
  </Step>

  <Step title="Notify approvers where they work">
    Register a webhook for `withdrawal.pending_approval` and `signing.pending_approval`. Post the wallet, amount, destination and a link to **Pending Withdrawals** into your approvers' channel or ticketing system. The decision itself is made in the console by a signed-in approver; the webhook only carries the notice.
  </Step>

  <Step title="Approve, reject, and record">
    Approvers open **Approvals → Pending Withdrawals** and **Approve** or **Reject**. When the required number have approved, the withdrawal proceeds to signing and `signing.resumed` fires; a rejection ends it with `withdrawal.cancelled` or `signing.rejected`. The audit log records each decision with its actor.
  </Step>

  <Step title="Test the unhappy paths">
    In the sandbox, confirm that a request needing two approvals does not proceed after one; that a rejection is final; and that a requester who is also an approver cannot satisfy the requirement alone if your policy forbids it. If the platform does not enforce that separation for your configuration, keep requesters out of the approving group.
  </Step>
</Steps>

## Considerations

* Approvals are exercised by people in the console; there is no API to approve, so a compromised service key cannot approve its own requests.
* A pending withdrawal holds its amount against the balance until decided, so a backlog of unapproved requests reduces what else can be sent.
* Pair approval with **Dual control** on configuration, so the threshold cannot be raised by a single administrator to slip a payment under it.

## Related

* [Define treasury policies](/solutions/compliance/define-treasury-policies)
* [Govern wallet access](/solutions/custody/govern-wallet-access)
* [Policies & approvals](/wallets/policies-and-approvals)