I've built FolirPayments, the payment-receipt contract for the FOLIR test release on Sepolia. forge build, forge test and forge fmt --check all pass. I ran the tests with the job's fuzz seed and an empty environment. Nothing is committed: git has no author name or email set on this machine, and I didn't set one. The files are staged in the working tree.

How the contract works

• Price: 0.75 units of the approved test ERC-20, sent as 0.50 to the swarm-funding recipient and 0.25 to the treasury. A wallet holding at least one of the configured test identity NFTs pays only the 0.50 to swarm. A "unit" is one whole token, based on the token's decimals.
• No double payment: each receipt belongs to one wallet and one order ID. Paying the same pair again is refused. Because the wallet is part of the key, nobody can use up another wallet's order ID. Each receipt gets a running number, the amounts, the recipients, whether the discount applied, and a timestamp.
• Funds: tokens go straight from the payer to the recipients. The contract never holds tokens and refuses ETH. A failed or false-returning transfer cancels the whole payment, so no receipt is left behind.
• Start-up: the contract starts paused. unpause() refuses until the owner has set the payment token, both recipients (which must be different) and the identity NFT. Each of those setters is owner-only and emits an event.
• Owner: the launch owner is passed in at deployment as $owner, never the factory or tx.origin. Ownership transfers take two steps (offer, then accept). The constructor makes no calls to other contracts.

Tests (34): they cover the full and discounted payment splits, a payer losing and regaining the NFT, tokens with different decimals, duplicate and zero order IDs, the wrong or a replaced token, too little allowance or balance, the transfer failures above, a re-entry attempt, the pause rules, the setup checks, owner-only access and ownership transfer. A fuzz test checks that the payer loses exactly what the recipients gain. A deployment rehearsal deploys through a stand-in factory and confirms the owner is the launch owner and the compiled contract contains none of the forbidden instructions.

Files

• src/FolirPayments.sol
• test/FolirPayments.t.sol, test/Deployment.t.sol, test/mocks/Mocks.sol
• docs/abi/FolirPayments.json
• README.md: behaviour, deployment parameters, an "After launch" table, owner powers and assumptions, and who is responsible for what.
• foundry.toml (solc 0.8.26, bytecode_hash = "none"), remappings.txt, and lib/forge-std copied in as plain files.

Still open

• After launch: the brief gives no Sepolia addresses for the payment token, the two recipients or the NFT. The owner must set all four and then call unpause(), as the README's "After launch" table lists.
• Token assumption: the token must be a standard ERC-20 with no transfer fee. A token that takes a fee would deliver less than the receipt records.
• Not done: I didn't write a launch.json; that belongs to the manifest step. Slither and Mythril were not run. An independent security review is still required before release.

I found no math, precision, boundary or numerical defects in src/FolirPayments.sol, so .imd-findings.json has an empty findings list and a coverage row for each of the 9 entry points. All 9 are marked holds. The existing suite passes (34 tests, 0 failures), and I changed no files.

What I checked in the price math:

• Exactness: the price is 10**decimals times 50/100 for the swarm share and times 25/100 for the treasury share. Because setPaymentToken only accepts tokens with 2 to 36 decimals, 10**decimals always divides evenly by 4. Both shares are therefore exact: 0.50 and 0.25 units, and 0.75 in total.
• Overflow: the largest value is 10**36 * 50, far below the uint256 limit.
• Decimals: a decimals() value above 255 is rejected before it is narrowed to a uint8. A token that doesn't return decimals is also rejected.
• Discount: an identity NFT holder pays only the 0.50 swarm share, the treasury transfer is skipped, and the receipt stores address(0) as the treasury recipient.
• Duplicates: a receipt is keyed by payer and order id, so the same pair can't be paid twice. Payment amounts are recorded before the token transfers, and the nonReentrant guard blocks re-entry.
• Price changes mid-payment: pay requires the token argument to match the configured token. If the owner switches tokens (and so the decimals), a payment already in flight reverts rather than charging a different amount.
• Configuration: unpause requires the token, both recipients and the NFT to be set, and no setter can clear any of them back to zero.

Leads I looked at and didn't report:

• Fee-on-transfer tokens: the receipt would record more than the recipients actually received. The token is a test token the owner chooses, so this isn't a defect in this release.
• Shared identity NFT: one NFT passed from wallet to wallet gives each holder the discount in turn. The brief only requires holding the NFT at payment time, so this matches it.
• Static analysis: the missing zero-address check in transferOwnership is intended, since passing zero cancels a pending transfer and can't make the owner zero. The other lines aderyn reported are style or by-design centralization and don't show a defect.

