verify: a row for sink 1.5.0, and why 1.4.0 cannot have one

[danvaneijck]

Sinks 1.4.0 (0xeC9f701C…) and 1.5.0 (0x061b6e70…) had no manifest row and read UNVERIFIED on Blockscout. Both are verified now; 1.5.0 gets the row.

🔴 The note that blocked this for two days was wrong

It said "its constructor changed shape again for the derived quote hop". It did not. The shape is identical to 1.2.0/1.3.0 — the same eight arguments. What changed is two values, and both are why a copied row fails with a bytecode mismatch that reads like a compiler-settings problem:

	1.1.0–1.3.0	1.4.0 / 1.5.0
burn token	0xD21C10dC…	0xEDF52618… (a later test token; both live)
minBurnBps / burnBps	8000 / 8000	5000 / 7000 (the B2 numbers; the floor is an immutable)

The row's hex was not derived from any of that. It was read off the bytes actually deployed — the last 256 bytes of the CREATE3 payload's creationCode argument in broadcast/09_DeployBuybackBurnSink.s.sol/1439/run-1789026244612.json — and cast abi-encode of the row reproduces it byte for byte. (The 1.4.0 deploy's tail is identical; only the code differs.)

⛔ 1.4.0 deliberately has no row

Not an oversight to fix later. It was built from ee3289b, before 88293f3 added the derived quote hop:

ee3289b  creation code 19,173 B  + 256 args = 19,429  ← the 1.4.0 deploy
main     creation code 20,405 B  + 256 args = 20,661  ← the 1.5.0 deploy

The whole 1.4.0 payload is smaller than today's code alone. This manifest compiles from the working tree, so a row for it could never pass from main — it would turn a green gate red for ever and teach a reader to ignore it, which is exactly what this file's own header warns about.

It is verified, from its own revision, and the comment carries the recipe (git worktree add --detach … ee3289b, then verify-blockscout.sh against that root with the same constructor hex).

Checked

• both addresses read is_verified: true on Blockscout (BuybackBurnSink, v0.8.26+commit.8a97fa7a)
• a manifest pass reports --- pass 1: 0 still waiting on the Blockscout indexer ---
• bash -n clean; the new row's cast abi-encode output compared byte-for-byte against both deploys

🤖 Generated with Claude Code