split snapshots held once and pays held - paid to the Treasury at the end, assuming each safeTransfer lowers the splitter's balance by exactly amount. The live factory explicitly expects custom tokens 'with their own transfer rules' that exempt the launch flows (ProjectFactory: 'a token that exempts the launch flows from its own rules can find [the distributor] at transfer time', and SwarmShareShort refuses a taxed swarm transfer).

The splitter's address is known before launch (it is remainderTo) but nothing in this repository or its tests says the token must exempt it. A token that burns or taxes the sender beyond amount leaves the splitter short at the final transfer and split reverts every time (recoverable only by someone donating the deficit, and for a burn-from-sender design not even then, since no wallet can ever send its full balance).

A max-wallet or max-transfer rule on a bucket address has the same effect at the bucket transfer. There is no splitter-side code fix that preserves exact payments for such tokens; the fix is a launch rule: the custom token must exempt the splitter (and the buckets as recipients) from its transfer rules, checked by the adapter before launch, and the README/natspec should say so.

_declared treats any failed or non-32-byte answer as 'declares nothing'. That is intended for contracts without the getter (a staking vault), but it also swallows a real bucket whose getter reverts (for example one that derives the number from state that is not initialised yet, or that runs out of the forwarded gas) or returns a tuple such as (uint256,uint256).

The bucket then receives zero, the Treasury receives that bucket's share, isSplit is set, and the split can never be repeated. The asymmetry with token() (which reverts loudly on a mismatch at line 107) means one bucket mistake locks everything while the other quietly misroutes a share.

Because the Treasury is an unverified contract whose withdrawer is unknown (0x6Ac8fF96Fb8DCF5d79A8eF1E59D9AC23f2BD27Bc exposes withdraw(address,address,uint256) and withdrawer()), recovery depends on that party.

Minimal fix that changes no payment in the correct case: the adapter's pre-launch check should call genesisAllocation() and token() on every other contract of the manifest and require exactly 32-byte, non-reverting answers; optionally the splitter could distinguish 'no such function' (empty return, ok == true on an EOA, or revert with no data) from a reverting getter and emit an event for the latter.

The unit suite covers the happy path, once-per-token, over-allocation, stranger launches, non-custom kinds, empty balance and post-split sweep, and the fork test proves the live registry ABI decodes.

Untested states that change the outcome: (1) a launch contract with non-zero genesisAllocation() and a foreign or non-address token() (whole remainder locked, no recovery); (2) a remainder that arrives from the factory's evm_project door or any ERC20 that was never split (sweep unreachable); (3) a token with transfer taxes, sender-side burns, max-wallet or blacklist rules applied to the splitter or a bucket (split reverts or buckets receive less than declared); (4) a token with transfer hooks that re-enters split or sweep mid-split (sweep re-entry moves the balance to the Treasury and makes the next bucket transfer revert, a self-DoS); (5) a launch whose artifacts contain no other contract at all (everything to the Treasury, which is correct but unasserted); (6) a bucket whose genesisAllocation() reverts or returns two words (silently skipped).

The fork test writes its own record with roles it chooses rather than reading a real custom_token launch; launch 1274 on mainnet is such a launch and could be asserted directly.

Boundary (external return value shape). split() iterates artifactsOf(launchNumber) and pays every other entry whose getter declares a nonzero amount, with no memory of which addresses it has already paid in this call. The invariant the brief states is 'pays each of that launch's own contracts the genesisAllocation() it declares': one contract, one payment.

If the registry returns the same address under role other more than once, that contract receives N times its declaration and the treasury receives held - N*amount instead of held - amount.

I checked whether the live LaunchRegistry (0x7c9D5ee697BfF5Ac4F10E2E54d3f40c44e48fE23) rejects duplicate artifact addresses: on a mainnet fork, impersonating the factory writer (0xfF03410d0Fe5fa8f7F59F743de35E333D9857120) and calling record() with the same bucket address twice succeeds (returndata 0x), and a split of that launch then paid the bucket 500,000,000e18 against a 250,000,000e18 declaration and the treasury 200,000,000e18 instead of 450,000,000e18.

The registry does refuse re-recording an already recorded launch number, so the only producer of duplicates is the factory itself; that is why this is low rather than medium. Note the over-allocation guard does not catch it: 2*250 <= 700.

Minimal fix inside the loop that preserves what split pays and to whom: skip (or revert on) an address already paid in this call, e.g. compare against earlier other entries before paying, so each contract is paid its declaration exactly once.

