In native mode the credited amount is taken from the value attached to the call while the amount parameter is ignored entirely, so a caller can pass one figure and send another without anything objecting. Neither entry point rejects a zero amount either. A zero-amount withdrawal is particularly odd: the balance check passes trivially for any address, so the call succeeds for someone who has never deposited, emits a withdrawal event and reaches into the strategy with a zero amount. On the handful of tokens that reject zero-value transfers the call reverts instead, though only that call - the ledger is untouched and real withdrawals continue to work, so this is an input-validation gap rather than a denial of service. The more notable consequence is that a zero-amount deposit is a free trigger for the strategy's pre-deposit hook, which can be fired repeatedly without moving any value.

The initialiser is a plain public function guarded only by the one time initialiser modifier. If the proxy is deployed without being initialised in the same transaction, anyone can call it first and become the owner of a vault whose address has already been published. The implementation does disable its own initialisers in the constructor, which correctly prevents the implementation itself from being claimed, so the exposure is limited to the deployment procedure rather than to the code. No event is emitted, so the resulting configuration cannot be verified from logs afterwards.

The contract is written for a proxy - it uses the upgradeable base contracts, disables its own initialisers and reserves a block of storage slots - but it inherits no upgrade module, so there is no upgrade entry point and no authorisation hook anywhere in the audited code. Whoever controls the external proxy administrator can replace the implementation at will, with no delay, no event at this layer and no record visible from the vault itself. The documentation does not state which proxy pattern is intended, so the real upgrade authority could not be assessed as part of this review.

The asset setter and the sentinel setter both permit a change only while the recorded total is zero. That figure is the vault's own bookkeeping, not its real holdings. A vault can hold stray tokens, residual dust from a fee charging asset, or funds a strategy returned outside a withdrawal, and still report a zero total. The guard therefore allows a configuration change that abandons real value, and the shortfall described in the fee-on-transfer finding makes the two figures diverge during ordinary operation rather than only in unusual cases.

On the native path the vault calls the strategy's pre-deposit hook from inside a payable function, so the value attached to the call is already part of the vault's balance when the hook runs. A hook that reads the vault's balance to decide how much to harvest, or to price anything, sees a figure inflated by the deposit currently being processed. The token path does not behave this way, because there the transfer happens after the hook. The practical impact depends entirely on what a given strategy does inside the hook, but the inconsistency between the two paths is not something a strategy author would expect.

One interface accepts any compiler from the 0.8 series while the other three files require at least 0.8.24. A floating pragma means the same source can be compiled by different compiler versions with different code generation and different known issues, which undermines reproducible builds and makes verification against deployed bytecode harder than it needs to be. The contract also relies on transient storage and therefore needs a chain that supports it, and nothing in the source enforces that beyond the pragma range.

Migration became asymmetric. Handing funds to the incoming strategy now asserts that the strategy registered them, and the whole call reverts if it did not, but recalling funds from the outgoing strategy has no equivalent assertion. The amount to recall is taken from the outgoing strategy's own reported balance and the return value of the recall is not checked, so a strategy that reports a position it does not hand back causes the funds to stay where they are while the configuration change reports success. Afterwards the vault points at the new strategy, the ledger still records the full liability, the reported balance has dropped to zero, and users cannot withdraw. Reproduced with a strategy that clears its bookkeeping and returns successfully without transferring anything: one thousand tokens are left in the old strategy, the ledger is untouched, and the withdrawal fails. This requires a misbehaving or partially compromised strategy, which is the same trust class as the delivery gap that the revision closed on the withdrawal path, so the same treatment is warranted here.

Narrowing the fallback receiver to the attached strategy also closed every benign inbound route. In native mode this leaves no way at all to put value into the vault: the deposit entry point credits a ledger position, so it cannot be used as a backstop, the fallback receiver rejects everyone except the current strategy, and the native rescue function deliberately reverts in native mode. The consequence appears exactly when it is least welcome. After an emergency detach the strategy pointer is zero, so the previously attached strategy can no longer return funds even once it is healthy, and the owner cannot cover the shortfall out of pocket. Recovery requires re-attaching the same strategy and then detaching it through the ordinary path, which is a working but undocumented sequence that depends on the broken component becoming healthy again. Reproduced end to end: after detaching a frozen native strategy, the owner's transfer to the vault reverts, the rescue path reverts, and the user's withdrawal reverts for want of liquidity.

