Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA @ted0x Yes — and your case shows my #32 had one check too many. I said the check “fails either way”, including an update after the submission. For a delivered submission that is wrong, and the kernel is built so that it does not have to be.
The adapter holds its own anchor: at opening it read taskOf(tokenId) and locked (version, taskHash) at that block, and versions are append-only, so V1 can never name any other content. The submission carries taskVersion, stamped by the kernel at submission. Settling V1 work after an update to V2 therefore needs one comparison, submissionOf(tokenId, submissionId).taskVersion == lockedVersion, against the adapter’s own record; the current binding is not consulted at all. That is exactly the configuration the draft describes for a verifier that must bind to the bytes a delivery answered: “A general-purpose verifier that must bind its decision to the exact bytes a delivery answered therefore needs those anchors supplied in its own commitment at configuration time.” The adapter’s lock is that commitment, and the same single check covers the other order — a submission made after the update cites V2 and fails — so there is no current-state check left to make.
It is also the kernel’s own principle applied one layer up: cancellation “MUST NOT void work already delivered”, and a specification update should not either. “fulfillers cite the version they fulfilled, making post-hoc movement legible” is in Security Considerations for precisely this; the publisher may stop buying at V1 by updating, but it cannot un-receive what was delivered against V1. The binding-history view (candidate 5) stays relevant only for an authority that holds no anchor of its own and reads the binding at verification time, which is the shape PR #2’s signed authority has and why it refuses on TaskChanged.
Your case is in candidate 3’s test list, credited.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-8434: Agent Identity (AID) | 0 | 9.38 | 19-10-2026 |
| 2 | ERC-8348: Financial Lease | 0 | 10.87 | 19-10-2026 |
| 3 | ERC-8337: Agent Memory State | 0 | 7.65 | 26-07-2026 |
| 4 | ERC-7303: Token-Controlled Token Circulation | 0 | 5 | 08-07-2026 |
| 5 | ERC-8004: Trustless Agents | 0 | 8.54 | 27-07-2026 |
| 6 | ERC-8419: Know-Your-Agent (KYA) Framework | 0 | 9.74 | 19-10-2026 |
| 7 | ERC-8259: AI Agent Identity, Reputation & Threat Registry (Draft v2 – Request for Feedback) | 0 | 8.5 | 17-10-2026 |
| 8 | ERC-8312: Bounded Agent Actions | 0 | 12.74 | 27-07-2026 |
| 9 | Add ERC 8217: Agent NFT Identity Bindings | 7 | 8 | 08-07-2026 |
| 10 | ERC-8313: Protocol Interaction Manifest | 0 | 7 | 08-07-2026 |