Swarm Commission NFT: launch specification

Report date: 5 October 2026. This is an architecture decision report, not audited Solidity, legal advice, or confirmation that the proposed IdentityMD Intake exists. ASSUMPTION below marks IdentityMD plane claims derived only from the assignment’s description. Factual statements have linked sources; inferences and unresolved points are identified as such.

Recommendation

Launch an ERC-721 collection of transferable claim tickets. The service-cost floor is 1.0 IMD for one 0.5 IMD image job and one 0.5 IMD panel request; charge 3.0 IMD if promising the bounded worst-case budget of three jobs and two reviews, with unused funds refundable. The token stays visually blank and its metadata discloses only its commission status until an image’s bytes, content identifier and signed panel verdict have been bound on chain. Prompt inputs are immutable collection rules plus a commit/reveal seed finalized from future block entropy; the deployer cannot choose per-token prompt parameters. Use four contracts created by the collection constructor: the ERC-721 coordinator, a bounded funds vault, a delivery evidence registry, and a royalty splitter (the Intake remains a pre-existing upstream dependency, not a fifth deployment). A panel “yes” gates reveal only after signature, signer, question prefix, chain, consumer, block window, expiry, quorum and minimum agreement checks. A “no” consumes a retry, while timeout, oracle refusal or exhausted retries become an explicit holder refund. This is a commissioned-art system whose on-chain guarantees are process integrity and evidence provenance, not proof that a subjective judgement is objectively correct.

Decisions

#	Choice	Figure / limit	Main reason
1	Mint non-revealed, transferable claim and advance the commission through bounded stages	1.0 IMD minimum service cost; 3.0 IMD launch price for capped retries	The buyer funds both creation and its first review; fully funded reserves prevent stranded tickets.
2	Freeze a brief hash and deterministic prompt recipe; use a post-commit seed	keccak256(brief bytes); seed commitment/reveal window 64 blocks	Fixed rules prevent operator discretion; delayed entropy resists deployer selection.
3	Ask the panel one exact bool question; require independent seats and a signed agreement floor	7 panelists, quorum 5, signed agreed >= 4/5	Meaningful majority evidence, with maker exclusion and independently identified voter seats.
4	Permit 3 image submissions and 2 paid reviews per token, then refund on terminal failure	Maximum three job spends and two review spends; funds cap 3.0 IMD/token	Bounds waste and avoids infinite retries; reserves must be funded before promising them.
5	Persist image/metadata/evidence by CID and EVM hashes; offer only rights actually controlled	At least 2 independent pins; broad nonexclusive display/reuse grant subject to rights	Content addressing proves bytes; replication supports retrieval. AI authorship rights vary by law.
6	Pay a maker only when upstream completion carries authenticated agent identity	Minimal upstream addition: signed agentId and registry-domain proof in callback	A delivery URI alone does not establish who delivered it.
7	Combine Art Blocks’ deterministic provenance, Botto’s panel/community selection, and Bright Moments’ reveal ceremony without inheriting their hidden dependencies	Five comparators plus Autoglyphs / Async Art	The design must also solve uptime, curation, fairness, rights, and royalty enforcement.

1. Lifecycle, price and holder experience

States and transitions

