← Contract Hero · WorkLearnPlugins
acc-evm-wal
Lesson 03 · Foundry

Replace IPNS with one eth_call against an ENS-gated resolver.

Build a Solidity contract that lets an ENS name's owner park a Walrus blob pointer on-chain. Authorization piggybacks on the ENS registry's owner/operator model, the pointer carries both the content address and the underlying Sui Blob object id (so a permissionless keeper can extend it), and reads cost one EVM eth_call. Replaces a DHT round-trip with a single SLOAD.

Slug: 03-walrus-resolver Stack: Foundry · Solidity 0.8.24 Sections: 4 Final gate: forge test · 9 tests

What you'll write

One file: src/WalrusResolver.sol. The reference-app inlines a forge-std-free Vm interface so the lesson runs offline. ENS is mocked locally; production points the resolver at the live ENS registry on whatever chain you deploy to.

  • s01 · storage + auth

    Storage + the ENS-piggybacked auth gate

    _requireAuthorized(node) consults the EXTERNAL ENS registry — ens.owner(node) and ens.isApprovedForAll(...). That single line inherits ENSIP-1's authorization model in its entirety: if the .eth name ever transfers, the new owner is automatically the authority here too, with no separate claim step on this contract.

  • s02 · write path

    The write path — setWalrusBlob

    Authorization is the FIRST line of setWalrusBlob. Every external mutator calls _requireAuthorized(node) before touching storage. Centralising the check in an internal function — instead of inlining the require — means a future mutator that forgets to call it stands out in a diff. A guard rail by convention, but the cheapest way to make missing auth visible at code-review time.

  • s03 · clear path

    The clear path — clearWalrusBlob

    delete _pointers[node] + an explicit zero-valued event, instead of a self-call to setWalrusBlob(node, 0, 0, 0). The self-call would re-run the auth gate (cheap but redundant) and would emit a "change" event that reads "set to zero" rather than "cleared". Indexers that surface history care about the difference.

  • s04 · read + erc165

    The read path + ERC-165 declaration

    supportsInterface claims ONLY type(IERC165).interfaceId — explicitly NOT the ENS resolver interface ids (0x3b3b57de for addr, 0xbc1c58d1 for contenthash). Advertising those would create a category confusion: a client that auto-detects "is this an ENS resolver?" would assume addr() and contenthash() exist and start staticcalling functions that aren't here.

Verification

Nine Foundry tests gate the lesson — pointer round-trip, owner + operator auth paths, owner-transfer revoke, zero-owner rejection, the clear path, and the ERC-165 declaration.

forge test

The test_setWalrusBlob_overwritePicksUpNewENSOwner case is the punchline: after a simulated ENS ownership transfer the previous owner is immediately locked out, no claim step required.

Sources

Read the reference-app on GitHub, or jump to the upstream showcase for the keeper-bot context.