Economic-dependency failure (Economic Security guide, 'Break dependencies'). The live ProjectFactory 0xfF03410d0Fe5fa8f7F59F743de35E333D9857120 constructs its own registry in its constructor (registry = new LaunchRegistry(address(this)), verified source via Sourcify) and LaunchRegistry.writer is immutable, so every factory has its own registry.

The splitter reads only the immutable registry 0x7c9d5ee697bff5ac4f10e2e54d3f40c44e48fe23. launchCustom transfers the remainder to remainderTo without checking anything about that address, so a launch run through a replacement/upgraded factory can still name this splitter as remainderTo.

For such a launch launchOf(n) on the pinned registry returns an empty record (kind == 0), split reverts NotCustomTokenLaunch forever, and sweep reverts NotSplit (src/GenesisSplitter.sol:124) because isSplit was never set. The entire remainder (typically 60-70% of the token supply) is permanently stuck in the splitter: no owner, no recovery path.

The same stranding occurs for a launch number that collides across registries only in the opposite direction (a launch recorded on the pinned registry under number n would be paid out of a token that belongs to it, so no cross-payment is possible; the harm is strictly stranding).

This is a trust/operational assumption the brief chose (static registry, no setter); it is reported because nothing on chain prevents a future-factory launch from selecting this address, and the loss is total and irreversible.

Mitigation within the brief's constraints is operational: the launch admission step must refuse remainderTo == this splitter for any launch not recorded by registry 0x7c9d...fe23, and README/ADAPTATION should state that the splitter serves only launches of the factory that owns that registry.

Live state read on mainnet at block ~26,166,667: ProjectFactory(0xfF03...7120).fees() = 0x12c9E1007262AfAC205567457F5826a9416a3863; LaunchFees.treasury() = 0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7 (an EOA, also LaunchFees.owner); LaunchFees.feeRecipient() = 0x3f252e859a277a86A3967c11D4E054B2f07a1F22.

The splitter's immutable treasury 0x6Ac8fF96Fb8DCF5d79A8eF1E59D9AC23f2BD27Bc is a different, unverified contract created at block 26,166,419 through the CREATE2 deployer 0x4e59b44847b379578588920cA78FbF26c0B4956C by 0x5167D014a056E43883e1BBEa5530c3c0dC993281; its selectors include reserveAsset/reserveAssets/isReserveAsset/reserveValueUsd/withdraw(address,address,uint256)/withdrawNative/withdrawer/vault/registrar/setRequester(uint64,address).

On a mainnet fork I confirmed it can custody and release arbitrary ERC20s: withdrawer() = 0xbeFd108085613662356aa26A2466Ad3426DA9C32, a Gnosis Safe proxy (masterCopy 0xFf51A5898e281Db6DfC7855790607438dF2ca44b, getOwners() = [0xd4C41b75c80B32312000C6b8b4eC05ffAf8aCCC1, 0x5167D014a056E43883e1BBEa5530c3c0dC993281, 0xa0Bf5b240634918c70d4ec9384DbD0111Ef40B42]); a pranked call from the Safe to withdraw(token, to, 1e18) of a freshly minted non-reserve ERC20 succeeded, and a stranger's call reverted with 0x82b42900.

So funds sent there are NOT lost; this is not a custody defect.

It is recorded because (a) the brief calls the argument 'the treasury', yet the factory routes a no-remainderTo launch's remainder to a different address, so the two paths for 'what the requester does not take' diverge; (b) LaunchFees.treasury is owner-mutable while the splitter's is immutable, so the divergence is permanent for this deployment; and (c) the treasury contract's source is unverified on Sourcify/Blockscout, so its withdrawal rules (e.g. ReserveProtected(address), InvalidReserveAsset()) cannot be reviewed from source.

No code change is required if 0x6ac8...27bc is the intended recipient; the manifest step should just confirm that choice and the review should note the treasury source is unverified.

Asymmetry / Trust Gap (access x asymmetry). The verified mainnet ProjectFactory at 0xfF03410d0Fe5fa8f7F59F743de35E333D9857120 (Sourcify, src/ProjectFactory.sol) sends a launch's remainder with the same private helper _seedShare(..., p.remainderTo, ...) from BOTH launch() (records kind "evm_project") and launchCustom() (records kind "custom_token"); the artifact layout (token, distributor, other..., hook) is the same _artifacts helper too.

