Moolam threat model

Every claim below has been attacked. The Proof column says what happened and names the file the output is saved in: an attack sent against the live contracts on Monad mainnet where that is possible, and a Foundry test where mainnet cannot reach the code path. npm run prove runs the whole set again. Weaknesses we did not fix are listed last, on purpose.

What Moolam promises#

1. A passport, once registered, cannot be altered or removed by anyone.
2. A passport carries a creator signature made by a passkey the creator bound, and, for generated images, a signature by the generator agent that the ERC-8004 registry says owns that agent id.
3. An edit can only be appended by the current owner of the parent passport. ERC-721 approvals and operators are refused; a marketplace listing grants no authoring power.
4. Only receivers listed by the policy can attest, and the list changes only through a public 24-hour delay.
5. Any copy of the image that survives as a picture (re-encoded, resized, re-uploaded, rotated, mirrored, metadata stripped) resolves to its passport.
6. Nobody can take money out of the registry except the person it is owed to.
7. A statement about how AI may use a picture is written only by the address the registry says holds that passport, is never edited or removed, and answers truthfully for any past day.

Who attacks, and what they want#

Entry points and what stops each attack#

The consent register#

MoolamConsent is where a passport's holder states whether their picture may be used to train AI. It is read by AI companies and their crawlers, by indexers, and by anyone taking a commercial or legal decision on what it says, so every value it stores is live input to somebody's parser. It holds no money and has no owner. The full reference is in MoolamConsent.

The write is authorised by a second contract's answer, so every ambiguity in "who holds it" applies to it: a passport that does not exist, a passport transferred a moment ago, an ERC-721 approval, an operator. The product's claim is "what was allowed on the day you took it", which makes the history the asset: any path that edits, reorders or deletes an entry breaks it. And because Moolam sponsors the fee on statements made through the app, a holder's writes are Moolam's bill.

Reentrancy, signature replay, upgrade and admin abuse do not apply here. The only external call is a view on a fixed, immutable contract; there are no signatures, no owner, no proxy and no funds. They stay not applicable only while that remains true, which the last invariant pins.

These eight are the definition of done, each with what proves it.

Eight refusals were executed against the live contract on 2026-09-21 and saved in consent-attacks.txt, with a valid statement from the real holder as the control that passes. They are cast call simulations rather than transactions, which is how the exact custom error is decoded, and they are reads only on purpose: writing the control would put a real statement on a real passport and change what the demo shows.

What the consent register deliberately does not do#

• It does not prove the holder owns the copyright. It records what the passport's holder states.
• A transfer carries the right to change a statement. The old one stands until the new holder changes it, and the history shows who wrote what and when.
• It knows nothing about disputes. A disputed passport's statement must not be relied on, so a reader takes the dispute status from the registry, and the verify service returns both together.
• The ten minute wait compares the caller with the writer of the newest entry only, so the "Bounded writes per writer" row above holds only while the passport stays in one wallet. A holder with a second wallet can pass the passport over and back and write again at once, as often as once a second, and each round costs two transfers of about 85,000 gas each, about 0.017 MON for the pair at 102 gwei (estimated against mainnet on 2026-09-26). It never lets anyone write for a passport they do not hold: the holder is read from the registry inside the same call, so the wallet that just gave the passport away is refused NotPassportHolder.
• The clock is the block timestamp, so a time query is only as fine as the chain's clock.
• No gasless relay and no signatures: a write is a plain call from the holder's wallet.
• It cannot stop anyone from ignoring a statement. It makes ignoring it provable.
• The text rule bounds the bytes and judges nothing else. It does not know what the text says or where a link inside it points, so a reader that follows one still owes its own check. That is written into the contract's own comment so the next reader does not assume more.

Sealed pictures#

A creator can register a picture without publishing it. The passport id on Monad is the SHA-256 of the exact file, so the chain commits to those bytes without showing them. Moolam pins one small JSON document and no picture, no thumbnail and no manifest. The verify service signs the file, hands it straight back to the creator's browser and keeps nothing, so the creator holds the only copy. Later the holder may unseal: the service takes that file and publishes it only if its SHA-256 is the passport id and its fingerprint is the one on chain. Unsealing publishes exactly the registered bytes or nothing. The routes are described in Verifier endpoints.

What is public by design#

Sealed hides the picture, not the passport. These are public from the moment of registration:

• the passport id, which is the file's hash
• the title the creator typed
• the two fingerprints: a 64-bit perceptual hash, and a 256-bit block hash that is a 16 by 16 sketch of light and dark squares and shows the rough layout of the picture
• the creator's wallet and the date
• the statement on how AI may use the picture, when the creator made one
• the fact that it is sealed
• for a picture the agent drew, the agent's id and the model's name. The prompt is left out

The sealed plate on the passport page is drawn from exactly those 256 bits. What a visitor sees there is what anyone can already read from the chain, so nobody is surprised by it.

What sealed promises#

1. Moolam stores nothing of a sealed picture: no file pin, and no file left on disk.
2. Moolam publishes nothing of it: the one document it pins has no image, thumbnail, manifest or prompt in it.
3. The creator holds the signed file before the chain holds the passport. The studio will not open the passkey prompt until the browser has the file and its SHA-256 equals the passport id.
4. No answer on the sealed routes is cached, refusals included, and no log line carries the picture.
5. Only the wallet the registry names as holder, read at that moment, can unseal through Moolam.
6. Unsealing publishes exactly the registered bytes, or nothing.
7. Sealed is said in words wherever a passport shows, and never reads as broken, as re-checked or as public.
8. The creator sees what becomes public before signing.

Promises 3 and 8 are the studio's own screens before the passkey prompt. The attack pass below does not cover them, and this page does not claim it does. For promise 7, the verify answer and the passport page are attacked below; Explore and the share card were read from outside on 2026-09-22 and are recorded in sealed-passports.txt.

Entry points and what stops each attack#

