Loan Protocol Vault

The Treasury is intended to hold an ERC-20 loan asset whose address and caps in raw token units are supplied at deployment. docs/AUDIT-SCOPE.md calls that asset USDG in its overview but USDC in its trust model. docs/REQUIREMENTS.md then describes USDG as Robinhood's native currency, although the scope excludes native currency and payout() transfers through IERC20.safeTransfer. These labels leave the token to configure and fund unclear. If USDG is the intended loan asset, an operator following the USDC label can configure or fund the wrong token, leaving the intended payouts unavailable until the configuration and funding are corrected.

Identify the intended ERC-20 loan token consistently in the scope and requirements, including its target chain contract address and decimals. Correct the native currency entry.

The deployment specification says Treasury instances have identical bytecode. The Treasury constructor initializes OpenZeppelin EIP712, which caches the instance address and its domain separator in immutable variables. Solidity embeds these values in deployed runtime code, so instances deployed from the same build with identical constructor arguments have different runtime bytecode and code hashes. The stated identical bytecode guarantee therefore cannot be used as a literal identity check on chain for shard instances.

State that instances use the same source and compiler artifact while their deployed runtime code contains instance specific immutable values. Compare deployed code with those immutable positions accounted for when verifying shards.

The audit invariant says total payouts for an asset and epoch never exceed dailyCap and each payout never exceeds maxPerPayout, without specifying when those cap values apply. The owner can lower either cap after a successful payout through setCaps(), which leaves historical spent unchanged. For example, a 10,000-unit payout followed by a reduction of dailyCap to 9,999 leaves spent at 10,000, above the current cap. That earlier payout can likewise exceed a subsequently reduced maxPerPayout.

This is accepted configuration behavior. When historical spend reaches or exceeds the current daily cap, the contract reports zero remaining capacity and rejects further positive payouts. The unqualified written invariant therefore overstates the guarantee that an audit report or integrator can make; the cap checks do not permit an excess payout at execution. The baseline test in test/Treasury.ts:265-271 exercises a cap reduction below prior spend, zero remaining capacity, and rejection of another payout.

Qualify both audit invariant lists so each successful payout is bounded by maxPerPayout and leaves epoch spend within dailyCap under the caps in force when it executes. Explain that later authorized reductions can leave historical epoch spend above the current dailyCap or an earlier payout above the current maxPerPayout. Keep the existing spend accounting.

Guardian: Invariant 3 in both documents still says that lowering either cap blocks further positive payouts until the epoch changes or a cap is raised. Lowering only maxPerPayout still permits a smaller payout in the same epoch when daily capacity remains.