DelegationManager implementation replaced 27 Aug 2026 (+88 bytes, unchanged ABI)

Protocol Research
1

A short decode of a recent DelegationManager upgrade.

DelegationManager proxy 0x39053D51B77DC0d36036Fc1fCc8Cb819df8Ef37A, block 25849689, 27 August 2026:

old implementation 0xE7022a128Acd4C6cad7aFf6FA874D61f984BcE75
new implementation 0x6a8BEd4062C895130E2d09bA442D3eCEAd5Df6c2

Deployed bytecode grew from 23,549 to 23,637 bytes, a delta of +88. The ABI is unchanged — no external functions added, removed, or changed in signature.

So this is a change to the internals of existing functions on the contract that governs delegation and the withdrawal queue, not a feature addition. 88 bytes is a small change: a bounds or state check, an added revert condition, or an accounting correction would all be consistent with that size.

Proxy admin: 0x8b9566AdA63B64d1E1dcF1418b43fd1433b72444

Method note: no storage-layout diff. Both implementations are verified, so the source diff is available to anyone who wants to look — I’m reporting the on-chain shape of the change, not its semantics.

Question: was this tied to a specific release or audit finding? For a contract in this position, “+88 bytes, no interface change” is the kind of upgrade most monitoring tools report as an undifferentiated “code replaced” alert, and knowing what class of change it was would help calibrate how such upgrades should be read.

2

Before drawing conclusions from the extra 88 bytes, separate compiler artifact noise from behavioral changes. Strip the CBOR metadata, compile both verified sources with the exact Solidity settings, diff the runtime bytecode, and map the changed basic blocks back to their functions. Since the ABI and storage layout are unchanged, focus testing on altered internal call paths, authorization branches, accounting or rounding behavior, and revert conditions. Sharing the compiler settings and block-tagged call traces alongside the two implementation addresses would make independent validation easier.