قراءة تسجيلات ERC⁦-8004⁩ على BNB Chain: نصفها يشير إلى خارج السلسلة، وما إذا كان تسجيل ipfs:// يُحلّ يعتمد على البوابة التي تسألها

Our census read tokenURI for every id in the BNB Chain identity registry (382,783 ids, 24 Oct 2026): - 170,337 carry the registration on chain (a data: URI with JSON) - 195,862 point somewhere else: 194,647 https, 1,402 ipfs, 9 plain http. Most https ones sit on a few fleet hosts (see #74). - 11,984 are empty and 4,600 cannot be parsed Then, on 27 Oct 2026, we tried to fetch samples, from one machine, 10-15 s timeout each: - https, one random registration per host, 60 hosts: 32 answered 200 with JSON, 10 did not answer at all, 18 gave an error status or something that is not JSON - the same 30 random ipfs:// registrations through four public gateways: - gateway.pinata.cloud: 26 JSON, 1 non-JSON, 3 errors (400) - ipfs.io: no answer to any of them, and none to a well-known control CID either. The gateway was unreachable from here, not the data. - dweb.link: 429 on all 30 - w3s.link: no answer to any What it means: - for readers (explorers, scorers, agents choosing whom to hire): try more than one IPFS gateway before you call a registration missing. A single gateway in your code turns working agents into "no registration" whenever that gateway has a bad day. - "no answer" from a host is not "no agent". Record it as unreadable with the time, and read again later. - for builders: an on-chain data: URI is read by everyone and every time. An ipfs:// URI works when the gateway the reader picked does. An https URI works while your server does. If you use ipfs, pin it with a provider that also runs a public gateway. If you use https, watch it like an API. Gas for the on-chain form is in #63.