This is a two-fold question because
- (main problem) I’ve noticed that our few “social links” for pool explorers — as correctly defined on our pool’s extended metadata — stopped appearing on cexplorer.io and maybe others a few months ago.
- (a clue, perhaps?) Today I saw our pool is showing errors retrieving our pool metadata on SMASH (I understand a current component of
cardano-db-sync), while data is correctly retrieved for all pools I checked that show this extended metadata properly.
I don’t care so much about SMASH itself, but I do need to get the social links working again. Our social links are blank on Cexplorer although they’re defined in our pool extended metadata. If SMASH turns out to be faulty or obsolete, I wouldn’t need to fix it: I’d be happy enough to find what the pool explorers are missing in our configuration.
According to Cexplorer’s last reading of our pool registration…
- pool hash =
c94e6fe1123bf111b77b57994bcd836af8ba2b3aa72cfcefbec2d3d4 - https://cexplorer.io/pool/pool1e98xlcgj80c3rdmm27v5hnvrdtut52e65uk0ema7ctfag596vr2/about#data
- > Pool certificates > latest > metadata > shows both our pool’s correct home page & extended metadata file
… our pool metadata hash is correct; the same as you get when running cardano-cli latest stake-pool metadata-hash --pool-metadata-file on that main metadata file:
- metadata hash =
8348dd33288f6a000d4349389ff98dbe984c9b02ebdd86b9e48e26c1243cbc76
In fact the IOHK SMASH server maintains an up-to-date copy of this file (at API endpoint /metadata/ poolHash / metadataHash):
… but it claims that there are errors retrieving the file since it doesn’t correspond to a metadata hash from a previous pool registration. 
You can see that hash farther back in our Cexplorer “Pool certificates” history:
- (API endpoint
/errors/poolHash) - https://smash.cardano-mainnet.iohk.io/api/v1/errors/c94e6fe1123bf111b77b57994bcd836af8ba2b3aa72cfcefbec2d3d4
… which repeats this same daily error 204 times:
cause:- ''Hash mismatch when fetching metadata from https://cosd.com/meta/cosd-pool.json.
- Expected “3ddc4dd108dcf9364ed3f083a694324445b75066e68cc16577282a7337666824”
# the expired metadata hash - but got “8348dd33288f6a000d4349389ff98dbe984c9b02ebdd86b9e48e26c1243cbc76”.‘".’
the correct metadata hash
poolHash“3ddc4dd108dcf9364ed3f083a694324445b75066e68cc16577282a7337666824”poolId“c94e6fe1123bf111b77b57994bcd836af8ba2b3aa72cfcefbec2d3d4”
It’s reporting an error because my pool metadata hash (here called poolHash) does not match an incorrect, obsolete value from a previous pool registration.
So I have to wonder if Cexplorer (and other pool explorers) are using cardano-db-sync and an error there is preventing it from getting my pool’s extended metadata.
I don’t have any expectations of SMASH as hosted on iohk.io but I can see it currently displays no errors on @Terminada’s pool:
- (Cexplorer listing) > pool ID =
08f05bcfaada3bb5c038b8c88c6b502ceabfd9978973159458c6535b - https://smash.cardano-mainnet.iohk.io/api/v1/errors/08f05bcfaada3bb5c038b8c88c6b502ceabfd9978973159458c6535b
- = empty JSON (no errors)
- (and metadata file is retrieved successfully; as COSD does, but with errors) =
I’m singling out Cexplorer here because, last I checked, it was still the most socially significant pool explorer. It’s also the only one I ever noticed social inks appearing on. So I would like to get the social links working somehow even if some of this tooling turns out to be obsolete or deprecated. (cc @werkof)