abc-123-c:
This is the idea of EIP-8158
Unfortunately, I cannot find the full text of the mentioned EIP-8158 proposal at the link, so I cannot comment on that EIP specifically.
But in terms of comparing “re-declared allowed modifications” to “post-transaction verification” in general, I believe that having a full access to the list of actual past changes enables a much more granular control that is not possible with a static allowed list declaration.
Also, I am happy to see multiple teams working on a solution to the same problem, so if you are an author, or know the author(s), of the EIP-8158, I would be happy to discuss the different trade-offs and ways to improve both proposals with them!
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | EIP-7906: Transaction Assertions via State Diff Opcode | 0 | 7 | 09-07-2026 |
| 2 | EIPIP Meeting #128, July 08, 2026 | 0 | 7 | 08-07-2026 |
| 3 | ERC-8100: Representable Contract State | 0 | 5 | 08-07-2026 |
| 4 | EIP-7723: Network Upgrade Inclusion Stages | 0 | 6 | 09-07-2026 |
| 5 | ERC-8335: Account-Level Transfer With Authorization | 0 | 7 | 10-07-2026 |
| 6 | ERC-8313: Protocol Interaction Manifest | 0 | 7 | 08-07-2026 |
| 7 | EIP-8146: Block Access List Sidecars | 0 | 6 | 10-07-2026 |
| 8 | ERC-7303: Token-Controlled Token Circulation | 0 | 5 | 08-07-2026 |
| 9 | Add ERC 8217: Agent NFT Identity Bindings | 7 | 8 | 08-07-2026 |
| 10 | EIP-7730: Proposal for a clear signing standard format for wallets | 0 | 7 | 08-07-2026 |