State	Entry and allowed transition	Holder sees	Target / timeout
Unminted	mint(recipient) escrows funds and mints ticket → SeedPending	Ticket number, immutable brief hash, “commission queued”; no preview	Immediate transaction; mint closes at fixed supply.
SeedPending	Keeper publishes seed reveal after future block; → JobPending	Prompt recipe/version and seed commitment; not image prompt if prompts are considered sensitive	64 blocks, typically ~13 minutes on 12-second L1 blocks (inference; chain dependent).
JobPending	Any keeper calls Intake ask with derived prompt, job payment → DeliveryPending	Ticket remains blank with status and deadline	ASSUMPTION: job costs 0.5 IMD and image delivery takes minutes; hard deadline 24h.
DeliveryPending	Valid Intake callback records immutable result hash/URI and optional authenticated maker; → JudgingPending	“Image received; awaiting review”; not yet visible	ASSUMPTION: callback best effort, 200,000 gas; keeper/anyone can reconcile; 48h deadline.
JudgingPending	Keeper pays oracle 0.5 IMD and submits attestation → Revealed if yes, otherwise Retryable	“Under panel review”; image remains undisplayed	ASSUMPTION: oracle answer arrives in minutes; 24h deadline.
Retryable	If reject, preserve rejected hash/evidence; start a new job using retry counter in prompt seed → JobPending	Rejected attempt count and evidence pointer; still blank	One retry, then fallback. A second oracle failure may use available funded reserve.
Revealed	Successful verification atomically sets final image and evidence URI, event emitted	Full metadata, image, signed verdict and provenance	Final state, never revocable or replaced.
Refundable	Deadline/refusal/final reject with exhausted paid retries; claimant burns ticket for their remaining escrow credit → Refunded	Refundable status and exact amount	Permissionless after deadline; refund to current token owner.
Refunded	Terminal	Burned ticket / audit record remains in events	Terminal.

Mint is a purchase of a claim, not a guarantee that any particular aesthetic result passes. The minimum service cost is 1.0 IMD (one 0.5 image job plus one 0.5 review); the proposed 3.0 IMD mint funds the bounded maximum schedule and leaves at least 0.5 IMD refundable. This cost does not include gas, permanent storage, or operational keeper costs. A sold-out system cannot promise retries unless the full reserve is prepaid into the vault. If the first result passes, unused escrow is returned to the current holder; recommendation: refund it, avoid disguised proceeds.

ASSUMPTION: the IdentityMD plane charges 0.5 IMD each for oracle.request and an artwork job, returns an answer in minutes, and supports the described request/callback flow. Confirm the actual payment token, decimals, escrow semantics, idempotency, callback identity and timeout before pricing. For Intake unavailability, a keeper pays through the HTTP door and later records the request identifier plus signed response; the contract’s verifier is identical either way. A retry is never free merely because a callback was missed: it requires escrow balance. The liveness deadline starts from the on-chain request timestamp, not from an off-chain claimed start.

2. Frozen brief and prompt derivation

At deployment the constructor stores briefHash = keccak256(UTF8(canonicalBrief)), promptRecipeHash, model/tool policy digest, maximum supply and a chainSeedCommitment. Canonical brief bytes, recipe source, criteria and licence are published in a permanent content-addressed release. Contract code fixes the template fields; there is no owner setter, upgrade key, or deployer exception. ERC-721 IDs remain stable identifiers under the standard. ERC-721

Each ticket commits a user salt at mint. Once minting is closed or the ticket is minted, the user reveals salt within a fixed interval; failure uses a deterministic default and makes that forfeiture visible. The contract also commits a secret seed at deployment, then reveals it after the reveal window. Derive:

seed[i] = keccak256(abi.encode(
  "IMD-SWARM-ART-v1", chainId, collection, tokenId,
  briefHash, promptRecipeHash, userSalt, revealedCollectionSeed,
  previousFinalImageHash (zero for token 1), retryNumber
))

The prompt is a deterministic serialization of the frozen template with tokenId, seed, and optionally prior final image hash/CID as variables. Use hashed previous artwork only to seed a new prompt, never as a hidden arbitrary text input. The image model itself is not deterministic; the reproducible claim is about the prompt inputs, not identical image bytes. On failure, incrementing retryNumber changes the prompt. Store every attempt’s derived prompt hash and output hash.

Do not use the minting block hash as the sole entropy source: the minter or block producer may influence it, and blockhash is unavailable after its short window. A commit/reveal seed stops unilateral deployer steering only if the secret is actually unpredictable and no single party can withhold it. Better: commit multiple independent entropy contributions (user, deployer, keeper) and define a timeout fallback from future blockhash plus commitment; this adds griefing risk. For a small immutable deployment, recommend user salt plus a future blockhash after mint commitment and disclose that it is pseudo-random, not unbiased VRF. Inference: no chain-independent scheme can guarantee both unbiased entropy and liveness without an external randomness source or threshold protocol.

