Tempo Receive Policies: Protocol-Level Control Over Inbound Stablecoin Transfers

TL;DR

Tempo added Receive Policies through the T6 network upgrade (TIP-1028), a mid-2026 addition to a mainnet live since March 18, 2026.

The feature gives account holders three optional protocol-native controls over inbound TIP-20 transfers:

• Accepted Tokens,
• Accepted Senders,
• a Recovery Authority.

On most chains, a rejected transfer either bounces or leaves funds stranded with no native way to recover them. Tempo handles a blocked transfer differently: the transaction still settles at the protocol level, funds route to a precompile called ReceivePolicyGuard with a receipt, and the named authority can later reclaim them.

For exchanges, custodians, and payment platforms, Receive Policies reframe wrong-token deposits and unwanted transfers from lost-funds incidents into routine recovery workflows.

Why Inbound Controls Exist on a Payments Chain

On a payments chain moving stablecoins at scale, inbound controls decide which transfers reach a regulated account and how much manual cleanup an operator absorbs.

The Problem With Open Receipt on General-Purpose Blockchains

On most general-purpose blockchains, any account can receive any token from anyone. There is no native way to refuse an inbound transfer or reclaim it afterward.

This open-receipt model creates persistent operational friction for regulated financial operators, generating manual work, support tickets, or compliance exposure:

• unsupported tokens landing in deposit addresses that cannot process them,
• unwanted counterparties sending funds an operator does not want to accept,
• scam and spam tokens cluttering account histories and confusing users,
• reconciliation exceptions where unexpected assets break automated accounting.

For a consumer wallet, unsupported or spam tokens are annoyances, but for an exchange or custodian moving regulated stablecoins at scale, they become a steady drain on operations and a source of compliance risk.

Tempo’s Payments-First Compliance-Forward Positioning

Tempo is a Layer 1 blockchain built for stablecoin payments, incubated by Stripe and Paradigm. It went live on mainnet on March 18, 2026, after a public testnet that began in December 2025.

The chain is fully EVM-compatible while tuned for payment workloads, with roughly 0.6-second finality, fees payable in any USD stablecoin, and around one-tenth of a cent per TIP-20 transfer. Tempo was built for institutions handling everyday payments, and its early validator group reflects that:

• Stripe
• Visa
• Zodia Custody (by Standard Chartered)

Read our introductory piece to Tempo Blockchain to learn more about the specifics of Tempo.

What Receive Policies Add

Receive Policies let an account redirect and recover inbound transfers natively, without off-chain tooling. The T6 network upgrade introduced them through TIP-1028, adding account-level controls for TIP-20 transfers and mints.

Tempo shipped its core payment primitives first, then added receipt governance once regulated operators were live on the network.

How Receive Policies Work

Each account configures its own rules for which inbound TIP-20 transfers it accepts, and anything blocked routes to a recoverable holding contract.

The Three Account-Level Controls: Accepted Tokens, Accepted Senders, and Recovery Authority

Receive Policies are an optional, account-level feature designed mainly for TIP-20 tokens, Tempo’s stablecoin-optimized standard. An account holder configures three conditions governing what it accepts and who can reclaim what it rejects.

Together these let a receiver filter inbound transfers by both asset and counterparty. A deposit address can accept only the tokens it supports, from only the senders it approves.

What Happens to a Blocked Transfer on Tempo

A blocked transfer still succeeds at the protocol level. The funds route to a precompile called ReceivePolicyGuard, which holds them alongside a receipt.

The named Recovery Authority can then claim the held funds later. The tooling enforces valid configuration: the TIP-1028 helper rejects recovery authorities that could never pass ReceivePolicyGuard.claim(), preventing a misconfigured policy from stranding assets permanently.

Blocked value stays recoverable: an unexpected inbound transfer becomes a claim to process.

Receive Policies vs. Post-Arrival Screening

Receive Policies exert control before receipt, while traditional screening applies remediation after funds arrive. On most chains, an operator screens deposits only once they have landed, so any response happens afterward through quarantine, manual reversal, or a compliance flag.

