Area: Boundary (constructor input vs. external token metadata) x Numerical Gap (boundary x invariant). The IMD address is a hard-coded constant, yet its decimals are taken from a free constructor argument that is only range-checked (0..18) at line 63 and then frozen into two immutables (lines 68-69).

Every deposit path calls totalValueUSD(), which executes _checkDecimals(IMD, imdDecimals) at line 182 and reverts with TokenDecimalsMismatch when the stored value differs from what the token reports. There is no setter, and pause()/unpause()/upgradeTo() cannot change an immutable, so a mis-encoded launch argument yields an instance that can hold and release funds but never accept a controlled deposit of any asset; the only remedy is a redeploy.

I verified the real token on Ethereum mainnet (chain id 1) over a public RPC on 2026-10-06: 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 is the LayerZero OFT 'Identity.md' (symbol IMD), decimals()=18, approvalRequired()=false, verified source on Sourcify is OpenZeppelin ERC20 + OFT with no transfer fee, hook, pause or proxy.

So the only correct argument is 18, and the README still says 'Local tests use 18 as a fixture, not proof of mainnet metadata' and 'Do not use 18 for IMD until confirmed'; no launch.json exists in the tree to pin the value. The arithmetic itself is exact for 18: imdUsdPerUnit = 9 * 10^0 = 9, so 1e18 base units value to 9e18 USD, and the 0-decimal path (9e18 per unit) and the 10 ** (18 - d) literal-base exponent evaluate in uint256 as expected (verified in scratch test).

Minimal fix that preserves the design: since IMD is a constant whose code is non-upgradeable and reports 18, replace the constructor parameter with uint8 public constant IMD_DECIMALS = 18 (and imdUsdPerUnit = 9), or keep the parameter but have the manifest/README state the verified value 18 as the required argument. Keeping _checkDecimals as a fail-closed runtime guard is fine.

Area: Boundary (external call corner cases: no code / revert / malformed return). totalValueUSD() at lines 179-185 performs three decimals() calls and three balanceOf() calls and is executed by _checkCap() on every deposit, including plain ETH sent to receive(). Any one of those reads reverting (token self-destructed or replaced, a decimals() value that no longer decodes into uint8, a balanceOf that reverts) makes every deposit of every asset revert.

The trigger is only available to the token issuers (Tether, Circle, the IMD owner), not to an unprivileged actor, and withdrawals are unaffected because _withdraw only touches the asset being withdrawn, so this is a liveness trust assumption rather than a loss path. The README already states it ('A failed token prevents deposits because total valuation fails').

Reported so the judge has the concrete boundary and so the author can decide whether a per-asset valuation that tolerates one failing token is preferred; the current fail-closed behavior is a defensible design choice given the fixed cap must sum all four assets.

Also verified: USDT's decimals() returns a 32-byte uint256 (6) and the vault's uint8 decode accepts it; values >= 256 fail closed (scratch test UsdtDecimals.t.sol).

Area: Numerical Gap (boundary x invariant). The invariant 'controlled holdings <= $10,000' is enforced only on the deposit path, but the value it compares is the gross on-chain balance, which anyone can raise without calling the vault (ERC-20 transfer, LayerZero lzReceive crediting IMD to the vault, SELFDESTRUCT-forced ETH).

Once gross value exceeds the cap, depositETH, receive and depositToken all revert with CapExceeded until 0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7 withdraws. The griefer forfeits the full remaining capacity to the recipient, so there is no profit and no loss of funds; a near-cap deposit can also be front-run by an ordinary deposit, which simply reverts the later one with its allowance intact. The README documents both behaviors.

Reported for completeness of the boundary record; no fix is required to preserve the requested design, though the author could track a separate 'controlled' accumulator if the intent is a lifetime contribution cap rather than a holdings cap.

The brief says the contract 'should accept maximum of 10K worth of assets'. The implementation enforces the cap only against live balances (totalValueUSD reads address(this).balance and the three balanceOf values at the moment of each deposit, src/IdentityVault.sol:179-185 and 225-227). There is no counter of what the controlled deposit paths have accepted over the contract's life.

Because the fixed recipient may withdraw at any time, the vault can accept an unbounded total through depositETH/receive/depositToken as long as holdings are swept between deposits. README.md:5-6 states this reading ('not a lifetime fundraising cap') explicitly, so this is a documented interpretation rather than an oversight; it is reported so the requester can confirm it is the intended one, because under the other reading the explicit requirement is not enforced.