3. Judging and attestation

Canonical oracle question

Question document prefix (UTF-8, canonical JSON with sorted keys and no whitespace; the actual canonicalization version is frozen in source):

{"answerType":"bool","criteriaHash":"0x…","imageHash":"0x…","purpose":"imd-art-acceptance-v1","tokenId":"…","briefHash":"0x…","attempt":0,"rubric":"The delivered image identified by imageHash satisfies every criterion in criteriaHash under the published rubric."}

The request window is appended as fromBlock and toBlock; the consumer computes the expected questionHash = keccak256(canonicalDocumentIncludingWindow). The oracle returns one boolean answer for: “Does the image at content hash <imageHash> satisfy every named criterion in criteria hash <criteriaHash> and the frozen collection brief <briefHash>? Return true only if all mandatory criteria pass.” Criteria must enumerate observable constraints (e.g., prohibited content absent, palette/subject requirements present) and define rejection examples. Art quality remains subjective; panel answers are not facts about external reality.

ASSUMPTION: the request and response fields, EIP-712 domain, service signer and chain-window behavior in the following rule are as specified in the assignment and have not been independently verified on a live IdentityMD deployment. Accept exactly answerType=bool, expected question hash, chainId=block.chainid, verifyingContract=address(this) in the EIP-712 domain IdentityMD Oracle, version 2, signer 0x5598aa9146215bc13eb26f2c692ad1461fd32982, quorum at least 5, panel size at least 7, issuedAt <= now < expiresAt, toBlock >= fromBlock, toBlock > previousAcceptedToBlock[tokenId], and the signed window exactly matches the expected question document. Require an 80% agreement floor: encode this as agreed >= 80 if the live scale is 0–100, or >= 8000 if basis points; settle this field’s scale before coding. The signature covers requestId, chainId, questionHash, answerType, answer, figure, fromBlock, toBlock, blockHash, panelJobId, panelSize, quorum, agreed, issuedAt, expiresAt. Do not accept unsigned callback booleans as oracle evidence.

ASSUMPTION: under the supplied oracle model, this is panel evidence, not a re-runnable chain recipe. The model says only named recipes such as log-sum/count, Uniswap v4 spot, call-compare, log-rank and volume-rank qualify as chain evidence; aesthetic judgement cannot be independently replayed from chain state. Therefore store answerType=bool, require signed source/answer fields and quorum, label it panel evidence in metadata, and do not market it as cryptographic verification of taste. The oracle signature authorizes an answer; the on-chain checks bind it to this ticket’s intended question and protect against a signed answer purchased for another consumer/question. Enforce strictly advancing toBlock to prevent replay across recurring requests.

Panel composition and maker exclusion

Require seven distinct panelists and quorum five. The oracle signer’s aggregate attestation does not prove seven independent participants or individual votes. ASSUMPTION: the oracle service can configure maker exclusion and provide attributable member receipts. Request exclusion of the verified maker ID and do not count that seat. The described signed struct does not include the excluded ID or panel member commitment, so on-chain exclusion cannot be enforced from the fields currently specified. Minimum upstream enhancement: include panelMembersHash and excludedAgentId in signed fields, plus a public receipt bundle resolving unique member IDs and votes. Until then, maker exclusion is an operational service policy, not an on-chain guarantee, and must be disclosed as such.

4. Failure, retry and terminal outcomes

Three job spends maximum per token and two oracle requests maximum; charge 3.0 IMD upfront into escrow, authorize spending up to three 0.5 IMD jobs and two 0.5 IMD reviews (2.5 IMD), and refund unused balance. The third job is available only to replace a timed-out, malformed or undeliverable attempt; it cannot be used after the two allowed reviews have both returned “no.” A false verdict consumes a review and may trigger one new image job; after the second false verdict the ticket becomes refundable immediately. An oracle refusal or timeout does not count as a verdict, but can be retried once from reserve. The 0.5 IMD unspent under the maximum schedule is also refunded.

Failure matrix:

