The brief says the contract 'should accept maximum of 10K worth of assets' and that the withdrawer 'shall withdraw it any time any amount, full too'. The implementation reads the cap as a lifetime total of accepted deposits (totalAcceptedUsd is only ever incremented; _withdraw never decrements it, and remainingCapacityUsd() = CAP_USD - totalAcceptedUsd). The README states this as an explicit assumption.

If the requester instead meant a cap on what the contract holds at any time (so that after the withdrawer drains it, new deposits up to $10K are accepted again), the current code violates that reading permanently: once $10K has been accepted, every further deposit on this receiver and on every replacement in its lineage reverts with CapExceeded, even when the balance is zero.

The arithmetic itself is exact and overflow-free under either reading; this is a product-semantics choice, not a math error. It is reported so the judge can confirm the intended semantics with the author rather than discover it after deployment, because switching readings changes the accounting model (a holdings cap would need per-asset balance tracking or a decrement on withdrawal, and withdrawals would then reopen capacity).

_account rejects a deposit outright when it exceeds the remaining capacity; there is no partial fill and no slippage/minimum parameter. Because the cap is shared by every depositor and the mempool is public, an unprivileged griefer can make any deposit that targets the exact remaining capacity (the natural amount to send, since remainingCapacityUsd() advertises it) revert by landing a dust deposit first.

The cost to the griefer is gas plus dust that is credited to the withdrawer anyway, so the attack is nearly free and repeatable; the victim loses the gas of each reverted transaction and must guess a smaller amount. Economic impact is bounded (no funds at risk, the pot still fills), hence low.

A minimal fix that preserves the design is to add an optional minAccepted-style parameter or a depositETHUpTo-type path that accepts min(amount, remaining) and refunds the rest for ETH, or simply document that callers should leave a margin. (Economic Security guide: cheapest griefing vector that blocks other users.)

As the brief requires, ETH is valued at a fixed $2,600 and IMD at a fixed $9 with no oracle.

Economic consequences the requester should accept explicitly: (1) the real value collected can be far above or below $10,000 depending on market prices; at $9 fixed, 1,111.11 IMD (the on-chain IMD token is a plain OpenZeppelin ERC20 OFT with 18 decimals, no fee, no blacklist, no pause, verified on Sourcify at block 26,134,647) consumes the whole cap regardless of IMD's market price, so if IMD trades below $9 a depositor can close the collection for less than $10,000 of real value; (2) assets pushed in without a deposit call (selfdestruct/coinbase ETH, direct ERC20 transfer) are held above the cap and never accounted; they are only recoverable by the withdrawer.

The mixed-asset math itself is exact (wei2600, usd61e12, imd18*9, cap compared before multiplying, no overflow), and real-token deposits/withdrawals of USDT, USDC and IMD were confirmed exact against live mainnet bytecode in a fork run. No code change is required; this documents the trust and valuation assumptions.

These are the brief's intended roles, recorded as trust assumptions rather than defects.

Owner: can pause deposits indefinitely and can retire this address once via upgradeTo; upgradeTo only checks six getters (predecessor, owner, WITHDRAWER, CAP_USD, totalAcceptedUsd, successor) so a replacement with matching getters but different withdrawal logic would be activated if the owner chose it, and future depositors would rely on the owner having reviewed that bytecode. There is no timelock on pause or upgrade.

The owner cannot touch funds in this contract: every payout path is hard-wired to WITHDRAWER and no setter exists. Withdrawer (0x047F606f...): an EOA on mainnet (no code, nonce 2685) that is also the owner of the IMD token contract; loss of that key strands all funds permanently because ownership does not grant withdrawal rights.

Token issuers: USDT and USDC can blacklist or pause, which would block deposits and withdrawals of that asset while leaving ETH and IMD unaffected; a withdrawal that reverts leaves funds in place.

Replacement flow: unprivileged parties cannot grief it (replacement cannot accept deposits before activation, old receiver cannot accept deposits while paused, so the totalAcceptedUsd equality check cannot be perturbed by outsiders).

Static-analysis leads examined and not promoted: slither incorrect-equality at _withdraw (address sentinel compare, withdrawals above balance revert as intended), missing-zero-check on previousReceiver (zero is the deliberate root sentinel), aderyn reentrancy in constructor (staticcall getters on a deployer-chosen address, no state to exploit), modifier ordering (pure msg.sender checks before nonReentrant are harmless).

Asymmetry pass (deposit <-> withdraw storage-write diff): _account() writes totalAcceptedUsd += value on every deposit (line 191) while _withdraw() never writes it. The brief says the contract 'should accept maximum of 10K worth of assets' and that the withdrawer may 'withdraw it any time any amount'. The implementation reads this as a lifetime intake cap (README 'Assets and accounting' calls it an explicit assumption).

Under the other plausible reading ('never hold more than $10K at once'), the contract is defective: once $10K has been accepted, it is permanently closed even after the withdrawer empties it.

The owner's upgrade power does not help, because upgradeTo() at line 157 requires next.totalAcceptedUsd() == totalAcceptedUsd and the replacement constructor copies the predecessor's total (line 66), so the cap travels with the lineage; the only way to collect again is a brand-new unrelated deployment, which is a new launch.

This is not a permission bypass and the code behaves exactly as its comments say; it is recorded so the requester confirms the intended cap semantics before mainnet deployment, since changing it afterwards means a new contract. If the holdings reading is intended, the minimal change is to track outstanding value and have _withdraw reduce it proportionally, keeping the same guard and recipient.

