From be234391484b32dfa38bd2212c182da4f68bbfe7 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 1 Sep 2026 21:43:30 +0000 Subject: [PATCH] docs: sync from base-std@868d513 --- docs/specifications/b20/changelog.mdx | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/specifications/b20/changelog.mdx b/docs/specifications/b20/changelog.mdx index 5ccef23f1..be267d325 100644 --- a/docs/specifications/b20/changelog.mdx +++ b/docs/specifications/b20/changelog.mdx @@ -53,3 +53,11 @@ Shipped with the [Beryl upgrade](/upgrades/beryl/overview). **Deprecated** - `burnBlocked` and `BURN_BLOCKED_ROLE`, retained for backwards compatibility. New seizure flows use `seizeWithMemo`. + + +**Pooled-balance integrators:** `seizeWithMemo` and `burnBlocked` both allow funds to move out of a contract address without the regular transfer flow. This affects lending-protocol vaults, AMM pools, staking contracts, custodial wallets, and bridges — any system that maintains internal accounting against a single on-chain token balance. The mechanism acts at the pooling contract's address, not at individual depositor-share granularity, so the accounting impact falls on the pool as a whole. + +This is not a new risk. `burnBlocked` already allowed an issuer to zero a blocked address's balance through block, burn, and reissue elsewhere. `seizeWithMemo` does not expand who is exposed — it collapses that workaround into one call, redirects the balance instead of burning and reissuing it, and emits a dedicated `Seized` event. Both paths remain live. + +To check current exposure, read the policy IDs assigned to `SEIZE_HOLDER_POLICY` and `TRANSFER_SENDER_POLICY` using `token.policyId(...)` (`IB20.policyId`, `src/interfaces/IB20.sol`), then query the Policy Registry's `isAuthorized(policyId, account)` with the pooling contract's own address against each ID. If the contract is not authorized under the seize-holder policy, or is blocked under the transfer-sender policy, funds can be seized or burned from that vault balance under the current configuration. This check is point-in-time only — an issuer can later change either slot with `updatePolicy`, so "not seizable today" is not a durable guarantee. +