The splitter accepts only the custom_token branch. An evm_project request that names the splitter as economics.remainderTo therefore delivers the remainder to an address from which nobody can ever move it: split reverts NotCustomTokenLaunch on line 89, and sweep reverts NotSplit because isSplit[token] can never become true for that token.

No admin, owner or recovery path exists by design, so the loss is permanent for the requester AND the treasury (which also never receives it). The contract's own NatSpec (lines 49-51) and README only document the restriction; nothing on chain or in the factory prevents the request.

This mirrors imported finding 9689055f, which the author dispositioned as documentation; the new evidence here is that the restriction is not grounded in any difference of the factory's remainder mechanics, so the precondition is an ordinary request with the wrong launch mode rather than an exotic state.

Severity is low because the trigger is the trusted deployer submitting a request that the documentation forbids (Gate 3 demotion), while the impact is permanent loss of the whole remainder once it happens.

Beneficiary review (Access Control / Trust Gap). The brief fixes the treasury argument as 0x6Ac8fF96Fb8DCF5d79A8eF1E59D9AC23f2BD27Bc and the repository (README.md:20, ADAPTATION.md:6, test/GenesisSplitter.launch.t.sol:9) carries that value, so the manifest will match the brief.

On mainnet, however, the ProjectFactory the splitter reads from resolves its own network treasury differently: factory.fees() = LaunchFees 0x12c9E1007262AfAC205567457F5826a9416a3863, whose treasury() = 0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7, an EOA (no code) that is also LaunchFees.owner(). That is where the factory sends a remainder when remainderTo is zero and where distributor sweeps go.

0x6Ac8... is instead a 12.5 KB Treasury contract (selectors: withdraw(address,address,uint256), withdrawer(), registrar(), vault(), reserveAssets(), sync(address), ...) whose withdrawer() 0xbeFd108085613662356aa26A2466Ad3426DA9C32 is a Safe proxy (masterCopy pattern), so it can move ERC20s and is not stranding funds. Neither address is Sourcify-verified.

This is not a code defect and the address is the brief's, but 'what no bucket declares' is the one external beneficiary this contract hard-codes immutably, and the two protocol treasuries disagree. The author should confirm 0x6Ac8... is the intended, current network treasury (and that LaunchFees.treasury() is simply stale) before the launch, since there is no setter afterwards.

Trust Gap seam access x asymmetry, recorded as a trust assumption rather than a splitter defect. split(launchNumber) is callable by anyone at any time after the launch transaction, and each bucket's share is whatever genesisAllocation() returns at that instant; a zero or reverting answer is treated as 'not a bucket' and the share falls to the treasury, after which isSplit[token] is set and no second split exists.

The NatSpec assumes the getter is 'a constant the swarm writes into the bucket'. If a future launch's bucket derives the value from mutable state (an owner-set variable, an initialize step, a balance read), then the requester does not choose when it is read: the first outsider to call split does, and nothing in the splitter can tell the difference.

The launch rules (constructor-only configuration) and the README's preflight make this a rehearsal requirement; it is reported so the judge and author see it stated with a concrete sequence, not because the contract should change (any fix would need an owner, deadline or configurable behaviour, which the brief forbids). It is distinct from imported finding 7f57e8c3 (malformed getter) in mechanism: here the getter is well-formed and the harm comes from who controls timing.

First-principles trace of split(): token is always the launch's own token artifact (lines 92-99), and line 114 transfers IERC20(token) only. So whatever a bucket answers to token(), split(n) can only ever move launch n's own token; a stranger's launch B whose bucket claims to serve launch A's token can never touch A's balance (scratch test test_tokenCheckOnlyEverGuardsTheLaunchsOwnToken).

The WrongToken check at line 111 therefore gives no cross-launch protection, which is the rationale test/GenesisSplitter.t.sol:147-159 ("still pays only its own token") attributes to it.

Its only effect is on the launch's own misdeclaration, and that effect is to revert the entire split for ever: one other artifact that declares a nonzero genesisAllocation() but has no token() getter (an ERC-4626 vault exposes asset(), not token()), returns a non-address word, or names another token blocks every honest bucket's payment and the treasury's remainder, with no sweep path because isSplit never becomes true (line 124).

The brief's rule is only "pays each of that launch's own contracts the genesisAllocation() it declares"; it names no token() requirement.