Failure	Response	Holder remedy
Job never acknowledged	Permissionless timeout after 24h; release no maker amount, mark attempt abandoned	Retry once from escrow; thereafter refund remaining escrow and close.
Intake callback lost	Anyone calls recordDelivery with verifiable Intake result proof, if available; else timeout	Do not pay twice; request IDs are unique/idempotent.
Malformed image/CID or hash mismatch	Reject before asking panel; preserve evidence hash	Counts as failed job; retry within cap.
Panel returns false	Store attestation and rejected content hash; prompt changes via retry counter	One replacement job; if last eligible attempt fails, refund.
Panel refuses or no answer	After 24h, allow one paid repeat; after 48h total, Refundable	Refund remaining balance; do not silently accept.
Oracle key rotates/compromised	No deploy-time privileged setter exists, so pause acceptance through terminal refund path	Tickets awaiting judgement become refundable after published emergency delay; no hidden key override.
Storage vanishes	The CID still identifies expected bytes but might not be served	Holder may supply matching bytes or pin elsewhere; evidence remains, no substitution.

The final fallback is a refund, never arbitrary curator acceptance and never a made-up placeholder image. If the operator’s service fails before all allocated payment was spent, the current token owner claims the remaining exact escrow balance. Any unspent funds on reveal return to the owner. All timeout paths are permissionless to execute, avoiding a privileged keeper veto. A fully minted collection cannot depend on future donations for promised retries/refunds.

5. Provenance, storage and rights

Delivery includes raw image bytes and a deterministic metadata JSON. The server computes the image CID; the contract stores the raw bytes32 imageKeccak, full CID string (or compact CID bytes), metadata CID, prompt hash, job request ID, attempt number, signed attestation digest and signer. Recompute the file digest before accepting. Content addressing allows verifying fetched content but does not guarantee it will remain available; IPFS documentation explicitly distinguishes persistence from permanence and recommends pinning for retention. Require two independent pinning operators plus a downloadable CAR archive mirrored by the project and community. IPFS persistence and pinning, IPFS content addressing

Before reveal, tokenURI returns a stable ticket JSON without final image link. At reveal it returns immutable metadata CID, image CID, brief hash, prompt derivation version, all attempt hashes, maker identity if verified, and full EIP-712 attestation (signature plus decoded fields) or a URI to it whose digest is committed on chain. Anyone can independently recover the oracle signer and recompute the question hash. ERC-721 permits metadata URI conventions, but the standard does not guarantee URI immutability; enforce this collection-specific invariant in code. ERC-721

Recommended rights notice: “The token conveys ownership of the token and a perpetual, worldwide, nonexclusive permission to display, reproduce, and adapt the delivered image for personal and commercial use, to the extent the commissioning entity has rights to grant those permissions. No exclusive copyright is promised. Third-party model terms and applicable law may limit rights.” Publish the model/vendor and provenance policy; prohibit submissions containing known third-party protected material or personal likeness without rights. The U.S. Copyright Office’s January 2025 report says copyright in AI output turns on sufficient human expressive contribution and that mere prompting is not enough; protection may apply to human-authored elements/arrangements. That is U.S. guidance, not a global rule. US Copyright Office report release, Part 2 report

Do not apply CC BY 4.0 automatically to an output unless the licensor has rights to license it. Its terms allow commercial sharing and adaptation with attribution, but cannot create copyright over otherwise unprotected output. CC BY 4.0 deed Open legal question: choose governing law and obtain counsel on likeness, dataset/model terms, consumer refunds, and enforceability of the rights notice.

6. Paying the maker

ASSUMPTION: the described Intake complete(requestId,status,resultHash,uri,args) callback does not inherently authenticate the agent that generated or uploaded the file. A URI, callback sender or job ID alone does not establish agent authorship. If the callback sender is a trusted plane contract, it verifies only that the plane completed a job, unless it also carries a signed agent identity binding.

