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

> ## Agent Instructions
> Bitnob API requests authenticate with an `X-Auth-Client` API key header against https://api.bitnob.com.
> Always use the sandbox environment for testing. Never put live API keys in sample code.
> Money amounts are integers in the smallest unit of the currency (satoshis for BTC, cents for fiat). Never use floats.
> Every state-changing request takes a client-supplied `reference` and must be treated as idempotent on retry.
> Quotes expire. Re-quote rather than reusing a stale quote id.

# Transaction policies on Bitnob Enterprise

> Policies are ordered rules the Bitnob Secure Enclave checks before it signs. Use them to block, hold, delay, or flag transactions.

A policy is the set of rules your organization enforces on every signing request. The Bitnob Secure Enclave evaluates the policy before it produces a signature, so a rule that blocks a transfer blocks it in hardware, not in your application code. An API key can only move funds the policy allows.

Your organization enforces one policy at a time. That policy holds an ordered list of rules. Each rule has conditions, such as an amount above a threshold or a destination outside a set of addresses, and an action to take when every condition matches.

## What a policy can do

| Action | What happens to the transaction |
| - | - |
| `allow` | It is signed and broadcast. |
| `block` | It is rejected before signing. Nothing is broadcast. |
| `require_approval` | It is held in `pending_authorization` until enough approvers approve it. |
| `delay` | It is held in `delayed` until a time lock expires, then executes on its own. |
| `alert` | It proceeds, and a `policy.alert` event informs the rule's notify targets. |

The first rule whose conditions all match decides the outcome. [How policy evaluation works](https://www.bitnob.dev/docs/platform/policies/how-policy-evaluation-works.md) covers the order, the conditions, and what happens when nothing matches.

## Why policies are safe to rely on

* **No single key can change them.** Activating a policy always goes through your organization's quorum, which needs at least two approvers. An API key can draft a policy but never enforce one by itself. See [Policy lifecycle and quorum](https://www.bitnob.dev/docs/platform/policies/policy-lifecycle-and-quorum.md).
* **The enforced policy is immutable.** You change it by drafting a replacement and activating that, so every change is reviewed and recorded.
* **You can test before you enforce.** [Dry-run evaluation](https://www.bitnob.dev/docs/platform/policies/test-rules-with-dry-run-evaluation.md) runs any draft against a sample request and returns a per-rule trace, with no side effects.
* **Every change is audited.** Each policy carries an audit log of who created, edited, and activated it.

## How you work with policies

**1. Discover what you can write**

[Rule reference](https://www.bitnob.dev/docs/platform/policies/rule-reference.md) lists the categories, actions, condition fields, and operators. [List approver candidates](https://www.bitnob.dev/api-reference/platform/users/list-approver-candidates.md) lists who can approve.

**2. Draft and lint**

Create a draft with [Create draft policy](https://www.bitnob.dev/api-reference/platform/policies/create-draft-policy.md), then check it with [Validate stored draft policy](https://www.bitnob.dev/api-reference/platform/policies/validate-stored-draft-policy.md). Drafts are never enforced.

**3. Test against real scenarios**

Run sample transfers through [Dry-run policy evaluation](https://www.bitnob.dev/api-reference/platform/policies/dry-run-policy-evaluation.md) with the draft's `policy_id`.

**4. Activate through quorum**

[Activate policy](https://www.bitnob.dev/api-reference/platform/policies/activate-policy.md) stages the draft. It becomes `enforced` once your quorum approvers approve it.

[Write and activate your first policy](https://www.bitnob.dev/docs/platform/policies/write-and-activate-your-first-policy.md) walks through all four steps with working requests.

## In this section

> [card] [Concepts](https://www.bitnob.dev/docs/platform/policies/how-policy-evaluation-works.md)
>
> How rules are evaluated, and how a draft becomes the enforced policy.

> [card] [Get started](https://www.bitnob.dev/docs/platform/policies/write-and-activate-your-first-policy.md)
>
> Draft, test, and activate a policy end to end.

> [card] [Guides](https://www.bitnob.dev/docs/platform/policies/require-approval-for-high-value-transfers.md)
>
> Approvals, time locks, testing, changing a live policy, and handling held transactions.

> [card] [Reference](https://www.bitnob.dev/docs/platform/policies/rule-reference.md)
>
> Actions, operators, condition fields, validation codes, statuses, and events.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.