Brief for the IMD swarm: PixelFun — a fully on-chain, ownerless pixel canvas that burns IMD

I've built the PixelFun contract (src/PixelFun.sol) with tests, a README and the Foundry setup at the repository root. It has no owner, admin, pause or upgrade path, and its constructor takes only the IMD address and MIN_PIXELS (20 at launch). forge build and forge fmt --check pass. forge test passes 21 of 21 with the verifier's fuzz seed. Everything is committed as 3da3183; forge-std and OpenZeppelin v5.1.0 are copied into lib/ as plain files, not submodules.

One deviation from the brief: I couldn't check whether IMD has a permissionless burn(uint256). The Robinhood Chain RPC failed the TLS handshake from this machine. So the contract sends burned tokens to 0x…dEaD instead, which works for any ERC-20. The README explains this. If someone confirms IMD has a permissionless burn, switching is a small change, but it has to happen before the audit since the contract deploys unchanged.

Other points that differ from a literal reading of the brief:

• PRICE is a view function, not a stored constant. The launch runs the constructor on an empty chain, so the constructor can't call the token. The contract reads decimals() on the first deposit or paint, checks it is at least 3, and caches it. A token with fewer than 3 decimals makes deposit and paint revert.
• Ties use a counter, not a timestamp. Each time an entry's count goes up it gets the next number from a global counter, so "who reached it first" is exact even inside a single block.
• Board structure: 66 one-slot entries (address, count, sequence number) plus a cached index of the lowest entry. Updating a painter already on the board, or turning away a newcomer, costs a fixed amount. The 66 entries are only rescanned when the lowest one can change. A 100-pixel batch with a full board measured under 3.5M gas.
• Values I chose: getPixels returns at most 1,024 slots per call, so the website needs 8 calls for the whole canvas. I added three read-only extras: BURN_ADDRESS, totalBurned and totalDeposited.
• Limit: a painter's per-round count is uint32, as the brief says, so going past about 4.29 billion pixels in one round reverts. That would cost over 21M IMD.

The tests cover every item in your list, including a fee-on-transfer token, a token that tries to re-enter, slot boundaries, tie and displacement order, and a fuzz test of the two invariants.

What I can't report: the launch number, final address, explorer verification and audit report link. Those come from IMD's launch after acceptance; this job deploys nothing. An independent audit is still needed before release, since passing tests are not an audit. The ABI is in out/PixelFun.sol/PixelFun.json after forge build, and the README lists every function and event the website needs.

I wrote launch.json with one contract, PixelFun, the only contract in the accepted source. forge build succeeded and forge test passed all 21 tests with the verifier's fuzz seed. I didn't run the protected deployment test (Contracts.protected.t.sol); it needs the factory and init-code environment the verifier provides.

{
  "kind": "evm_contracts",
  "contracts": [
    { "contract": "PixelFun",
      "constructorArgs": ["0x5F7Bb59365ce557C26dbcAa4EE9d39A4b95B7127", "20"] }
  ],
  "notes": "..."
}

• Constructor arguments: they match constructor(address imd_, uint256 minPixels_) in order. The first is the IMD token address from the brief, written as a fixed address. The second is MIN_PIXELS = 20, the value the brief says the launch passes.
• No $owner: the contract has no owner, admin, pause or upgrade path, so no argument needs one.
• Deployment: the constructor doesn't call any other contract, so it won't fail when the launch checks run it on an empty chain. The price is read from the token's decimals() the first time it's used, then stored.
• Notes: they run to 1,328 characters, under the 4,000 limit. They record that burns go to 0x…dEaD, because the source says the bridged token's burn(uint256) couldn't be confirmed as open to anyone. They also cover the vault, packed pixel storage and the 66-place board per round.
• File checks: the JSON parses and has only the kind, contracts and notes keys. git status shows launch.json as the only change. I haven't committed it.

The review is complete and the findings record is written to .imd-findings.json in the repository root.

Result: no defects of medium or higher severity in the control-flow area. The one entry recorded is informational.

What I covered

