Swarm references vs IPFS CIDs
A Swarm reference is a 32-byte address (rendered as 64 hex chars, or 128 hex chars for the encrypted variant) that identifies content in the Swarm network. It looks like:
c79394a6c311f816373ec9945365325e7fc0784cfa9a62deec1524d2c2bdc36a
bee-check accepts that hex string with or without a 0x prefix.
How it differs from an IPFS CID
A reference is content-addressed like a CID, but the resemblance ends there:
| Swarm reference | IPFS CID | |
|---|---|---|
| Hash function | BMT-keccak256 (Binary Merkle Tree) | configurable; usually sha2-256 |
| Encoding | raw hex | multibase + multihash + codec |
| Self-describing | no — the bytes don’t tell you the hash function | yes — the multihash prefix does |
| Length | 32 bytes (64 hex), 64 bytes (128 hex) for encrypted | variable |
| Mutable equivalent | Swarm feed (feed:OWNER:TOPIC) | IPNS / DNSLink |
The practical consequence is that you can’t tell from the bytes alone
whether a reference points to a raw chunk, a manifest (file or
directory), or a feed update. bee-check will try to walk it as a
manifest when you pass --per-chunk; if that fails, it falls back to
treating it as a single chunk.
Mutable references — feeds
Swarm feeds are the analog of IPNS/DNSLink. A feed is identified by
an (owner, topic) pair:
owner— a 20-byte Ethereum address (40 hex chars)topic— a 32-byte hash (64 hex chars)
bee-check accepts feed inputs as feed:OWNER:TOPIC or
feed:OWNER/TOPIC and resolves them via GET /feeds/{owner}/{topic}
on the first --bee URL before probing. The resolved chunk reference
becomes the report’s top-level reference, and the original
(owner, topic) is preserved under resolution.
Note: Feed resolution only goes one level deep. If the feed points at another feed, you’d need to resolve that one separately. In practice this never comes up because feed payloads are normally manifest references, not other feeds.