For platforms

The platform kit lets an AI image company give every picture made on it a Moolam passport on Monad that credits the person who imagined it. The company's ERC-8004 agent signs for the tool that drew the picture, and the person signs as its creator. A platform is where a picture was drawn, never its maker. It is a TypeScript package for the company's server, @moolam/platform, and four routes on Moolam's verify service that sign the C2PA manifest, fingerprint the picture and hand back the passport fields.

What is live today. The verify service at https://verifier-production-d76f.up.railway.app runs the four /platform routes and the MCP server, and https://<verify-service> on this page stands for that address. Moolam's platform list has one entry, Dreamloom, the demo platform at https://dreamloom-production-3e74.up.railway.app, which registers its pictures through the kit. Not live yet: the email claim routes (/claims and /platform/deliveries), the confirmed credit described below, and the co-sign and connect pages on moolam.vercel.app. The routes and the credit go live with the next deploy of the verify service, and the pages with the next deploy of the web app. The package is private to this repository and not on npm yet.

The two modes#

A platform picks a mode for each picture. Co-sign is the main path: the person signs, and the passport credits them from the first block.

In co-sign mode your server prepares the picture and your agent signs, and the person finishes it on a page at https://moolam.vercel.app/cosign#<handle>. The handle travels after the #, so it never reaches a server log, an analytics tool or a Referer header. The co-sign page ships with the next deploy of the web app.

In platform mode you register the picture at once and hold the passport for the person until they claim it. One company holds both keys the registry asks for. The chain records the same fields it records for anyone, and Moolam says exactly what that proves: a key bound to the creator wallet signed the fingerprint, and your agent's owner signed it too. The person claims the passport later through a transfer from your wallet to theirs (Handing a passport to a person). How Moolam credits each case is below.

Which way to hand passports to people#

There are three ways for the person who imagined a picture to end up holding its passport and named as its maker. Sign it yourself is the one we recommend.

Pick sign it yourself when the person is at the screen when the picture is made, which is almost always. Pick leave it for their email when you generate in the background or in bulk and you have already verified each user's email. Pick connect once when you have no verified email for your users and they come back to your site.

Why we recommend it: sign it yourself is the only way that puts the person's own key on the picture. Their passkey approves this exact picture before the registry writes it, so the credit never rests on your word about who asked for it, and it costs you no gas. The other two ways credit the person too, but only after your hand-over and their own confirmation, and the passport says so.

Joining the list#

Moolam keeps one public list of platforms, packages/verifier/src/platforms/platforms.json, copied byte for byte into the web app. No route writes it. A Moolam operator adds an entry with scripts/platform-add.ts and commits it, so every change is in git history.

What an entry holds. Your platform's name, your ERC-8004 agent id, the address that owned the agent when you joined, your creator wallet, the sha256 of your Moolam key, one to four https origins your site opens Moolam from, the time the entry starts (validFrom), the time it ends (validTo, set only when it is replaced), the time the operator accepted it, and two signatures.

What each signature proves. Both are EIP-712 signatures over one PlatformOnboarding message in the domain Moolam platform, version 1, chain 143, covering the name, agent id, agent owner, creator wallet, key hash, origins and start time.

• The agent owner's signature proves that whoever holds the key of the address named as your agent's owner agreed to be listed under this name, with this wallet, this key and these origins.
• The creator wallet's signature proves the wallet that will be the creator of every platform-mode passport agreed to the same.
• The operator's acceptance is running the script and committing the entry. It is recorded as acceptedAt and is not a signature.

How the list is checked. The service and the web app check every signature when they load the list, offline, with no network call. One bad entry refuses the whole list, and a refused list means no platform routes and no labels anywhere, never a partial list. Names are stored cleaned (NFKC, trimmed, one space between words), at most 48 characters, printable, and unique after case folding. One name belongs to one agent, one agent and one creator wallet to one name, a key hash appears once, and two entries of one platform never overlap in time. Origins are stored in the one canonical form new URL(origin).origin gives, https only, with no path.

