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

# Send and Receive Policies

> Where MIP20 policy checks run, how they affect transfers, and how FIs configure and combine them

A financial institution (FI) can use send and receive policies to control how
MIP20 value enters and leaves the accounts it operates. A send policy can
restrict outgoing payments, while a receive policy controls the incoming
payments. The policies are evaluated and enforced by send and receive policy
contracts. The FI chooses the rules and configures the accounts they govern.

## Where policies apply

A send policy contract checks spending rules before calling MIP20 to transfer
funds from the sender's account. Enforcing the policy across an account's
spending requires checks on every path that can spend or authorize spending.

The receive policy contract, `ReceivePolicy`, stores rules for each
destination account. MIP20 calls this contract before crediting the account.
The contract evaluates the token, sender, recipient, and amount against those
rules. The sender is the account whose balance is debited, including when a
spender or relayer submits the transfer.

## Execution order

For a payment made through a send policy contract:

1. The send policy contract checks spending authority and any outgoing rules.
2. It calls MIP20, which calls the receive policy contract to check the
   recipient's incoming rules.
3. MIP20 credits the recipient or applies the refusal outcomes described below.

![The send policy contract checks spending rules before calling MIP20. The token calls the receive policy contract to check the recipient's stored rules, then credits the recipient, reverts, or credits quarantine escrow with a recovery receipt.](https://mintcdn.com/nexus-ed339086/RqZ8DjiF3RN_92qp/images/compliance/mip20-policy.svg?fit=max\&auto=format\&n=RqZ8DjiF3RN_92qp\&q=85\&s=91f3bd07d451d8fe594933e772f7b6e2)

When send policy requires a signed decision, the send policy contract checks it
before calling MIP20. Missing or invalid required evidence makes the call
revert. [Programmable Compliance](https://docs.metalntwx.com/learn/compliance/programmable-compliance.md#connecting-offchain-decisions-to-execution)
explains how offchain decisions are prepared and authenticated.

## Transfer outcomes and quarantine

When a send policy contract rejects a payment, it reverts the payment entirely.
If the receive policy contract refuses a credit, the recipient's refusal mode
determines whether the transfer reverts or goes to quarantine.

| Outcome | Effect on MIP20 value |
| - | - |
| Accepted | The sender is debited and the recipient is credited. |
| Reverted | The transfer's balance changes are undone, leaving the funds with the sender. |
| Quarantined | The sender is debited and the same amount is credited to ReceivePolicy escrow. The intended recipient's balance remains unchanged. |

A quarantined transfer leaves the token's total supply unchanged. The funds
remain in escrow as the same MIP20 token, with a quarantine receipt recording
the intended recipient and recovery authority. Recovery can deliver the funds
to the recipient, refund the sender, or redirect them under the receipt's
recovery rules. A quarantine therefore establishes that funds moved, but the
intended recipient has not been paid.

A revert rolls back the failed call's balances, policy updates, nested calls,
authorization consumption, and events. An uncaught revert fails the containing
transaction, which still pays gas. A caller that catches the failure may
continue with other work in that transaction.

Refused mints, MIP20 hold captures, and payouts from a token's own balance
always quarantine. The [Receive Policy reference](https://docs.metalntwx.com/reference/compliance/receive-policy.md)
defines refusal modes and recovery rules.

## What an FI can configure

An FI can combine reusable checks, supplied as
[policy primitives](https://docs.metalntwx.com/learn/compliance/programmable-compliance.md#combining-checks-into-a-policy),
in its policy contracts and add routing through application calls. For the
accounts it controls, it can:

* Block incoming senders or accept only configured senders and tokens.
* Set incoming amount bounds and per-sender limits on total value or payment
  frequency for each token over a configured period. Maximum amounts and
  per-sender limits are [not on Metal Testnet yet](https://docs.metalntwx.com/reference/compliance/receive-policy.md).
* Freeze outgoing payments, set payment limits, restrict recipients, or require
  approvals.
* Authenticate supplied policy decisions in the send policy contract.
* Route payments through an explicit application call to a treasury or an
  account that holds funds for review.

The FI also chooses the refusal mode for ordinary transfers and the recovery
settings for quarantined funds.

## Routing and application calls

An application contract can check send policy and make several token transfers
in one payment call, such as routing incoming funds to a treasury. For each
transfer, MIP20 calls the receive policy contract to check the destination's
rules. The application decides whether quarantine is acceptable or should
cause the enclosing call to revert, undoing the route's transfers and other
state changes.

## MIP410 boundary

Shielding deposits MIP20 into the shielded pool through a public token transfer.
MIP20 calls the receive policy contract to check the pool's rules. The deposit
must fully credit the pool, so a quarantined deposit causes the shielding call
to revert. Unshielding makes a public MIP20 transfer, which also calls the
receive policy contract to check the destination's rules.

Changes to private notes inside the MIP410 shielded pool do not move public
MIP20 balances between note holders or invoke MIP20 policy contracts.
The pool's proofs and [private policies](https://docs.metalntwx.com/learn/mip410/privacy-preserving-policy.md)
govern shielded payments.


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