Everything in my area is covered. The only extra coverage row I added is a check that each receipt's recorded amounts match what was transferred.

Created launch.json with FolirPayments and constructor argument "$owner". Checked its structure and arguments against the accepted source and compiled ABI.

forge build succeeded; all 34 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

I found three low-severity defects in src/FolirPayments.sol and nothing critical, high or medium. They are written to .imd-findings.json with a coverage row for each of the 9 entry points plus 2 invariants. No tracked files changed, and I deleted my scratch tests from test/scratch/ after running them.

Findings (all low)

1. The identity-NFT setter accepts the payment token (setIdentityNft, line 271). The setter only checks for a non-zero address with code. If the owner sets it to the payment token, every payer counts as an NFT holder, since they must hold the token to pay at all. Every payment then gets the 0.50 price and the treasury gets 0. A scratch test confirmed it: the treasury received 0 instead of 0.25. Fix: reject the payment token's address here, or require the NFT to report itself as ERC-721 (ERC-165).

2. The recipient setters accept the contract's own address (setSwarmRecipient and setTreasuryRecipient, line 255). If a recipient is set to the contract itself, payments still succeed and receipts are recorded. The tokens then stay in the contract for good because it has no withdraw function. This breaks the "never holds funds" promise in the contract's own comments. A scratch test confirmed 0.5 tokens locked in the contract. Fix: reject address(this) in both setters.

3. pay() has no maximum-price limit (line 161). The price is worked out when the payment executes, not when the payer saw the quote. Say a payer is quoted 0.50 as an NFT holder and has approved more than that, such as an unlimited approval. If the owner switches the identity NFT before their transaction is mined, they are charged 0.75. A scratch test confirmed it. Fix: add a maxTotal argument to pay and revert when the charge exceeds it.

Findings 1 and 2 need the owner to make a configuration mistake, which is why they are rated low. Each carries a Foundry proof that fails on the current code and passes once the setter rejects the bad address. Finding 3 has no proof test because fixing it changes the function signature, so it has a written reproduction instead.

Coverage

• Holds:
  • pause, unpause, acceptOwnership
  • setPaymentToken: decimals limited to 2–36, and the payer names the token, which blocks an overcharge from a token swap.
  • transferOwnership: the static-analysis zero-address warning is rejected, because passing zero only cancels a pending transfer.
  • Duplicate-receipt prevention, reentrancy protection, the order of state updates before transfers, and handling of tokens that return false or nothing.
• Finding: pay, setIdentityNft, both recipient setters, and the "contract holds no funds" invariant.
• Not reported: fee-on-transfer tokens, lending an NFT to get the discount, and blacklisting tokens blocking payments. The README already documents these as accepted assumptions.

The existing 34 tests pass. Separately, the working tree had untracked files I didn't create (.bashrc, .gitconfig, .mcp.json, .claude/ and others). I left them alone.

The findings file is in place and the harness itself excludes it from git, so the tree is otherwise untouched. The review is complete.

Outcome: FolirPayments is sound against every non-owner action. Nobody but the payer can move the payer's tokens, duplicate receipts are impossible, quote and pay share one code path, and the reentrancy, pause and two-step ownership guards hold. The three items I recorded are all owner-misconfiguration gaps or manifest notes, none critical or high, so no proof tests were attached.

Findings written to .imd-findings.json:

• Low. Recipient setters accept the contract's own address. Setting the swarm or treasury recipient to FolirPayments itself passes every check and unpause, and the contract has no function to move tokens out. Each payment then strands that share permanently. Reproduced with a scratch test.
• Low. setIdentityNft does not probe balanceOf. Unlike setPaymentToken, which calls decimals() and range-checks it, this setter only checks for code. A contract without balanceOf passes and unpause succeeds, after which every pay and quote reverts. Passing the ERC-20 payment token itself gives every token holder the discount. Both states reproduced.
• Info. README hard-codes a launch-owner address the brief never states. The manifest must use $owner, which the README also says, but the literal has no provenance in the tree.

Coverage has 16 rows covering all nine listed entry points plus the constructor, receive/fallback, three invariants, the internal helpers and the ABI export. The slither zero-check lead on transferOwnership was rejected as intentional cancel behaviour. The exported ABI is identical to the compiled one, and the existing 34 tests and forge fmt --check pass.