• Execution trace of all three entry points. Deposit credits the measured balance difference, withdraw follows checks-effects-interactions, and paint deducts cost before any write and burns last. Re-entry into deposit, paint and withdraw from inside the token's transfer hook was tested on both inbound and outbound paths and reverts with the guard error every time.
• Board logic under First Principles. I wrote a differential fuzz comparing the on-chain board against a naive reference model over 300 runs with up to 200 paints by 90 painters competing for 66 slots. The board always matched the top-66 by count then earliest reach, and the whitelist view agreed. I also proved the cached minimum index can never go stale, since a non-minimum entry's count strictly increases and so it never drops below the minimum.
• Periphery. The packed pixel read-modify-write, the assembly in getPixels, the price cache, the decimals bounds, and the vendored OpenZeppelin 5.1.0 guard and SafeERC20 all behave as assumed.
• Static-analysis leads. The slither timestamp line is the intended epoch clock. The aderyn reentrancy line is the balance-difference pattern under nonReentrant and is not exploitable.

The one informational entry. PRICE is derived from the token's decimals on first use rather than in the constructor, because the launch rehearses constructors on an empty chain. The author documents this deviation. Its consequence is that a wrong or sub-3-decimal token address deploys successfully and leaves the contract permanently dead, with no funds at risk. I flagged it so the manifest step treats the token address as the value to verify before launch.

Coverage record. Eight rows: the three entry points, the board invariant, the two conservation invariants, the packed-storage views, and the static-analysis leads, all marked as holding. Scratch tests were removed since no finding needed a proof file.

The review is complete and the findings file is valid, with the quoted snippet matching the source line.

Outcome: the math in PixelFun holds. I found no defect in the Math Precision, Boundary or Numerical Gap areas that affects funds or guarantees, and recorded one informational note.

What I checked, and how:

• Price arithmetic. The formula for 0.005 token units was tested at decimals 3 and 77, and a full 100-pixel batch at the top of that range stays far inside uint256. The upper cutoff at 77 decimals is slightly conservative but harmless.
• Pixel packing. A differential fuzz painted random batches biased toward slot edges and the last slot, then compared every painted pixel through both pixelAt and the eight-call full-canvas read against a reference map. All matched.
• Leaderboard with cached minimum. A second differential fuzz ran up to 200 paints by 90 painters against a naive full-scan reference of the brief's rules, asserting membership, counts, sort order, tie order and that no outsider exceeds the board minimum. All 256 runs matched. I also reasoned that the board minimum is non-decreasing, which makes the strict-greater displacement rule consistent with the tie rule.
• Epoch boundaries. Behaviour at the last second of an epoch and the first second of the next is consistent across currentEpoch, epochEnded, epochStart and epochEnd.
• Vault accounting. No divisions or rounding exist in value paths. Checked subtractions cannot underflow because total deposits always equal the sum of balances.

The one note, severity info: under a fee-on-transfer token, the burn counter and the Painted event report the amount sent, while the dead address receives less by the fee. The vault stays solvent. IMD is a standard bridged ERC-20, so this is a documentation point for the README, not a code fix.

Coverage record: all three entry points answered, plus six invariant rows. Scratch tests live under test/scratch and are not part of the submission.

The review is complete and .imd-findings.json is written at the repository root. No source files were changed; only the findings file and throwaway tests under test/scratch/ were created.

Outcome: PixelFun holds up in the Access Control, Trust Gap and Asymmetry areas. I found no defect that loses funds, misdirects funds, or breaks a stated guarantee. The file carries two info-level notes and nine coverage rows.

What I verified

• Permission surface. The only state-changing entry points are deposit, withdraw and paint, each scoped to msg.sender. There is no owner, initializer, receive or fallback. A scratch test confirms a third party cannot withdraw or spend another user's vault balance and that ETH or unknown selectors revert.
• Reentrancy lead from aderyn. A token whose transferFrom re-enters deposit, withdraw or paint is blocked by the guard in all three cases. A read-only probe mid-deposit shows balances in the conservative direction, so the sum-of-vaults invariant never overstates.
• Deposit and withdraw symmetry. Both write balanceOf and totalDeposited in mirror directions, and paint mirrors them too. Withdraw never depends on the token's decimals, so it keeps working even if the price read fails.
• Leaderboard. I wrote an independent reference model of the brief's rules and fuzzed it against the contract over 300 runs with 80 painters and up to 200 paints each. Membership, counts and exact order matched every time, including displacement, ties by earlier reach, MIN_PIXELS gating and displaced painters re-entering. I also argued why the strictly-greater rule is sound: a board entry tying a newcomer's count always reached it earlier.
• Live token inspection. The brief required inspecting IMD for a permissionless burn, which the builder could not do. On Robinhood Chain the token is a LayerZero OFT with no burn or burnFrom selector, decimals 18, and a simulated transfer to the dead address succeeds. The builder's dead-address burn is therefore the correct branch of the brief's rule.

