From 9abe7ffb43da003f978ffbf8ee528991ce50563e Mon Sep 17 00:00:00 2001 From: Derek <256792747+decofe@users.noreply.github.com> Date: Tue, 23 Jun 2026 22:13:35 +0000 Subject: [PATCH] Edit T6 blog for clarity --- blogs/t6.md | 40 +++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/blogs/t6.md b/blogs/t6.md index 186efc9b..c3e76eaa 100644 --- a/blogs/t6.md +++ b/blogs/t6.md @@ -9,35 +9,37 @@ category: network-upgrades ## 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. +Receive policies (TIP-1028) 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 to limit who can send to their accounts. -An account opting in configures three things: +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 send to it. -- **Recovery authority:** who can move the funds if a send is held. +- **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. -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. +Receive policies are optional. Without one, transfers and mints can be credited without an additional receive-policy check. -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. +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 (TIP-403) 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 does not go through, as today. +- **Failed:** token checks revert and the transfer fails. - **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. +- **Held (new):** the transfer succeeds, but the policy routes the funds to the guard for recovery. ![A receive policy adds a third delivery state, held, alongside failed and credited.](/blog/receive-policy-delivery-states.svg) -*An unaccepted transfer still succeeds; the funds are held by the guard and stay recoverable.* +*A blocked transfer still succeeds; the funds are held by the guard and stay recoverable by the configured party.* -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. +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 (TIP-1022), the respective master account's policy is used, and receipts preserve the original recipient for attribution. -In practice, this makes several common payment operations easier to run: +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 and recoverable rather than becoming an operational problem. +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 @@ -49,7 +51,7 @@ Read the [specification](https://tips.sh/1028), [learn more in the docs](/docs/l [Access keys](/docs/protocol/transactions#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: +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. @@ -59,24 +61,24 @@ Until now, key management itself still depended on the root key. Admin access ke *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. +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](https://tips.sh/1049) and [learn more in the docs](/docs/protocol/transactions#access-keys). ## 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. +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.0 release](https://github.com/tempoxyz/tempo/releases/tag/v1.9.0) and the [T6 upgrade notes](/docs/protocol/upgrades/t6). +See the [v1.9.1 release](https://github.com/tempoxyz/tempo/releases/tag/v1.9.1) and the [T6 upgrade notes](/docs/protocol/upgrades/t6). ## Resources - [T6 upgrade docs](/docs/protocol/upgrades/t6) - [Receive policies overview](/docs/learn/tempo/receive-policies#account-level-receive-policies) - [Access keys](/docs/protocol/transactions#access-keys) -- [TIP-1028: receive policies specification](https://tips.sh/1028) -- [TIP-1049: admin access keys specification](https://tips.sh/1049) +- [Receive policies specification](https://tips.sh/1028) +- [Admin access keys specification (TIP-1049)](https://tips.sh/1049) - [Receive policies demo](https://tempo.xyz/receive-policies) -- [v1.9.0 release](https://github.com/tempoxyz/tempo/releases/tag/v1.9.0) +- [v1.9.1 release](https://github.com/tempoxyz/tempo/releases/tag/v1.9.1) - [Tempo on GitHub](https://github.com/tempoxyz) - [All TIPs](/docs/protocol/tips)