Smallest upstream change: add makerAgentId and makerRegistry to completion data plus an EIP-712 maker signature over (requestId, resultHash, uriHash, chainId, target) made by the registered agent wallet, and have Intake validate the ERC-8004 identity/wallet at completion. Emit these fields in the completion event/callback. Consumer checks the immutable registry address/domain and the attested signature; store agentId with the token. If agent-to-agent wallet proof is unavailable, return explicit makerVerified=false, and route no token royalties based on the unverified name. ERC-8004 is a draft standard defining agent identity and feedback, and allows reputation feedback to be keyed by agentId; registry deployment/address remains chain-specific and must be verified at launch. ERC-8004 draft

Royalty recommendation: EIP-2981 report 5% to a per-token immutable splitter that allocates e.g. 70% to verified maker, 20% panel pool, 10% storage/maintenance. If maker identity is unverified, maker portion accrues to a disclosed claim escrow for 12 months, then treasury. But ERC-2981 only signals royalty information; the marketplace payment is voluntary and the standard does not enforce transfers. EIP-2981 Therefore do not promise royalties as a guaranteed income stream; the primary maker payment is the job fee. Each test must prove no address can redirect escrow.

7. Comparables and unresolved product problems

Comparator facts below are read 5 October 2026 unless the source itself is date-stamped; dynamic project documentation does not expose a reliable revision date. No market-volume or royalty percentages are asserted.

Project	Mechanism evidenced by primary source	Problem it solved	Lesson here
Art Blocks	Collector mint creates unique hash fed to on-chain algorithm; same hash deterministically reproduces output. Engine stores scripts and token hashes. Docs, core contract	Reproducibility, artist-authored generative rules, long-lived reconstruction	Our model is stochastic and off-chain; freeze recipe and prompt provenance, avoid claiming exact reproducibility.
Botto	Community votes on fragments; documentation describes weekly mint/auction cadence and feedback shaping future generation. Project summary, governance	Human curation loop and collective taste	State the rubric and panel composition; a majority can still be wrong, so panel evidence is limited.
Async Art	Layered masters could change via separately held layers; public project page records that when its infrastructure went dark, composition/control stopped working. Async	Programmable collaborative artwork and changing ownership controls	Avoid critical rendering logic behind a single web service; publish frozen output and independent renderer/bytes.
Bright Moments	Describes first-time reveal as an in-person designed minting experience and DAO-curated collection. About	Ceremony and provenance around first reveal	Our reveal can mark an on-chain completion event; do not confuse reveal ceremony with content persistence.
Autoglyphs	Fully on-chain generative art project, generated and stored by contract (source project/contract). Larva Labs project	Minimal dependency surface and on-chain reconstruction	Our image size/job economy makes full raster storage impractical; preserve content hashes and redundant bytes.
Foundation / curated marketplaces	ERC-2981 royalty signaling is advisory, not forced by token transfers. EIP-2981	Standard royalty discovery across marketplaces	Maker economics must work at primary job payment even if resale royalties are ignored.

The commissioned collection also has problems comparators do not solve together: oracle request cost versus mint demand, selection bias in subjective panels, sybil panel seats, repeated-image similarity, prompt injection through content, agent identity attribution, biased model outputs, token-holder expectations during long asynchronous work, legal rights, and available data after the pinning sponsor leaves. A growing chain of prior art can produce interesting cumulative semantics, but serial dependencies make later prompts and deadlines depend on every previous token; make this optional and freeze whether failed tokens are skipped or represented as a fixed failure marker. Recommendation: chain only to the previous revealed final piece, and if one ticket refunds, use its committed seed and a fixed “no predecessor” marker so the sequence remains live.

Contracts (interfaces and deployment constraints)

Four-contract cap counts newly deployed contracts only. The constructor deploys three child contracts and wires them directly. The Intake is an upstream dependency at a source constant address; it is not assumed deployed until verified. No deployment-time setX transaction follows. The supplied service signer is a compile-time constant. IMD token address, chain ID, Intake address and ERC-8004 registry addresses are currently unspecified, so there is no honest deployable artifact yet: once the IdentityMD launch publishes them, pin the verified addresses in source and reproduce bytecode. This resolves the instruction that privileged addresses are constants, not constructor parameters; it also makes launch contingent on knowing the target chain and addresses, not a hidden constructor placeholder.

Contract 1 — SwarmCollection (ERC-721 coordinator)

