Skip to content

Points of Divergence

Three aspects of Vault-K-NO semantics diverge from strict ERC-7540 compliance. These divergences are intrinsic to the protocol's yield and liquidity mechanics — they cannot be resolved by interface wrapping alone.


Divergence 1: Non-Deterministic Fulfillment Price

ERC-7540 expectation: claimableRedeemRequest() returns a stable asset amount once a request becomes claimable.

Vault-K-NO reality: The exit price for a given share quantity is determined at keeper processing time, not at request time. It depends on: - The aggregate market NAV at the moment of processing - The fill position within the daily cap at that moment - The queue position relative to other requests processed in the same batch

Two identical share amounts queued on the same day may receive different USDC amounts if processed at different fill levels.

This is not a defect. It is the mechanism by which the exit curve distributes liquidity fairly across the day. However, integrators must not assume price stability between request and fulfillment.


Divergence 2: Dynamic maxRedeemRequest

ERC-7540 expectation: maxRedeemRequest() reflects the maximum shares an owner can request for redemption — a relatively stable value.

Vault-K-NO reality: The practical limit is bounded by the remaining daily cap at the time of keeper processing — a value that: - Changes throughout the day as other requests are processed - Resets each day - Can drop to zero instantly if the pause condition is triggered

remainingDailyLiquidity() provides a real-time proxy for current capacity but is not a guarantee that a given request will be fulfilled in the current day window.


Divergence 3: Permissioned Keeper vs. Open Claimability

ERC-7540 expectation: The standard is compatible with both open and permissioned operators. Some integrators assume any caller can trigger fulfillment once a request is claimable.

Vault-K-NO reality: Fulfillment is exclusively controlled by the permissioned keeper. No other address can call processWithdrawals().

Why this restriction exists: If any caller could trigger processing of specific requests, they could selectively process their own requests at favorable fill levels. The keeper processes the FIFO queue in full batches, preserving order fairness. Removing this restriction would enable MEV extraction at the expense of other investors.