Approved workflow

registerMembers is permissionless and irreversible. ProjectFactory makes no initialization calls, so TipSplitter goes live on Sepolia with members.length == 0 and the member list is decided by whichever externally-owned account lands the first successful registration, using as little as 1 SPLT base unit.

This matches the approved brief ('a member list is fixed by the first depositor's call'), so it is NOT a blocking implementation defect and must not be fixed unilaterally - but it is the one privileged role in the system, it is unassigned at deployment, and it is awarded by transaction ordering rather than by policy.

The deployment sequencing makes the window unavoidable: the entire 10^27 supply mints to the factory, the policy split then distributes SPLT, and every recipient of SPLT is a candidate first registrant. README.md documents the hazard ('Registration is permissionless and can be front-run'), which is why this is filed as a trust-assumption observation and not as a code bug.

Resolving it would require changing the agreed design (e.g. moving the member list into the TipSplitter constructor as bytes32/address arguments, which the manifest could supply), so it is a scope decision for the workflow owner, not a change the source author may make.

Operational mitigation that needs no redesign: the deployment service must submit the registration transaction from the coordinator's address as the first transaction against the contract, and the admission/frontend steps must read getMembers() and refuse to publish until it equals the intended list.

The member validation rejects address(0) and address(this) but not address(token).

Because the list is permanent and there is no membership editor, registering the SPLT address - by a copy/paste of the token address into the members field, which is a plausible mistake in a UI that asks for the token address on the same screen - routes that member's entire lifetime entitlement into the token contract's own balance, where nothing can move it (Splitwise has no owner, no sweep and no burn path).

The asymmetry is the defect: the contract already performs self-referential address validation, so the omission reads as an oversight rather than a decision, and neither the unit suite nor docs/ABI.md treats address(token) as an invalid member - test/TipSplitterAdversarial.t.sol deliberately registers address(token) as a member, so the existing suite cements the behaviour instead of flagging it.

Same class, not fixable in-contract: a member address that is a contract with no way to call claim() locks its share too; README.md already documents that case.

Only registerMembers/deposit increment totalDeposited, and claimable() is derived from totalDeposited rather than from the token balance. A plain token.transfer to the TipSplitter address therefore creates no claim rights, and because the contract has no sweep, owner or rescue path, those tokens are locked forever.

This is the documented and intended accounting model (README.md 'Use the deposit functions', docs/ABI.md warns the frontend), and it is the correct choice for this design - donation-crediting would break the exact-deposit check at src/TipSplitter.sol:106. It is filed so the reviewer of the website contribution has it in writing: 'tip' in a wallet UI most naturally maps to a transfer, and this is the single highest-probability way a real user loses funds on this deployment.

The frontend review must confirm the tip flow is approve + deposit(uint256) and never transfer(splitter, amount), and the published address should carry a 'do not send tokens directly' warning.

claimable() is floor(totalDeposited / members.length) - claimed[member], so at any instant totalDeposited % memberCount base units are held by the contract and owed to no one. Remainders correctly carry forward across tips rather than being discarded per-deposit (confirmed by fuzzing: after every member drains, the residual is always < memberCount), so the loss is bounded at memberCount - 1 base units - at most 9 wei of an 18-decimal token, economically negligible.

It is reported because the stranding is permanent once tipping stops and there is no sweep, and because there is a user-visible intermediate state the UI must not misrepresent: with 10 members, any tip below 10 base units makes claimable() zero for everyone while the pool balance is non-zero, so a naive 'your share' display derived from balance rather than claimable() will show a claimable amount whose claim() reverts with NothingToClaim.

Every deposit path in the suite is funded from a wallet that never re-deposits what it claimed, so totalDeposited is always bounded by the 10^27 supply. In production nothing bounds it: a member can claim and tip the same SPLT back, so totalDeposited is a lifetime counter that grows without limit and is decoupled from both the pool balance and the token supply.

This matters because claimable() divides that unbounded counter, so a reviewer cannot tell from the committed suite whether entitlement accounting still holds once totalDeposited exceeds the supply.

This is a coverage observation, not a defect: I fuzzed the recycling case (512 runs, 1-10 members, eight interleaved deposit/claim/redeposit rounds) and solvency held in every run, with token.balanceOf(splitter) == totalDeposited - totalClaimed exactly and the final residual always below memberCount. The stateful invariant is also pinned to memberCount == 3 with a single depositor, so n == 1 and n == 10 are exercised only by unit and fuzz tests, never by the stateful suite.