launch.json is written and verified. It is the only file changed in the tree.

What it contains

• Kind evm_contracts with three contracts in dependency order: Renderer, Composer, then Registry, matching the approved workflow's deployment order.
• Renderer and Composer have empty constructor argument lists, as their source has no constructor.
• Registry carries the eight address arguments in declaration order: WhitelistCurator, IdentityMD, IMD token, Intake v2, the oracle attester, $contract:Renderer, $contract:Composer, and the IMD BurnExecutor V2. The static addresses are the ones the brief names and match the mainnet constants in script/Deploy.s.sol.
• No $owner appears, because the accepted contracts are ownerless with no setter or upgrade path. No token, pool, distributor, funding or initialization fields.
• Notes run to about 2,600 characters and describe each contract, its arguments and the size evidence from the test notes.

Checks run

• forge build with the pinned settings succeeded.
• forge test with the verifier's fuzz seed: 181 passed, 0 failed, 16 opt-in fork tests skipped.
• A scratch Python check confirmed only the schema keys are present, each constructor argument list matches the compiled ABI's parameter count and address types, contract references point backward, and no static address is zero.
• A scratch Forge test deployed all three contracts with the exact manifest arguments on an empty chain, exercising the Registry constructor's floor path that the protected probe uses.

One item for the reviewer, not the manifest The accepted test notes record a combined runtime of 72,315 bytes, above the 69,800-byte section 6 budget. Each contract is individually under EIP-170, but the single-transaction gas cost needs confirmation by the deployer's simulation. I recorded this in the notes field as explanatory text only.

I wrote .imd-findings.json with 4 findings and 17 coverage rows (all 15 listed entry points plus 2 invariants). No repository file changed: the two scratch tests I ran were deleted afterwards, and git status is clean. Both scratch proofs fail on the current code for the reason each finding states.

Findings

1. High: the three contracts are too big for the one-transaction deployment. Registry is 23,535 bytes, Composer 24,234 and Renderer 24,546, a total of 72,315. The workflow's hard budget is 69,800. test/NOTES.md admits the overrun and estimates the launch transaction would go over the 16,777,216-gas cap. The proof test deploys all three and checks the total.
2. Medium: docs/V2.md item 18 is missing. Composer's spec check still accepts a shared-fact spec built on an anonymous event (V2's own regression, event Receipt(...) anonymous), and it accepts a grouping argument that isn't an address. The question text never says which position the argument holds in the event, so the trait can go to the wrong wallets. The proof test passes V2's anonymous Receipt spec through validateSpec and expects the rejection V2 requires; it doesn't come.
3. Medium: docs/V2.md item 8 is missing. A shared-fact answer with any length from 1 to 64 is accepted, not exactly the required count (32 for fact 1201). A short signed answer, for example one address, is stored for good. After that, requesting the fact again always fails, and wallets left off the short list can never claim the trait. This one has a written reproduction but no test.
4. Low: docs/V2.md item 9 is only half done. Spec ids are still 16-bit, so after id 65534 every new spec registration fails for good. Reaching that takes 55,534 registrations.

Permissions themselves held up. There is no owner, setter or upgrade path, and the constructor gives no one a role. Its arguments are in the order the workflow approves. Only the Intake can deliver results or failures, and every action works on the caller's own wallet, so holding or transferring a card changes nothing. Payments are taken before any oracle request is made, and abandoning a request is limited to its claimant or payer. I traced reentrancy through the ETH refunds and found nothing that can be exploited.

Some behaviour looks risky but is approved in docs/V2.md, so I didn't report it:

• A list member can make a sponsored claim they know will fail once a day, costing the pool one price each time (item 3).
• One IDMD seat passed from wallet to wallet can give the "Armed" trait to every card minted while holding it (item 14).
• Only the payer can abandon a stuck shared-fact request (item 5).

Not covered. I didn't review Renderer, or Composer's body and hash encoding, beyond what my area touches. Items 19 (tokenURI gas at maximum state) and 20 are also undone according to test/NOTES.md. I didn't measure them or write findings for them.

I found three defects and saved them, with coverage, to .imd-findings.json. No repository files were changed; I deleted the scratch tests after running them.

Findings

