Implemented all four contracts, tests, vendored dependencies, ABI exports, and deployment/operations documentation.

Verified:

• forge build and offline rebuild
• forge test: 53 passed, including 16,384 stateful actions
• forge fmt --check
• ABI consistency

See README.

Manifest creation, independent review, deployment, funding receipts, and frontend delivery remain assigned to later stages.

Created launch.json with the accepted token metadata, Ponziramid("$token", "$owner"), and required pool values.

Verified manifest fields and constructor ABI compatibility. forge build succeeded with lint warnings; forge test passed all 53 tests.

Only launch.json changed outside permitted scratch output.

I found two problems in the economics and wrote them to .imd-findings.json, with a coverage row for all 16 entry points and two solvency invariants. I changed no project files. The two scratch tests I used for reproduction are deleted, and the existing 53 tests still pass.

1. Medium: the 700M funding gate can stop the game from ever starting (src/PonziRewards.sol:12, enforced in reserveRound at line 509)

• The problem: No round can start until the reward pool has held 700,000,000 PONZIRAM. That number is fixed in the code. It only works if the factory gives the creator's wallet 70% of supply.
• Why it matters: Under the standard factory split (80% to the pool, 10% swarm), the creator's wallet gets only 100M. After the creator deposits all of it, the first build call fails with InitialFundingRequired(). 100M would already pay for 100 rounds. The other 600M sits in the liquidity pool and swarm wallets, so in practice the game never starts. The contracts can't be changed after deployment, so this can't be fixed later.
• What decides it: The project docs say the split is "20% pool, 70% allocation wallet", but nothing in the code enforces that. If the launch policy really gives that wallet 700M, there is no defect. Otherwise the gate should be tied to the 1M-per-round reservation, or to a threshold passed in at deployment that matches the policy.
• Proof: I attached a Foundry test that fails on the current code for exactly this reason.

2. Low: withdrawing Stone early doesn't forfeit the PONZI reward share (src/Ponziramid.sol:198)

• The problem: The brief says withdrawing a brick's Stone "loses end-of-round shares". But a player who builds a brick and withdraws its Stone before the round ends still claims a full participation share. In my test that was 350,000 PONZIRAM, the same as a player who kept their brick in.
• Why it matters: A wallet can collect a full PONZI share for only the 10% non-refundable fee, which dilutes players who stay in.
• What decides it: The handoff describes this as deliberate, so it's a question of how the requirement is read, not a loss of funds. Whoever judges the reviews should decide whether "end-of-round shares" includes PONZI rewards.

What holds: I traced every entry point and found no problems in:

• ETH accounting: the 90/10 Stone/Mortar split, the 50/40/10 Mortar split down to the wei, dividend tracking for withdrawn bricks, and the 40/40/20 Tomb payout with leftover wei carried into the next round.
• Withdrawals: Stone can always be withdrawn in full, even during a pause, and a failed payment keeps the player's credit.
• Solvency: the vault always holds at least all unwithdrawn Stone, and the game contract always holds enough ETH for everything it owes.
• PONZI reward rounding: leftover tokens are returned to the uncommitted pool exactly.

Static-analysis leads I checked and rejected:

• Reentrancy in fund: the token is a plain ERC-20 with no transfer hooks.
• "Arbitrary ETH destination" in _pay: only the owner of a credit can choose where it is paid.
• Divide-before-multiply in build: it is deliberate whole-wei rounding, and the remainder goes to the Tomb.

Not reported: Two behaviours the brief allows are left out:

• A player who controls many wallets can end a round early by withdrawing many bricks at once, each taking 10 minutes off the timer.
• The owner can pause building near expiry to keep the current Pharaoh in place.

There is no launch.json in the tree yet, so I didn't review a manifest.

The review is complete. The findings file is written and validated, and no tracked source or configuration file was changed.

Outcome. The permission model holds on every one of the 16 entry points. Only one item in my area is substantiated, and it is a trust assumption rather than a bypass.

• Finding 1 (low), setPaused at src/Ponziramid.sol:309. The owner can build last, pause in the same block, and let the round expire with themselves as Pharaoh. Repeating unpause, build, pause each round makes the owner the sole participant. The scratch test shows the owner then takes 80% of a Tomb seeded by other players' Mortar and the full 1,000,000 PONZIRAM round reward for one 0.001 ETH brick, draining the 700M reward pool at 1M per day. The README and handoff only say a pause "can influence who remains the last builder", so the documented trust assumption understates the power. The repro is in the findings file with exact wei values.

