Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA Thanks @Revinand, good catch.
Yes, in this form, with two conditions kept apart. When to show “retired”: a wallet MUST NOT show the old key as retired on L2 until the L1 migration block M is finalized and the L2 migration is itself in a finalized L2 block whose L1 origin is at least M; until then it shows the migration as pending. The MUST warn and SHOULD-migrate-L1-first from #16 stay. When to submit: a wallet SHOULD submit the L2 migration only after M is final and a safe L2 head reports L1Block.number() >= M (that value is the number of the L1 origin of the L2 block being executed). Finality of M is needed because a reorg could undo the L1 migration. Safe is needed because an unsafe block can be rebuilt; origin never moves backward, so once a safe head shows at least M, every later block on the canonical chain does too, including the one that will hold the migration. The display condition asks for finalized rather than safe because a safe block is derived from L1 data that could still be reorged. An early L2 migration can’t be undone, so wallets should wait before submitting.
Your reading matches the spec: a deposit is derived from the receipts of its L1 origin and appears only in the first L2 block of that epoch, ahead of the sequenced transactions, so a deposit from L1 block N can’t run in an L2 block whose origin is below N. An L1 receipt says nothing about where L2 is, and deposits check neither the sender’s nonce nor its code, so one queued before the L1 migration can run after the L2 migration.
What the rule does and doesn’t do. It can’t rescue what a queued deposit moves before the migration lands; that is a loss before migration, which I accept. It pins down what “retired” means: once shown, every deposit from an L1 block at or before M has already executed on L2, and new old-key transactions on this chain are rejected. Deposits from the same L1 address after M can only come from the account’s new code, since the old key can no longer send L1 transactions. Not covered: earlier approvals and roles, unfinalized withdrawals, and failed messenger messages that can be replayed; wallets should say so. A deposit that runs after adoption can also reach the new code: with to set to the account it looks like a self-call, which is what the ORIGIN == ADDRESS rule in the next revision is for, so the ordering is a second layer.
The rollup-side check would remove the ordering dependence for deposits whose from is the account: one that runs after adoption sees a sender with code, fails, and keeps its mint. It doesn’t see messages relayed through the CrossDomainMessenger, whose from is the aliased L1 messenger and whose L2 targets read the L1 caller from xDomainMessageSender(); I’ll list those under Residual risks.
I haven’t measured the window in practice. op-node’s default sequencer.l1-confs is 4; beyond that the lag behind the L1 head is the sequencer’s choice, though a block with transactions can’t run more than max_sequencer_drift ahead of its origin’s timestamp.
I’ll add your sequence to the OP discussion as a regression test (queue a token-transfer deposit, migrate L1, migrate L2 while the origin is behind, advance derivation) and credit you. On a chain without the rollup-side check, the same sequence tests the wallet rule: “retired” must not appear until the queued deposit has run. My PoC (GitHub - nezu511/setcodefrom-adoption-poc · GitHub) runs on EELS, which has no derivation, so running it needs an OP Stack devnet.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-TBA: Credit-Matched Liquidity | 0 | 9.1 | 26-10-2026 |
| 2 | ERC-TBA: Agent Credit Backers | 0 | 8.78 | 26-10-2026 |
| 3 | EIP Editing Office Hour (EIP + ERC ) Meeting #118, October 27, 2026 | 0 | 20.05 | 26-10-2026 |
| 4 | EIP draft: CALLSTATUS instruction | 0 | 15.26 | 26-10-2026 |
| 5 | ERC-TBA: Agent Repay-First Payees | 0 | 10.22 | 25-10-2026 |
| 6 | ERC-8107: ENS Trust Registry for Agent Coordination | 0 | 9.8 | 18-10-2026 |
| 7 | All Core Devs - Consensus (ACDC) #183, July 23 2026 | 0 | 15.18 | 13-07-2026 |
| 8 | ERC-8335: Account-Level Transfer With Authorization | 0 | 7 | 10-07-2026 |
| 9 | ERC-8340: Transaction Metadata Encoding | 0 | 34.21 | 15-07-2026 |