Why ERC-4626 Does Not Apply

ERC-4626 defines a synchronous vault interface where redemption is atomic: a caller invokes redeem() or withdraw() and receives assets within the same transaction.

Vault-K-NO is structurally incompatible with this model for three reasons:

Reason 1: Asynchronous Redemption

Redemptions are queued and processed asynchronously by a permissioned keeper in a separate transaction. There is no path for a caller to receive USDC in the same transaction as their redemption request.

ERC-4626 requires the assets to be delivered within the redeem() or withdraw() call. Vault-K-NO's requestWithdraw() initiates the process but does not deliver assets — assets arrive later when the keeper calls processWithdrawals().

Reason 2: Non-Deterministic Exit Price

The exit price for a given share quantity is not deterministic at request time. It depends on: - Where the request lands within the daily fill window - The aggregate NAV at the moment of keeper processing - The queue position relative to other pending requests

ERC-4626's convertToAssets() implies a single, unconditional exchange rate. Vault-K-NO has no such fixed rate — the same number of shares submitted on the same day may receive different USDC amounts depending on fill order.

Reason 3: Dynamic Capacity Limits

ERC-4626's maxRedeem() and maxWithdraw() are designed to express stable or slowly-changing limits. In Vault-K-NO, these values change continuously: - The daily cap resets every 24 hours - The pause condition can bring the effective processable amount to zero instantly - Remaining daily capacity changes with every processed withdrawal

These are runtime values that the standard was not designed to express cleanly.