What the list does not prove: who the company is. Moolam checks that you hold the keys you name.

Your Moolam key. The operator's script makes 32 random bytes and prints them once, as 64 hex characters, to hand to you over a private channel. Nothing writes the key to a file. The list stores only its sha256, which is safe to publish and is your platform's id in every PlatformPrepare message. You send the key as Authorization: Bearer <64 hex characters> and nowhere else. Moolam cannot show it to you again.

The key identifies your platform and meters it. Alone it cannot make a manifest: every prepare also needs your agent owner's signature, checked against the ERC-8004 registry at that moment. A leaked key costs you quota, not your name.

Rotation. Each key can be replaced without touching passports already registered.

Your agent id cannot change under the same name. A new agent is a new platform.

Before your first picture#

1. Register an ERC-8004 agent on Monad's identity registry, 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432, from a plain key. The Moolam registry recovers the maker's signature with ECDSA and compares it with ownerOf(agentId). It does not accept a contract signature, so an agent held by a multisig cannot sign for Moolam.
2. Pick a wallet for platform mode that holds no passports yet, and fund it with MON.
3. Send Moolam your name, agent id, agent owner address, creator wallet and origins. Sign the typed data the operator sends back from the agent owner key and from the creator wallet, and keep the Moolam key the operator hands you.
4. For platform mode, run setupPlatform once from the creator wallet.

The secrets you keep#

The package runs on your server only, never in a browser. It logs nothing, and its errors never carry a key, a private key or a co-sign handle, so they are safe to log.

Quickstart#

Co-sign mode, the main path#

