Read a passport

A passport page is one registered image and everything the chain and the index know about it. Every block on it is a live read: nothing is cached into the page and nothing is written by hand.

You get to one from a verify result, from "Your passports" in the studio, from an agent's contact sheet, or from the id directly. The id is the sha256 of the registered bytes, so the URL of a passport is a fact about the file rather than a database key.

If the id is not 64 hex characters, or no passport holds it, the page says "No passport with that id. Check the id, or find it from the verify page."

The poster#

The registered picture, full bleed, with the title and four facts over it.

Standing follows a strict order. A dispute outranks everything, because it is the only state with money behind it. A re-check that did not match comes next, because a passport nobody has checked and a passport that failed a check must never read the same. Everything else is simply not re-checked yet, which is the honest word for registered and nothing more.

If the gateway will not hand the picture over, the poster shows the seal and says "Image unavailable from IPFS right now" rather than a broken image icon. The record is on chain either way.

A passport whose picture is public also carries "Download the original" on the poster. It saves the exact file that was signed and registered, with its Content Credentials, named after the title and read straight from IPFS through Moolam's own route, GET /api/passports/{id}/picture. Nothing re-encodes it on the way, so the saved file's sha256 is the passport id and the copy still verifies byte for byte. A sealed picture its holder has published downloads the same way. A sealed passport has no public download: the route answers 404 for it, as it does for an id no passport holds, and the only copy is the signed file its creator kept with "Save the signed file" in the studio.

A sealed passport#

Some passports have no picture on them, and that is the record rather than a failure. A creator can register a picture without publishing it: the verify service fingerprints and signs the file, hands the only copy back to them, and pins a small record that carries no image, no thumbnail and no manifest document. The passport id is the sha256 of that file, so Monad commits to the exact bytes without anybody being able to see them.

Such a page reads differently in four places, and never as a fault.

Everything else on the page is the same: the creator, the owner, the lineage, what the holder has said about AI use, and the dispute panel. The one thing the holder cannot do yet is add an edit: an edit is a new picture made from this one, and the service has no picture to read, so the panel says "This passport is sealed, so it cannot be edited until the picture is published."

The drawing on the poster is the block hash and nothing more: a 16 by 16 reading of light and dark that the chain already holds in public. It is rough composition, not the picture, and the studio shows the creator exactly that before they sign.

A creator who asked for the private re-check reads three lines differently. The poster says "Moolam keeps only a small private copy, for the private re-check." The second opinion block says whether that copy is still kept, and while it is, offers "Request a re-check"; a verdict from the sealed receiver is badged "Private re-check" and says the confidential workflow ran in Chainlink's simulator on one machine, which is not a real enclave. The holder alone sees "Delete Moolam's private copy", which asks once more before it deletes, cannot be undone and leaves the passport sealed.

Publishing a sealed picture later#

A seal is not forever unless its holder wants it to be. The wallet the registry says holds a sealed passport sees one more panel on the page, under the lineage: "Publish the picture". Nobody else sees it at all.

It asks for the signed file that was handed back at registration. The browser hashes that file on the machine it is on and compares the hash with the passport id, and a file that is not the registered one is refused right there, with nothing uploaded and nothing spent. Only a file that matches is offered a Publish button, and pressing it is the one thing on this site that cannot be undone: the picture, its thumbnail and its manifest are pinned to IPFS and stay public and permanent. The panel says so before the button exists.

The verify service checks the same two things again, against the chain, before it pins a byte: the sha256 of the upload has to be the passport id, and the fingerprint recomputed from it has to be the one Monad recorded. It also refuses a picture whose thumbnail cannot be made small enough for the Chainlink verifier to fetch, because publishing that would leave a passport nobody could ever re-check.

Nothing on chain changes, and nothing can. The registry writes a passport's metadata address once and has no setter, so the sealed document stays its metadata for good. Where the picture went is said by a small record pinned beside it, named after the passport, and that is what the page reads.

Once it is published, the page reads as any other passport: the picture on the poster, the link to its address in the record, and a second opinion that says "not re-checked yet" until the Chainlink workflow runs, because now there is something for it to fetch. Two lines are added rather than taken away: a "Published" clause on the poster's metadata row, and in the record "Registered with no picture published, and published by its holder on that day. The file's hash is the passport id", with a link to the record itself. Explore shows the picture on its plate like any other, and a copy of it checked on the verify page matches with the same line.

If the lookup cannot answer, the page keeps the sealed drawing and says nothing about the record. "Could not find out" and "not published" are two different answers, and this site never prints the first as the second.

Checked again, by someone else#

The loudest block on the page, and the one that separates a passport from a caption. Its own line says why: "Anyone can say a picture is theirs. This part is different: a Chainlink CRE workflow fetched the image, hashed it again and wrote the answer back on Monad."

Each entry is one attestation stored on the registry. Above its fields the page draws both fingerprints as the 64 bits they are, the registered one and the recomputed one side by side with every disagreeing cell marked, and states the verdict in a sentence: a Chainlink CRE workflow re-fetched this picture and recomputed its fingerprint, so many of 64 bits apart, counted on the page from those two values rather than copied from the figure the receiver wrote.

Under that sentence the page says how the report reached the chain. It reads the to address of the report transaction: the CRE simulation forwarder means one machine ran the workflow with no network consensus, which is what every re-check on chain before 2026-10-02 came from, and the Chainlink network forwarder means a quorum of nodes agreed on the answer. The first one that says so is the verdict written at 07:23:42 UTC on 2026-10-02, in transaction 0x760dcb5e…2882. An address that is neither gets no line at all.

