Tempo TransactionsTIP-20 tokens
DocsWalletFaucetTIDXTempo ExplorerMPPSDKs
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, 2026New

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 →

Account-level receive policies

Receive policies let an account specify which TIP-20 tokens it will accept and which addresses can send to it. This is useful for exchanges, custodians, on and off ramps, payment processors, and treasury systems that need to keep unsupported or unwanted assets out of balances, or limit who can send to an account.

An account opting 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 send to it.
  • Recovery authority: who can move the funds if a send is held.

Policies are opt-in. An account with no policy works exactly as it does today, and a sender starts a normal transfer or mint without needing to know a policy exists. Policies are set and enforced on the TIP-403 precompile, and any policy a token already enforces still runs first.

When a transfer is accepted, the funds are credited normally. When it is not, the transfer still succeeds, but delivery is redirected to the ReceivePolicyGuard precompile and a receipt records enough context 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 does not go through, as today.
  • Credited: the receiver accepts the transfer and the funds arrive.
  • Held: 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

An unaccepted transfer still succeeds; the funds are held by the guard and stay recoverable.

Wallets, explorers, and indexers should treat held sends as their own state and listen for the TransferBlocked event, since blocked receipts are not enumerable onchain. For deposit flows that use TIP-1022 virtual addresses, the policy is resolved against the master account before the check runs, and receipts preserve the original recipient for attribution.

In practice, this makes several common payment operations easier to run:

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 and recoverable rather than becoming an operational problem.

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.

Until now, key management itself still depended on the root key. Admin access keys change that: an account can designate certain access keys as administrative, 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 a signature came from an active key on an account, and verifyKeychainAdmin confirms it came from the root key or an admin key. Builders get a safe primitive for account-gated workflows instead of rebuilding key-status logic in every contract. 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 whatever 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.0 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.0 release and the T6 upgrade notes.

Resources