Solidity compiler by default appends CBOR-encoded metadata to contract’s bytecode. *.getcode.eth is an ERC-3668 wildcard ENS resolver that extracts metadata hash from contract’s bytecode and resolves that as ENS contenthash.
a) old contracts don’t have embedded metadata in contract bytecode
b) all most all contracts with swarm metadata are fail to resolve as they’re not pinned in swarm storage
c) bad proxies like USDC return blank implementation() address
d) lots of contracts don’t have their IPFS metadata pinned in IPFS network
You can read more about this in https://playground.sourcify.dev/, *.getcode.eth is same as sourcify playground but 100% onchain using contract’s bytecode & ENS wildcard resolver.
Another possible issue, there’s no index and ipfs _redirect supported in dag-cbor, and it was was even failing over cidv1.eth’s raw dag-pb/unixfs too. I have to recheck that.
Multichain support with CCIP is cool feature, sourcify team have to run their own signed web2 gateway+fallback servers to handle that.
Resolver is verified on both sourcify & etherscan… UI is basic Helia+CAR builder parsing metadata.json. I even pinged @ligi over twitter to take a look. I’ll be waiting to review & test sourcify’s resolver… ++ I can transfer this getcode.eth domain to sourcify team. Just ack and it’ll be yours to deploy v2 with l2 support.
In the case I outlined this isn’t an issue because we wouldn’t be using inline CIDs. Instead, we would calculate the actual CID on-chain, then we’d need to precompute the folder off-chain as well.
Oh, I thought your dag-pb/unixfs was compatible with the kubo one?
That’d be last option to go for extra headache managing offchain pinning…
I was checking how much we could squeeze in 128 bytes of dagpb inlined.
max 2 inlined files only, metadata.json comes from contract & static offchain pinned index.html is total 115 bytes using CIDv1 OR 111 bytes using CIDv0… we’ve to use CDN/add js scripts in index.html.
I’ve to recheck to find how much of dag-pb/unixfs extra data we can skip in this without breaking… but for your use case of 2 files that should work within 128 bytes.
// cidv0, = NO hex"0170" prefix
bytes internal index_html_cid = hex"122003d76bfe86d06e9a7a6b044b8979d7961078bef8b1673b6205a7da071ede6b51";
bytes internal metadata_json_cid = hex"1220f4cc38c6dd6d2b1c3d4f9081c017f99d119ca28e22eb7d515a2c6deb25349ebd";
// ready to concat format using cidv0
//0170006b12330a22___CIDv0(metadata.json)___120d6d657461646174612e6a736f6e12300a22___CIDv0(index.html)__120a696e6465782e68746d6c0a020801
it is compatible & tested with kubo/helia js data. I mean there’s no index file supported with dag-cbor (index works for dag-pb only, eg link above) & _redirects isn’t working if it’s raw dag-pb/dag-cbor 0x00.
I see you’ve 
Hello from Namesys.eth team here. I only published this resolver coz of recent etherscan API drama.
: 