The Chainlink line is not a badge Moolam awards itself. A log-triggered Chainlink CRE workflow wakes on PassportRegistered, reads the passport back out of the registry rather than trusting the event, downloads the thumbnail on each node, decodes the JPEG and recomputes the 64-bit hash inside the sandbox, and the verdict is signed into a report. From Chainlink's network the report goes through the Keystone Forwarder to MoolamReceiver. From a run in Chainlink's simulator, Chainlink's simulation forwarder delivers it to a SimulationReceiver, which takes it only in a transaction Moolam's CRE wallet signed. Either one then calls attest. The registry checks the receiver against VerifierPolicy before it writes. The workflow is written so that on Chainlink's network a quorum of nodes must produce the identical verdict before that report is signed, which is the difference the forwarder line above names.

A passport with no attestation says so plainly: "No verification has been written for this passport yet. The Chainlink workflow adds one when it re-checks the image." Where the index has no transaction for one, it says "The index does not carry the transaction for this one." rather than linking somewhere it cannot back up.

Under the block, on every passport whose picture is published, there is a button that says "Request a re-check": anyone can press it, it costs nothing and needs no account, and it puts the passport in a queue. The re-check runner reads that queue every two minutes and runs the Chainlink workflow on it, at most five passports a round and forty a day, so the verdict usually lands on chain within a few minutes. A new picture needs no request at all: the runner picks it up the same way a few minutes after it is registered. The line under the button reports where that request stands, from its place in the queue to the transaction the new verdict was written in, and a sealed passport does not show it because there is no published picture for the workflow to fetch.

The workflow is described in full in Chainlink workflow.

The record#

Two columns that deliberately do not match: who and when on the wide side, the hashes on the narrow one.

The wide side, all read from the chain.

• "Creator", the address that signed the registration, linked to MonadVision, with one line underneath: "This creator's wallet has a passkey bound on chain." or "No passkey is bound to this creator's wallet."
• "Owner", ownerOf for this token id today. It starts as the creator and changes if the token is transferred.
• "Generator agent", a link to the agent page for a Generated passport, or "No generating agent. This one was registered as a photograph." for a Captured one.
• "About" and "Prompt", when the pinned metadata carries them. These are the only two fields on the page that come from a document rather than from the chain.

The narrow side, the fingerprints. Its own line explains the point: "A verifier fetches the picture, hashes it again and compares it with these. Nothing here depends on the file name or on anything the metadata claims."

• "pHash", the 64-bit perceptual hash as a hex word.
• "Blockhash", the 256-bit second perceptual hash.
• "Exact bytes", the sha256 of the registered file.
• "Manifest hash", the sha256 of the C2PA manifest store, or 32 zero bytes when nothing was embedded.
• "Metadata", the ipfs:// URI, linked through the gateway.
• "Passport id", in full, with a note that it is also the ERC-721 token id.

These are shown in full rather than shortened, because they are the part a verifier recomputes. What each hash is and how it is computed is in Fingerprints.

How AI may use this picture#

What the holder has said about AI training, read live from the consent register on Monad. Its own line says why it is not simply a line in the file: a file can carry a line saying its creator refuses AI training, and anyone can strip that line out on the way past. This is the same statement written to a register where only the holder of this passport can write it and nobody can take it back out.

The block leads with the passport's life drawn as one rule, from the day it was registered to today, with every statement marked on it. Drag the thumb, or use the arrow keys, and the page asks the chain what was in force on the day under it: consentAt for that second, not today's answer with an old date printed over it. While it asks it says so, and if the chain does not answer for that day it says that too rather than filling the gap. Above the rule is the reading itself, headed "On this day, AI could", in one of five summaries: Open to AI use, Not for AI training, Ask the holder first, Stated use by use, or Nothing stated yet.

Under the rule is what the summary loses.

A passport nobody has spoken for is a designed state rather than an empty box: "Nobody has written a statement for this picture. It is reported here as silence, because that is what it is: no use has been allowed by it." The four marks are drawn in a colder family than the accent so a creator's no never reads as a fault.

If the register cannot be read, the block says the chain could not be asked and that this is not permission either. It does not fall back to anything.

The control is the holder's alone. A wallet that holds the passport sees "Say how AI may use it" under the block, with the same three plates the studio offers and a use-by-use expander. Anyone else sees only the reading. The send is sponsored, so it costs the holder nothing, and the page confirms it by reading the chain back rather than by trusting the send. The register takes one statement per wallet every ten minutes for the same picture, so after one lands the control locks and prints the time it opens again.

What the choices mean and what they do not do is in Say how AI may use a picture.

Challenged#

This block only appears when a dispute exists. A passport nobody has challenged says nothing here, because an empty dispute box on every page would read like an accusation.

It shows the status, one of "Open, and not yet settled", "Upheld: the challenge was right" or "Rejected: the record stands", plus the challenger, the bond in MON, when it was opened and the evidence hash. The rules behind it are in Disputes.

Edits#

Where this picture came from and what was made out of it. An edit registers as its own passport carrying its parent's id, so the chain of edits is a record rather than a claim in the metadata.

"Edited from" links to the parent when there is one. "Registered from this one" lists the children, read from getChildren on the registry. With no children it says "No edit has been registered from this passport." The rules are in Edits and lineage.

Check a copy#

The same verify run as the verify page, asked from the one place where you are already looking at the original. Drop any copy on "Is your copy this picture?" and it answers against this passport rather than against the whole registry:

• "Yes. Byte for byte, this is the file."
• "Yes. This is the same picture."
• "No. This copy belongs to a different passport."
• "This copy matches no passport at all."

The hint under it is honest about the limit: "A resized, re-encoded, turned or mirrored copy still matches. A crop does not, yet."

Where each number comes from#

If Monad cannot be read, the page says so with the RPC's own reason and asks you to reload. It does not fall back to a cached copy, because a passport page that might be stale is worse than one that says it could not read the chain.