ERC7540 Vault Security: Requests, Claimable Balances and Exit Risk

Follow one redemption from request to collection

A user requests a redemption and sees shares leave their available balance. The underlying assets have not necessarily reached the user, and they may not yet be claimable. In an asynchronous vault, requesting an exit and collecting its proceeds are separate actions. An interface that turns the first action into "withdrawal complete" has skipped the part the user most needs to understand.

ERC7540 vault security concerns the authorization and accounting of those asynchronous requests, including the transition from pending to claimable and the later claim. ERC-7540 extends ERC-4626 with asynchronous deposit or redemption flows. A vault may make either direction asynchronous or make both directions asynchronous.

In this illustrative redemption, the request takes control of the shares from their owner. The implementation may lock them temporarily or burn them earlier, but they must be removed from the owner's custody when requested and burned by the time the request is claimed. That rule does not itself specify when the corresponding assets will become available.

The standard requires a separate claim action. A request can become claimable immediately, but the lifecycle still requires the user to pull the output through the corresponding claim function. The implementation must not silently push output tokens to the user instead of that claim. The state labels therefore describe meaningful integration boundaries rather than decorative progress indicators.

The ERC-4626 vault security guide examines synchronous conversion and rounding assumptions. An asynchronous adapter needs an additional state model because the eventual exchange rate may differ from the conversion value seen when the request was made. The request records an amount entering the process, not a universal promise about its final output.

This distinction remains useful even before an engineer reads implementation code. Ask whether the screen is showing requested shares, claimable shares or received assets. If one number is used for all those meanings, the interface may be concealing a unit or state transition that needs explicit treatment.

Original census of preview behavior

A preview call reverting can be the expected result for an asynchronous direction. We classified every inherited preview method across every permitted asynchronous-flow configuration. The resulting matrix gives integrators a complete reference for this narrow compatibility question.

Method

Source snapshot

ERC-7540, ERC-4626 and ERC-7575, retrieved on October 3, 2026.

Population

3 configurations: asynchronous deposit only, asynchronous redemption only and both directions asynchronous.

Methods

previewDeposit, previewMint, previewWithdraw and previewRedeem.

Denominator

12 configuration-method cells, with no exclusions.

Classification rule

A preview for an asynchronous direction must revert. The other direction follows ERC-4626 synchronous requirements.

Measurement type

A complete normative classification, not a test of deployed vault behavior.

The replay script is seo/research/authorization-boundaries-2026-10-03/measurements.py. Its rows are retained in seo/research/authorization-boundaries-2026-10-03/erc7540-vault-security/measurement.json. Both artifacts remain in the repository and are not public download links. The script checks the source clauses and reproduces the entire matrix.

Results

The matrix contains 8 required-revert cells and 4 cells governed by synchronous rules. These are obligations across configuration combinations, not 8 bugs or 4 demonstrated successful calls. The distinction changes how a compatibility scanner should interpret its result: a preview revert on the asynchronous side cannot by itself establish that the vault is broken.

An adapter that catches every preview revert and substitutes convertToAssets has not recovered an equivalent execution quote. ERC-7540 explicitly allows the amount eventually received to differ from a conversion value at request time. A conversion estimate and an executable claim amount answer different questions.

Limits

• No deployed vault was called and no implementation compliance rate was measured.
• The census covers the preview contract only. Authorization, fulfillment and liquidity still need independent review.
• A reverting preview does not prove standards compliance; the wrong function can also revert for an unrelated reason.
• Synchronous-rule cells are subject to the complete ERC-4626 requirements, not an unconditional promise that every call succeeds.

Use the matrix to select the correct interaction path, then test that path against the actual vault. The OpenZeppelin asynchronous vault explanation also directs integrators to inspect the supported asynchronous interfaces rather than assuming all inherited previews remain usable.

Keep owner, controller and receiver separate

