Send and receive controls
Each institution configures policies for the accounts it operates. The sending and receiving institutions may operate in different jurisdictions and apply different rules. A transfer reaches the recipient only if both policies approve. If the recipient opts into quarantine, a refused credit is held in escrow until it is recovered. Each institution can therefore enforce its own requirements without trusting the other to perform an offchain check.Payment-control primitives
Metal provides primitives that institutions can compose to:- Require a signed sanctions-screening result
- Enforce per-payment or cumulative limits
- Bind Travel Rule evidence to a payment
- Require signed evidence from an offchain decision service
- Restrict a specific onchain identity
- Allow only approved senders, recipients, or operators
- Route payments through an explicit call to a treasury or an account holding funds for review
Onchain enforcement and offchain decisions
Institutions can make policy decisions from public or private information. A public rule can read onchain state directly. A private rule is evaluated by the institution or its chosen service, then represented onchain by verifiable evidence. Metal verifies the required authorization or policy result without receiving the private inputs used to produce it.
The institution decides which information its policy uses and which evidence
the transaction must carry. Encrypted offchain channels can deliver private
records between authorized parties, while Metal verifies the resulting
signature, commitment, or proof.
Policy can vary by asset
Send and receive policies can use the token address to apply different rules to different assets. An institution can set limits or permissions for one MIP20 token independently of the other tokens an account holds.Write your first policy
Configure incoming rules and control outgoing payments.
Compliance architecture
Compare the policy surfaces available across Metal payments.