# Account-level receive policies \[Control what accounts can receive] Account-level receive policies give Tempo accounts a way to define which TIP-20 tokens they are willing to receive and which addresses are allowed to send to them. They are designed for teams that need more control over inbound funds: wallets, custodians, exchanges, on/off-ramps, payment processors, treasury systems, and stablecoin orchestration platforms. ::::info\[Planned for T6] This page describes a feature planned for the T6 network upgrade. Check the [T6 upgrade docs](https://docs.tempo.xyz/protocol/upgrades/t6) for current activation status. :::: Try the [receive policies demo](https://tempo.xyz/receive-policies) to see credited, held, and recovery flows in practice. ## Why receiving needs policy On most blockchains, an address can send a compatible token to any other address without the recipient's permission. That flexibility is useful, but it creates operational problems for payment and financial applications: * A customer deposit address may receive a token that the platform does not support. * A treasury or settlement wallet may receive funds from an address it is not allowed to interact with. * A stablecoin orchestrator may need to prevent users from sending one issuer's token to a deposit address meant for another asset. * A support team may need a clear way to identify, review, and recover funds that should not have landed in a user's balance. Receive policies provide a means to express for receivers to express such preferences at account level. Instead of only letting token issuers decide who can send or receive a token, a user can also define what it is willing to accept and from whom. ## What a receive policy controls An account-level receive policy has three parts: * **Tokens**: an allowlist or blocklist of TIP-20 tokens the account can receive. * **Senders**: an allowlist or blocklist of addresses that can send to the account. * **Recovery authority**: who is allowed to move funds when an inbound send is held instead of credited. This could be the sender (default), the receiver, or a designated third-party address or smart contract. ## How inbound sends work A sender still starts a normal TIP-20 transfer or mint. Tempo first runs the usual token checks: balance, allowance, pause status, and issuer-level policies such as TIP-403 allowlists or blocklists. If those checks fail, the transaction reverts as usual. If they pass, Tempo checks whether the receiver has an account-level receive policy: * **No receive policy**: the transfer or mint is credited normally. * **Policy accepts the token and sender**: the transfer or mint is credited normally. * **Policy rejects the token or sender**: the transfer or mint can succeed, but the funds are held for recovery instead of being credited to the receiver. That held state is the key difference. The protocol records the details needed to review and recover the funds later, including the token, amount, sender, intended receiver, and reason the send was held. ## Common use cases ### Exchanges and custodians Deposit infrastructure can accept only supported assets for each customer or deposit flow. If a user sends an unsupported token, the platform can surface the held transfer and provide a structured support or recovery process instead of manually investigating a mismatch. ### Wallets and wallet-as-a-service providers Wallet providers can offer business customers controls over which tokens and counterparties their accounts accept. This is useful for internal wallets, customer wallets, treasury wallets, and accounts that need to avoid unwanted tokens. ### On/off-ramps and payment processors Receivers can limit inbound funds to known assets or known counterparties. That helps operational teams align onchain receipt behavior with compliance, risk, and reconciliation workflows. ### Stablecoin orchestrators Platforms that route between stablecoins can reduce user error by preventing sends to deposit addresses that are not meant to receive a particular asset. ## What builders should plan for Builders should plan to: * Let receivers configure token and sender allowlists or blocklists. * Show recovery authority choices in plain language. * Warn senders when a transfer is likely to be held. * Index held-send events so support and operations teams can find them. * Build recovery workflows for sender, receiver, or third-party controlled funds. ## How this fits with TIP-20 Receive policies complement the issuer controls already built into TIP-20 and TIP-403. Token issuers can still enforce their own policies for regulated assets. Account-level receive policies add a receiver-side layer for businesses and users that need to decide what their own accounts are willing to accept. Together, these controls make Tempo more practical for payment applications that need the flexibility of open stablecoin rails and the operational safeguards expected by financial platforms. ## Related reading