1. High: the three contracts are too big to deploy in the planned single transaction. The brief sets a hard limit of 69,800 bytes for Registry, Composer and Renderer together. The current build is 23,535 + 24,234 + 24,546 = 72,315 bytes, which is 2,515 over (test/NOTES.md:10). Based on the lab's measured build, the extra bytes should add about 0.5M gas, which would push the one mainnet deployment transaction past the 16,777,216-gas cap. The builder recorded the overage and left the decision to review, but the brief says the limit is hard. The finding includes a self-contained Foundry proof: it deploys all three contracts and checks the total size. It fails on this tree as 72315 > 69800.

2. Medium: V2.md item 8 is missing, so an incomplete shared-fact answer becomes permanent (src/Registry.sol:603). A signed answer to a "top 32" question that lists only one address is stored. After that, requesting the fact again reverts with FactAlreadyStored, and every other wallet in the real top 32 can never claim the trait. I confirmed this locally with a scratch test.

3. Medium: V2.md item 9 is missing, so spec registration can be used up for good (src/Registry.sol:658). Spec ids are still uint16. After id 65534, every later registerSpec call reverts with an overflow, and the contract has no owner or upgrade path to fix it. Using up all the ids deliberately would take 55,534 × 6.4 IMD = 355,417.6 IMD plus gas. The existing test test_specIdsEndAt65534 already shows the limit.

What holds in the economics area

• Value flows: the registry's IMD balance changes only through fees, donations and payments of exactly the Intake price. Paid paths pull the user's IMD before spending it.
• Pool draws: each draw is capped by maxPrice, an eighth of the pool and 2 IMD. The per-trait, per-UTC-day and nine-verified limits work as V2.md describes.
• Burn rule: every path returns exactly this call's msg.value, and the preview's return values match the reference BurnExecutor V2.
• Re-entrancy: re-entering during ETH refunds can't move value, because the functions that move value are nonReentrant.
• Oracle callbacks: onResult and onFailure settle each request once and release the sponsored reservation correctly.

The coverage record has a row for all 15 listed entry points plus three invariants: 11 entry points hold and 4 point to findings 2 and 3. I left one point out on purpose: if the Intake price goes above 2 IMD, the pool can't be spent until it comes back down. That follows from item 1's cap, which V2.md made final, so it isn't a defect.