Attack pass 3 ran on 2026-09-23 in two halves, both saved in pass-3.txt. The route half runs the real routes, the real C2PA signer and the real schema, with Pinata, Privy and the registry reads stubbed so every pin can be counted. The live half sends single requests to the hosted service and the live site, and reads the chain. It sends no transaction and spends nothing.

The pass found two gaps and both were fixed the same day. The verify answer did not say a match was sealed (4a), and the re-check queue refused the one unsealed passport as sealed because it read only the sealed document (5g). After commit d07df6e the route half shows both fixed, and the live service, running that build since 07:37 UTC, answered 200 pending for the same passport. The section "After the fixes" at the end of pass-3.txt holds that run.

The first unseal on mainnet#

Passport 0x980549624f85e4ef47043383c5a746cbdd1d82797b5b5583e1f5aeb3841d010c, "Old but strong", was registered sealed from the live studio on 2026-09-22 at 12:23:50 UTC. Its holder published it at 12:27:28 UTC, four minutes later, through the unseal route with the file the studio had handed back. The sealed document on chain is unchanged, because the registry cannot rewrite it. A record pinned beside it says the picture is public since, and the passport page reads the two together (5e and 5i). On 2026-09-23 the Chainlink workflow re-checked it through that record: distance 2, matched, report transaction 0x48aa7543..., a simulation run on one machine like every re-check on chain then. The addresses are in sealed-passports.txt and the row in rechecks.txt.

The private re-check#

A creator who seals a picture may also ask for a private Chainlink re-check. Moolam then keeps one 512 pixel copy of the picture on Pinata's private storage. Nobody can open it from the web; Moolam's operator and the storage provider can. A Chainlink CRE confidential workflow, moolam-sealed-verifier, whose handler is registered with handlerInTee, opens that copy through a read link the verify service mints only while the re-check runner holds a claim on that passport. It recomputes the fingerprint, compares it with the one on chain and writes only the verdict, through a second receiver, so the registry's own record says which workflow wrote it. Today it runs in Chainlink's simulator with --broadcast: one machine, no network consensus, and the simulator is not a real enclave. The workflow is described in Chainlink CRE workflow and the routes in Verifier endpoints.

"Nobody can open it from the web" rests on Pinata not serving a private file through any public gateway. That is Pinata's promise, and no attack here can test it.

What the private re-check promises#

The ids are the ones attack pass 4 uses, so every promise can be followed into pass-4.txt. Where an attack cannot reach the code that keeps a promise, the test that holds it is named instead.

Entry points and what stops each attack#

Attack pass 4 ran on 2026-09-25 in two halves, both saved in pass-4.txt. The route half runs the real routes, the real Pinata client, the real queue and the real sweep, 28 attacks. Pinata is a recording stub whose listing matches on prefix, which is looser than any real filter; Privy tokens are signed by a key the test makes; the chain and the gateway are stubbed; the claim window and the sweep's clock are moved with fake timers. The live half sends single requests and eth_calls to the hosted service, the gateway and the sealed receiver at block 107,820,614. It sends no transaction and spends nothing, and before it sent the real link token it asked the queue whether a runner held the passport. Neither half reaches the runner's or the workflow's own code, which their own suites cover.

No attack got through where it should have been refused. One landed as designed: 5b, the sweep deleting a 49 hour old copy whose passport the chain says was never registered.

The first private re-check on mainnet#

Passport 0x864c33c6806185d4dc7acd65f465fc4c3cb6b8faaa157c32880cbef9dd93fc09 was registered sealed with the private re-check on 2026-09-23 and has never been published. On 2026-09-25 the workflow opened its 25,349 byte private copy through one link minted under a queue claim, recomputed the fingerprint and landed 1 bit of 64 from the chain's: matched. The report transaction is 0xdc1834ea..., block 107,817,793, delivered by the simulation forwarder, and the attestation it wrote names the sealed receiver 0x7b9eF7cD5e40Af9c29d8b7d0D22E54B80947E45A (off the policy since 2026-09-26; attack 8d reads it back). The receiver was put back on the production forwarder and pinned again afterwards. The details are in sealed-passports.txt. A second private re-check the same afternoon, on Kanchipuram Silk Loom at First Light, matched at distance 0 (0xa38fd971..., block 107,834,613).

Simulator-fed receivers and the re-check runner#

Every re-check the runner starts runs in Chainlink's CRE simulator with --broadcast, and a small machine, the re-check runner, starts one within minutes of each new picture. A simulated report reaches Monad through Chainlink's MockKeystoneForwarder, which checks no signature. So the verdicts land through two receivers built for that path, SimulationReceiver (one for the public workflow, one for the sealed one). Each accepts a report only when the transaction was signed by Moolam's CRE wallet, fixed when the contract was deployed. The policy has listed both since 2026-09-27 14:18 UTC. The two MoolamReceiver contracts that came before came off the policy on 2026-09-26, in the run that deployed these, and every verdict they already wrote keeps their address. The public one has been listed again since 2026-10-02 at 07:08:18 UTC, as the door for Chainlink's network (see "Look-alikes, the trust mark and challenges" below). This section is about the simulator path only.

A) What kind of system this is#

Three systems in one: a privileged on-chain writer gated by who is calling, fed by a forwarder that verifies nothing; an unattended bot that fetches addresses strangers wrote and spends money; and a host holding credentials that outrank every user.

• Writer authentication. The mock forwarder calls onReport with metadata built from bytes the caller supplied. The simulator's stamps (workflow id 0x11..11, owner 0xaAaA.., a public workflow name) can be reproduced by anyone who reads this repo, so on chain the only value a stranger cannot forge is the wallet that signed the transaction. Applies to every report.
• Replay and floors. A report's calldata is public. Each receiver keeps its own per-passport timestamp floor starting at zero, so a new receiver would accept every old report once, and the floor is set from a value inside the report. Applies to both new receivers.
• Configuration drift. The forwarder and the pins are owner setters on a hot wallet, and one transaction could reopen the door. Applies.
• Fetching what strangers name. The runner follows the document address written into a passport, from inside the machine, and the simulator does the same for the picture. Applies.
• Spend griefing. Anyone may register passports and anyone may ask for a re-check, and each costs the CRE wallet about 0.1 MON. Applies, bounded by the caps.
• Credential blast radius. One file holds the CRE key, the runner token and the sealed link token, and the machine holds the Chainlink login. Applies.
• Not applicable: rendering user content (the runner draws nothing), storage shared between users (nothing per user on the machine), shell injection (the CLI is started with an argument list and no shell).

