Learn · Topic 2 of 10
contentmultimap
Every Verus identity carries a built-in key-value store, and this project puts the entire NFT inside it.
What it is
The contentmultimap (CMM) is a data structure attached to every VerusID. It maps VDXF i-address keys to arrays of typed DataDescriptor values. Think of it as an on-chain document store where the keys are deterministic and the values are self-describing.
This is fundamentally different from the contract-and-tokenURI model used by Ethereum NFTs. On Ethereum, the token contract stores a URL that points to metadata hosted elsewhere — IPFS, Arweave, or a server. If the host goes down, the metadata is gone. On Verus, the metadata is part of the identity itself. It lives on chain, typed, signed, and retrievable via a single RPC call.
Why it matters
Because the data is on chain and self-describing, there is no external
dependency to break. No IPFS pin to expire, no server to go offline,
no API to rate-limit. Anyone with a Verus node (or access to a public
RPC endpoint) can call getidentity, getidentitycontent, or getidentityhistory and read the full CMM
directly. This viewer uses getidentity pinned to each piece's
registration block, so the CMM shown reflects the original signed state
regardless of any later updateidentity changes.
The typed DataDescriptor format means each entry carries its own structure information — a viewer doesn't need out-of-band knowledge to parse it. The combination of deterministic keys and self-describing values makes the CMM a general-purpose on-chain data layer for any application: credentials, supply chain records, legal instruments, or NFTs.
Worked example
Each Bitcoin Kali piece has one outer key
(i5mntfEpcAWot1dses5qu3hGom3y7r6VHm — series1) containing an array of 10 DataDescriptors.
Three distinct types are used:
Message DataDescriptors (flags: 96)
Human-readable text or JSON with an explicit mimetype. Five of the ten slots use this type:
- name
iQtY1MAM98kf4Ep9AkF6yZ2LRbRUH1Jy1r—text/plain→ "Mahāmāyā"- desc
iCnywaD6yMYuao5cc5WJmNPcpvCDrDXtNE—text/plain→ devotional verse- attrs
iLZq1iNgauVEfV4tN3eapkZcpw3cXTyfyH—application/json→ generative attributes- rights
iMkRBt9sEbrXLxYLxo6s9CgaGEfTeJQf5i—text/plain→ rights assertion (~1500 bytes)- delivery
iMd6GTxpdqoUJjXC87aXVPpKjzZQ3y4bzA—application/json→ z-addr, EVK, txid, filename
Typed DataDescriptors (flags: 32, auto-set)
Structured data where the daemon sets the type automatically. Three sub-types appear:
- crosschaindataref
- Pointer to a transaction (txid + vout). Used for the image reference and the mmrdescriptor reference.
- uint256
- 32-byte hash. Used for the image SHA-256 and the mmrroot.
- signaturedata
- The curator's signature block — identity, hash, base64 signature, and the VDXF key it's bound to.
All 10 DataDescriptors fit in roughly 5000 bytes on chain. The entire NFT — name, verse, attributes, image hash, signature, provenance root, rights, and delivery info — lives inside a single identity's CMM.