Hello Astar-Community,
Following up on our Astar Degens Reporting Q1 2026 and the recent thread Remove Astar Degens from dApp Staking, where I had already shared some information about the broken metadata situation.
We continued working on the issue after that thread and have now fully resolved it.
TL;DR
The Astar Degens NFT collection metadata has been recovered. The original IPFS directory CID is restored and the smart contract’s tokenURI() function works correctly again. No on-chain changes are required.
The Problem
The Astar Degens contract at 0xd59fC6Bfd9732AB19b03664a45dC29B8421BDA9a references the IPFS CID bafybeiecbnxyn6aqvzqy3xe3wl6pzz7grqzu7wuaxedjosr4bi3qjxgcj4 for metadata. Over time this pinning had degraded — the original Hetzner-hosted IPFS node became unreliable, marketplaces showed broken metadata, and there was no easy fix because setBaseURI() had been permanently locked when renounceOwnership() was called, transferring ownership to the zero address.
This meant we couldn’t simply re-point the contract to a new IPFS location. The only viable path was to recover the exact original directory CID, byte-for-byte. Initial realistic estimate of success was around 5–15%.
The Recovery
The recovery took several days and combined multiple approaches:
A custom Node.js toolset walked the HAMT directory structure and recovered all 967 sub-shards through a 9-gateway race against Pinata, Filebase, ipfs.io, and others. Individual file blocks were salvaged from cached snapshots across different gateways. Council member Sababa contributed a complete local archive of all 10,000 JSON files he had downloaded back in 2022.
Cross-validation between IPFS-recovered files and Sababa’s archive showed a 99.6% byte-identical match (7,395 of 7,426 overlapping files), confirming both sources were the genuine 2022 originals.
The combined dataset of 10,000 verified files was imported to a local IPFS node with the exact same parameters as the original (CIDv1, raw-leaves enabled). The computed root CID matched the smart contract’s expected CID exactly: bafybeiecbnxyn6aqvzqy3xe3wl6pzz7grqzu7wuaxedjosr4bi3qjxgcj4. This proved a perfect bit-for-bit reconstruction. The complete directory was then exported as a 14.4 MB CAR file and uploaded to Pinata’s paid infrastructure.
What This Means
The original CID is now actively pinned and resolvable. Marketplaces such as OpenSea will show correct metadata after a “Refresh Metadata” action on individual tokens. Holders see their proper Astar Degens again. The smart contract itself didn’t need any modifications.
Going Forward
To prevent this from recurring, the DAO consider redundant pinning across multiple providers (Pinata, Filebase, web3.storage), automated monitoring of metadata gateway accessibility, and maintaining offline backups of the CAR file with multiple trusted holders.
Happy to answer technical questions about the recovery process if anyone is interested.
Regards,
Jonas