A second consequence of valuing live balances rather than counted deposits: anyone can shrink the remaining capacity, including while paused or retired, by transferring a supported token or ETH directly to the vault (no function call, no pause check). One base unit of USDC ($0.000001) sent ahead of a contributor's exactly-at-capacity deposit makes that deposit revert with CapExceeded.

The attacker's cost is the dust itself (it goes to the recipient), the contributor's cost is a reverted transaction and the need to re-quote remainingCapacityUSD. Under a lifetime-accepted counter neither effect exists: unsolicited transfers would not consume the counted budget.

Context on the fixed prices used by the cap: on 2026-10-06 the pinned IMD token (Identity.md, 18 decimals, plain OpenZeppelin ERC20 + LayerZero OFT, no fee/blocklist/hook) trades near $13 with about $3.5M of Uniswap liquidity, so the fixed $9 undervalues it and a full IMD fill (1,111.11 IMD) represents roughly $14.5K at market; filling the cap with IMD is therefore not a cheap griefing vector.

Suggested fix if a lifetime cap is intended (scope decision for the requester): add uint256 public acceptedUSD; incremented in _depositETH and depositToken by usdValue(asset, received) and check acceptedUSD + value > CAP_USD instead of, or in addition to, the holdings check; unsolicited transfers then neither count toward nor block the counted budget.

If the holdings-cap reading is intended, no code change is needed; keep the README statement and consider documenting the dust front-run in the contributor interface (quote slightly under remainingCapacityUSD).

The brief requires 'Upgrades and pausing: owner can upgrade and pause'. The launch recipe forbids proxies, DELEGATECALL and SELFDESTRUCT, and the protected floor scans the runtime for those opcodes, so an in-place code upgrade is impossible under the recipe. The author resolved the conflict by implementing a one-way retirement: upgradeTo stores an address, permanently disables deposits on this instance (unpause reverts with Retired forever), and changes nothing else.

No code is replaced, no funds, approvals or storage move, and the fixed recipient must manually withdraw and re-deposit into the replacement within its cap. The README documents this honestly, but it is a deviation from an explicit requirement and the function name invites the wrong expectation from the owner and from integrators reading the ABI.

This is a scope decision for the requester rather than a code bug: either (a) accept retirement semantics (and consider renaming to retire/announceSuccessor so the ABI does not promise an upgrade), (b) relax the launch recipe to permit a UUPS/transparent proxy, or (c) make the parameters that could plausibly need changing (cap, prices, accepted token set) owner-settable so an 'upgrade' is a parameter change rather than a code change.

Option (c) conflicts with the fixed prices in the brief, so it also needs the requester's decision. Reporting so the judge can decide whether the requirement is met.

The cap is checked against current holdings valued at fixed policy prices (ETH 2600, IMD 9, stables 1). Any third party can push totalValueUSD() past 10,000e18 by sending IMD directly to the vault (ERC-20 transfers do not call the vault) or via depositToken, and from then on every depositETH, receive() and depositToken call from every contributor reverts with CapExceeded until WITHDRAWER withdraws.

The real cost to the griefer is the market price of ~1,111.2 IMD, which the fixed $9 valuation does not track; if IMD trades far below $9 the denial costs little, and it can be repeated after each withdrawal. This is inherent in the brief's fixed prices and in valuing raw balances, so it is a documented trust/operational assumption rather than a code defect: the recipient must monitor and withdraw to restore capacity.

Tracking an internal ledger of controlled deposits instead of balances would remove the direct-transfer vector but not the depositToken vector, so no in-scope code change eliminates it. Recorded so the operator knows the cap is a soft gate.

totalValueUSD() calls decimals() on USDT, USDC and IMD before summing, and _checkCap() calls totalValueUSD() on every deposit including receive(). The IMD decimals value is an immutable constructor argument that the repository could not verify against mainnet (README: live metadata 'not verified').

If the manifest supplies a value other than IMD's actual decimals(), or if IMD does not implement decimals() (optional in ERC-20) or returns it as something that does not decode as uint8, then depositETH, receive() and depositToken for every asset revert with TokenDecimalsMismatch (or a decode failure) from the first call onward. Withdrawals are unaffected, nothing is lost, and there is no attacker, which is why this is informational.

But the only remedy is redeployment, and upgradeTo cannot repair it. This is a launch-parameter risk for the manifest author: the fourth constructor argument must be the verified on-chain decimals() of 0xD34a...63B7 on chain 1, confirmed with cast call before the manifest is written. The behaviour is already covered by test/IdentityVault.t.sol testMetadataMismatchBlocksDepositsButNeverWithdrawals.