import { readFile } from "node:fs/promises";
import { createPublicClient, http, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { monad } from "viem/chains";
import { signAsAgent, startCosign, waitForCreator, waitForPassport } from "@moolam/platform";

const publicClient = createPublicClient({ chain: monad, transport: http() });
const agentAccount = privateKeyToAccount(process.env.AGENT_OWNER_KEY as Hex);
const picture = new Uint8Array(await readFile("lighthouse.png"));

const handle = await startCosign(picture, {
  verifyUrl: "https://<verify-service>",
  platformKey: process.env.MOOLAM_PLATFORM_KEY ?? "",
  agentAccount,
  publicClient,
  title: "A lighthouse at dusk",
  terms: { aiTraining: "notAllowed" },
});

// The link is the person's key to the page. Send it to them and to nobody else.
await sendToUser(handle.cosignUrl);
// Keep the 32 hex characters too, so a restart can pick the co-sign up again.
await saveHandle(handle.handle, handle.passportId);

const digest = await waitForCreator(handle);
await signAsAgent(handle, digest);
const passport = await waitForPassport(handle);
console.log(`${passport.passportId} registered by ${passport.creator} at ${passport.registeredAt}`);

declare function sendToUser(link: string): Promise<void>;
declare function saveHandle(handle: string, passportId: Hex): Promise<void>;

• startCosign signs a PlatformPrepare in co-sign mode. The service signs the manifest, computes every file's IPFS content id, and freezes the files on its own disk. Nothing is pinned yet.
• The person opens the link and signs in. Their Moolam wallet becomes the creator, set once, from their verified session. A second wallet opening the same link is refused.
• waitForCreator polls until then, rebuilds the digest from the fields, the person's wallet and the deadline, and refuses a digest the service computed differently.
• signAsAgent signs that digest as your agent. The service accepts the signature only if it recovers to your agent's owner read now, then pins the frozen files and checks each content id is the one the passport names. Only then may the person's page ask for their passkey.
• waitForPassport returns only after the registry holds this passport with this creator, agent, manifest and metadata.

The person's wallet sends register, and only a passport's holder can state its AI-use terms on chain, so in this mode the terms you sent are in the manifest and the metadata, and the person states them on chain.

After a restart. Keep handle.handle, the 32 hex characters, and pick the co-sign up again:

import { createPublicClient, http, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { monad } from "viem/chains";
import { resumeCosign, signAsAgent, waitForCreator, waitForPassport } from "@moolam/platform";

const publicClient = createPublicClient({ chain: monad, transport: http() });
const agentAccount = privateKeyToAccount(process.env.AGENT_OWNER_KEY as Hex);

const handle = await resumeCosign(await loadHandle(), {
  verifyUrl: "https://<verify-service>",
  platformKey: process.env.MOOLAM_PLATFORM_KEY ?? "",
  agentAccount,
  publicClient,
});

const digest = await waitForCreator(handle);
await signAsAgent(handle, digest);
await waitForPassport(handle);

declare function loadHandle(): Promise<string>;

resumeCosign reads the record's status and returns the same kind of handle, so the three calls carry on from wherever the record is, with the same checks. A handle another key made is refused as not found. Store the handle like the link: it opens the person's page.

The signed file in co-sign mode. The files are pinned when your agent signs. The passport's metadata document, which the chain names, gives the signed picture's IPFS address as image, and its sha256 is the passport id. Hash it before you serve it.

One-time setup (platform mode)#

import { createWalletClient, http, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { monad } from "viem/chains";
import { setupPlatform } from "@moolam/platform";

const walletClient = createWalletClient({
  account: privateKeyToAccount(process.env.PLATFORM_WALLET_KEY as Hex),
  chain: monad,
  transport: http(),
});

const setup = await setupPlatform({ walletClient, rpId: "images.example.com" });

// Shown once and never again. Put it in your secret store before anything else.
await saveSecret("MOOLAM_PASSKEY_KEY", setup.passkeyPrivateKey);
console.log(`bound ${setup.qx} to ${setup.wallet} in ${setup.bindTx}`);

declare function saveSecret(name: string, value: string): Promise<void>;

setupPlatform makes a P-256 key and binds it on the registry as your wallet's creator key, sent and paid by that wallet. Before anything is signed it refuses a wallet that already has a passkey bound (unless rotate: true), a wallet that already holds passports (unless it is rotating a key it already has), and an rpId that is Moolam's hostname, localhost, an IP address, a single word, or anything the URL parser would rewrite. Use your own public hostname. Nothing on chain reads the rpId, so it is your honest label for the key, not a proof.

Platform mode#

import { readFile, writeFile } from "node:fs/promises";
import { createWalletClient, http, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { monad } from "viem/chains";
import { ServerPasskey, registerAsPlatform } from "@moolam/platform";

const walletClient = createWalletClient({
  account: privateKeyToAccount(process.env.PLATFORM_WALLET_KEY as Hex),
  chain: monad,
  transport: http(),
});
const agentAccount = privateKeyToAccount(process.env.AGENT_OWNER_KEY as Hex);
const passkey = ServerPasskey.fromPrivateKey(process.env.MOOLAM_PASSKEY_KEY as Hex, "images.example.com");

const picture = new Uint8Array(await readFile("lighthouse.png"));

const registered = await registerAsPlatform(picture, {
  verifyUrl: "https://<verify-service>",
  platformKey: process.env.MOOLAM_PLATFORM_KEY ?? "",
  agentAccount,
  passkey,
  walletClient,
  title: "A lighthouse at dusk",
  terms: { aiTraining: "notAllowed", aiInference: "constrained", constraintInfo: "Ask licensing@example.com" },
});

// Serve these bytes, never the original upload: their sha256 is the passport id.
await writeFile(`${registered.passportId}.jpg`, registered.signedFile);
console.log(registered.registerTx, registered.consentTx);

What happens, in order:

1. Your agent owner signs a PlatformPrepare: the mode, the picture's sha256, your platform id, a fresh random nonce and the latest block's time.
2. The service checks your key, then that signature against the agent's owner read on chain now. It signs a C2PA manifest naming your agent, fingerprints the signed picture, pins four files and answers with the passport fields, the digest and the signed file.
3. The kit checks the signed file hashes to the passport id, that the creator is your wallet, that the terms in the manifest are the terms you sent, and rebuilds the digest itself. Any difference stops it before anything is signed.
4. Your agent signs the passport, your server passkey signs the same digest, and your wallet sends register, then setConsent with the same terms.

Nothing is sent on chain until every check passes, and a result comes back only from receipts with status success.

Your own statement. Pass platformStatement to registerAsPlatform and the passport's document carries one line in your own words, which the passport page shows as your statement:

const registered = await registerAsPlatform(picture, {
  // ...the options above
  platformStatement: "Dreamloom's image agent drew this from a visitor's prompt on Dreamloom.",
});

These are your words, carried byte for byte: the kit sends exactly the string you give it, and the verify service writes exactly that string or refuses the prepare. Nothing is trimmed or rewritten. The service's rule:

The kit refuses an empty statement as invalid-input before anything is sent. Anything else outside the rule comes back as service-refused with details.status 400 and an error that names platformStatement, never your words. Say only what is true for every picture you send it with: Dreamloom sends one sentence when the person is signed in and another when they are not. Leave it out and the document carries no statement at all.

platformStatement is platform mode only. A co-sign passport carries the person's own sworn line instead, "I made this picture, or I hold the rights to register it.", so startCosign has no such option and the service refuses a co-sign prepare that carries one.

Handing a passport to a person#

This is how the person claims a platform-mode passport you hold for them when they give you an address. The hand-over alone credits nobody: the passport reads handed until the first wallet you hand it to states its own AI-use terms, and only then names that person as the one who imagined it (how the credit reads).

import { createWalletClient, http, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { monad } from "viem/chains";
import { MoolamPlatformError, transferPassport } from "@moolam/platform";

const walletClient = createWalletClient({
  account: privateKeyToAccount(process.env.PLATFORM_WALLET_KEY as Hex),
  chain: monad,
  transport: http(),
});

try {
  const moved = await transferPassport(await passportIdToHandOver(), await addressTheyGaveYou(), walletClient);
  console.log(`${moved.passportId} now held by ${moved.to}, in ${moved.txHash}`);
} catch (error) {
  if (error instanceof MoolamPlatformError && error.code === "refused-recipient") {
    console.log(error.message);
  } else {
    throw error;
  }
}

declare function passportIdToHandOver(): Promise<Hex>;
declare function addressTheyGaveYou(): Promise<string>;

transferPassport refuses a mixed-case address whose checksum is wrong, the zero address, your own wallet and the registry, uses safeTransferFrom, and returns only after a successful receipt and a fresh ownerOf read that names the new holder. The terms your wallet stated stay in force until the new holder states their own, and the history shows who wrote each. The person can hand you their address through Moolam's connect page, which ships with the co-sign page: it names your platform from the list and posts the address only to one of your listed origins, after they click.

Leaving a passport for a person's email#

When you already verified a user's email, you can register their picture in platform mode and leave the passport waiting for that address at Moolam. You never ask them for a wallet. Pass deliverTo to registerAsPlatform:

import { readFile } from "node:fs/promises";
import { createWalletClient, http, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { monad } from "viem/chains";
import { ServerPasskey, registerAsPlatform } from "@moolam/platform";

const walletClient = createWalletClient({
  account: privateKeyToAccount(process.env.PLATFORM_WALLET_KEY as Hex),
  chain: monad,
  transport: http(),
});
const agentAccount = privateKeyToAccount(process.env.AGENT_OWNER_KEY as Hex);
const passkey = ServerPasskey.fromPrivateKey(process.env.MOOLAM_PASSKEY_KEY as Hex, "images.example.com");
const picture = new Uint8Array(await readFile("lighthouse.png"));

const registered = await registerAsPlatform(picture, {
  verifyUrl: "https://<verify-service>",
  platformKey: process.env.MOOLAM_PLATFORM_KEY ?? "",
  agentAccount,
  passkey,
  walletClient,
  title: "A lighthouse at dusk",
  terms: { aiTraining: "notAllowed" },
  deliverTo: { email: await verifiedEmailOf(currentUser()), verifiedBy: "google" },
});
console.log(registered.transfer === null ? "waiting at Moolam" : `handed to ${registered.transfer.to}`);

declare function currentUser(): string;
declare function verifiedEmailOf(userId: string): Promise<string>;

deliverTo is platform mode only; a co-sign prepare that carries it is refused. verifiedBy says how you know the address is your user's:

Moolam does not check this word. It shows it to the person as your claim, beside your listed name: "Dreamloom says it checked this address with a Google sign-in." Send only an address you verified for this user, in the spelling they will sign in to Moolam with.

What Moolam keeps. The address travels only inside the prepare request's body, and the kit never logs it. The verify service puts it in one form (NFKC, trimmed, lowercase, exactly one address), keeps only an HMAC-SHA256 of that form under a secret only the service holds, and drops the address. No answer, log line or error carries the address or its hash; a malformed one is refused as deliverTo, naming the field only. Nothing is folded beyond case: r.am@gmail.com and ram@gmail.com are two addresses, and so is ram+art@gmail.com.

When the offer appears. The ticket is written pending at the prepare and opens only once the chain shows the passport registered by your wallet, held by your wallet and carrying your kit label. The service looks about once a minute. A passport that has not landed within two hours of chain time closes its ticket, and so does one your wallet moves before the person answers.

What the person sees at Moolam. Dreamloom, the demo platform, tells the person "Your passport is waiting at Moolam. Claim it with r****@gmail.com at moolam.vercel.app/en/mine". There:

1. They sign in to Moolam with Google or an emailed code. Only an address Privy verified for them, their email account or their Google account's email, matches a ticket.
2. My pictures opens with "Waiting for you": your listed name, your verifiedBy worded as your claim, and the pictures you hold for them, each with its title and picture through Moolam's pinned-picture rule, or "No preview" and its passport id.
3. They pick the AI-use terms for those pictures and answer for all of them at once:
   • These are mine accepts them for their Moolam wallet, the first embedded wallet in their Privy record. Neither you nor they choose the address.
   • Not mine refuses them for good, stops your offers to that address until they allow you again, and counts against your key.
   • Send my future platform pictures straight to my account, a tick beside the answer, makes that wallet and those terms a standing choice for your platform.
4. Once your worker has handed the passports over, they press Confirm. One setConsentBatch from their own wallet writes their terms on up to 32 passports, with the fee paid by Moolam. That is the moment the passport names them as the person who imagined it.
5. Under "Your platform choices" they can Stop a standing choice, or Allow again a platform they said no to.

The delivery worker. Run one on your server, beside the code that registers:

import { createPublicClient, createWalletClient, http, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { monad } from "viem/chains";
import { runDeliveries } from "@moolam/platform";

const walletClient = createWalletClient({
  account: privateKeyToAccount(process.env.PLATFORM_WALLET_KEY as Hex),
  chain: monad,
  transport: http(),
});
const publicClient = createPublicClient({ chain: monad, transport: http() });

const worker = await runDeliveries({
  verifyUrl: "https://<verify-service>",
  platformKey: process.env.MOOLAM_PLATFORM_KEY ?? "",
  walletClient,
  publicClient,
});

process.once("SIGTERM", () => {
  void worker.stop();
});

Every five seconds (intervalMs, 250 ms to an hour) it reads GET /platform/deliveries: the accepted tickets of your key whose passport your wallet still holds, with the wallet each goes to, at most 32 a poll. For each one it reads ownerOf again and skips a passport your wallet no longer holds, checks the address by the same rule transferPassport uses, simulates safeTransferFrom, and only then sends it from your wallet. It sends a ticket at most once a poll, logs nothing, and throws nothing once started. stop() lets a send in flight finish and starts no other. Run one worker per platform: two would race to send the same hand-over, and the loser pays for a failed transaction. Moolam marks a ticket delivered when the chain shows the person holding the passport; the worker reports nothing on success.

A standing choice, deliverNow. When the person ticked "send my future pictures straight to my account" for your platform, the prepare answer carries deliverNow, their wallet. registerAsPlatform checks that address by the same rule before anything is sent, then registers, writes your terms and hands the passport over in one call, and returns the hand-over in transfer. The person is not asked again; the picture waits on My pictures for their Confirm. If the passport and its terms land and the hand-over does not, the call throws delivery-failed with the passport id and both transactions. The passport waits in your wallet, its ticket stands accepted, and the worker hands it over on a later poll.

After a failed hand-over. A refused address, a refused simulation or a failed transaction counts as one failed try. After maxTries failed tries (3 by default, 1 to 10) the worker calls POST /platform/deliveries/:ticketId/failed. The ticket closes as failed and is never listed again, and the person's page says you could not hand those pictures over and asks them to ask you to send them again. The passport stays in your wallet and reads held. You can still hand it over with transferPassport to an address the person gives you, for example through the connect page. The try count lives in the worker's memory, so a restarted worker tries a ticket up to maxTries times again.

Limits and refusals.

A prepare with deliverTo is refused 400 deliverTo for a malformed field or co-sign mode, 403 deliver-closed for a key closed by refusals, 429 deliver-full at a ticket cap, and 503 claims-unavailable when the verify service's claim routes are closed. Each answer reads the same whether or not the address has a Moolam account, so a prepare tells you nothing about Moolam's users; the one difference is deliverNow, which only that person's own standing choice for your key produces.

What this does not check: that the address is your user's. That is your check, and the person sees it as your word.

Errors#

Every refusal is a MoolamPlatformError with a code to branch on and details that never carry a secret.

import { MoolamPlatformError, registerAsPlatform } from "@moolam/platform";

type Options = Parameters<typeof registerAsPlatform>[1];

async function register(picture: Uint8Array, options: Options) {
  try {
    return await registerAsPlatform(picture, options);
  } catch (error) {
    if (!(error instanceof MoolamPlatformError)) throw error;
    if (error.code === "service-refused" && error.details.status === 429) {
      return null; // A daily limit: try again after the reset.
    }
    if (error.code === "consent-failed") {
      // The passport landed and the terms did not. Send setConsent again with the same terms.
      console.log(error.details.passportId, error.details.registerTx);
    }
    throw error;
  }
}

export { register };

Limits#

Every window is read against the latest block's time, never a server clock. A prepare that is refused before anything that costs Moolam lands gives its quota slot back. Status stays readable for a day after a record's deadline.

The quotas, the replay memory and the waiting co-signs live on the service's volume at /data, so a redeploy keeps them. The service runs one copy, so each deploy has a short gap: a request sent during it fails and must be sent again, and a co-sign whose deadline passes inside the gap is lost.

What it costs on Monad mainnet#

Monad charges the gas limit a transaction sets, not the gas it used. Measured on mainnet on 2026-09-30 at about 102 gwei, from receipts unless the row says estimate:

The C2PA signing and the four IPFS pins of every prepare are Moolam's cost in both modes. A new platform wallet that sets up, registers ten pictures with terms and hands one over spends about 0.73 MON; fund it with 1.5 MON for the margin a gas limit and a failed attempt need.

How Moolam credits a platform picture#

The person who imagined a picture gets the credit. Your platform is where it was drawn, and in platform mode the one holding the passport until it hands it on. Moolam never names a platform as a picture's maker or creator.

One function decides the credit, creditFor, beside platformLabel in packages/verifier/src/platforms/platforms.ts, so the site and the MCP server say the same thing. It reads the passport's fields from the chain, its holder read now, for a listed agent that agent's owner read now, and for a platform-mode passport two facts from Moolam's index: the first wallet your wallet handed it to, and who wrote each of its AI-use statements. It gives one of five cases:

Only the first wallet you hand a passport to can ever be credited, and only once that wallet has written its own terms. Terms your own wallet stated at registration never count, and neither do a later buyer's.

With the email path. The person's Confirm on My pictures is that first statement: their own wallet writes their AI-use terms with setConsentBatch, and the passport moves from handed to confirmed. Until then it reads held while it waits for their answer, and handed once your worker has moved it. A standing choice skips the wait for an answer, not the Confirm. With connect once, the person confirms the same way, by stating their terms on the passport page.

A picture's plate carries the short form, "Drawn on platform". The MCP server's get_passport answers with the case as credit.

When there is no credit line. creditFor gives nothing, and credit is never guessed, when:

• Moolam's platform list did not load;
• your listed wallet registered the picture outside the kit;
• the holder could not be read;
• the index could not say who the passport was first handed to, or says it never left your wallet while the chain shows someone else holding it;
• the agent is not on the list, its owner could not be read, or its owner is not the one that signed the entry now in force;
• a co-signed picture was registered before the entry now in force began, for example before a key rotation.

The passport's base line and the holder and creator facts stand either way.

What the label on a passport means#

A passport your platform registered in platform mode carries this line on its passport page:

Registered by your platform through the Moolam platform kit

and under it:

Your platform's own server key signed as the creator, and its agent signed as the maker. Moolam checked that the company holds both keys, not who the company is.

Its plate in Explore carries the platform's mark, and the MCP server's get_passport answers with platform: { status: "kit", name, creatorWallet, agentId }.

A co-sign passport's creator is the person, so it carries no platform label, only the cosigned credit above. Its page names your agent by its ERC-8004 id, with the name your agent's own card gives, marked as the card's own word, and the MCP server's get_agent answers with the name Moolam lists for that agent.

Every passport's base line stays the same with or without the list: "A key bound to this creator's wallet signed this picture's fingerprint on Monad." The label is added on top, so losing the list loses a label and never adds a claim.

One function issues it, platformLabel in packages/verifier/src/platforms/platforms.ts, used by the service and, as a byte for byte copy, by the web app. It gives the label only when all of these hold:

• the passport's creator is your listed creator wallet;
• it is Generated, by your listed agent;
• it carries a C2PA manifest;
• it was registered inside your entry's window, from validFrom up to validTo.

When it is withheld.

• A passport from your listed wallet that fails any of those reads: "This wallet is listed as your platform, but this picture was registered outside the Moolam platform kit."
• A passport registered after an entry was replaced takes its label from the new entry, or none.
• A list that fails to load gives no label anywhere.
• When your agent's owner changes after you joined, get_agent answers ownerUnchanged: false, and Moolam's co-sign page shows your platform's badge only while the owner read now is the owner that signed your entry. Passports already registered keep their label, because it is judged on the fields the chain recorded when they were made.

When the holder is not the creator, every reader says both: "Registered by creator. Now held by holder." A passport someone holds but did not make is listed apart in their pictures, never as their work.

What the kit does not promise#

• Moolam does not check who the company behind an agent is. It checks that the listed keys signed.
• The chain cannot tell a server key from any other passkey, and Moolam does not pretend it can. A platform-mode passport is one company holding two keys.
• It cannot vouch that a listed platform's generator made what the platform says it made.
• It cannot make a platform hand a passport over, or tell a correctly typed wrong address from the right one.
• Your key custody, your copy of the package and your users' identity are yours.
• In platform mode your server holds the signed file before it registers, and in co-sign mode the files are public on IPFS from your agent's signature until the person signs. Whoever registers those bytes first holds the passport; the prepare refuses a picture already registered.
• A look-alike name in another script can pass the name check, which is why the label always sits beside the wallet and the agent id.

The full list of what is checked, where and by which test is in the threat model. The routes are in the API reference, and AI agents read passports through the MCP server.