B) Threat model#

Trust boundaries. Any wallet to the mock forwarder to onReport, the one unsigned crossing on chain; the receiver to attest, trusted because the policy lists it; the owner wallet to the receiver setters and the policy; a registrant's document to the runner's and the simulator's fetch; the Envio index to the runner; the public request route to the queue to the runner's spend; the runner's result to the verify service's public status; IPFS and Pinata to the simulator; the public RPC to the runner; the machine's disk to everything.

What an attacker controls. The raw report and its 109 byte header, through the mock; the chain id, executedAt, passport id, match, distance and fingerprint, for whoever runs the CLI with the key; the document address and every document field, the picture bytes and any redirect behind them, for any registrant; the queued passport ids, through the public route; index rows and RPC answers; the runner's saved counts after a restart; the CLI's output text, which becomes a published reason.

What the privileged position holds. The CRE key writes any verdict on any passport through both new receivers and holds the wallet's MON. The policy list is the only thing the registry trusts. The owner key re-points, unpins and unlists. The Chainlink login is Moolam's account. The runner token claims and closes any request, and with the sealed link token and a claim it reads a private copy.

What an attacker wants. A false verdict on a passport or an agent's record; a passport frozen by an executedAt of 2^64-1; the machine's secrets, taken by SSH, a poisoned install or a fetch pivot, then used quietly; the wallet burned by junk registrations or request spam; the machine made to fetch an internal address or an enormous body.

C) The standards, and where each is held#

These are the definition of done. R1 to R6 are the contracts and their launch; R7 to R18 are the runner's and the web's. R12 and R13 were added after the code review of 2026-09-28, and R14 to R18 after the one of 2026-09-29.

Four general rules hold across all of it:

• One rule, not a list. The sender check is one equality on the signing wallet. It covers every caller path and does not cover the key holder. The web's list of receiver addresses is labels only; the trust rule is the registry's isReceiver at the moment of writing.
• Compare after the same parser. The workflow name pins and the simulator's stamps are both the first ten hex characters of a sha256, and a mismatch reverts. Passport ids are lowercased by one function on both sides; addresses in the web are compared after one normaliser, addressKey.
• Fail closed. A parse error, a wrong shape, an unknown copy state, an unreadable record, a missing token, a timeout or a cap: no report, no claim used up where that can be avoided, nothing written.
• What this does not defend against. The holder of the CRE key or the owner key. A verdict is one machine's word, with no consensus behind it. Smart-account and relayed senders are excluded on purpose, since only a plain wallet can sign a transaction. The CRE wallet must sign nothing but reports, because a contract it called would inherit its authority. A stolen machine means forgery until removeReceiver runs. The mock forwarder is Chainlink's contract and may change. How exposed the fetches are depends on where the machine sits on its network.

One behaviour of the mock matters to anyone reading the chain: when a receiver refuses a report, the mock does not revert. The transaction succeeds and its ReportProcessed event carries false, and nothing is written to the registry. A report transaction's status alone does not say a verdict landed.

The deploy, 2026-09-26#

One scripted run from the deployer wallet, rehearsed first on a local fork of Monad mainnet, sent twelve transactions, all status 1. The full record is simulation-receivers.txt.

Between the deploy and the listing none of Moolam's four receivers was listed, so no new re-check could be written. The workflow configs point at the new receivers since the listing ran (R3). The runner names no receiver of its own: it runs the workflows with their own config.json, so it sends to whatever the copy of the repository on its machine names.

The platform kit and the MCP server#

Two systems added on 2026-09-30. The platform kit lets an outside image generator give its pictures Moolam passports: four routes on the verify service and the @moolam/platform package on the platform's server (For platforms). The MCP server lets any AI agent read passports and AI-use terms (For AI agents). Neither is live until the next deploy of the verify service, and the live attack pass against them has not run yet, so every row below is proven by the route, store and fork tests it names, and says so. The co-sign page and the connect page in the web app are being built; where an invariant rests on them, the row says it is not built yet.

A) What kind of system this is#

• A signing broker for three parties who do not trust each other. A company's server, a person's browser, and Moolam's certificate, pins and sponsored fees. The co-sign page asks a person to sign a digest another company's server started. The classic faults: the page shows one thing and the digest names another, a link made for one person is opened by another, a record changes between show and sign.
• A credentialed machine API where one party holds every key. In platform mode one server holds the agent's owner key and the passkey bound to its creator wallet. The chain record has exactly the shape of any other passport, so every word Moolam says about a passkey must be true of a server key too.
• A vouching list. "Registered by X through the Moolam platform kit" is a label Moolam issues from its own list. Anyone can mint an ERC-8004 agent with any name, so the list is the only thing behind the label. The credit for who imagined a platform picture ("Imagined by Y. Drawn on X") comes from the same list and one rule, creditFor, beside platformLabel. A platform is only where a picture was drawn and who holds it until the person claims it, never its maker. The classic fault is crediting on a platform's word as if the person had signed.
• Spend by callers. Each prepare costs a C2PA signing and four pins; a co-sign costs Moolam a sponsored registration. Without keys and ceilings it is a faucet.
• Stored, then trusted. A waiting co-sign keeps its fields, digest, files and signature on disk, and the service reads them back to decide what a person's passkey is asked to sign.
• An unauthenticated reader that fetches what strangers name and hands text strangers wrote to a model that acts on it. check_picture fetches a URL, get_agent a card at an address an agent's owner chose, and titles and conditions come back into a model's context.
• A shared, rate-limited index. The index behind lists allows about 100 queries a minute for everything, and Claude calls from one cloud address for all its users.
• Not applicable: SQL or shell injection (no database of our own, no shell, the index is queried by parameterised GraphQL); rendering user HTML (MCP returns JSON, text is drawn as text); contract changes (none; every on-chain check stays as attacked above).