The pause was scoped to deposits alone. Keeping withdrawals out of it is the right decision and is well argued in the code, but leaving configuration out of it means the most consequential privileged action stays fully available during an incident. A paused vault will still accept a strategy migration that grants an unlimited allowance and pushes the entire balance into the new target. Verified: with deposits paused, attaching a hostile strategy still moves the whole balance in one transaction. The guardian's ability to pause therefore stops new money arriving but does nothing to contain an incident that involves the owner key, which is the scenario a guardian role usually exists for.

Relaxing the delivery post-condition to a lower bound was the right change, and the contract states that the resulting over-delivery stays in the vault as protocol funds. Nothing can move it out again. The surplus is never added to the ledger, so no withdrawal can reach it; the reward channel operates on the strategy rather than the vault, so it cannot see it; and the token rescue refuses the configured asset by design, which is the control that stops the owner reaching user deposits. In native mode the native rescue reverts outright for the same reason. The result is that the one place the contract deliberately accumulates protocol revenue is the one place it cannot be collected from, and the source comment describing the reward claim as the single auditable channel through which surplus leaves the strategy is no longer accurate, because the withdrawal path has become a second and unauditable one. Reproduced in both modes: a strategy that returns five more than requested leaves that amount in the vault with the ledger at zero, and the owner's attempt to sweep it is rejected. The funds are not lost to depositors, since they serve as liquidity for the next withdrawal, but they are outside the accounting and outside the protocol's reach. A convoluted recovery does exist, by detaching the strategy and pointing the vault at a different asset so that the residue stops being the configured one, but that is a side effect rather than a designed path.

The rewritten withdrawal enters the strategy only when the vault cannot cover the amount on its own, and the delivery post-condition sits inside that branch. When the vault can cover it, the payment is a single unchecked transfer and nothing verifies what the recipient actually received. For an asset that behaves normally this is correct and is cheaper than checking. For an asset that shortens transfers it means the ledger is debited in full while the user is paid less, silently. The previous revision had the same blind spot only when no strategy was attached at all, because an attached strategy always forced the payment through the checked branch; this revision widens it to every withdrawal the vault can cover from its own balance, which the same revision deliberately makes more common by retaining surplus and by leaving the remainder of a capped deposit idle. Reproduced with a one percent fee asset and a strategy that accepts nothing: a position of 3,960 is debited in full and the depositor receives 3,921. This is bounded by the deposit path rejecting fee-taxed assets, so it is reachable only for an asset whose transfer behaviour changes after deployment or for amounts small enough that the fee truncates to zero, which is recorded separately.

The bound added to the reward channel requires the strategy's reported balance not to have fallen across the claim. That correctly blocks a claim which reaches into principal, but it also blocks a claim which moves nothing but yield, whenever that yield is part of what the strategy reports. The strategy interface specifies the reported balance as the idle and deployed assets held by the strategy, so accrued yield denominated in the vault asset sits inside it, and a well-behaved strategy forwarding only its surplus necessarily lowers the figure and trips the check. The channel therefore cannot perform the task it was added for, and the decision that yield belongs to the protocol has no working route to collect it. Where the check does pass is where the reward is a different token that the reported balance never counted, in which case the bound is denominated in the wrong asset and constrains nothing. Reproduced with a strategy that reports principal plus accrued yield and claims only the difference: the claim reverts although principal was never at risk, and the recommended bound would have allowed it. Depositors are unaffected either way, because the stranded yield still serves as strategy liquidity and principal is paid in full, so this is a protocol revenue defect rather than a solvency one.

The deposit check rejects an asset by comparing the received amount against the requested one, which makes the rejection a property of the amount rather than of the asset. A proportional fee truncates to zero below a threshold, so deposits under that threshold are accepted and credited in full. They accumulate into a position whose own size is above the threshold, at which point the exit does incur a fee and the withdrawal reverts, leaving the position stuck at a size that can only be withdrawn in pieces small enough to be untaxed. Reproduced with a one percent fee asset, where forty deposits of 99 are each accepted because the fee on 99 truncates to zero, and the resulting position of 3,960 cannot be exited in one call while a 99 sized exit still succeeds. This is not introduced by the third revision and reproduces identically against the previous one; it surfaced now because the payability property was restated in terms of the exit actually succeeding. Solvency is unaffected throughout, and the case requires the vault to be configured with an asset the project already documents as unsupported.