• Constructor: (canonicalBrief, recipeHash, maxSupply, seedCommit, criteriaHash, pinnedIntakeAddress, imdTokenAddress); stores hashes, creates CommissionVault, DeliveryBook, and RoyaltySplitter children. In production, Intake/token/service signer/registry constants are hardcoded in this build; constructor parameters only carry collection-specific immutable content/limits. Revert if Intake/token code absent or token decimals() unexpected. Service signer constant is the supplied 0x5598…2982.
• Storage: immutable brief/recipe/criteria/supply; seed and prompt commitments; mapping(tokenId => State); attempts, escrow, request IDs, imageHash, CID/metadata hashes, maker ID/verification flag, accepted oracle window, evidence digest, prior finalized image hash; constant addresses; no mutable administrator or proxy.
• External functions: mint(recipient, saltCommit) payable in IMD via transferFrom; revealSalt; startJob(tokenId) callable by anyone when stage/deadline allow; recordDelivery(requestId, …) only Intake or proof-validating public function; submitAttestation(tokenId, Attestation, signature) permissionless but fully verified; claimRefund(tokenId) by current owner, permissionless execution sends to owner; ERC-721 transfer functions. tokenURI returns ticket/final JSON by state. No arbitrary accept, force-reveal, owner setter, or withdrawal.
• Events: TicketMinted, StageChanged, JobRequested, DeliveryRecorded, PanelAttested, TokenRevealed, RefundAvailable, RefundClaimed, MakerVerified.
• Invariants: ticket never reveals absent exact matching signed yes; signer/domain/question/window/agreement/quorum/expiry all valid; toBlock advances; final image immutable; retries bounded; callbacks idempotent; refund cannot exceed escrow; only current owner receives refund; failed states cannot be forced to reveal; token transfer cannot alter commission/evidence.

Contract 2 — CommissionVault (child, IMD escrow)

• Constructor: (IERC20 imd, address collection) called only by collection constructor; collection becomes immutable controller.
• Storage: per-token balance, per-attempt spend, cumulative job/review budgets, refund claimed bit; immutable token/controller.
• Functions: depositFrom(payer, tokenId, amount) collection only; payJob(tokenId, requestId) and payReview(tokenId, requestId) collection only with fixed exact amount; refund(tokenId, recipient) collection only; no generic withdraw, arbitrary recipient, approvals or user callback. Use safe transfer and balance delta checks; reject fee-on-transfer token.
• Events: Deposited, ServicePaid, Refunded.
• Invariants: balance accounting is conserved; fixed fees; no double payment for request ID; cannot spend another ticket’s balance; all unspent amount is claimable on terminal status.

Contract 3 — DeliveryBook (child, immutable evidence registry)

• Constructor: (address collection, address intake, address identityRegistry); controller/intake/registry immutable constants verified at deploy.
• Storage: request-to-token mapping; attempt result hash, URI hash, job status, maker agentId, maker signature digest and verification bit; used callback IDs.
• Functions: registerRequest collection only; completeFromIntake only configured Intake; proveDelivery permissionless with upstream-signed payload; getDelivery view. Cannot edit or delete accepted evidence.
• Events: DeliveryAccepted, DuplicateIgnored, MakerIdentityBound.
• Invariants: one result per request; request binds one token/attempt; maker marked verified only after signature and registry ownership check; no callback can change a finalized attempt; result hash matches later bytes.

Contract 4 — RoyaltySplitter (child)

• Constructor: (address collection, address reputationRegistry); immutable parent and registry, no owner.
• Storage: token-to-maker agentId and verified status; fixed 500 bps; accrued claims if protocol elects direct job-paid rewards; registry address is chain constant.
• Functions: bindMaker(tokenId, agentId, verified) collection only, once; royaltyInfo(tokenId, salePrice) view under ERC-2981; claimMakerPayment(tokenId, recipient) verifies maker wallet/agent ownership if paid commissions are later routed here. Avoid taking custody of marketplace sale proceeds: ERC-2981 only reports a quote.
• Events: MakerBound, MakerPaymentClaimed.
• Invariants: never redirects an already bound maker; unverified maker gets no maker royalty claim; quote is salePrice × 5%; no claim exceeds recorded accrual.

