Interface Mapping¶

Function-level correspondence between ERC-7540 and Vault-K-NO.

ERC-7540 Function	Vault-K-NO Equivalent	Compatibility
`requestRedeem(shares, receiver, owner)`	`requestWithdraw(shares, receiver)`	Direct
`pendingRedeemRequest(requestId, owner)`	`getRequest(requestId)` — returns full Request struct	Direct
`claimableRedeemRequest(requestId, owner)`	Determined at keeper processing time	Partial — see Divergence
`redeem(shares, receiver, owner)`	Implicit in `processWithdrawals()`	Partial — see Divergence
`cancelRedeemRequest(requestId)`	`cancelWithdraw(requestId)`	Direct
`maxRedeemRequest(owner)`	`remainingDailyLiquidity()` as proxy	Partial — see Divergence
`RedeemRequest` event	`WithdrawRequested` event	Direct — same semantics

Direct-Compatible Functions¶

The following functions are structurally equivalent and can be mapped 1:1 in a wrapper:

// ERC-7540 → Vault-K-NO

function requestRedeem(uint256 shares, address receiver, address owner)
    → requestWithdraw(shares, receiver)

function pendingRedeemRequest(uint256 requestId, address owner)
    → getRequest(requestId)   // returns Request { owner, receiver, shares, timestamp }

function cancelRedeemRequest(uint256 requestId)
    → cancelWithdraw(requestId)

Partially-Compatible Functions¶

These require additional handling in a 7540 wrapper:

// claimableRedeemRequest — not deterministic until keeper processes
// A wrapper should return 0 until WithdrawProcessed event is observed for this requestId

// redeem — fulfillment is keeper-controlled, not caller-triggered
// A wrapper cannot expose a synchronous redeem() — document this clearly

// maxRedeemRequest — real-time proxy only
// A wrapper should expose remainingDailyLiquidity() and document it as non-binding

See Points of Divergence for full explanations.