The other V2 items NOTES.md marks as not done (18, 19's 8,000,000-gas test, 20 and the documents) are outside my area, so I didn't report them.

The review is complete and .imd-findings.json holds three findings and twenty coverage rows. Nothing outside that file and test/scratch/ was touched.

What I checked (Math Precision, Boundary, Numerical Gap guides)

• Every arithmetic site in Registry, Composer and Renderer: the direct-trait bit layout, price * k, the pool/8 and 2 IMD draw caps, the UTC-day bucket, the uint8 sponsored counter, the 31-day abandon window, the answer-length bounds, the window and timestamp comparisons, the gas floor formula, and the refund sums on every burn path. All hold.
• Every spec that passes validateSpec also composes. I registered the maximum spec of each of the five kinds and composed each one. The largest body is 2,041 bytes and the longest question stays under the 1,000-character cap, so no 6.4 IMD fee can be stranded on an uncomposable spec.
• The Renderer buffer grows on demand, and every table index derived from counts stays inside the generated tables.

Findings

1. Medium. tokenURI at the item-19 maximum state costs 11,958,908 gas cold against the approved 8,000,000 ceiling. Items 19(a), (b), (d) and the regression test are absent, and test/NOTES.md reports no measured number as the item's fallback requires. A proof test under test/scratch/TokenURIGasMaxState.t.sol fails on this tree for exactly that reason.
2. Low. nextSpecId is still a uint16, so item 9's widening is not done. At id 65535 the increment panics and registerSpec is dead for ever after 55,534 registrations.
3. Low. Item 8 is not done. A signed kind-3 answer with one address for head 32 is stored as the 1201 fact, that address can apply it, and no second request for 1201 is ever possible.

Coverage. All fifteen listed entry points have a row. onResult and registerSpec point at findings 3 and 2. The rest hold, with the reason on each row. Five invariant rows record the spec-composes check, the buffer check, the burn arithmetic and the gas measurement.

Not reached. The fork suites and the real BurnExecutor were not run. The static-analysis leads in my area (the strict equalities, the timestamp comparisons, the uninitialized locals) all traced clean and are not reported.

The review is complete. The findings file is valid and nothing outside .imd-findings.json and test/scratch/ was touched.

Outcome. The control flow in my area holds: I traced every state-changing entry point through its guards, state writes and failure paths, and the request → callback → verify pipeline, the pool draw with its ETH refund paths, the kind-3 decode bounds and the ERC-721 transfer story all behave as intended. All 181 offline tests pass. A cold 64-address shared-fact delivery, the largest answer the code accepts, uses 169,324 gas under the Intake's 200,000 stipend.

Findings written to .imd-findings.json (six, with a coverage row for every listed entry point plus three invariants):

• Medium, launch size budget. The three runtimes total 72,315 bytes against the hard 69,800-byte budget of docs/V2.md section 6. The builder recorded the overrun and deferred the decision to review. Outside my guides, but it projects the single deployment transaction past the gas cap.
• Low, item 8 not implemented. A kind-3 answer with 1 to 64 addresses is stored regardless of head. Reproduced: a one-address list for trait 1201 is stored and the listed wallet gets "Top Weights".
• Low, item 18 not implemented. An anonymous kind-3 event and a non-address grouping key both register; no topic position in the T3 text. Reproduced with the regression case V2.md names.
• Low, item 9 half done. Ids stay uint16, so registration after id 65534 reverts with a panic forever. Reproduced; the suite's own test pins the same behavior.
• Info. Items 19, 20 and 22 remain open per test/NOTES.md. CATALOG.md and INTEGRATION.md still describe the removed upgradeSponsored function and a 14-day abandon window.
• Info, trust assumptions. The ownerless design fixes the attester, action id and Intake. A signer rotation or action retirement freezes oracle traits with no remedy short of a redeploy.

Not reached. The Renderer's maximum-state tokenURI gas (item 19) was not re-measured; it is reported from the builder's notes only. The fork suites were not run.

I added two test files. With the verifier's fuzz seed, forge test passes: 209 passed, 0 failed, 16 skipped (fork tests that need a network). I also found four defects that can't be tested around, and reported them in .imd-findings.json instead of writing tests that pass on the broken code.

test/V2Edges.t.sol (26 tests). These cover the edge cases and failure paths the existing V2 tests skip:

• Item 1, pool draw limits: a draw at exactly an eighth of the pool passes, and one wei more is refused without using up the day. A draw at exactly the 2 IMD cap passes, an empty pool refuses every draw, and non-members and non-chain traits are refused. A fuzz test checks that a draw succeeds exactly when the price is within all three limits.
• Item 2, price checks: zero price on shared facts, and a price above maxPrice on the paid paths (nothing is pulled).
• Items 3 and 7, failed requests: after a miss, a retry is refused the same calendar day and allowed the next. Abandoning a pool request gives back the trait but not the day. A second completion for the same request is rejected by the Intake. The callbacks refuse any caller except the Intake, and a wrong signer or altered answer misses.
• Item 5, abandon: exact 31-day boundary, strangers refused on both personal and shared requests, double abandon refused, and a late answer after abandon misses.
• Item 9: expectedId too high, too low, or wider than 16 bits is refused, and only one fee is pulled.
• Items 12–14, cards:
  • totalSupply counts mints, not transfers.
  • Someone sent a card they didn't ask for keeps all their own powers, and the minter's facts can't be changed by whoever holds the card.
  • The direct traits frozen at mint are pinned bit by bit.
  • "Armed" stays off when a seat arrives after the mint.
• Item 16: a fuzz test checks that a spec registers exactly when its window ends at least 64 blocks back; future and short windows are refused.
• Item 20: the generated template and hive tables have no gaps or overlaps. The spec asked for this test and it was missing.

test/PoolInvariants.t.sol. This runs random call sequences across four member wallets with a changing Intake price: donations, mints, pool draws, paid upgrades, the four delivery outcomes, abandons and time jumps. After every sequence these must hold:

• the pool equals donations plus fees minus draws;
• no accepted draw broke a limit, and no draw the limits allowed was refused;
• one draw per wallet per day, at most nine sponsored traits per wallet, and the count matches what was actually verified;
• a trait's pool reservation is held only while its request is pending or after it was verified.

A separate test confirms the random calls really do draw, verify and release, so the invariants aren't checking nothing.

Reported defects. Each of the first three has a self-contained proof test that fails on the current code:

Item 19 (the card's metadata must render in under 8,000,000 gas at the maximum state) has no test in the tree. I didn't write one or measure it, so it's untested rather than reported as a defect.

The review is complete. The findings file at .imd-findings.json holds 7 findings and 18 coverage rows (all 15 listed entry points plus three invariants). Git shows no tracked file changed; only the findings file and test/scratch/ were written.

What reproduced, merged across the five specialist reports

1. High. Runtime size over budget. Registry, Composer and Renderer sum to 72,315 bytes against the hard 69,800-byte one-transaction budget of docs/V2.md section 6. The specialists' proof test fails on this tree with 72315 > 69800 and is attached. Four areas reported this; merged into one.
2. Medium. Item 18 missing. validateSpec accepts a kind-3 spec over an anonymous event and a non-address grouping key, and the T3 question names no topic position. The attached proof fails with "next call did not revert as expected". Three areas reported it; merged.
3. Medium. Item 8 missing. A one-address answer for fact 1201 is stored permanently, every later request reverts FactAlreadyStored, and the single address gains the trait. Reproduced with a scratch test through the mock Intake. Five areas reported it; merged, kept at medium because the stored short list is irreversible on an ownerless contract.
4. Medium. Item 19 missing. I rebuilt the maximum state and measured tokenURI at 12,022,786 gas with a 40,265-byte URI. A call capped at 8,000,000 gas fails. Only part (c) of the item is done and no regression test exists.
5. Low. Item 9 half done. With nextSpecId stored as 65535, registerSpec reverts with Panic(0x11). Reproduced via vm.store on slot 25.
6. Info. Item 22 open. CATALOG and INTEGRATION still describe upgradeSponsored and a 14-day anyone-may-abandon rule.
7. Info. Trust assumptions of the fixed attester, action id, Intake and executor, documented as the brief's deliberate design.

What I dropped or corrected. audit_flow's claim that item 20 has no Solidity test does not hold: test/V2Edges.t.sol has two passing item-20 tiling tests, so only test/NOTES.md is stale there. I folded that correction into finding 6.

My own pass on the Registry entry points, the callback checks, the burn rule, the ERC-721 overrides and the manifest found nothing further. The manifest is schema-clean, with the eight Registry arguments in declaration order matching the approved addresses.

The full suite passes now: forge test with the verifier's seed gives 217 passed, 0 failed, 16 skipped. The skipped ones are the fork tests, which skip when no RPC URL is configured. forge build is clean. The only file changed is test/V2Edges.t.sol.

What broke and why: after my last round, another contributor's revision changed how the Registry checks shared-fact answers. That change carries out docs/V2.md item 8: an answer must hold exactly head addresses, which is 32 for trait 1201 or the spec's threshold for a community spec. Two of my tests still delivered 1- and 2-address lists. Those now count as a decode miss and store nothing, so the tests failed with FactNotStored(1201). The implementation is right and my tests were out of date, so there was no defect to report.

What I changed:

• The two failing tests now deliver a complete 32-address list through a new _headList helper. Bob sits at the last position (index 31), so the test also confirms the whole list counts when someone applies. Their other checks are unchanged:
  • An unsolicited recipient keeps its own claims, upgrades and shared-fact applications.
  • The card's minter, snapshot and facts stay the same whatever the holder calls.
  • Only a wallet on the list can apply.
  • Applying twice, a mismatched list and an unknown fact id are all refused.
• One new fuzz test, testFuzz_item8_kind3HeadRegistersExactlyWithinOneToThirtyTwo. It checks that a community T3 spec registers only when its threshold is between 1 and 32. Outside that range it reverts BadSpec("threshold"), keeps the fee and doesn't use up an id. This bound matters more after item 8: the callback now walks exactly threshold entries within its 200,000-gas limit, and nothing tested the bound before.

test/Revision3.t.sol already covers item 8's main paths (31- and 33-entry answers refused, community head enforced), so I didn't duplicate them. My pool invariant suite never delivers shared facts and was unaffected.

No .imd-findings.json was needed. I haven't committed anything; the change is in the working tree.

The manifest is updated and verified. Here is the recap.

What changed

Only launch.json changed, and only its notes. The size sentence still described the pre-revision build: runtimes of 23,535, 24,234 and 24,546 bytes summing to 72,315, over the project budget. The other contributor's revision 3 shrank all three contracts, so that claim was stale and contradicted test/NOTES.md. The sentence now reports the measured figures and the test that pins them.

What stayed the same, by verification

• The Registry constructor still takes the same eight address parameters in the same order. The manifest's three entries and their arguments match the compiled ABIs exactly, checked by a script against the build output.
• The five static addresses and the burn executor match the approved workflow and the Deploy script constants.
• Renderer and Composer still have no constructor arguments. No contract has an owner, so $owner is correctly absent.
• The manifest has exactly the keys kind, contracts and notes. Every argument is a string, references point backward into address slots, no address is zero, and notes are 2,723 characters.

Checks run

• forge build succeeds. The one EIP-170 warning is for RendererHarness, a test mock, not an application contract.
• forge test with the pinned fuzz seed: 188 passed, 0 failed, 16 skipped (opt-in fork suites).
• git status shows launch.json as the only modified file.

All four blocking findings from last round are now fixed, so nothing blocks the launch. One low, advisory finding is left; it's in .imd-findings.json along with a coverage row for each of the 15 entry points.

I re-checked each finding against the revised tree. I copied the attached proofs into test/scratch/, ran them, then deleted that folder. The full suite gives 222 passed, 0 failed and 16 skipped.

Settled this round:

• Size budget (high): fixed. forge build --sizes now gives Registry 22,943 + Composer 23,621 + Renderer 23,092 = 69,656 bytes. That is 144 under the 69,800 limit. All three size proofs pass.
• Item 18 (medium): fixed. The proof with the anonymous Receipt event now passes, and so do the three new item-18 tests in test/Revision3.t.sol. They cover the anonymous event, the rule that the grouping key must be an indexed address, and the topic position in the question.
• Item 8 (medium): fixed. src/Registry.sol:606 now refuses any shared-fact answer whose length is not exactly the head (n != threshold). Both item-8 tests pass: lengths 1, 31 and 33 are rejected and nothing is stored, while 32 is stored.
• Item 19 (medium): settled under the item's own fallback. tokenURI at the maximum state still costs about 10.3M gas, over the 8M target. But parts (a) and (b) are done, the cold regression test exists and passes, and test/NOTES.md records the measured number and the next cut. That is what item 19 asks for when the target is still missed, so I dropped it.
• Item 22 (info): fixed. The upgradeSponsored sentences, the 14-day abandon rule and the stale item-20 row in test/NOTES.md were corrected.
• Trust assumptions (info): dropped. This was the brief's chosen ownerless design and was already documented, not a defect.

Still reported:

• Item 9 (low, advisory). The spec counter is still a 16-bit number. At src/Registry.sol:661 (nextSpecId = traitId + 1;) every registerSpec call reverts with an overflow error from id 65535 onward, permanently. No funds are lost, and reaching it takes 55,534 registrations at 6.4 IMD each. The author disputed it as a recorded deviation. A plain "spec ids exhausted" error in place of the overflow would fit the remaining 144 bytes.

None of the specialists' findings is new: each is one of the earlier-round findings above, now settled. I found no new defects.

Implemented the Sworn frontend and 1.60 MB static export with verified deployment ABIs and manifest.

Passed build, typecheck, 51 unit tests, 100 browser checks, 10 live-browser checks and 10 local-fork checks.

README · Validation and limitations · Design documentation

Design documentation is under docs/ to respect the permitted write scope.

Recorded 2 medium findings, no high or critical findings, in .imd-findings.json. The website and tracked files remain unchanged.

• bug: RPC recovery leaves transactions disabled. At 390×844, restore RPC responses after an initial outage, connect, and refresh reads. Live prices return, but “Approve exact IMD” remains disabled until the RPC selection changes. The refresh action should update the application’s deployment-verification state. Source: web/src/main.tsx:15.
• bug: community-trait copy understates a changed price. At 390×844 with a controlled 2 IMD oracle-price response, adjacent paragraphs quote both a 0.5 IMD and a 2 IMD first claim. Delete the fixed-cost introduction and retain the existing live-price explanation. Source: web/src/Claim.tsx:191.

Validation passed: 51 unit tests, build/typecheck, ABI/export checks, 100 Chromium/WebKit browser checks, and 20 live-browser checks. The temporary rebuild produced byte-identical assets. No mainnet transaction was signed.

The checklist groups related clauses; contract implementation items 1–22 are upstream accepted work, outside this website review.