Access-control/trust-gap note, not a bypass: the brief grants the owner upgrade rights, and the launch policy forbids DELEGATECALL, so 'upgrade' is a successor pointer. The successor validation is a set of view calls on an owner-supplied address.

A contract that returns the expected values from predecessor(), owner(), WITHDRAWER(), CAP_USD(), totalAcceptedUsd() and successor() passes, regardless of what its deposit or withdraw functions actually do (README already states 'Getter checks cannot prove a replacement is honest').

Consequences the requester should accept explicitly: (a) the owner, and nobody else, can redirect all future deposits to code with a different beneficiary; (b) funds already held by the retired receiver are unaffected and remain withdrawable only by WITHDRAWER (verified); (c) the owner cannot touch existing balances under any path (pause, unpause, transferOwnership, upgradeTo write no balance and call no transfer).

The guard itself is correct: only owner can call, the receiver must be paused and activated in its lineage, successor is written once, unpause is refused afterwards, and a third party deploying a candidate that names the real owner cannot force activation (verified). If the requester wants stronger assurance than owner trust, that is a design change (e.g. a timelock or a second signer on upgradeTo), outside this review's scope.

Merged from audit_math, audit_flow, audit_economics and audit_permissions (same root cause, four reports). _account() at line 191 only ever increments totalAcceptedUsd; _withdraw() never decrements it; remainingCapacityUsd() is CAP_USD - totalAcceptedUsd; the replacement constructor (line 66) copies the predecessor's total and upgradeTo (line 157) requires it to match. So the brief's 'should accept maximum of 10K worth of assets' is implemented as a one-time intake budget.

Under the equally plausible reading 'never hold more than $10K at once', the contract is permanently closed after the first $10K even when its balance is zero, and the owner's upgrade power cannot reset it because the exhausted total travels with the lineage; the only way to collect again is an unrelated new deployment, i.e. a new launch.

The README and launch.json notes state the lifetime assumption explicitly, the arithmetic is exact and overflow-free under either reading, and no funds are at risk, so this is low: a requirements-interpretation risk the requester must settle before mainnet, because switching afterwards needs a new contract.

If a holdings cap is intended, the minimal change is to track outstanding accepted value per asset and reduce it in _withdraw (keeping the same guard and the fixed WITHDRAWER recipient), and to carry the outstanding rather than lifetime total across replacements. If the lifetime cap is intended, no code change is needed.

Note for the author: the specialists' step 'depositToken(USDT, 1) reverts CapExceeded' only holds when the caller has approved the receiver first; without an allowance the revert comes from the token, because safeTransferFrom runs before the cap check.

Merged from audit_economics (two info findings) and audit_permissions (one). These are the brief's intended roles and the fixed-price rule it asked for, documented as trust assumptions, not defects; the README already states most of them.

1. Upgrade: the launch policy forbids DELEGATECALL, so 'upgrade' is a successor pointer. upgradeTo only reads predecessor(), owner(), WITHDRAWER(), CAP_USD(), totalAcceptedUsd() and successor() from an owner-supplied address; a contract returning those values with arbitrary deposit/withdraw logic is accepted, and clients that follow successor() will send new deposits to it. Funds already held by the retired receiver are unaffected and remain withdrawable only by WITHDRAWER. The owner cannot move existing balances through any path (pause, unpause, transferOwnership, acceptOwnership, upgradeTo write no balance and call no transfer), and outsiders cannot perturb the activation flow (a candidate cannot accept deposits before activation; the paused old receiver cannot change totalAcceptedUsd). No timelock on pause or upgrade.
2. Withdrawer: 0x047F606f... has no code on mainnet (cast code returned 0x on 2026-10-06); every payout path is hard-wired to it with no setter, so losing that key strands all assets permanently and the owner cannot repair it.
3. Valuation: ETH at $2,600 and IMD at $9 are fixed by the brief; the on-chain IMD token reads decimals()==18 and symbol()=='IMD' (checked via public RPC), so 1_111_111_111_111_111_111_111 IMD base units (about 1,111.11 IMD) close the collection regardless of IMD's market price. Forced ETH (selfdestruct/coinbase) and direct ERC20 transfers are held above the cap, never accounted, and recoverable only by WITHDRAWER.
4. USDT/USDC issuer pauses or blacklists would block that asset's deposits and withdrawals while ETH and IMD remain unaffected. Static-analysis leads examined and not promoted: slither incorrect-equality at _withdraw (the only equality is the address(0) ETH sentinel; amount checks are strict inequalities and revert as intended), missing-zero-check on previousReceiver (zero is the deliberate root sentinel, lines 56-57), aderyn reentrancy in the constructor (view calls on a deployer-chosen address, no exploitable state), nonReentrant ordering (the role modifiers before it are pure msg.sender checks).

From audit_flow, reproduced. I downloaded the OpenZeppelin v5.2.0 and forge-std v1.9.7 release tarballs and compared every .sol file under lib/ byte-for-byte. lib/openzeppelin-contracts/contracts/token/ERC20/utils/SafeERC20.sol and seven forge-std files (src/StdJson.sol, src/StdAssertions.sol, src/console.sol, src/StdToml.sol, src/Vm.sol, src/interfaces/IMulticall3.sol, src/interfaces/IERC7540.sol) differ.

After stripping all whitespace the SHA-256 of every pair is identical, so the differences are forge fmt line-wrapping only and the compiled SafeERC20/ReentrancyGuard behaviour that AssetReceiver relies on is upstream's. No functional defect; the provenance statement is inaccurate, which matters to an offline verifier hashing lib/ against the tags.

Fix: restore the byte-identical upstream files (and exclude lib/ from forge fmt), or amend DEPENDENCIES.md to state that forge fmt was applied.