Deployment wrinkle: task’s “at most four” and “every link in constructor” are achievable only if the upstream Intake supports target registration at its deployment address or an immutable deployment-independent callback. If Intake must be configured after our deployment, this design cannot launch under the stated no-post-deploy-call rule. All address values must be confirmed against deployed bytecode and token methods before freezing constants. No keys, mutable admin, proxy or deployment transaction is specified here.

Foundry test plan

Build with local mocks for IMD (standard, fee-on-transfer, reverting), Intake, ERC-8004 registry and EIP-712 signatures. Tests are required before implementation acceptance; none were run because this deliverable is an architecture report and the execution profile is none.

Test	Required assertion / adversarial case
testConstructorWiresChildrenAndConstants	Child addresses point to collection; hardcoded signer/domain/chain dependency correct; no owner setters.
testMintEscrowsExactAmountAndMintsBlankTicket	Correct amount, owner, state and placeholder URI; rejects insufficient allowance/payment.
testBriefAndRecipeFrozen	No call path can alter hashes, collection cap or prompt recipe.
testSeedCannotBeChosenAfterCommit	Reveal mismatch fails; timeout fallback deterministic; user cannot grind multiple salts after observing final entropy.
testPromptDerivationIncludesTokenAndPreviousFinal	Golden hash vector; token, retry and predecessor each alter derived hash.
testStartJobPermissionlessOnce	Anyone can progress; second call cannot double-spend or create duplicate request.
testIntakeCallbackReplayAndWrongRequest	Duplicate callback idempotent; wrong token, attempt, status or Intake rejected.
testMalformedDeliveryHashRejected	Supplied bytes/hash mismatch cannot be accepted; malformed CID rejected.
testAttestationValidRevealsAtomically	Correct signed yes reveals once and binds image, question, answer, evidence and metadata.
testWrongSignerRejected	Same signed payload from non-service key fails.
testWrongConsumerOrChainRejected	Domain replay against another collection/chain fails.
testQuestionHashMismatchRejected	Answer purchased for different content hash, brief, criteria or token is rejected.
testWindowMustAdvance	Repeated or decreasing toBlock rejected; future/invalid ranges rejected.
testExpiredOrNotYetIssuedAttestationRejected	Expiry and issuedAt bounds enforced.
testAgreementQuorumAndPanelFloor	agreed below 8,000, quorum below five, panel size below seven fail.
testPanelRefusalEnablesTimeoutNotReveal	No callback never causes reveal; deadlines unlock bounded retry/refund.
testMakerSeatExcludedOrFlaggedUnverifiable	If signed seat commitments exist, maker ID among seats rejects; without them, verified-exclusion mode cannot be claimed.
testRejectedImageCannotBeRevealedLater	False result is terminal for that attempt; same content cannot bypass retry counter.
testRetriesAreBounded	More than allowed jobs/reviews reverts; exact final transition refundable.
testRefundGoesToCurrentOwner	Ticket transfer changes refund recipient; no operator destination parameter.
testReentrantTokenCannotDoubleClaim	Reentrant mock during refund cannot overdraw or claim twice.
testFeeOnTransferTokenRejected	Vault balance delta enforcement prevents underfunded commitments.
testDifferentTicketsCannotCrossSubsidize	Per-token balance isolation.
testMakerIdentityRequiresAgentWalletProof	Forged agent ID/signature/registry rejected; unverified delivery cannot acquire maker share.
testFinalImageAndAttestationImmutable	Replays, later deliveries and admin-like callers cannot mutate revealed token.
testTokenURITransitionAndCIDIntegrity	Ticket metadata before acceptance, final metadata after acceptance; CID/evidence hashes match.
testRoyaltyQuoteIsSalePricePercentage	Exactly 5% across zero/low/high inputs and no incorrect fixed amount.
testNoPrivilegedRescueOrHiddenUpgrade	No method drains escrow, swaps verifier, changes signer or force-reveals.