B) Threat model#

Trust boundaries. Any MCP client to /mcp, with no sign-in; the MCP server to the hosts a call names (a picture URL, an agent card address); a platform's server to the /platform routes, where its key is the only credential and identifies without authorising; the person's browser to the co-sign page, where the Privy token is the credential and the handle is not; the platform's site to the co-sign and connect pages; the waiting-co-sign folder on disk to the service that reads it back; Moolam's operator to the platform list; the ERC-8004 registry to the list, since an agent's owner can change after onboarding; the RPC, the index, IPFS and the gateway to every reader; the MCP server's answer to a model that acts on it.

What an attacker controls. The picture bytes and URL; the mode, title, nonce, issuedAt, signature and terms of a prepare, and any creator, wallet or agent field in its body; an agent id, including an agent they own with any name and card; a platform key's value; a handle in a URL or a POST; the agent signature bytes; passport ids, agent ids, limits and times in MCP calls; MCP headers and Origin. Indirectly: the redirects and addresses behind a URL, the body a host returns, the card at an agent's address, a metadata document, the RPC's and the index's answers, every waiting record read back after a restart, and a to address a person or a page gives a platform.

What the privileged position holds. Moolam's C2PA certificate, which says "AI-generated by agent N" under Moolam's name; the Pinata account, where pins are permanent and paid; the Privy sponsorship budget; the platform list and its keys' hashes; the waiting records, which decide what a person's passkey is asked to sign; the Moolam origin a passkey answers to; the MCP server's voice, which models trust.

What an attacker wants. A passport in a person's name over a picture, agent or terms they did not see; to wear a listed platform's name, or make Moolam's certificate say a platform made a picture it did not; to register a platform's picture first; to drain Moolam's pins, signing or sponsored fees; to make Moolam's server fetch from inside its network; to steer a model through Moolam's answers, or have "no match" read while the index was down; to make the site say a person signed what a server signed.

C) The standards, and where each is held#

P1 to P25 are the platform kit's, M1 to M6 the MCP server's. Paths are under packages/verifier unless they name another package. Web app rows name the files as they stand in the working tree.

The rules across all of it:

• One rule, not a list. The label is one predicate over chain fields and one entry, and the credit one rule built on it, so the site and the MCP server cannot disagree about who imagined a picture. Address safety is safeFetch's predicate, text safety the contract's byte rule, id safety one pattern per shape, and the creator check one equality against a verified session.
• Compare after the same parser. getAddress on both sides of every address comparison, agent ids as bigint on both sides, one EIP-712 encoder shared by the service and the package and checked against the registry's hashPassport, platform names through one normaliser.
• Fail closed. No list, no label. No agent signature, no manifest. A digest that differs, an unreadable record, a passed deadline or a chain that did not answer: no prompt, no pin, no send. An index that did not answer: no verdict.
• Where state lives. Quotas, the replay memory and waiting co-signs are on the service's volume at /data and survive a deploy. The service runs one copy, so a request in flight during a deploy is dropped and must be sent again.

Claim with your email#

Added on 2026-10-01. A platform that registers a picture in platform mode can leave the passport waiting for its user's email address instead of asking for a wallet. The platform sends the address with its prepare, and the verify service keeps only a keyed hash of it. When the person signs in to Moolam with Google or an emailed code, My pictures lists what platforms hold for the addresses Privy verified for them, and they answer "These are mine" or "Not mine". The platform's delivery worker hands each accepted passport to the person's Moolam wallet, and the person confirms with one sponsored setConsentBatch from that wallet, which is the moment the credit names them. Moolam writes nothing new on chain: the hand-overs are the platform's transactions and the confirmation is the person's. How a platform uses it is in For platforms.

This section states what the code does today. The live attack pass has not run against these routes yet, so every row below is proven by the route, store, SDK, fork and web tests it names. Paths are under packages/verifier unless they name another package.

A) What kind of system this is#

• An identity broker between two companies. The platform says an address belongs to its user; Privy says the person signed in to Moolam proved they read that inbox. The two strings meet only through one normaliser. Too loose hands a stranger someone's pictures, too strict strands them.
• An attribution channel. A ticket names an address and a picture. If the person accepts and confirms, the credit names them for good, so anyone who can write a ticket can try to pin a picture on a real person. A ticket is therefore only ever an offer.
• A small multi-tenant store keyed by a hash of personal data. An HMAC of an email under a server secret can be reversed by dictionary by anyone holding both the secret and the store, and the store lists the platforms each address used.
• A hand-over service whose output a third party acts on. The destination wallet goes to the platform, whose server moves a token to it. A damaged or swapped address is a transfer nobody can undo.
• A public record keeper. Waiting, delivered and confirmed are said on Moolam pages and in MCP answers, so each must rest on a chain read, never on a platform's word or the ticket file alone.
• A state machine on disk, read back as truth. An accept racing a refuse, two accepts, a worker trying again after its transfer landed.
• Platform-chosen fetch targets inside a person route. A platform-mode passport's metadata address is the platform's choice, and GET /claims draws its title and picture.
• Spend by callers. Each /claims read calls Privy and the gateway, each confirm is a sponsored transaction, and each failed hand-over costs the platform gas.
• Unsolicited content sent to a named person. Spam or a phishing-shaped title can ride a ticket.
• Not applicable: SQL or shell injection (no database engine and no shell; the store is schema-checked JSON on the volume); rendering user HTML (titles are drawn as text); blind signing (the person's one transaction is setConsentBatch over ids and terms the page shows first); contract changes (none).

B) Threat model#