What held, with the checks traced.

• Every state-changing function has the guard its effect needs: vault deposit and the withdrawal callback are contract-only, reward reservation, participant recording and finalization are game-only, claims are bound to the brick owner, credit holder or verified participant, and the only owner function is the pause.
• Paired surfaces are symmetric: deposit and withdraw mirror the same three vault slots, the claim write path reuses the claimable view, reserve and finalize move committed in mirror, and the dividend accumulator sums exactly to what was distributed.
• Constructor roles are sound: only owner_ is privileged, zero addresses revert, factory and tx.origin gain nothing, children are bound immutably, and the exported ABIs match the compiled ones.
• The existing suite, including the 128x128 invariant run, passes on this tree.

Not reached. No launch.json exists yet, so the manifest row is marked unreached. The handoff's constructor facts match the source. Sybil bank-run round shortening and token farming by non-owners were examined and left out because the brief explicitly accepts bot and multi-wallet influence.

The review is complete and .imd-findings.json is written at the repository root. No source files were changed.

Outcome: the math holds. I found no reproducible precision, boundary or numerical-gap defect in the four contracts. The file carries one info-level note and a coverage row for all 16 listed entry points plus five invariant rows.

What I verified, with concrete runs

• Mortar split to the wei. Over a 1,500-brick single-round ladder with interleaved pre-expiry withdrawals, owner fee plus distributed dividends plus tomb equalled mortar on every brick, and the game balance equalled the sum of all liabilities after every step.
• Stone/mortar rounding. Stone is floor(0.9P), so sub-wei fractions land on the non-refundable side. The README documents this, and it is at most 1 wei per brick.
• Price ladder. The 0.5% compounding is monotone and only overflows after roughly 27,000 bricks in one round, which no round can reach before expiry.
• Dividend accumulator. The sum of claimable dividends across all bricks equals the round's remaining dividends, including bricks frozen by withdrawal.
• Diamond-hands division. Per-brick floors lose under one wei each, the divisor cannot be zero while an eligible brick exists, and the residue is recycled to the next tomb on the last settlement, even when a prize rounds to zero.
• Expiry boundaries. A withdrawal at exactly ten minutes remaining expires the round immediately, a withdrawal at or after expiry keeps its eligibility, the 7-day cap holds, and build, withdraw and finalize agree on the >= versus < comparators.
• No-survivor finalize and cross-round seeding. The diamond pool folds into the seed with no division by zero, and the next round's tomb equals the seed plus the first brick's tomb share exactly.
• Reward dust. With three participants the share floors and exactly one wei of dust returns to uncommitted.
• Deeper invariant campaign. The repository's invariant suite at depth 400 ran 19,200 calls with zero failures.

The one note (info). INITIAL_FUNDING at src/PonziRewards.sol:12 equals the entire 70% allocation with zero margin. A funding wallet holding even one wei less than 700,000,000 tokens leaves isFunded() false and every build reverts with InitialFundingRequired. The README already says anyone may top up the shortfall, so this is a configuration dependency for the judge to confirm against the pinned policy, not a code defect.

Not covered. Access control, economics and reentrancy belong to other specialists. I checked reentrancy only as far as the vault and game guards interact on the payout paths, and both held.

The review is complete and written to .imd-findings.json. The tree is otherwise unchanged; the scratch test directory was removed.

Outcome. The control flow of Ponziramid, StoneVault and PonziRewards holds under the Execution Trace, Periphery and First Principles checks. I found no loss-of-funds or permission defect. All 53 project tests and the stateful invariant suite pass, and the four ABI exports match the compiled artifacts exactly.

Findings recorded

• Low, PonziRewards.sol line 12. The 700M funding gate hard-codes the policy's payer share. If the admitted policy pays the creator less than 700M, such as the launch reference's default 80% pool and 10% payer split, the creator can deposit its whole balance and every build still reverts with InitialFundingRequired, so no round can ever start. I confirmed this with a scratch test. The brief itself names a 70% allocation, so this is a configuration item for the manifest and admission review to confirm, with a constructor argument as the design-preserving alternative.
• Info, Ponziramid.sol line 220. Two alternating wallets holding 144 bricks can end any round in one block after their own placement and take 40% of the Tomb as Pharaoh, at a net cost near 0.007 ETH. The brief asks for both rules and accepts multi-wallet influence, and the README discloses it, so it is recorded as a trust assumption, not a defect.

