OpenChainGraph Suite · ART-611 · EVM-Standard Math

ERC-7540 Async-Vault Request Accounting

ERC-7540 extends ERC-4626 for vaults that cannot settle a deposit or redemption in the same transaction, which is the normal case for institutional and real-world-asset funds. This tool recomputes the pending, claimable and claimed split from declared request state, applies a sequence of claims at the pro-rata rate the vault fixed when it made the request claimable, reports the rounding residue a run of partial claims strands, and checks the standard's own invariants one by one. Exact uint256 integer arithmetic throughout, no floating point.

ERC-7540 (Final, 2023-10-18)Exact uint256 integer mathDeclared inputs, no chain reads
🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
The Request Lifecycle
1. Pending
A holder calls requestDeposit or requestRedeem. The amount appears in pendingDepositRequest or pendingRedeemRequest and waits. The standard deliberately leaves the timing of what happens next unspecified.
2. Claimable
The vault fulfils the request. The amount leaves the pending view and appears in the claimable view at a fixed pro-rata rate. The two views exclude each other, so they never double-count.
3. Claimed
The holder calls deposit or mint (deposit leg) or withdraw or redeem (redeem leg) and receives the output tokens. The standard requires that a request never skips or short-circuits this state.
One Thing The Standard Leaves Open

ERC-4626 fixes a rounding direction for every one of its functions. ERC-7540 does not extend that to partial claims: it requires that all requests sharing a non-zero requestId become claimable at the same pro-rata rate, but it states no direction for rounding an individual partial claim. So the direction here is something you declare, not something this tool derives, and every claim reports what the other direction would have paid out beside what it did pay. Defaulting to rounding down follows ERC-4626's favour-the-vault reasoning, which is an inherited convention rather than a requirement of ERC-7540. What this tool cannot tell you: whether the amounts you typed match any deployed vault, when or whether a pending request will actually be fulfilled, whether the controller is authorised, or whether a claim transaction would succeed.

Request State
Zero is the standard's aggregate convention: the vault discriminates purely by controller and amounts are fungible across that controller's requests. A non-zero id is a discrete request that must hold one pro-rata rate.
Deposit Leg (requested in assets, claimed as shares)
The two claimable fields are a pair: together they fix the rate the vault made the request claimable at, so they must be both zero or both non-zero.
Redeem Leg (requested in shares, claimed as assets)
Both are carried into the receipt verbatim for your own records. Neither selects any behaviour.
Claims To Apply
unit is requested (deposit: assets, redeem: shares) or received (deposit: shares, redeem: assets), matching the standard's four claim overloads. A claim beyond what remains claimable is rejected rather than silently clamped.
Claims
Opening and Closing State
Rounding Residue
Invariants Checked
Execution Hash (SHA-256)







  

    
Ask your agent

    
  

  
Copy this paragraph into Claude, OpenClaw, or any MCP-aware agent to run this exact tool, with this sample, and verify the artifact.

  
Run the AINumbers MCP tool `recompute_erc7540_request_accounting`. Task: Recompute ERC-7540 asynchronous-vault pending/claimable/claimed request accounting from declared state, applies a claim sequence at the bucket's pro-rata rate under a declared rounding direction, and reports the standard's invariants by name.
Call it with arguments: {"policy_parameters":{"request_id":"0","deposit":{"pending_assets":"500","claimable_assets":"1000","claimable_shares":"333"},"claims":[{"leg":"deposit","unit":"requested","amount":"300"},{"leg":"deposit","unit":"requested","amount":"700"}]}}
Verify before trusting: call `verify_execution_hash` on mcp.ainumbers.co (https://mcp.ainumbers.co/mcp) with the parameter `claimed_hash` set to the returned `execution_hash`, passing the full artifact the run returned (the object containing `policy_parameters` + `output_payload` + `execution_hash`; equivalently `policy_parameters` + `output_payload` with `claimed_hash`), not the bare hash string.
Return the ledger link https://ledger.ainumbers.co/ so a human can re-verify without contacting us.
PII rule: All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
Open the tool with the sample prefilled: https://ainumbers.co/chaingraph/art-611-erc7540-async-vault-request-accounting.html#p=v1.H4sIAAAAAAAA_wHbACT_eyJyZXF1ZXN0X2lkIjoiMCIsImRlcG9zaXQiOnsicGVuZGluZ19hc3NldHMiOiI1MDAiLCJjbGFpbWFibGVfYXNzZXRzIjoiMTAwMCIsImNsYWltYWJsZV9zaGFyZXMiOiIzMzMifSwiY2xhaW1zIjpbeyJsZWciOiJkZXBvc2l0IiwidW5pdCI6InJlcXVlc3RlZCIsImFtb3VudCI6IjMwMCJ9LHsibGVnIjoiZGVwb3NpdCIsInVuaXQiOiJyZXF1ZXN0ZWQiLCJhbW91bnQiOiI3MDAifV19OuIOmNsAAAA