Send and Receive Policies

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.

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 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. 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 defines refusal modes and recovery rules.

​

What an FI can configure

An FI can combine reusable checks, supplied as policy primitives, 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.
• 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 govern shielded payments.