The account supplying tokens need not be the account controlling the request. The account controlling the request need not be the final receiver. Those roles often coincide in a simple wallet flow, which makes it easy for an adapter to accidentally treat them as one address.

ERC-7540 defines the controller as the owner of the request and an operator as an account permitted to manage requests for another account. A redemption event records the share owner separately from the controller. The controller determines who can manage the claim even when the tokens originally came from elsewhere.

Owner

Supplies the assets or shares entering the request.

Controller

Controls the request and its claim rights under the standard's authorization rules.

Operator

Acts through permission granted by the relevant account; review the exact request or claim rule.

Receiver

Receives the output when the claim is executed.

For a deposit request, the owner must be the caller unless the owner has approved the caller as an operator. For a redemption request, share approval can also authorize a caller under the standard's rules. For the claim, the controller and its approved operators are the relevant authority. A router cannot safely copy one authorization check across all these operations without checking their distinct requirements.

Operator approval is consequential. The standard warns that an operator can control both the vault's asset and share within the described permission model. A user-facing permission screen should explain that scope. Presenting the action as merely allowing a one-time preview would conceal the authority being granted.

A clear test uses deliberately different addresses for owner, controller and receiver. Give each only the permissions its role requires, then exercise the request and claim. Repeat with an unauthorized caller and after revoking the relevant operator. This reveals adapters that passed a happy-path test only because every field happened to contain the same wallet address.

The threat modeling guide helps turn these roles into trust boundaries. Preserve the distinction in logs and monitoring as well as code, because an incident investigation needs to know whose tokens moved and who controlled the request at each stage.

Test a revoked operator against an existing request

Operator revocation changes who may act; it should not be confused with canceling a request. Keep an existing pending or claimable request in the fixture, revoke the operator through the supported path and attempt the next management action from that operator. Then verify that the controller's legitimate route still behaves as the implementation intends.

This test separates authority from lifecycle state. If the request disappears, or if the former operator can still claim through an alternate adapter, the result needs investigation against the actual specification and implementation. The expected outcome should name both the permission change and the retained request accounting, rather than checking only that the revocation transaction succeeded.

Also inspect how a router records the controller. A router that accidentally becomes controller may leave the user's request dependent on the router's own authorization or upgrade policy. That is a different trust arrangement from a router submitting a request controlled directly by the user, and the interface should make it explicit.

Price a claim without promising immediate liquidity

A pending request is not the same object as an immediately transferable asset balance. The standard leaves the exchange rate, including fees and yield treatment, to the implementation. Pending redemption requests may not earn yield and may not have a fixed rate. The interface needs to explain the actual policy of the vault it integrates.

Request identifiers also have narrower guarantees than their name may suggest. Multiple requests may share an identifier, so a request is distinguished using both its identifier and controller. For nonzero identifiers, requests sharing an identifier must become claimable together and receive the same exchange rate. Partial fulfillment must apply at the same pro-rata rate to that group.

Different identifiers carry no general ordering guarantee in ERC-7540. An integration must not infer first-in-first-out settlement merely from increasing identifiers or submission timestamps. If the vault promises a queue policy, inspect where that policy is defined and enforced. The common interface alone does not establish it.

The special identifier 0 has a different meaning. A vault using that convention must use it for all requests and distinguish request state by controller, aggregating that controller's pending and claimable amounts. An indexer that assumes every new event creates a unique request object can therefore duplicate balances or lose the relationship between aggregate state and individual actions.

Requested amount

The assets or shares placed into the asynchronous process.

Claimable amount

The processed amount available through the appropriate claim function, in that function's expected units.

Estimated output

A value derived under the implementation's pricing assumptions, which must be labeled as an estimate when not fixed.

Received output

The assets or shares delivered by the included claim transaction.

Keep the unit beside every amount. Deposit request views concern assets, while redemption request views concern shares. A dashboard combining these into one unlabeled "pending balance" can create an accounting error without any contract exploit. Trace each displayed field to the exact view or event that supplies it.