Receive Policies move the decision point earlier, filtering at the moment of transfer and routing rejected value to a recoverable holding contract.

Relationship to TIP-20 and the TIP-403 Policy Registry

Receive Policies sit alongside Tempo’s existing compliance primitives. The TIP-403 Policy Registry lets an issuer define one policy and apply it to multiple tokens, so a single update propagates to every token using it, whereas traditional chains require updating each contract individually.

• TIP-1015 extends this model, adding compound transfer policies that specify different authorization rules for senders and recipients.

• TIP-403 and TIP-1015 govern issuer-level transfer rules, while TIP-1028 gives the receiving account its own inbound controls. The issuer sets who may transact with a token, and the receiver sets what its account will accept.

Compliance and Regulatory Use Cases

Receive Policies apply to the enterprise accounts that exchanges, custodians, and payroll operators run, giving compliance teams a lever over inbound exposure.

Supporting AML, Sanctions Screening, and Travel Rule Workflows

Receive Policies give compliance teams a protocol-level lever for controlling inbound exposure. By restricting Accepted Senders, an account can decline transfers from addresses outside its approved set, supporting sanctions screening at the point of receipt.

These controls complement established compliance obligations. AML, KYC, sanctions, and Travel Rule processes still require identity verification and record-keeping off-chain, while Receive Policies reduce the volume of transfers reaching an account before those checks apply.

Enterprise Scenarios: Exchanges, Custodians, On/Off-Ramps, Payroll, and Tokenized Deposits

Different institution types face different inbound risks, and account-level filtering addresses five at once:

1. exchanges can limit deposit addresses to supported tokens from vetted senders;
2. custodians can enforce which counterparties may deliver assets to client accounts;
3. on/off-ramps can filter inbound transfers to match their supported currencies;
4. payroll operators can restrict who funds disbursement accounts,
5. tokenized-deposit issuers can control which senders reach settlement addresses.

Each scenario reduces the manual handling that open receipt forces onto operations teams.

Reducing Operational Risk: Wrong-Token Deposits, Erroneous Transfers, and Spam/Scam Tokens

Receive Policies cut down three recurring operational problems:

• wrong-token deposits;
• erroneous transfers;
• spam and scam tokens.

A receiver that accepts only specific tokens avoids the reconciliation work that unsupported assets create. Wrong-token deposits are a familiar support burden, where a user sends the wrong asset to a deposit address and the operator must manually identify and send it back.

Erroneous transfers and spam or scam tokens create the same class of exception, cluttering account histories and breaking automated reconciliation. Filtering by Accepted Tokens and Accepted Senders stops most of these at the point of receipt, so unwanted assets never land in the operator’s spendable balance.

How Receive Policies Coexist With Tempo’s Opt-In Confidentiality

Receive Policies coexist with Tempo’s opt-in confidentiality, a separate primitive delivered by Zones, which Tempo launched in April 2026. Zones are parallel permissioned chains that let companies run private stablecoin transactions, such as confidential payroll, treasury, and merchant settlement, while staying interoperable with the public mainnet.

Receive Policies operate at the account level regardless of whether an account uses a Zone. Filtering and auditability apply while preserving the confidentiality that Zones provide.

Institutional Impact and Strategic Outlook

Receive Policies are one piece of a wider enterprise-oriented architecture. Tempo’s validator set includes Visa, its TIP-20 standard anchors stablecoin issuance, and Stripe provides distribution into existing payment channels.

The network is reportedly working with firms including OpenAI, Shopify, Anthropic, and Deutsche Bank. Inbound controls fit this stack because institutional operators need granular account-level governance beyond fast settlement.

Everstake, an established validator and staking provider that has operated 130+ networks to date, provides the kind of infrastructure institutional chains typically rely on.

How Tempo Compares to XRPL Deposit Authorization