This is the residual of imported finding c091e431 that ADAPTATION.md chose to keep; it is reported here because the new observation is that the kept check buys nothing against strangers, so its cost (permanent loss of the whole remainder on a single misdeclared bucket, which only off-chain preflight can prevent) is not offset by any on-chain protection.

Severity low because the triggering state is the launch's own misconfiguration and README/preflight document it; the change it suggests (pay the declared amount, or skip the bucket, instead of reverting) alters who is paid and so needs the requester's decision rather than a silent fix.

Merged from audit_permissions c09c9d45 (evm_project kind), audit_economics a9e7e379 (other registry) and audit_flow 67fbf164 (own bucket's token() mismatch); the earlier-round finding 9689055f is the same root cause. All three reproduce.

The root cause is one: a token that arrives here can only ever leave through split(), and split() has three gates that are permanent for a given launch (kind != custom_token at line 89, a launch number the pinned registry does not know, and WrongToken at line 111), while sweep() refuses anything not already split (line 124).

The verified mainnet ProjectFactory (Sourcify, src/ProjectFactory.sol lines 197 and 230) sends the remainder of BOTH launch() [kind evm_project] and launchCustom() [kind custom_token] to p.remainderTo with the same _seedShare helper and does not check what remainderTo is, and a replacement factory would construct its own LaunchRegistry (writer is immutable), so nothing on chain prevents a request from naming this splitter for a remainder it can never pay out.

The WrongToken check at line 111 does not add cross-launch protection (split(n) only ever moves launch n's own token artifact, line 92-99 and 114), so its sole effect is to make the launch's own misdeclaration (a vault exposing asset() instead of token(), or a bucket naming another token) a permanent revert rather than a skipped or paid bucket.

This is the design the brief asked for ('no owner... takes no instructions', 'Unsplit tokens cannot be swept') and the README documents it, so the severity is low: the trigger is a request that contradicts the documentation, but the loss when it happens is the whole remainder, for the requester and the treasury alike, with no remedy.

The only fix within the brief is operational: the launch admission step must refuse economics.remainderTo == this splitter for any launch that is not a custom_token launch recorded on registry 0x7c9D5ee697BfF5Ac4F10E2E54d3f40c44e48fE23, and the preflight must require every nonzero-declaring other artifact to answer token() with the launch token. Adding a recovery path, or skipping a WrongToken bucket, changes who is paid and needs the requester's decision.

Found on the second read (not reported by any specialist; slither's calls-loop lines 130-138 are the lead). The low-level staticcall receives 63/64 of the remaining gas and Solidity copies the whole returndata into memory before ret.length == 32 is tested.

A bucket whose getter returns as many bytes as its forwarded gas can pay for (memory expansion is quadratic, so it spends roughly all of its 63/64 share producing the returndata) leaves the splitter with 1/64 of the gas to pay the same expansion cost for the copy, which always fails. Raising the gas limit does not help, because the bucket's output scales with it.

The result is identical to finding 1: split(n) reverts for ever, isSplit stays false, sweep refuses, and the whole remainder is stuck. The actor is the launch's own contract (verified source, reviewed in preflight), so this is a trust assumption on the bucket code rather than an outsider's attack, and the requester gains nothing they could not get by naming a different remainderTo; hence low.

Unlike finding 1 the fix is behavior-preserving and inside the contract: perform the staticcall in assembly and copy at most 32 bytes, only when returndatasize() == 32 (treat anything else as 'declares nothing', exactly as today), in both _declared and _servedToken. No recipient or amount changes.

audit_math 3cbcbef3, reproduced against the code but demoted from low to info. The payment loop (lines 106-116) keeps no memory of addresses already paid in this call, so a record listing the same address under role other N times pays it N times and the treasury receives held - Namount; the OverAllocated guard does not catch it while Namount <= held.

However the only writer of the pinned registry is the ProjectFactory (LaunchRegistry.record line 71: msg.sender == writer; cast call writer() -> 0xfF03410d0Fe5fa8f7F59F743de35E333D9857120), and its _artifacts() (verified source lines 377-390) builds the other entries from _deployContracts(), which CREATE2-deploys contract i at contractSalt(launchNumber, i); distinct salts give distinct addresses, and _checkNames() rejects duplicate names.

So no record the live factory can write contains a duplicate other address, and the specialist's fork reproduction had to impersonate the factory to write one. Recorded as information for a future registry writer; a per-call duplicate check in the loop would preserve every payment under valid records.