Coverage. All 16 listed entry points have rows: 14 hold, two reference finding 1 (fund and reserveRound). Three invariant rows hold. The manifest row is unreached because no launch.json exists in the tree yet. The README and handoff describe the expected manifest, one application contract with $token and $owner, which matches the constructor ABI.

What I could not cover. No launch.json to validate, and no "This launch" section to confirm the 20% pool choice behind the 70% payer allocation. Static-analysis leads (arbitrary send, reentrancy in fund, divide-before-multiply) were traced and are either intended pull-payment behaviour or guarded, so none became findings.

Added 16 unit/fuzz tests and two stateful invariant campaigns covering failure rollback, funding exhaustion, refunds, token approvals, and individual payouts.

forge build and the full forge test suite pass. All additions are under test/. No confirmed contract defects found.

Review complete. The findings file is written and validated, the scratch tests are removed, and the tree is otherwise untouched (the untracked dotfiles in git status are sandbox device mounts, not changes).

Outcome: no critical or high defect. The code holds up under my own pass: the per-brick dividend accumulator, the diamond-hands snapshot at expiry, the reentrancy ordering across the three contracts, and the PONZI commitment accounting all behave as the brief specifies. All 71 project tests, including the two invariant suites, pass. Initcode and runtime sizes are far under the limits, the ABI docs match the compiled ABIs exactly, and launch.json is schema-clean with constructor args matching the two-address constructor. Every slither and aderyn line was checked and none reproduces as a defect.

Findings reported in .imd-findings.json:

1. Medium, merged from three specialists. The 700M initial-funding gate is a compiled-in guess at the launch policy's payer share with zero margin. If the admitted policy pays the funding wallet less than that, no round can ever start and the immutable contract cannot be repaired. The resolution is either admission evidence that the policy's pool share is 20% or a constructor-supplied threshold. I ran the economics specialist's proof and it fails as described, but I did not attach it because it pins the current constructor signature and would forbid the natural fix.
2. Low, trust assumption. The owner can build, pause, and let the round expire to become sole Pharaoh and sole participant, taking the rolled Tomb and the full 1M PONZIRAM round reward each round. Reproduced with concrete numbers. The brief asks for the pause, so this needs documenting rather than removing.
3. Info. Withdrawing Stone before expiry keeps the wallet's PONZI participation share. Reproduced, but it is a defensible reading of the brief and is recorded in the handoff.
4. Info. A multi-wallet builder can self-bank-run to end a round at will. The project's own test shows the sequence, and the brief accepts this.

Coverage: all 16 entry points answered, 12 hold and 4 point at a finding, plus three invariant rows for vault solvency, reward commitment, and the manifest.

The responses file is excluded by the harness's own .git/info/exclude entry, alongside the .imd/ inputs, so that is the intended collection path and nothing else is needed. The work is complete.

Outcome. The medium finding reproduced and is fixed. The three advisory findings reproduced as described; two are answered with fuller documentation and no code change, and the bank-run note is disputed as the brief's rule applied as written.

Funding gate fix (medium). The 700M figure is no longer compiled in. Ponziramid now takes a third constructor argument, creatorAllocation_, and passes it to PonziRewards, where it is stored as the immutable INITIAL_FUNDING. The getter name is unchanged, so the funding reads and the round reservation logic are untouched. The constructor rejects a value below one round reward or above the token supply, and there is no setter. The manifest writes the admitted policy's payer share, which for this launch's stated 70% is 700000000000000000000000000. The gate deliberately keeps zero margin, since the brief requires the pool to hold at least the creator allocation; README, the handoff and the ABI guide now say that a shortfall must be made up by the wallet or a donor.

Tests added.

• A 100M-allocation pool reverts one wei short and reserves once complete.
• A 100M-allocation game starts round 1 on the funding wallet's entire-balance deposit.
• Constructor bounds: zero, one round reward minus one, and supply plus one are rejected; both bounds and 700M are accepted.
• The CREATE2 deployment test now encodes all three arguments and checks the bound gate.