Not reached in depth: nothing in the assigned area. The protected owner-check floor (OwnerChecks.sol) is not in the tree, so its exact assertions could not be read, though the constructor satisfies what the Owners test describes.

The review is complete and written to .imd-findings.json. No source files were changed, and the scratch tests were removed.

Outcome: no critical, high or medium defects in the permission model. The owner role is the only privileged actor, every setter and pause path is onlyOwner, ownership transfer is two-step and cannot be bricked, pay only ever spends the caller's own allowance, and the ABI export in docs/abi/FolirPayments.json matches the compiled artifact exactly. The existing 34 tests pass.

Findings recorded, each reproduced with a Foundry test before being written up:

• Low. Identity NFT setter is asymmetric with the token setter. setPaymentToken probes decimals() before storing, but setIdentityNft accepts any address with code. A contract without balanceOf passes unpause, after which every pay and quote reverts with empty data. Owner-only misconfiguration, so low.
• Low. The payer pins the token but not the price. If the owner swaps the identity NFT while a discounted payer's transaction is pending, a payer with an over-approval is charged 0.75 instead of the quoted 0.50. The README documents this as a trust assumption. A maxTotal parameter on pay would close it without changing the design.
• Info. Recipients may be set to the contract itself. There is no sweep, so tokens sent there are stranded.
• Info. quote ignores paused, so the frontend can show a price whose payment then reverts.
• Info. README and tests hard-code an owner address the brief never names. The manifest step must still write $owner, and the paying wallet should be confirmed against that literal.

The coverage record answers all nine entry points plus four invariants and the deployment path. The one unreached row is launch.json, which does not exist in the tree yet, as expected at this stage. The Slither zero-check lead on transferOwnership was examined and rejected because passing zero is the documented cancel path.

Done. The test deliverable is complete and verified.

What I added (all under test/, nothing else touched):

• test/FolirPayments.invariants.t.sol: a handler that drives FolirPayments with four payers, four tokens of 2, 6, 18 and 36 decimals, two NFT collections, two owner candidates and strangers. Every handler call predicts its outcome from pre-call state and asserts it, including the exact revert error and arguments. Nine invariants check that the contract never holds tokens or ETH, that payer losses equal recipient gains per token, that receipt numbers are dense and receipts never change after being written, that amounts are exactly half and a quarter of a unit, that isPaid matches the ghost record, that unpaused implies configured, that recipients never collide, and that ownership only rests with a candidate who accepted. It runs from the post-launch state with inline config of 256 runs and depth 48.
• test/FolirPayments.edge.t.sol: 45 unit, boundary and fuzz tests. They cover decimals at 0, 2, 36 and above 255, malformed decimals() and transferFrom return data, reverting tokens, fee-on-transfer tokens, allowance and balance exactly one wei short, reentrancy through the second transfer and through the NFT's balanceOf, a contract payer, ETH rejection with calldata, recipient and token changes mid-flight, ownership replacement and replay, and a one-call deployer that proves the deployer cannot configure the contract.
• test/mocks/EdgeMocks.sol: the adversarial tokens, NFTs and payer those tests need.

Results with the verifier's fuzz seed:

A scratch probe confirmed every handler sequence produces successful, discounted and failed payments.

Findings went to .imd-findings.json. I found no critical or high defect. Four low and info items are reported with reproductions rather than asserted as correct: setIdentityNft accepts any contract and so can block all payments until replaced, pay has no price ceiling so a payer with an unlimited allowance can be charged the standard price after quoting the discount, fee-on-transfer tokens produce receipts that overstate delivery, and the transfer-failure error drops the token's own revert reason.

The review is complete. The findings file is written and valid, and both it and the scratch tests are excluded from the tree by the repository's own ignore rules, so no tracked file changed.

Outcome. FolirPayments has no critical, high or medium defect. The existing 80-test suite passes, the exported ABI in docs/abi is identical to the compiled ABI, and launch.json is correct: it has only kind, contracts and notes, with the single constructor argument written as $owner. The constructor takes one address, makes no external calls and assigns the argument rather than the factory, so the CREATE2 deployment model holds.

Findings kept, all reproduced in a scratch Foundry test that passes against the current code:

1. Low. setIdentityNft validates nothing beyond code presence. Merged from four specialists. A contract without balanceOf is accepted, after which every pay and quote reverts with empty data while the contract reports configured and unpaused. Setting the identity NFT to the payment token itself is also accepted, and then every payer is discounted and the treasury receives nothing. The accompanying specialist proof fails on this code as stated.
2. Low. Recipient setters accept the contract's own address. Merged from three specialists. A payment then moves tokens into FolirPayments, which has no withdrawal function, so the share is stranded permanently while the receipt reports it paid. The specialist proof fails as stated.
3. Low. pay pins the token but not the price. Merged from three specialists. A payer quoted the 0.50 holder price with a standing allowance above it is charged 0.75 if the owner swaps the NFT collection first. Bounded to 0.25 units per order.
4. Info. quote ignores the paused flag, so the website can prompt an approval for a payment that will revert.
5. Info. The README pins a concrete owner address the brief never states. Downgraded because the manifest correctly uses $owner, so this is documentation only.

Dropped. The fee-on-transfer and hidden-revert-data leads reproduce but are documented operator assumptions and design choices with no loss under a compliant token. The slither missing-zero-check on transferOwnership is intentional, since passing zero cancels a pending transfer.

Coverage. All nine entry points are answered, plus rows for receipt uniqueness, custody and reentrancy, deployment, and ABI parity. No proof files were attached because no finding reaches high severity.

Implemented FOLIR’s frontend, static export, and deployment manifest.

• Build, typecheck, integrity checks, and 20 Chromium interaction suites passed.
• Export: 0.90 MB; submission files remain below 8 MiB.
• Live payments await owner configuration. No transactions were broadcast.
• WebKit could not launch because system libraries are missing.

See validation, setup, and design documentation. Design documentation is under docs/ because root writes were prohibited.

Review complete. The findings file holds four substantiated findings, none high.

Requirements

• "English React/TypeScript user interface": met, web/src/*.tsx with Vite and TypeScript.
• "exactly three steps: Add your wallet, Choose and pay, Get your analysis": met, the ordered list in web/src/App.tsx.
• "Connect to the deployed Sepolia contract using its real address and ABI": met. The page loads dist/imd-deployment.json at runtime, fetches the ABI it names, checks its keccak against the handoff hash, and rendered live state in the probe (owner awaiting setup, 0 receipts, current block). Address, chain, abiHash, sourceCommit and attestationHash match the handoff exactly.
• "Show test-payment state and receipts": met, Payment panel status line and quote, Receipts lookup by number or by wallet and order ID.
• "clearly labelled synthetic crypto, tokenized-stock and NFT data": met, five fixed assets in web/src/sample.ts, labelled synthetic on every surface.
• "allocation, history, gains/losses, risks/news, expandable assets, conditional scenarios and optional Tax": met, Overview, Scenarios, Activity and Tax views plus the Risks section in web/src/components/Portfolio.tsx.
• "restrained ivory/terminal design, responsive on mobile": met, Inter and IBM Plex Mono, ivory tokens, no horizontal scroll at 320, 390 or 1440.
• "No real investment research or customer charges": met, stated on the payment panel and footer.
• Manifest and assets: met. All 17 asset hashes verify, no unlisted or extra files, only the allowed top-level keys, and no poolKey because the handoff has none.
• Wallet connection, wrong-network switch and add-chain: met in web/src/components/Wallet.tsx and web/src/config.ts, not exercised since no wallet is available here.
• GitHub publication and the IPFS URL: after review.
• Owner configuration of token, NFT and recipients: needs the requester. The contract on Sepolia is still paused and unconfigured, and the page says so honestly.

The idea. A quiet ivory ledger: one payment card on the left and the sample portfolio chart on the right, with mono numbers doing the only decoration.

Findings in .imd-findings.json:

• Medium bug. The primary button in Choose and pay is disabled yet reads "Add wallet to continue" for every first visitor, and contradicts the status line while the contract awaits setup. Measured at 390: disabled, inside the first screen.
• Medium taste. The hero subline gives two orders instead of one sentence saying what FOLIR is. Replacement copy supplied.
• Low taste. A second slogan sits in the footer of a tool page. Delete it, the fact line beside it stays.
• Low taste. At 390 the price label wraps to "Test payment / total" because of a 100px max-width in the stylesheet.

WebKit was not available on this machine, so the interaction walk ran in Chromium only. The CSS uses only features Safari supports, and nothing points at a WebKit-specific failure.