Trust boundaries. A platform's server to POST /platform/prepare with deliverTo; Privy's user record to the verify service; the person's browser to GET /claims, POST /claims/accept, /claims/refuse, /claims/unmute and DELETE /claims/standing/:platformKeyHash; the ticket file on disk to every route that reads it back; GET /platform/deliveries to the platform's worker; the chain (the registry's record and ownerOf) and the Envio index (the first hand-over and the consent history) to the ticket states and the credit; the IPFS gateway to GET /claims; the stored terms to the browser that builds setConsentBatch; Google's ID token to Dreamloom's server, which is Dreamloom's own boundary.

What an attacker controls. Directly: deliverTo.email (any string, any length, any script), deliverTo.verifiedBy, how many tickets a key writes, the ticket ids in an accept or a refuse, the terms and the send-future tick, a platform key, a Privy token, the picture and title of a prepare, and the metadata address on chain. Indirectly: the set and spelling of the addresses in a person's Privy record, the wallets Privy lists, every ticket field read back, what the RPC and the index answer and how far behind the index is, the document behind a content id, the writer and time of every consent entry, transfers anyone makes to anyone, and the pepper if it leaks.

What the privileged position holds. Moolam's Privy app secret, and with it every Moolam user's verified addresses; the pepper; the ticket file, which after an accept links an address's hash to a wallet; the authority to tell a platform where to send a token; the authority to say waiting, delivered and confirmed on a public page and in MCP answers; the sponsorship budget.

What an attacker wants. To pin a picture on a real person (a ticket, an accept, a confirm, a credit); to catch someone else's pictures, through a spelling collision or by naming another address's ticket ids; to learn whether an address has a Moolam account, or which wallet it owns, by probing prepares; to send a passport somewhere wrong, or make the worker spend for nothing; to make Moolam state a false chain fact: an offer for a passport that does not exist, delivered on the platform's word, confirmed from a stale index or the wrong writer.

C) The standards, and where each is held#

P26 to P39 extend the platform kit's P1 to P25 above. P35 and P39 replace P16's credit cases: "claimed" is retired, and the credit is held, handed, confirmed, passedOn or cosigned.

The rules across all of it:

• One rule, not a list. One address predicate and one normaliser for both strings, one chain read each for open, delivered and held, and one credit function. What they do not cover: look-alike letters across scripts, and one person with two addresses.
• Compare after the same parser. The same emailHash on the platform's string and on Privy's, getAddress on every address pair, passport ids lowercased by one function, ticket ids by exact lookup.
• Fail closed. Chain unreadable: no ticket opens, nothing is delivered, no credit. Privy unreadable: no list and no accept (privy-unavailable). No pepper: every claim route, and every prepare with deliverTo, answers claims-unavailable. A record that fails its schema is dropped, a metadata address that is not a content id shows no preview, and an unknown verifiedBy is refused at prepare.
• Where state lives. Tickets, standing choices, mutes and each key's tally are one JSON file on the service's volume at /data, written whole, so a process killed mid-write leaves the previous file.

Look-alikes, the trust mark and challenges#

Added on 2026-10-01. A passport proves who registered a picture first, and nothing stopped a person from registering a re-saved copy of someone else's picture as a fresh original. Moolam does not refuse a look-alike, because a refusal hands the picture to whoever registers first. It labels one. Before signing, the studio and the platform kit say when an earlier passport by someone else looks like the picture, and a public camera upload is checked against the web through Google Cloud Vision. After registration, Chainlink's workflow measures the picture itself and writes any earlier look-alike it can prove to a new receiver, MoolamLookalikes. Each passport wears one trust mark, issued worst first, and only the network's own writes can light it. A challenge still needs a bond; the holder may now sign an answer within 14 days, and the resolver's reasons are published through a second new contract, MoolamDecisions. What the mark means to a reader is on The trust mark; how a challenge runs is in Disputes.

Both contracts are on Monad mainnet with a full Sourcify match: MoolamLookalikes 0xC0f3984A8116dB8BE514F649e3605A2a3aCd454C and MoolamDecisions 0x30AbA7747342fA3ac9d990Ec2Cf407cC968c497F. This section states what the code does today. The live attack pass has not run against any of it, so every row below is proven by the contract, workflow, service, index and web tests it names.

What went live on 2026-10-02, on Monad mainnet:

• The policy's listing of MoolamReceiver (0x0d69055c43EAcb3B1ca687ca2263A049Bc7Eff04), the receiver the network's verdicts go through, ran at 07:08:18 UTC, block 109,830,535, in 0x446c3051....
• Chainlink's network runs moolam-verifier, owner 0xf072a8c620bfc818875736e3f2d3a2a339c06584, active from about 07:09 UTC as workflow ID 00c4dd797775bb465fff638ab5171b19a35ed11d4513eb4890661935d4801890, which held the verdict step only. Since 2026-10-07 it runs as workflow ID 0031b78176458a823e3930d4efe7d5b6a45807964dac463e9551b49e28e3fe21, with the look-alike step too. The index and the workflow count network writes from 1790924898 (07:08:18 UTC).
• The first network verdict: passport 0x793a540e287cbdfc6cb680c42b553641fa504afebcce6fd5f035e5e600f15782, registered at 07:23:26 UTC in 0x162c97a7.... Ten Chainlink nodes recomputed its fingerprint, distance 0, matched. The verdict is 0x760dcb5e..., block 109,833,597, 07:23:42 UTC, sent to the Keystone Forwarder 0x76c9cf548b4179F8901cda1f8623568b58215E62: 16 seconds from registration to the network's verdict.
• The treasury was set to the burn address 0x000000000000000000000000000000000000dEaD in 0x45700954..., block 109,834,440, 07:27 UTC. Rejected bonds are burned.

Live from 2026-10-07: the look-alike step in the network workflow, the verify service's look-alike routes and its Google web check on the hosted service, and the hosted index rebuild that lets the live site's marks and counts see the network flag. Before that rebuild the live site's index could not tell network verdicts from test runs. Paths are under packages/verifier unless they name another package.

A) What kind of system this is#