Use fuzzing for token IDs, amounts, timestamp boundaries, callback order, signature fields, and attestation lengths. Invariant handler should randomize mint, deliver, accept, reject, timeout, transfer and refund while checking escrow conservation, immutable reveal, monotonic state, bounded counters and no double-spend. A separate fork check is required after target network publication to verify deployed Intake/token/registry code and methods; that is not possible from the information supplied.

Risks ranked by severity

Rank	Severity	Risk and mitigation
1	Critical	Service key compromise or dishonest majority can attest a bad image. Require signer rotation policy before launch, panel seats/receipts, short expiry, visible evidence, refund path; current source key is fixed, so compromise cannot be patched without redeployment.
2	Critical	Intake callback semantics/identity differ from the assignment description; callbacks may be lost or spoofable. Validate deployed bytecode/interface and provide replay-safe proof path.
3	High	Subjective rubric and panel capture, collusion, sybils, maker judging, or biased data. Independent seats and maker exclusion need signed evidence; agreement is only a signed claim absent seat receipts.
4	High	CIDs identify bytes but pinning can end; media disappears even when chain record remains. Two independent pins, CAR mirrors, and periodic retrieval audits.
5	High	Payment denomination, decimals, chain and contracts are unknown. Incorrect constant can strand funds or deploy against a fake token. Publish target details and verify runtime code before build.
6	High	AI copyright/licensing is jurisdiction dependent and the commissioner may not possess rights it purports to grant. Avoid exclusivity claim, publish model/rights policy and get counsel.
7	Medium	Seed grinding/withholding compromises fairness or liveness. Combine commitments with timeout fallback; describe residual block-producer influence.
8	Medium	Job cost/review cost exceeds reserve as prices or service policy change. Fixed bounded budget, no overcommit; launch price must cover escrow plus operational/storage costs.
9	Medium	ERC-2981 royalties may not be paid by marketplaces. Treat them as optional upside and pay maker primarily from commission fee.
10	Medium	Serial “previous artwork” dependency propagates failures and alters later prompts. Use only final successful predecessor and defined refund marker.

Open questions for the IdentityMD developer

1. “Which chain, IMD token address, token decimals, and canonical deployed Intake address should this collection pin in source, and where can we verify their runtime code?”
2. “Can Intake be called and target-bound from a consumer constructor without a later registration transaction, and what exact authenticated callback ABI and retry behavior does it expose?”
3. “Does Intake bind requestId to the originating consumer, payment amount, status and result hash, and can anyone independently prove a callback that was not delivered?”
4. “Can a completed image job provide a cryptographically verified ERC-8004 agentId, registry address, agent wallet, and signature binding the request ID to the result hash?”
5. “Can oracle requests exclude the commissioned maker from panel selection and return a signed panel-member commitment, distinct member identities, votes, quorum and agreement scale?”
6. “Is agreed an integer percentage, basis points, or another scale, and is the specified oracle signer key fixed, rotated, or revocable?”
7. “What exactly does questionHash canonicalization use (JSON canonicalization, encoding, and field names), and how does the verifier distinguish panel evidence from recipe-reexecuted chain evidence?”
8. “What are the permitted answerType encodings for bool, the exact EIP-712 Solidity struct/domain type strings, and is expiresAt bounded by a service maximum?”
9. “What is the funded retry/refund policy when a service request is accepted but never completed, and can the consumer safely reuse request funds after a timeout?”
10. “May the collection publish the full prompt and output URI publicly before reveal, or must sensitive prompt data be held privately until after adjudication?”
11. “Which jurisdictions, image-generation providers, dataset policies and user licence language are approved for artwork commissioned and sold through IdentityMD?”

Source notes

Technical interface claims are attributed to the relevant EIP; storage facts to IPFS documentation; copyright guidance to the U.S. Copyright Office; and comparator mechanisms to project documentation/pages. Project pages can change; the report date records when reviewed, while absent page revision dates are explicitly acknowledged above. Statements about the IdentityMD service behavior remain ASSUMPTIONS based on the task brief, not independently verified facts.