# Understanding signing policies

A Signing Policy is an ordered list of rules that the Crypto Vault evaluates for every signing request. The first matching rule decides whether the request is approved, denied, or sent to an External Rule Server.

## Policy scopes

The **Signing Policies** page lists each policy separately:

| Policy | What it controls |
|---|---|
| **Offchain** | Signing with exchange and API keys |
| **Vault policy** | Transaction and raw signing by wallets in one vault |

Each vault has its own policy. Select a row to review its rules, or open the **Signing Policy** tab inside the vault.

## First match wins

Rules are evaluated from top to bottom. The first rule whose conditions match determines the outcome. Put specific rules above broad ones.

Every policy ends with a permanent **deny all** rule. It cannot be removed or reordered, so a request that matches no earlier rule is blocked.

## Rule conditions

Every rule identifies an initiator group and a source security group. Vault policies then use one of two rule types:

### On-chain transfer

An on-chain transfer rule can restrict:

* **Network:** any enabled network or selected networks.
* **Asset amount:** any supported asset, selected assets, and optional per-asset amount caps.
* **Destination:** any address or an allowlist of valid EVM or Solana addresses.
* **USD value:** an optional cap on the total transfer value. This condition appears only when price-based policies are enabled in [System Settings](/guide/system-settings/configure).

The Network, Asset amount, and Destination conditions are required, but each can explicitly allow any value. All configured conditions in a rule are combined with AND.

### Raw signing

A raw-signing rule covers `POST /v1/keys/{key_id}/sign` in the Offchain policy or wallet raw signing in a vault policy. It does not inspect a blockchain transaction.

:::warning
A vault raw-signing rule grants transaction-equivalent signing power. Restrict its initiator and security groups carefully.
:::

Transfer rules and raw-signing rules are separate. A transfer rule never approves a raw-sign request, and a raw-signing rule never approves a decoded transaction.

## Results

| Result | Effect |
|---|---|
| **Approve** | Proceed with the MPC signing ceremony |
| **Deny** | Reject the request immediately |
| **External Rule Server** | Ask your rule server for a signed decision |

## Enforcement chain

1. The Orchestrator routes the signing request to all three Policy Server nodes.
2. Each Policy Server independently evaluates the ordered rules and signs its decision.
3. A 2-of-3 consensus is required.
4. The Key Store nodes verify that consensus before participating in the MPC signing ceremony.

The Orchestrator cannot create a policy approval on its own, and Key Store nodes do not sign without verified policy consensus.

## Signing Policy vs. Administrative Policy

Signing Policies control how keys and wallets may sign. Administrative Policy controls who may edit each Signing Policy and its security groups. Vault-scoped administrative rules can grant that access for any vault or only selected vaults.