• An oracle whose output is a label on a named person. Chainlink's nodes measure a stranger's picture and write through a forwarder, and the site turns the record into "Registered after a look-alike" on one passport and "A later passport looks the same" on another. The classic faults: a writer that is not who the reader thinks, a replayed or stale report, an order turned round so the original reads as the copy, and a candidate source, Moolam's own search, that can make the oracle say "none" by staying quiet.
• A service that repeats what strangers wrote. The warning before signing carries another registrant's title and date into a creator's studio and into a platform's server. seenEarlier and the web pages are pinned for good and drawn on public pages. Anyone can also register straight on chain with a document that says anything.
• A client of a paid third party that sees pictures. A camera upload's public thumbnail goes to Google before the person has decided to register.
• Public routes that steer a spender. The candidates and backlog routes are read by Chainlink's nodes with no credential, and the backlog decides what the network spends gas on.
• Two signed-message routes that pin for good: the holder's answer and the resolver's reasons.
• Not applicable: SQL and shell injection (no database engine, no shell); reentrancy on the two new contracts (neither holds money, MoolamLookalikes calls nothing, MoolamDecisions only reads the registry and the policy); upgrade abuse (no proxy); user HTML (every title, answer and reason is drawn as text).

B) Threat model#

Trust boundaries. Chainlink's forwarder 0x76c9cf548b4179F8901cda1f8623568b58215E62 to onReport on both receivers, the one signed crossing for the network's writes; the owner key of MoolamReceiver to its setters, a crossing with no delay (MoolamLookalikes has no owner, so no such crossing); Chainlink's nodes to the candidates and backlog routes, and the answer back into the run; a registrant's document and thumbnail, and up to three candidates' records per run; the Envio index to the site, the MCP server and the backlog route; Google's answer into a document the creator signs; another registrant's title into a studio or a platform's server; the holder's wallet to the answer route; the resolver's key to resolve, publish and the reasons route; the chain and the index to the one rule that says which passport came first.

What an attacker controls. Directly: the picture bytes, title and sealed flag of every prepare; a document written straight on chain, seenEarlier, the sworn line and the title included; the fingerprints of a passport registered straight on chain; the fingerprints, asOf and n sent to the candidates and backlog routes, by anyone; the answer text, passport id and signature; the evidence address on flag; how many passports a wallet registers, and when. Indirectly: Vision's page addresses and counts, the gateway's bodies, the RPC's and the index's answers and lag, and clock values that become executedAt.

What the privileged position holds. The forwarder's signed path is the only thing that can light "Checked by Chainlink" or "Registered after a look-alike". The deployer key owns MoolamReceiver and is today the policy's owner and resolver. The treasury is the burn address. The verify service holds the Vision key, the Pinata key and the index copy, and decides which candidates the network ever hears about. The workflow owner 0xf072a8c620bfc818875736e3f2d3a2a339c06584 deploys what the pins accept. The resolver key alone decides a bond and the mark "Challenge upheld".

What an attacker wants.

1. To brand an original as a copy: turn the order round (a same-second pair, a replayed older record, an index that joins the wrong way), or write a record through a re-pointed receiver.
2. To keep a stolen registration clean: register straight on chain to skip the warning, the sworn line and the web check, or make the search or Vision fail so the silence reads as clean.
3. To show a person a false "someone registered this earlier" as they sign, through crafted fingerprints or a fake seenEarlier.
4. To spend Moolam's money: Vision calls, network reports through junk registrations, pins through the answer and reasons routes.
5. To plant text or links in front of other people.
6. To freeze a passport's record with an executedAt at the top of the range, or carry an answer over to another dispute.

C) The standards, and where each is held#

The numbers are the ones the code's own comments carry, so each row can be found with a search.

The rules across all of it:

• One rule, not a list. "Earlier" is one function over the registry's registeredAt. "The network's" is one rule over the transaction and the event. What goes to Google is one predicate. The mark is one function. What they do not cover: the network itself writing a wrong record, and who made a picture.
• Compare after the same parser. Passport ids are lowercased by one function everywhere, creators are compared after one normaliser, and the thresholds come from one file the service and the workflow both keep.
• Fail closed. No candidate without this run's own measurement, no record without two passports in order, no mark on a tie, "could not check" instead of silence, "not ready" instead of a partial list, no answer outside an open dispute, and a refused write is a failed run.
• The bond. A rejected challenge's bond is credited to the policy's treasury, and since 2026-10-02 at 07:27 UTC the treasury is the burn address 0x000000000000000000000000000000000000dEaD (change id 0x87571be2e5c590b8fa1e9f2921d8a3807c8e210f216c32fbc1f29b069030f3a0, executed in 0x45700954..., block 109,834,440). Before that the treasury was the deployer 0x559F357aDa3A96d11AEa679eC0D622E4AF15F67c. Rejected bonds are burned.

What the screens promise#

Three rules for what the web app draws and serves. The first two were added after the code review of 2026-09-26, and the third after the one of 2026-09-28. All three hold for every visitor, whatever a registrant wrote into their document.

Weaknesses we did not fix, stated plainly#

