The review is complete. The findings file is at .imd-findings.json, the only new file in the tree, and the scratch directory is removed.

Outcome. The permission model itself holds: every hook callback is PoolManager-only, initialization is factory-bound and single-shot, the two unlock callbacks verify a commitment hash, the router pulls only from its caller, every token take goes to a fixed or committed recipient, and there is no owner, setter, upgrade or pause anywhere. The defects I could substantiate all live at the trust-gap seams the assignment named, not in a missing modifier.

Findings (3), each reproduced in Foundry against the current tree:

• Medium. Public submit() settles a pending plea with a re-asked verdict. The callback is bound to the registry's Intake request, but submit binds only by signer and question hash. The question document is public, the body's consumer field makes the oracle sign in the registry's domain, and each oracle request has a fresh UUID. So a pleader can re-roll the panel for 0.5 IMD per try, and a third party can deny a competitor's plea or force an approval at a bad moment, which also locks the victim out of re-filing for 24 hours. A proof test is attached that fails now and passes once submit is bound to the seller or the Intake path.
• Low. The 10% cap is checked only at filing, per wallet. The same PRAY moved through N wallets backs N pleas of 10% each, and consumption never re-checks balance. Reproduced with two wallets selling 20% of one holding at 1%.
• Low. The tx.origin fallback lets any contract a blessed wallet calls sell its own PRAY at 1% and spend the wallet's blessing. This is the brief's stated fallback, so it is reported as a trust assumption with a concrete abuse path rather than a bypass.

Coverage. All 18 listed entry points have a row plus two invariant rows. Fifteen hold, three carry findings, none unreached. Things I checked and did not report: buyback sandwiching is bounded by the 5% floor minus the buyback's own impact against a 4.5% round-trip fee even while the swarm sleeps, the BlessingUnavailable revert in _answer is unreachable, and the fee delta accounting nets to zero on all four swap paths.