Checks run. forge build --offline --force, forge test --offline --threads 4, and forge fmt --check all pass. The project suite has 56 tests, all passing. ABI exports were regenerated and verified against the build. Bytecode sizes in the validation record were updated from the deployment test's own output. The linter output is the same set of previously reviewed heuristics with nothing new.

Documentation. The README and launch handoff now state the owner pause's full reach, that a PONZIRAM participation share survives a Stone withdrawal and costs only Mortar, and that a multi-wallet bank run can end a round in one block. The README's after-launch list asks the website to state all three in plain words.

Answers to all four finding ids are in .imd-responses.json at the repository root, with verdicts fixed, fixed, fixed, and disputed respectively. No launch.json or .imd-blocked.json was written.

Revised launch.json to match the accepted source. The only file changed is the manifest.

What was wrong. The accepted revision of Ponziramid added a third constructor parameter, creatorAllocation, which becomes the immutable funding gate in PonziRewards. The previous manifest listed only two arguments, so deployment would have failed ABI encoding.

What I changed.

• Added the third constructor argument. It is the 70% payer share this launch states, written as a decimal ABI word for seven hundred million tokens at 18 decimals. The source constructor accepts any value from one round reward up to the full supply, and this one sits inside that range.
• Updated the notes to name all three constructor parameters, state what the allocation value means, and clarify that the funding gate latches once. Notes remain well under the 4000 character limit.
• Left the token block, pool block, contract list and ordering untouched, since those were already correct.

Checks run.

• A scratch validator confirmed only schema keys are present, every uint and address is a string, fee, tickSpacing and decimals are numbers, names are unique and within 32 characters, and the argument count and types match the constructor in docs/abi/Ponziramid.json.
• forge build succeeded.
• forge test passed all 56 tests across 8 suites, including the deployment test that exercises the three-argument constructor on an empty chain.
• git status shows launch.json as the only modified file.

The revision is complete. The full suite passes with 81 tests and no findings file was needed.

What changed since my last round. The implementation replaced the compiled 700M funding constant with a creatorAllocation_ constructor argument stored as the immutable INITIAL_FUNDING gate. My accepted tests still passed against it, but none of them exercised the new argument, so that is what this revision adds. Everything else in my files is unchanged apart from two hard-coded 700M literals that now read the fixture's constant or the deployed pool balance.

Added, all within test/:

• FundingGateArgumentTest in test/AdversarialBoundaries.t.sol. A 1000-run fuzz over the whole accepted allocation range shows that a pool one wei short, filled through fund() or a plain transfer in either order, never starts a round, keeps the player's payment and never latches, while the exact amount does. A second fuzz proves allocations below one round reward or above the supply never deploy through either constructor. Pinned edges cover the minimum gate (exactly one round, an empty pool that stays latched, then exactly one more round reward needed), the maximum gate (every token in existence, last wei donated and latched by the first reservation), per-pool isolation and the absence of any setter.
• test/invariant/FundingGateInvariant.t.sol, a new campaign starting a game with a 3M gate from an empty pool. Random funding, donations, builds, finalizations, claims and pauses drain and refill the pool. Invariants: the gate never changes, no round starts before the latch, the latch equals a ghost flag set only by a reaching fund() call or a reservation, pool balance equals funding plus donations minus claims, committed equals reservations minus payouts minus recycled dust and never exceeds the balance. A pinned sequence confirms the handler reaches rejection, depletion and refill states.
• Contributor notes updated for both.

Verification. Build is clean, all 81 tests pass on the default and an alternate fuzz seed, and the new handler hits all seven actions with zero unexpected reverts. The three failures I hit while writing were harness mistakes on my side, not contract bugs, and were fixed rather than tested around.

One item for the manifest reviewer, not a code defect. The README and handoff state a 70% payer share and write 700M as the third argument. The reference policy's default pays the funding wallet 10% with 80% to the pool. The contract accepts whichever value is written, so the review must confirm the manifest value equals what the funding wallet actually receives, as the handoff already instructs.

The second-round review is done: all four findings from last round are settled. One new low-severity defect is in a test file; no contract is affected. .imd-findings.json has one finding and a holds row for all 16 entry points. No repository files were changed.

Last round's findings:

