Introducing *.getcode.eth: onchain wildcard contract metadata resolver

🌱 ENS Ecosystem Integrations
1

:pray:
Hello again…

According to my basic dune query there’s total ~5.5 million contracts on mainnet with embedded metadata, I’m not sure what % of that is resolvable using IPFS… Almost all swarm metadata are dead end.

*.GetCode.eth

Solidity compiler by default appends CBOR-encoded metadata to contract bytecode containing IPFS/Swarm hashes with ABI, metadata & contract’s source code.

*getcode.eth is a minimal ERC-3668 wildcard ENS resolver that extracts Solidity compiler metadata from contract bytecode and returns that as ENS contenthash.

Basic UI and Metadata parsing :

Source code (verified on etherscan) :
0x7661a4705F10d828B7d9FAB680c6E9559faEABB0

  • I’ve added IPFS/Helia client in browser/service worker to help with metadata storage and propagation. UI also supports downloading source code as IPFS Content Archive (CAR) & ZIP files. You can read more about this in https://playground.sourcify.dev/, *.getcode.eth is same as sourcify playground but 100% onchain using ENS wildcard resolver.

3 modes

Direct mode :
0x<addr>.getcode.eth --> IPFS contenthash (0xe3010170...) of metadata.json

CBOR mode :
0x<addr>.cbor.getcode.eth --> Returns Raw dag-cbor CID of metadata.json

Proxy Mode :
0x<addr>.proxy.getcode.eth --> Tries to detect proxy & resolve implementation's metadata.json

Example :

https://0xbd3531da5cf5857e7cfaa92426877b022e612cf8.getcode.eth.limo/
https://0x07880d44b0f7b75464ad18fc2b980049c40a8bc3.getcode.eth.limo/

Limitations :

a) old contracts don’t have embedded metadata in bytecode
b) contracts with swarm metadata are almost useless as nobody’s paying postage stamps for that metadata storage
c) bad proxies like USDC return blank implementation() address
d) lots of contracts don’t have their IPFS metadata pinned

// cc @ethlimo.eth :pray: plz giv us wildcard ssl for *.cbor.getcode.eth & *.proxy.getcode.eth

:vulcan_salute: Back to building another thing…

6 Likes
2

This is very clever!

Ironically, it doesn’t have support for named contracts (eg, foo.eth.getcode.eth)?

1 Like
3

I removed direct ens/sub.domain.eth support to go easy on @ethlimo.eth’s ssl providers. With >= 2x wildcards it’ll take big chunk of their monthly SSL cap… if some random kids start abusing ssl/gateways (!not again🤦‍♂️), eth.limo backend will auto check?/limit on wildcards ssl per domain.eth, fallback to secondary ssl providers, & then as last option they’ll disable that wildcard resolver to restore QoS.

That’s why i’m requesting this…

EDIT:
2nd thought,
I’ll update resolver to support sub_domain_eth.getcode.eth, replacing . with _ to save that space.

4

These have been issued :saluting_face:

1 Like