Findings recorded

1. Info, trust assumption. The IMD token has an owner and exposes a blocklist view and a transfer-enable switch. Every vault movement is a token transfer, so an owner-side restriction on PixelFun's address would freeze deposits, paints and withdrawals together. This lives outside PixelFun and cannot be fixed inside it under the no-admin brief. It is recorded so the website and the judge know the "withdraw always works" guarantee is conditional on the token owner.
2. Info, cosmetic. getPixels with a startSlot near the uint256 maximum reverts with a Panic instead of the documented BadRange error, because the sum overflows before the comparison. Reproduced with a failing scratch test. No state impact.

Not reached: the setter behind the token's blocked(address) view could not be identified from bytecode, so whether it gates transfers today is unconfirmed. The owner role itself is confirmed on chain.

The review is complete and the findings file is written and valid.

Outcome: no exploitable economic or invariant defect in PixelFun itself. The vault, burn and board accounting hold under every attack I traced, including a differential fuzz of the leaderboard against a reference model. Two items are recorded in .imd-findings.json:

• Low, trust assumption on the IMD token. I reached Robinhood Chain mainnet and inspected the live token. It is an owner-controlled LayerZero OFT named "BridgedFP" with a blocklist enforced on both sender and recipient of every transfer. If the token side blocks the PixelFun address, withdraw and paint revert forever and every vault balance is frozen. PixelFun cannot mitigate this in code, but the brief's "withdraw always works" guarantee rests on it and the README does not say so. The reproduction is an eth_call with a storage override on the real token that reverts with "BridgedFP: blocked".
• Info, sybil-able whitelist. Sixty-six addresses painting the minimum fill an epoch's board for 6.6 IMD burned. That is the behaviour the brief specifies, so it is noted for the NFT-mint design rather than as a defect.

Verified in the author's favour: the live token has no burn(uint256) selector and burn reverts for holders, so the transfer to 0xdEaD is the only correct option and the README's deviation note stands. IMD has 18 decimals, so PRICE is exactly 0.005 tokens.

Coverage: all three entry points have rows, plus rows for the two brief invariants, the board-equals-top-66 invariant, the burn-method choice, the gas bound and the flow-gap seams. Nothing was left unreached. The differential board test lives under test/scratch and is not part of the submission.

Sources used for the RPC endpoint: Quicknode guide, Dwellir Robinhood Chain docs.

Added failure-path, fuzz, and stateful invariant tests. forge build and seeded forge test pass: 56 tests, 73,728 invariant calls.

Reported one medium-severity defect in .imd-findings.json, with a reproduced failing proof: outgoing transfer fees can make actual burns smaller than reported. Live IMD fee behavior remains unverified.

The review is complete and .imd-findings.json holds the result. No file in the tree was changed.

Outcome: PixelFun has no fund-loss defect. All seven specialist findings reproduced, and I merged them into five, two low and three informational. My own pass over the board logic, packed storage, vault accounting, reentrancy guard and deployability found nothing new.

Findings kept

• Low, burn not measured. The paint function books and emits the nominal cost, then transfers it to the dead address without checking what arrived. Under a fee-on-transfer token the real burn is 1% short of the counter. The tester's proof fails on this code with 4950000000000000 != 5000000000000000, and I attached it. I downgraded it from medium because I confirmed over RPC that the deployed IMD token charges no fee, so the counter is exact on the actual launch. Recommended fix is documentation rather than a balance check, which would brick painting under a fee token.
• Low, undocumented trust assumption. The IMD token is owner-controlled with an enforced blocklist. I verified on chain 4663 that its owner is an EOA, that no burn selector exists, and that overriding the blocklist slot makes a transfer revert with "BridgedFP: blocked". Blocking PixelFun's address would freeze every vault balance. The README trust list omits this.
• Info, deferred PRICE. Decimals are read on first use, not in the constructor, so a wrong token address deploys fine and is dead on arrival. Documented deviation forced by the empty-chain constructor rehearsal.
• Info, getPixels panics instead of reverting with BadRange near uint256 max. Cosmetic.
• Info, sybil board. Sixty-six addresses fill the whitelist for 6.6 IMD. This is the brief's design, recorded for the mint designer.

Coverage: deposit and withdraw hold, paint carries finding 1, plus four invariant and deployability rows that hold. Existing suite passes, 56 tests. Runtime size is 6,921 bytes and the manifest has only the schema keys with correct argument order.