• Hard-coded 700M funding gate (medium): fixed. The amount is now a third constructor argument, creatorAllocation_. The constructor stores it once as INITIAL_FUNDING and rejects anything below 1,000,000 or above the 1,000,000,000 supply. launch.json passes 700000000000000000000000000, which matches the brief's "the 70% allocation" in workflow.md:20. The author's three new tests pass. The constructor still makes no outside calls, and the contracts are well within the size limits.
• Owner pause lets the owner win every round (low): fixed by documentation. README.md:74 and docs/LAUNCH_HANDOFF.md:48 now describe the full power. README.md:82 requires the site to state it. That was the fix I asked for; the brief requests the pause itself.
• Withdrawing Stone keeps the PONZIRAM participation share (info): fixed by documentation. The per-wallet reading is confirmed as intended and disclosed in the README.
• Multi-wallet bank run can end a round early (info): the author's dispute holds. It is the brief's rules applied as written, and it is now disclosed.

New finding (low): forge test fails on this tree, with 80 passing and 1 failing. The failing test is FundingGateInvariantTest in test/invariant/FundingGateInvariant.t.sol. At line 77, its handler computes actors[(actorSeed + 1) % actors.length]. When the fuzzer passes the maximum uint256 value as actorSeed, that addition overflows and the run panics. The finding includes the shrunk call sequence that triggers it. The fix is in the test only: reduce actorSeed modulo the actor count before adding 1. The property the test checks still holds for the contracts. The author's "56 passed" report predates this test file, which came from another contributor.

Static-analysis leads: none reproduced.

• The fund() reentrancy warnings don't apply with the plain launch token.
• _pay only sends a caller's own credit, to a recipient the caller chooses.
• The rounding dust Slither flagged in build() stays in the Tomb, which is intended.
• The strict equality in quote() is safe.

Implemented the frontend, static export, runtime deployment manifest, and documentation.

• Build/typecheck, 12 core tests, and 22 browser scenarios pass.
• ABI and asset hashes verified.
• Export: 740 KB; verified bundle: 1.15 MB.
• Live deployment was unfunded; no funding transaction observed or real transactions sent.

Evidence: validation. Design documentation is in docs/DESIGN.md to respect the write scope.

Git metadata is read-only; deliverables are ready for publisher capture.

Recorded in .imd-findings.json:

• High — fidelity: The pyramid stops growing after 204 confirmed bricks. At 205, its drawing remains identical; mobile also hides the limit notice.
• Medium — bug: Changing direction, amount or slippage while a quote loads can restore an actionable quote for the previous trade.
• Medium — bug: Cancelling a transaction through the wallet produces “Build a brick: confirmed,” although no brick was added.
• Medium — bug: Mobile ellipsizes the Tomb balance and hides its complete value.

Each finding includes exact source citations, the requested change and a concrete reproduction.

Build, typecheck, 12 core tests and all 22 supplied browser scenarios passed across Chromium and WebKit. The rebuilt export is byte-for-byte identical to the committed export. Manifest fields, pinned ABI bytes and all 11 asset hashes match. Additional reproductions used mocked wallets; no real transaction was sent. Website files remain unchanged.

PONZIRAMID’s visual idea is a shared limestone pyramid beneath a gold crown, framed by ink-black panels.

The checklist below deduplicates the repeated workflow text and groups related clauses. Contract entries describe preserved implementation and existing test coverage, not a new Solidity security audit.

Reproduced and fixed all four findings: pyramid growth, stale quotes, cancellation reporting, and mobile Tomb precision.

Rebuilt dist/ and its verified manifest. Build, typecheck, and all 50 tests passed. Responses are in .imd-responses.json; evidence is in docs/REVISION_VALIDATION.md.

Submission bundle is under 8 MiB. No real transactions were sent.

All four prior findings are fixed. No new reproducible defect was found. .imd-findings.json contains {"findings":[]}. The website and tracked repository files remain unchanged.

Validation passed: 13 core tests, 22 Chromium/WebKit scenarios and 15 revision scenarios. An isolated build reproduced the committed export byte for byte. Manifest verification covered four pinned ABIs and all 11 assets, totaling 739,341 bytes.

The requirement inventory below groups related clauses and counts duplicated brief passages once. Contract requirements retain their accepted source-stage evidence; this frontend review did not repeat the Solidity audit.