How it works

Can I write an identity to my token?

As of block 25,641,947 (2026-07-30 00:01:47 UTC), writing is not enabled on either contract: setIdentityHash(uint256,string,bool) reverts IdentityHashNotAllowed() on both the NFT and the registry. The registry currently holds a hash for 1 of 2,000 tokens. The state page lists the raw reads and the registry's event history.

Each row is one eth_call simulation from an address with no relationship to the collection. mint takes the id as an argument, so one simulation describes one id: ids 0–1999 revert AlreadyMinted(), and 2,000 and above revert TokenIdOutOfRange(). The remaining recovered entry points are standard ERC-721 approval, transfer and ownership functions.

Two identity stores

The NFT and the registry each keep their own identity hash per token — two separate stores on two separate contracts. tokenURI reads the NFT's store, which is empty for every token, while the registry holds a hash for 1 of 2,000. That is why every token's canonical render carries Memory State = Unwritten even though the registry holds a hash for token 0.

Memory State and Memory Lock are attributes the renderer emits from the arguments it is given. They are not reads of registry storage.

Three reachable render states

The renderer takes identity state as arguments rather than reading it from storage: tokenURI(uint256,string,bool,bool) accepts a hash and two bools, and is a view function callable by anyone. All four bool combinations were called for the same token id and the returned bytes compared. Three distinct states come back:

The fourth combination, (written=false, permanent=true), returns bytes identical to (false, false): the second bool has no effect unless the first is set.

Between the unwritten and written states, one <text> element in the SVG changes and two attribute values change. The written states add an eighth Identity Hash attribute and an external_url field. All markup outside the <text> elements is byte-identical, so the geometry does not depend on identity state.

The hash argument is printed into the SVG footer exactly as passed. Calling with a bare CID and calling with the same CID prefixed ipfs:// produce different bytes. The registry stores the bare form in identityHash; identityURI returns the prefixed form.

Contracts

The renderer address is not hardcoded on this site. It is resolved by calling renderer() on the NFT, so the address above is whichever renderer the NFT pointed at when the data was read.

How the state previews are made

Every token page has an Unwritten / Written / Permanent toggle. Each position shows real output from the renderer: 4,000 SVGs were fetched by calling tokenURI(uint256,string,bool,bool) once per token per state and saved to disk at build time. None is produced by editing an existing file.

The arguments are only sourced from chain for token 0, whose hash comes from registry.identityHash(0) and whose permanence flag comes from the third parameter of that token's IdentityHashUpdated log. For every other id the registry holds no hash, so a sample string is passed instead and the result is labelled HYPOTHETICAL on the tab, in an amber dashed frame around the art, and in the caption below it.

Preview data is read only by the token page. It does not reach the grid, the filters or any count on this site. The Written and Permanent figures in the status bar come from registry.hasIdentityHash and the IdentityHashUpdated logs.

Method: recovered from bytecode, then called

No published ABI was used. Function selectors were recovered from each contract's deployed bytecode by scanning for PUSH4 immediates and matching them against a generated space of candidate signatures — and a match is only believed after calling it, because a PUSH4 constant proves a byte sequence exists in the code, not that it is a function selector. This is the recovery step referenced throughout this page.

Every figure on this site comes from a script in the repository that writes a JSON file the pages read. Chain access is eth_call, eth_getLogs and eth_getCode only.

The state page lists the raw contract reads and the registry's event history. The archetype page compares the two places an archetype name appears.

Affiliation

This is an independent reader. It is not affiliated with the identity.md collection or its creators, and it is not a source of authority on the collection. The contracts linked above are.