Approved workflow

Verified against the delivered source (forge test, Solidity 0.8.26). id = openProposal(keccak256("t"), now+1h, now+2h); salt = keccak256("salt"); alice commits the brief's preimage commitVote(id, keccak256(abi.encode(true, salt)), 100 ether) -- accepted, 100 QRM transferred in. warp to now+1h; alice calls revealVote(id, true, salt).

Expected per workflow.md: the vote counts.

Actual: reverts InvalidReveal(). forVotes and againstVotes stay 0, alice's balance stays 900 ether, and the 100 QRM remain locked until revealDeadline (now+2h) before reclaim() returns them. keccak256(abi.encodePacked(true, salt)) fails identically.

Three independent mutations of the delivered source, each run with forge test on the unmodified test/ directory; all three leave 17 passed / 0 failed.

1. Delete all four emit statements from src/CommitRevealVote.sol (ProposalOpened, VoteCommitted, VoteRevealed, TokensReclaimed) -- 17 passed.
2. Replace line 118 with emit VoteRevealed(proposalId, msg.sender, !choice, 0); so every reveal logs the opposite choice and zero weight -- 17 passed.
3. Delete emit Transfer(address(0), msg.sender, totalSupply); from src/Quorum.sol:19 so the token mints 1,000,000,000 QRM with no ERC-20 log -- 17 passed. Expected: at least one test fails in each case.

Mutate src/CommitRevealVote.sol to invert the order in both custody functions: in commitVote move if (!token.transferFrom(...)) revert TokenTransferFailed(); above ballot.commitment = commitment; ballot.amount = amount;, and in reclaim move if (!token.transfer(msg.sender, amount)) revert TokenTransferFailed(); above ballot.reclaimed = true;.

Run forge test.

Expected: testRejectsCommitReentrancyAndRollsBackState / testRejectsReclaimReentrancyAndFalseTransfer fail.

Actual: 17 passed, 0 failed.

id = openProposal(keccak256("t"), now+1h, now+2h). alice commits 500 ether FOR, bob commits 10 ether AGAINST. warp to now+1h; bob reveals (againstVotes == 10 ether, publicly readable). alice reads the tally, sees her side would win and that she prefers the proposal to fail, and simply never calls revealVote. warp to now+2h; alice calls reclaim(id).

Result: forVotes == 0, againstVotes == 10 ether, alice's QRM balance is back to its full 1000 ether.

She paid nothing to remove 500 ether of committed weight from the outcome after seeing the other side.

Verified against unmodified src/ (test passes):

id = vote.openProposal(keccak256("p"), uint64(block.timestamp + 60), type(uint64).max); // ACCEPTED, no revert

prank(alice); vote.commitVote(id, keccak256(abi.encode(true, bytes32("s"))), 1000 ether);

warp(block.timestamp + 1000 * 365 days);

prank(alice); vote.reclaim(id);

Actual: reverts TooEarlyToReclaim() after 1000 simulated years; balanceOf(alice) == 0 and the 1000 QRM sit in the contract forever.

Expected: openProposal rejects a reveal deadline beyond a sane maximum horizon, or the voter retains some path back to their stake.

Both verified against unmodified src/ (tests pass):

(a) unrevealable reveal window

t0 = block.timestamp;

id = vote.openProposal(keccak256("p"), t0 + 120, t0 + 121); // ACCEPTED

prank(alice); vote.commitVote(id, keccak256(abi.encode(true, bytes32("s"))), 600 ether);

warp(t0 + 119); prank(alice); vote.revealVote(id, true, bytes32("s")); // reverts RevealPhaseClosed()

warp(t0 + 121); prank(alice); vote.revealVote(id, true, bytes32("s")); // reverts RevealPhaseClosed()

Actual: with 12s slots landing at t0+108 / t0+120 / t0+132, any deadline pair not aligned to the slot grid leaves zero mineable blocks in [t0+120, t0+121); forVotes + againstVotes stays 0 forever while 600 QRM were locked.

Expected: openProposal rejects a reveal window shorter than some minimum that guarantees at least a few blocks.

(b) unvotable commit window

id = vote.openProposal(keccak256("p"), uint64(t0 + 1), uint64(t0 + 1000)); // ACCEPTED

warp(t0 + 12); // the next block on a 12s chain

prank(alice); vote.commitVote(id, keccak256(abi.encode(true, bytes32("s"))), 1 ether);

Actual: reverts CommitPhaseClosed() — no block after creation can ever commit.

Expected: a minimum commit window is enforced.

Run the delivered suite: forge test gives 12 passing tests. Now apply either mutation to src/Quorum.sol and re-run — the suite still reports 12/12 passing, i.e. the tests do not detect it:

(1) delete line 44 require(to != address(0), "ERC20: zero recipient"); -> suite still passes; token.transfer(address(0), 1) now silently burns.

(2) change line 35 if (permitted != type(uint256).max) to if (true) -> suite still passes even though infinite approvals now decrement.

A test asserting vm.expectRevert(bytes("ERC20: zero recipient")); token.transfer(address(0), 1);, a self-transfer balance-preservation check, and assertEq(token.allowance(alice, address(vote)), type(uint256).max) after a commit would close the gap. For the misnamed voting test, a second actor funded with 1 ether but approving type(uint256).max and calling commitVote(id, c, 2 ether) reaches the balance underflow that 0xBAD never reaches.

Baseline: forge test --offline on the unmodified tree gives 17/17 passing.

Apply any one of these four single-line mutations to src/CommitRevealVote.sol and re-run — the suite still reports 17/17 passing, i.e. it detects none of them (all four verified in a scratch copy of the tree): (1) line 86: delete emit ProposalOpened(proposalId, msg.sender, titleHash, commitDeadline, revealDeadline); -> no proposal is ever announced; a frontend that enumerates proposals from logs sees nothing.

(2) line 100: change emit VoteCommitted(proposalId, msg.sender, commitment, amount); to emit VoteCommitted(proposalId, msg.sender, bytes32(0), amount); -> every commitment is logged as zero.

(3) line 118: change emit VoteRevealed(proposalId, msg.sender, choice, ballot.amount); to ... choice, 0); -> every reveal is logged with zero weight while the on-chain tally is correct, so a log-derived tally shows 0/0.

(4) line 131: change emit TokensReclaimed(proposalId, msg.sender, amount); to ... address(0), amount); -> refunds are attributed to the zero address.

Expected: at least one test fails for each.

Actual: 17 passed; 0 failed in all four cases.

Contrast: mutating the tally direction at line 116-117, >= to > at line 92, < to +1 < at line 124, or deleting the AlreadyCommitted guard at line 96 each does fail the suite, confirming the gap is specific to events.

Verified against unmodified src/ with solc 0.8.26: t0 = block.timestamp; id = vote.openProposal(keccak256("title"), uint64(t0 + 1 hours), uint64(t0 + 2 hours)); prank(alice); vote.commitVote(id, keccak256(abi.encode(true, keccak256("alice"))), 600 ether); // brief's literal preimage: ACCEPTED, 600 QRM transferred in; warp(t0 + 1 hours); prank(alice); vote.revealVote(id, true, keccak256("alice")); Actual: reverts InvalidReveal() because line 113 hashes (id, alice, true, salt); proposals(id) stays (forVotes 0, againstVotes 0) and alice cannot recover the 600 QRM until t0 + 2 hours.

Expected by a brief-following client: the reveal is accepted and 600e18 lands in forVotes.

The correct client-side commitment for the same ballot is keccak256(abi.encode(id, alice, true, keccak256("alice"))), which I confirmed reveals successfully in the same scenario.