• First registered wins. A passport proves who registered first, not who created. For AI output the two are the same moment, because the generator registers before publication. For a human photo it is a timestamped claim.
• Crops. A crop of more than a few percent breaks both fingerprints. We publish the measured number rather than pretend otherwise.
• Adversarial perturbation. Someone who knows the algorithms can craft an image that fingerprints close to another. We do not defend against that; the exact hash and the signatures still separate the two records.
• The verifier's fetch. The Chainlink workflow fetches a downscaled copy through an image proxy because of its 100 KB response cap. If the proxy lies, the attestation is wrong. The attestation is one signal next to the signatures, not the source of truth.
• A stolen wallet can rebind the passkey. Rotating a passkey needs the wallet plus an assertion from the new key, not the old one, so whoever controls the wallet controls the binding. We chose that so a lost passkey does not strand the account. Passports already registered keep their original signatures either way.
• Tunnelled IPv6 forms. The fetch guard normalises IPv4-mapped IPv6 and blocks every private, loopback, link-local and metadata range, pinning the socket to the address it checked. It does not decode the IPv4 embedded in 6to4, NAT64 or Teredo addresses, so on a host with one of those tunnels configured they remain a path inward. The verifier is deployed without such tunnels.
• Software keys. The seed, agent and proof scripts sign with a software passkey (a P-256 key held in process memory on the operator machine) so they can run unattended; a creator in the studio signs with the passkey in their own device authenticator, which never leaves it. The verifier posts reputation feedback from a plain key in its host environment, so a compromised host could post feedback in its name. A platform in the kit signs the same way, from its server: a platform-mode passport is a single-party attestation, one company holding the agent's key and the key bound to its creator wallet, and every word Moolam shows for it says so. The chain cannot tell that key from any other passkey.
• IPFS liveness. If the pinned files disappear, the on-chain record still proves the hashes but the image is gone from our storage. Anyone holding a copy can re-verify it.
• The digest the passkey signs comes from the RPC. Today the browser asks the registry for the EIP-712 digest of the passport it is about to register and hands that answer straight to the passkey. A hostile RPC endpoint, or anyone sitting between the browser and it, could return a digest for different bytes, and the creator's device would sign something they never saw. The damage is bounded, because the signed struct still names the creator as the signer and the registry mints to that address, so an attacker gets a passport written in the creator's name rather than one written in their own. The fix in flight derives the digest locally in the browser from the same struct, which turns the RPC answer into a cross-check instead of the source of truth.
• The passkey's rpId is a deployment constraint, not a contract rule. A passkey is scoped to a registrable domain, and any page served under that domain can ask the authenticator for an assertion from the same key. So the app must never share a registrable domain with a page we do not control, including anything user-generated. On vercel.app the public suffix list gives us that for free: each subdomain is its own registrable domain, so no other deployment can reach our keys. On a custom domain the rule has to be kept by hand, which means every subdomain under it stays ours.
• The orphan pin of a sealed prepare. The sealed document is pinned before the creator signs, because its address is part of what they sign. A creator who walks away leaves that document on IPFS for good, holding the title, the fingerprints and the hash, with no passport behind it. Attack 1e shows it, and nothing tidies it up yet.
• A title is the creator's own public words. The title is published as typed, sealed or not, up to 120 characters. Someone who pastes a picture into it publishes at most 72 bytes of one, which is no picture (attack 1c).
• The sketch is public. The block hash is a 16 by 16 light and dark sketch of the picture. It shows the rough layout and nothing finer, and the passport page draws it large so nobody is misled.
• Front-running a sealed registration. The registry is immutable and first registered wins, so someone who copies the hash out of a pending transaction and lands first holds the passport. That is as true of public pictures. For a sealed one the dispute path is weaker, because a challenge is judged only on what each side chooses to reveal.
• The image model's provider has seen a generated picture. It drew the picture. Sealed keeps it from the public, not from them.
• The creator holds the only copy. Moolam keeps nothing of a sealed picture, so a creator who loses the signed file can never unseal that passport. Any copy of the picture still matches it in Verify, because matching runs on the public fingerprints, not on the file.
• The picture passes through the service's memory. To fingerprint and sign it, the verify service holds the picture in memory for the length of one request, about 100 MB at the peak for a 20 MB file, and Node does not wipe freed memory. Nothing is written to disk (attack 1d).
• The private copy is private from the web, not from us. Moolam's operator and Pinata, the storage provider, can both open the 512 pixel copy a creator asked Moolam to keep. The studio says so beside the switch, before the creator signs.
• One shared token plus a live claim reads a copy. Whoever holds the link token while the runner holds a claim can read that one passport's copy. The ten minute claim window and five links an hour bound it (attacks 1c to 1e and 1k), but the hourly count is held in memory, so a redeploy resets it.
• The simulator is not an enclave. Every private re-check so far ran in Chainlink's simulator on one machine, which says of itself that it is not a real TEE. That machine sees the token, the link and the picture, and no quorum of nodes stands behind the verdict.
• The simulation receivers trust one wallet. Re-checks run in Chainlink's simulator, so their reports come through Chainlink's mock forwarder, which checks no signature. The two simulation receivers accept such a report only when Moolam's CRE wallet signed the transaction. Whoever holds that key, which lives on the re-check machine, can write any verdict until the owner removes the receivers from the policy, which takes effect at once. Before this change the old receivers were opened to the mock for each operator run, and anyone with the simulator could write during that window.
• The first fetch through a fresh private link is slow. Pinata's private gateway took 6 to 12 seconds to answer the first request on a new link, past the workflow's 10 second limit per call, so the workflow tries the same link up to three times inside its 120 second life.
• Moolam vouches for keys, not companies. A platform on the list proved it holds the agent's owner key and its creator wallet. Moolam does not check who the company is, or that its generator made what it says it made.
• A platform's picture can be registered first by someone else. In platform mode the platform holds Moolam's signed file before it sends register. In co-sign mode the files are pinned to public IPFS when the agent signs, and stay there unregistered until the person signs, up to 30 minutes. Whoever registers those bytes first holds the passport, as with every picture here. The prepare refuses a picture already registered, and the status route says failed when another passport took the id.
• A tap proves a key signed, not that a person understood. The co-sign page shows the picture, the agent and the terms before the prompt; it cannot make anyone read them.
• Hand-overs are the platform's promise. Nothing makes a platform transfer a passport it promised, and a correctly typed wrong address is still an address. transferPassport refuses only what it can check.
• An agent's owner can change after onboarding. Prepares follow the owner read at that moment, and get_agent says when the owner is no longer the one that signed the entry. A passport already registered keeps its label, because the label is judged on the fields the chain recorded then.
• Look-alike names. The name check folds case and Unicode forms, not look-alike letters from two scripts. The label always sits beside the wallet and the agent id for that reason.
• The platform's own keys. Its Moolam key, agent key, passkey and wallet, and its copy of the package, are its to keep. A leaked Moolam key alone makes no manifest; a leaked agent key makes pictures in the agent's name until the agent token moves.
• The MCP server cannot tell one Claude user from another. It has no sign-in, and Claude calls from Anthropic's cloud, so every Claude user shares one address and one rate count. The count is kept per process.
• Rules outside Moolam. Privy's sponsorship rules and credit balance bound what co-sign mode can spend, and Anthropic decides where Claude's calls come from.
• A platform's own email check is the platform's. Moolam does not check that the address a platform sends belongs to the person who made the picture. It checks only that the Moolam user who sees the offer proved that address to Privy, and it shows the platform's verifiedBy as the platform's claim. A platform that sends the wrong address hands the offer to that address's owner, who can accept and confirm it. Whoever confirms a picture they did not make has signed a public statement, and Moolam records it.
• Gmail dots and plus tags are not folded. r.am@gmail.com, ram@gmail.com and ram+art@gmail.com are three addresses here, and a googlemail.com address is a fourth. Folding them is one provider's rule, and a list of providers' rules misses the next provider. An offer sent to a spelling the person never verified with Privy is never shown to them, and expires after 180 days.
• A new pepper ends what waits under the old one. Raising CLAIM_PEPPER_VERSION expires every pending and open ticket written under the old pepper at the next sweep. Accepted tickets keep their destination and are still delivered. Standing choices, mutes and the per-address ticket counts made under the old pepper stop matching, so a person has to choose again, and a platform they said no to can offer again.
• Losing the email account. Offers match the addresses in the person's Privy record, not live access to the inbox. A person who loses the inbox but can still sign in to Moolam another way, a passkey or a second linked account, still sees and answers their offers, and keeps every passport already in their wallet with its credit. A person who can no longer sign in at all cannot accept: their offers expire after 180 days and the passports stay in the platform's wallet, read as held. Moolam has no recovery path of its own; account recovery is Privy's. Whoever takes over the inbox can sign in with a code sent to it, and so can see and accept what waits for that address.
• A platform can credit its own second wallet. A platform that hands a passport to another wallet it controls and writes terms from it reads as confirmed for that wallet. Nothing on chain tells a platform's second wallet from a person's.
• Pictures are not moderated. A person can say "Not mine" and stop a platform's offers, and a key that collects too many refusals stops writing tickets. Moolam does not judge what a title or a picture shows.
• A look-alike mark proves order, not authorship. "Registered after a look-alike" says which passport came first. A thief who registers a picture before its maker does is marked as the earlier one, and the maker's later passport carries the mark. The challenge is the remedy.
• "None found" rests on Moolam's search. The network only proves what the verify service proposes. A service that is down, behind, or that leaves a candidate out makes the run write "none", which the site words as none among the candidates Moolam's search proposed, never as original. A search that gives no answer at all writes nothing.
• Crafted fingerprints, and an open search. Someone who knows the algorithms can craft a picture that lands near another's fingerprints, and the public candidates route tells them how near they are. Nothing here defends against that.
• Registering straight on chain skips the checks. A passport registered without Moolam's studio or the kit has no warning, no sworn line and no web check. The page says so in those words, and that is all Moolam can say.
• The web check answers one narrow question. It says whether Google found the picture on the web when Moolam looked, nothing about who posted it first. It sends a public camera picture's 512 pixel thumbnail to Google before the person signs, which the studio says beside the upload. When it finds nothing, fails or times out, nothing is recorded, so its absence proves nothing.
• Only originals are compared. A passport registered as an edit skips the look-alike step, so a copy registered as an edit of the copier's own earlier passport is not marked by it.
• Two passports in the same second are never ordered. Monad seals more than one block a second and registeredAt counts whole seconds, so neither of two same-second registrations is ever marked as the later one.
• The verdict receiver has no ceiling on time and still has an owner. MoolamReceiver (0x0d69055c43EAcb3B1ca687ca2263A049Bc7Eff04) cannot change, and it refuses no executedAt for being far in the future. A clock fault in the workflow could set a floor no later run passes and freeze that passport's verdict there; the fix would be a new receiver. Its owner, the deployer key, can re-point it in one transaction with no delay, to another forwarder, author or workflow name. A workflow it is re-pointed to still writes through Chainlink's forwarder, so the rule in L4 counts its verdicts as the network's: the site cannot tell them apart. Each re-point is a public transaction on the receiver.
• The workflow's code can change without touching either receiver. Both pin Moolam's Chainlink account (0xf072a8c620bfc818875736e3f2d3a2a339c06584) and the workflow name, not one workflow id, so a new version of moolam-verifier deployed from that account writes at once. The code is this repository's, and every deploy is recorded in Chainlink's workflow registry. MoolamLookalikes has no owner and no clock problem.
• The network's spend is bounded by caps, not by who caused it. Each junk registration costs the network one verdict and at most one look-alike report through its own run, with no daily cap on that path; the caps in L15 bound only the catch-up.
• Chainlink's nodes see every public thumbnail they check, as they always have.
• One resolver decides. Moolam decides challenges today, through one address the policy names. The written rules, the holder's answer and the published reasons make each decision checkable; they do not make it a court's. The holder's answer and the resolver's reasons are their authors' words, and Moolam bounds their bytes and judges nothing else.
• A holder in a contract wallet cannot answer. The answer route takes only a plain wallet signature, so a passport held by a smart account has no way to answer a challenge here.
• A quick re-flag can strand a decision's reasons. A rejected passport can be flagged again at once, and the registry then holds the new dispute. Reasons for the earlier decision that were not yet published can no longer be published through MoolamDecisions, because it reads the dispute the registry holds now.
• A burned bond is gone for good. Since the treasury was set to the burn address on 2026-10-02, a rejected challenge's bond is credited to an address nobody holds a key for. The registry credits bonds rather than sending them, so nothing reaches that address and nothing can be withdrawn from it.
• Self-audited. No third party has audited these contracts. The attack scripts and their outputs are the evidence, and they are in this repo.