Not covered in depth. Site code, the exact canonical-JSON hash reproduction against the live oracle (relied on the repository's check script and fixture), and the mainnet fork rehearsal, which I did not re-run.

The review is complete. The findings file is written and the working tree shows no tracked changes (the findings file and scratch tests are gitignored or untracked, as intended).

Outcome. The arithmetic in the pray contracts holds up. I found one low-severity defect in my area and nothing at medium or above.

What I checked, with results

• Hook fee math on all four paths. A fuzz over exact-input and exact-output buys, blessed sells and unblessed sells shows the hook fee equals the rate times the gross FWA side within 1 wei. Rounding goes against the user on gross-up paths and loses at most 1 wei on the sell-output path. The 90/10 split is exact, with remainder dust going to the vault.
• Launch decay. The buy fee is 4998 bps one second after launch, 103 bps at 1799 seconds, and 100 bps from 1800 seconds. It rounds upward along the curve as the README states.
• Delta accounting. I traced the specified-side and unspecified-side hook deltas through the vendored v4-core for both token orderings. The partial-fill equality check and the int128 guard behave as intended.
• Buyback floor. The time-weighted tick average, the sign-aware floor rounding, the sqrt-price squaring branches and the price-direction formulas are correct in both orderings. Measured output divided by floor is 1.0526, which is exactly the 95% margin.
• Buyback budget split. The spend and reward never exceed the budget, including at 201 wei and at the 50,000 FWA maximum. A budget below 201 wei reverts cleanly.
• Oracle question hash. I fetched three live oracle requests containing emoji, guillemets, an inverted question mark and newlines, and reproduced their published hashes with the registry's canonicalization. Escaping non-ASCII does not match, so the registry's raw-UTF-8 approach is the right one.
• Static-analysis leads. The flagged strict equality, unused getSlot0 return and the tick cast are all bounded or intentional. None became a finding.

The one finding (low). The 10% blessing cap in filePlea reads the seller's PRAY balance only at filing. Moving the same tokens to a second wallet lets that wallet file for another 10%, so one holding can be blessed k times with k pleas. The scratch test reproduces 20% of a single holding selling at 1% within one day. The suggested fix is to re-check the balance at grant or consume time, or escrow the pleaded PRAY.

Not reported, for lack of a reproduction. A plea whose text trips the oracle's wording screen would be refused without a callback, costing 0.5 IMD and locking the wallet's plea slot for 24 hours. The README documents the MEV exposure of the buyback during a sleeping swarm. Both are outside the math area and I could not verify the first against the live service.

Review complete. The findings file is written at .imd-findings.json with 4 findings and 22 coverage rows, every snippet verified against the tree, and the one proof test confirmed failing on current code.

What I covered

I traced all 18 verifier-listed entry points through the Execution Trace, Periphery and First Principles lenses, checking the hook's before/after-swap deltas against the vendored v4-core accounting, the router's sync/settle ordering, the vault's unlock commitment, the registry's attestation checks, and the canonical question-hash construction against the live oracle fixture. The existing 71-test suite passes, and my scratch probes confirmed the transient swap context resets correctly across multiple swaps in one unlock.

Findings (none above low)

• Low, src/Hook.sol:149. Any contract a blessed wallet transacts with during its 15-minute window can sell its own PRAY at 1% and consume the victim's blessing, because non-router sells are attributed to tx.origin. This follows the brief's "else tx.origin" rule, so I flagged the tradeoff and proposed an opt-in. Proof test attached and failing on current code.
• Low, src/BurnVault.sol:39. A 201-wei buyback passes every check and occupies the global 60-second cooldown, so dust calls can turn the 50,000 FWA burn rate into a priority-fee race.
• Low, src/PleaRegistry.sol:95. The 10%-of-balance cap is a filing-time snapshot; one actor moves the same stack through several wallets in one block and files for 10% from each.
• Info, src/Token.sol:6. The sinner tax exists only on the hooked pool. A standard ERC-20 can be sold on any second market with no plea, which the launch policy makes unavoidable but the README should state.

What held

Fee math on all four swap paths and the launch decay, the exact 90/10 claim split, callback authentication, question-hash binding across pleas, replay consumption, the 24-hour sleep and wake, blessing consumption bounds, buyback limits and burns, and the rule that no function moves FWA or PRAY to a caller-chosen address. The oracle callback stays under the 200k stipend in the cold case.

Not reached

Live Intake admission behavior (whether the wording screen refuses pleas) and the site's browser flows, both of which need network access I did not use for verification.

The review is complete. The findings file is written and validated, the scratch directory is removed, and the working tree contains no new files outside the findings file.

Outcome. Three substantiated findings in the Economic Security, Invariant and Flow Gap area, written to .imd-findings.json with a coverage row for all 18 entry points plus four invariants. The existing 71-test suite passes on the delivered code. The live oracle question-hash canonicalization reproduces with the captured fixture.

Findings

• Medium, PleaRegistry.filePlea. The 10% plea cap reads balanceOf only at filing time. The PoolManager lends the pool's PRAY reserve for free inside an unlock, so a contract can flash-take 9M PRAY, file for 1M against a real 1M holding, return the PRAY, and after approval sell 100% of its holding at 1%. Self-contained proof included; it fails on the current code with the whole bag taxed at 1% instead of a blended rate near 50%. The same snapshot lets one bag back several wallets' pleas by shuffling it between filings.
• Low, BurnVault.buyback. No minimum budget. A 2010-wei call every 60 seconds succeeds and resets the global cooldown, so every real buyback that minute reverts. Reproduced for four consecutive minutes with the vault's 90,000 FWA left unspent.
• Low, Hook.buybackFloor. The TWAP extends the last post-swap tick across any quiet period and references the newest observation at least 30 minutes old. One 20M FWA pump plus 30 silent minutes moved the floor from 9,286 to 4,799 PRAY per 10,000 FWA, and the buyback then burned 5,026 PRAY instead of at least 9,286. The 50% sell fee suppresses arbitrage, so the pumped price sustains itself.

What holds. Fee math on all four swap paths, the exact 90/10 claim split, hook delta neutrality, partial-fill protection, router and vault settlement, FWA transfer-rule compliance, treasury redemption to the fixed recipient, oracle callback checks, blessing consumption and expiry, and the sleep/wake rule all traced as intended.

Not reached. The mainnet fork rehearsal was not run (network), and the site was not reviewed beyond its economic claims.

Added adversarial, fuzz, invariant, and mainnet fork tests under test/.

• Build passed.
• Offline: 104 passed, 0 failed; optional fork suite skipped.
• Mainnet fork: 3 passed.
• Invariants: 49,152 random calls, 0 reverts.

No production defects confirmed. Implementation and configuration unchanged. Details in test/README.md.