Tempo TransactionsTIP-20 tokens
DocsTempo WalletFaucetTIDXTempo ExplorerWallet CLIMPPSDKs
PerformanceBlogDocs
Tempo MCP serverGive agents search and read tools for Tempo docs
Tempo pluginInstall MCP, workflow skills, and editor metadata
Tempo Docs skillAdd docs, examples, and source context
← Blog
network upgradeJun 23, 2026

T6 network upgrade: Receive policies, admin access keys, and more

The T6 network upgrade adds two new account-level controls to Tempo: receive policies, which let an account decide which tokens and senders it accepts, and admin access keys, which let an account delegate key management without using the root key.

The T6 network upgrade adds two new account-level controls to Tempo: receive policies, which let an account decide which tokens and senders it accepts, and admin access keys, which let an account delegate key management without using the root key. Read the T6 docs to start integrating →

Receive Policies

Receive policies let an account specify which TIP-20 tokens it will accept and which addresses can send to it. This enables exchanges, custodians, on-and-off ramps, payment processors, and wallet platforms to avoid receiving unsupported or unwanted assets and/or to limit who can send to their accounts.

An account that opts in configures three things:

  • Tokens: an allowlist or blocklist of TIP-20 tokens it will accept.
  • Senders: an allowlist or blocklist of addresses that can or cannot send to it.
  • Recovery authority: who can move the funds if a transfer is blocked.

Receive policies are optional. Without one, transfers and mints can be credited without an additional receive-policy check.

When an account configures a receive policy, senders initiating transfers and issuers minting assets still do not need to check the recipient's policy in advance. The token's existing transfer policy runs first; if the token rejects the transfer, it fails.

Receive policies add a receiver-side check after that. If the token allows the transfer and the receive policy accepts it, the funds are credited normally. If the receive policy blocks it, the transfer still succeeds, but Tempo routes the funds to the guard (ReceivePolicyGuard, a new precompile) and records a receipt for recovery. The held funds stay attributable and recoverable by the authority the account chose in advance.

For integrators, this adds a third delivery state to model:

  • Failed: token checks revert and the transfer fails.
  • Credited: the receiver accepts the transfer and the funds arrive.
  • Held (new): the transfer succeeds, but the policy routes the funds to the guard for recovery.

RECEIVE POLICY: THREE DELIVERY STATES WHAT AN INTEGRATOR MUST MODEL INBOUND TRANSFER FAILED token checks revert, no transfer CREDITED receiver accepts, funds arrive HELD held by ReceivePolicyGuard recoverable by the chosen authority

A blocked transfer still succeeds; the funds are held by the guard and stay recoverable by the configured party.

Wallets, explorers, and indexers should listen for the TransferBlocked event and index blocked transfers as blocked receipts are not enumerable onchain. For deposit flows that use virtual addresses, the respective master account's policy is used, and receipts preserve the original recipient for attribution.

In practice, this streamlines several common payment operations:

Supported-asset controls

A platform can configure deposit addresses to accept only the stablecoins it supports. If a user sends an unsupported token, the funds are held with clear attribution and a defined recovery path instead of becoming a support and reconciliation issue.

Counterparty controls

A regulated business can define which addresses are allowed to send to an account. This gives compliance and operations teams a protocol-native control for inbound payments, rather than relying only on monitoring after funds have already arrived.

Read the specification, learn more in the docs, and try the demo.

Admin access keys

Access keys on Tempo let users and applications authorize limited actions. They are useful for subscriptions, delegated payments, automated operations, and other flows where a narrowly scoped key is safer than using the root key directly.

Without admin access keys, key management itself depends on the root key. Admin access keys change that: an account can designate certain access keys as administrators, and those keys can authorize and revoke other keys on the account's behalf. This separates account ownership from day-to-day key administration:

  • An admin key can manage operational keys for services, devices, and automated systems while the root key stays protected.
  • An operational key can be rotated or revoked without root-key access.
  • Admin keys are for key management only. They cannot carry spending limits, call scopes, or expiry.

ACCOUNT KEY ROLES T6 SEPARATES OWNERSHIP FROM KEY ADMINISTRATION ROOT KEY owns the account stays protected ADMIN KEY authorizes + revokes other keys LIMITED KEY spend limits, call scopes, expiry MANAGES KEYS

Admin keys manage operational keys without using the root key.

T6 also gives contracts a canonical way to verify key status. verifyKeychain confirms whether a signature came from an active key on an account, and verifyKeychainAdmin confirms whether it came from the root key or an admin key. This gives builders an out-of-the-box, safe primitive for authorization instead of requiring every contract to rebuild key-status checks. Note that verifyKeychainAdmin does not bind the account into the signed digest, so callers should include a replay domain such as chain ID, contract address, and account address in the message they ask a key to sign.

Read the specification and learn more in the docs.

What integrators should know

Node operators should run the v1.9.1 release to stay in sync with mainnet. The full set of changes and compatible package versions are in the release notes.

See the v1.9.1 release and the T6 upgrade notes.

Resources