The ERC-7575 interface also matters because ERC-7540 requires its support, including the share method. Do not assume that the address used for a vault operation is necessarily the share-token address an integration should inspect. Resolve the relationship from the supported interface and the implementation.

For collateral use, a pending exit introduces timing and valuation questions beyond ordinary share conversion. The lending protocol review should establish whether the position can actually be realized under the proposed liquidation design. A displayed estimate does not demonstrate that collateral can be converted within the required window.

Test partial fulfillment and cancellation

Partial fulfillment is where a simple progress label often becomes inadequate. A controller can have an amount that remains pending and another amount that is claimable. Those amounts must not be counted twice. The corresponding views explicitly exclude the other state, so an adapter should preserve that accounting separation.

1. Create requests with distinct controllers and the identifier pattern supported by the implementation.
2. Fulfill only part of the requested amount and verify the pending and claimable views in their correct units.
3. For shared nonzero identifiers, check the required pro-rata behavior across the affected controllers.
4. Claim an allowed amount and verify that the claimable balance decreases without incorrectly consuming unrelated pending state.
5. Attempt an excessive or unauthorized claim and assert the intended rejection.
6. Repeat the state reads after each included transaction so the interface does not display a stale pre-claim total.

Cancellation is not a universal immediate exit supplied by the base asynchronous interface. ERC-7540 notes that assets or shares can remain stuck pending and that implementations may provide cancellation mechanisms. An integration should inspect what the actual vault supports before showing a cancel control or promising a refund deadline.

ERC-7887's cancellation extension describes a separate asynchronous cancellation lifecycle. Its documentation introduces cancellation requests and later claims, with relevant new requests blocked while cancellation is pending. This is a useful reference for an implementation that supports it, not a feature that can be assumed for every ERC-7540 vault.

Read the implemented interface and deployed behavior even when an extension is advertised. Confirm what happens to a partially processed request, who may cancel and whether the cancellation itself can wait for fulfillment. The user needs to know whether pressing cancel submits another request or actually returns assets in the same transaction.

The fulfillment actor belongs in the threat model. An implementation may use administrative decisions, a delay strategy or another mechanism to move requests forward. OpenZeppelin's documentation illustrates different strategies and notes their exchange-rate implications. A shared request interface does not make those strategies economically or operationally identical.

Tests should therefore include the actor becoming unavailable and the behavior of any recovery route. If fulfillment stops, establish what state remains readable and what authority can restart processing. A view call continuing to work is not evidence that a pending position has a usable exit.

Build an adapter that exposes uncertainty

The adapter should select its interaction path from the supported interfaces and verified implementation behavior. Detect the asynchronous direction, display request state and require a distinct claim action. Keep estimates separate from claimable amounts and report failed reads as unavailable data, rather than substituting zero.

Use events to discover activity and current views to reconcile state. A historical request event does not tell the interface how much remains claimable now. Another claim or fulfillment can change that amount. Record the block context used for the displayed state so that a discrepancy can be investigated without guessing which observation the screen represents.

Compatibility evidence

Supported interfaces, asynchronous directions and expected preview behavior.

Authorization evidence

Owner, controller, operator and receiver checks with distinct test addresses.

Accounting evidence

Pending, claimable and received amounts reconciled in the correct units.

Exit evidence

Fulfillment and cancellation behavior under the implementation's documented conditions.

For review planning, the Pharos Production member profile provides assessment context and the audit scope builder helps organize requirements. Include the adapter and indexer when they determine what users see or which claim calls they submit. Reviewing only the vault contract can leave those integration assumptions unexamined.

Apply the model to a final illustrative case: a preview reverts, a redemption request is pending and a conversion view returns a positive value. The supported conclusions are limited. The preview may be required to revert, the request has not yet become claimable and the conversion value does not promise immediate proceeds. A correct adapter preserves those distinctions until the actual claim establishes what the receiver obtained.