The closest on-chain analogue is XRPL’s DepositAuth, a real and long-standing feature. The defining difference is what happens to a blocked transfer:

Feature	XRPL DepositAuth	Tempo Receive Policies
Blocked transfer outcome	Transaction rejected outright	Transaction settles; funds route to guard
Recoverability	No settlement occurs	Funds recoverable by named authority
Preauthorization	DepositPreauth for approved senders	Accepted Senders list
Credential-style parallel	Credentials + DepositPreauth	TIP-403 policy registry

XRPL DepositAuth, enabled on the ledger in 2018, rejects an unauthorized payment so it never settles. Tempo takes the opposite approach, where the transfer completes and rejected value is held for recovery.

XRPL’s Credentials amendment with DepositPreauth offers a KYC-style preauthorization parallel to TIP-403. Both let an account preapprove specific senders under credential-based rules.

Receive Policies as an Emerging RegTech Primitive for Stablecoin Infrastructure

Receive Policies point toward an emerging RegTech primitive for stablecoin infrastructure. The backdrop making this credible is the GENIUS Act, the federal stablecoin framework signed into law in July 2025.

With a federal framework in place, protocol-native compliance controls become table stakes. Account-level inbound governance is the building block that regulated stablecoin infrastructure will likely standardize around as the market matures.

Trade-Offs and Open Questions

Receive Policies carry trade-offs around trust, cross-chain reach, and long-term security. Each is a design question an operator should weigh before relying on the feature.

Trust and Centralization Around the Recovery Authority

The Recovery Authority introduces a trust assumption. Whoever holds that role can reclaim blocked funds, concentrating control at a specific address.

The recoverability that makes the feature useful depends on a named party with claim rights. Poor key management or a compromised authority address would undermine the protection the mechanism provides.

Interoperability Across Multichain and Bridged Environments

Receive Policies operate on Tempo and govern TIP-20 transfers. Their behavior across bridged or multichain transfers is a more open question, since assets arriving through bridges or wrapped representations may not carry the same native controls.

Cross-chain interoperability remains an area to watch. As stablecoins move between networks, the account-level guarantees that hold on Tempo may not extend to other environments without additional tooling or standards.

Security Surface and Future-Proofing as Regulation Evolves

Any new protocol feature adds surface area to secure. ReceivePolicyGuard, the claim logic, and the policy configuration all become components that must be audited and maintained.

The tooling already rejects unclaimable recovery authorities, addressing one class of misconfiguration. Regulation will keep evolving, and a framework like the GENIUS Act sets a baseline while requirements around AML, sanctions, and reporting continue to change.

Whether account-level controls can adapt to future rules without breaking existing integrations is an open design challenge. Operators should treat the policy layer as something that will need ongoing maintenance.

Toward Programmable, Compliant Stablecoin Receipt

Tempo’s Receive Policies move inbound control into a native protocol capability. By letting accounts define Accepted Tokens, Accepted Senders, and a Recovery Authority, the T6 upgrade (TIP-1028) reframes how regulated operators handle transfers they did not request.

The defining choice is that blocked transfers still settle and route to ReceivePolicyGuard, keeping value recoverable. For exchanges, custodians, on/off-ramps, payroll operators, and tokenized-deposit issuers, wrong-token deposits and unwanted transfers become recovery workflows instead of incidents.

Compliance teams gain a protocol-level filter that complements AML, KYC, and Travel Rule processes. The feature sits alongside Tempo’s opt-in confidentiality through Zones as a complementary primitive.

The open questions around the Recovery Authority, cross-chain behavior, and evolving regulation are real, and operators should weigh them against their own controls. Institutions building on Tempo can begin by mapping which accounts need inbound filtering and who should hold recovery rights.

Validators like Everstake with deep technical blockchain experience proven by over 8 years of operation on 130+ networks, provide the consensus infrastructure that regulated stablecoin networks depend on.

As federal frameworks like the GENIUS Act take hold, programmable and compliant receipt looks like the direction stablecoin infrastructure is heading.