{"id":"EIP-5792","name":"Wallet Call API","status":"Final","chain":"both","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"EIP-5792 defines wallet_sendCalls, wallet_getCallsStatus, and wallet_getCapabilities for wallet-mediated call batches. Atomicity is capability- and request-dependent: use atomicRequired: true only when the wallet advertises the atomic capability for the target chain, and show the status result.","officialUrl":"https://eips.ethereum.org/EIPS/eip-5792","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-5792","specConstraints":[{"id":"eip-5792-atomicity-capability","constraint":"atomicRequired declares the app's minimum atomicity requirement, and a wallet must honor the atomic execution rules when that capability is used.","appliesTo":"application","normativity":"normative","specQuote":"The `atomicRequired` field specifies if a wallet is required to handle the batch of calls atomically or not.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Ask for atomicity only when the product needs it and gate that request on the wallet's advertised capability. Never imply all-or-nothing execution when the wallet has not returned that guarantee."},{"id":"eip-5792-capability-overrides","constraint":"Default wallet_sendCalls rules can be overridden only by an explicitly defined capability.","appliesTo":"wallet","normativity":"normative","specQuote":"Unless these requirements are explicitly overridden by a certain `capability`, the wallet must adhere to the following rules.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Name the capability that changes the expected behavior in the review UI. Do not silently substitute wallet-specific batching behavior for the standard default."},{"id":"eip-5792-call-order","constraint":"The wallet must send calls in the order specified by the request.","appliesTo":"wallet","normativity":"normative","specQuote":"* MUST send the calls in the order specified in the request","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Preserve the user's intended sequence in previews and status. If a step depends on a prior call, show that dependency instead of presenting a reorderable list."},{"id":"eip-5792-call-chain","constraint":"The wallet must send every call on the chain identified by the request.","appliesTo":"wallet","normativity":"normative","specQuote":"* MUST send the calls on the same chain identified by the request's `chainId` property","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Show the target chain in the batch review and invalidate the plan after a chain change."},{"id":"eip-5792-call-sender","constraint":"When from is provided, the wallet must send calls from that address.","appliesTo":"wallet","normativity":"normative","specQuote":"* MUST send the calls from the address specified in the request's `from` property, if provided","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Keep the requested sender visible and verify it against the active account before signature."},{"id":"eip-5792-no-finality-wait","constraint":"wallet_sendCalls does not wait for all calls to finalize before completing the batch request.","appliesTo":"application","normativity":"normative","specQuote":"* MUST NOT await for any calls to be finalized to complete the batch","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Separate submission from confirmation in the product. Keep the batch in a pending state until wallet_getCallsStatus and chain receipts provide the outcome."},{"id":"eip-5792-user-rejection-no-send","constraint":"If the user rejects the request, the wallet must not send any call from that request.","appliesTo":"wallet","normativity":"normative","specQuote":"* MUST NOT send any calls from the request if the user rejects the request","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Make rejection terminal for that batch and do not report partial execution. Offer a fresh review rather than silently resubmitting."},{"id":"eip-5792-atomic-execution","constraint":"When the atomic requirement applies, all calls must execute contiguously and atomically or have no material on-chain effect.","appliesTo":"wallet","normativity":"normative","specQuote":"* MUST execute all calls atomically, meaning that either all calls execute successfully or no material effects appear on chain.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Label atomic batches as a capability-backed guarantee and show the boundary clearly. Do not reuse this copy for sequential execution."},{"id":"eip-5792-atomic-contiguity","constraint":"Atomic batches must execute contiguously without other transactions or calls interleaved.","appliesTo":"wallet","normativity":"normative","specQuote":"* MUST execute all calls contiguously, meaning no other transactions/calls may be interleaved with the calls from this batch.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Explain contiguity when users depend on intermediate state not changing between calls."},{"id":"eip-5792-atomic-capability-upgrade","constraint":"A wallet that can upgrade atomicity from ready to supported must do so before submitting calls with those guarantees.","appliesTo":"wallet","normativity":"normative","specQuote":"If a wallet is able to upgrade its atomicity guarantees from `ready` to `supported` but has not yet done so, it MUST upgrade before proceeding to submit the calls with the above guarantees.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Show capability preparation as a visible preflight step, not as an invisible promise made after the user approves the batch."},{"id":"eip-5792-unsupported-capability","constraint":"An unsupported non-optional capability must cause the wallet to reject the request.","appliesTo":"wallet","normativity":"normative","specQuote":"* MUST reject the request if it contains a `capability` (either top-level or call-level) that is not supported by the wallet and the `capability` is not explicitly marked as optional.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Distinguish optional enhancements from requirements in the review. Do not silently drop a capability the app required."},{"id":"eip-5792-batch-identifier","constraint":"A supplied batch identifier must be returned, and identifiers must be unique within the stated app and sender scope.","appliesTo":"application","normativity":"normative","specQuote":"If provided, the wallet MUST respect the `id` field and return it in the response.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Use the returned identifier to connect approval, progress, and recovery states. Generate or accept identifiers that do not collide across the app's active requests."},{"id":"eip-5792-identifier-unique","constraint":"Every wallet_sendCalls identifier must be a unique string within the allowed size.","appliesTo":"application","normativity":"normative","specQuote":"Identifiers, whether provided by the app or generated by the wallet, MUST be a unique string up to 4096 bytes (8194 characters including leading `0x`).","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Use stable, collision-resistant identifiers in progress and history surfaces, while respecting the protocol's size limit."},{"id":"eip-5792-app-id-scope","constraint":"App-provided identifiers must be unique per sender and app, with the app preferably identified by its domain.","appliesTo":"application","normativity":"normative","specQuote":"App-provided `id`s MUST be unique per sender per app, where each \"app\" SHOULD be identified by their domain.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Scope identifiers to the app and sender used for the request. Avoid reusing a global counter that can conflate requests across accounts or domains."},{"id":"eip-5792-status-availability-window","constraint":"For the 24-hour window after wallet_sendCalls, wallets SHOULD return a call-batch status when queried with the same id.","appliesTo":"wallet","normativity":"normative","specQuote":"Within 24 hours from the corresponding `wallet_sendCalls`, wallets SHOULD return a call-batch status when `wallet_getCallsStatus` is called with the same `id`.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Keep a pending batch status retrievable for the expected window and give users a clear unresolved state when the status is not yet available."},{"id":"eip-5792-duplicate-id-rejection","constraint":"Wallets must reject requests with duplicate batch identifiers.","appliesTo":"wallet","normativity":"normative","specQuote":"Wallets MUST reject requests with duplicate `id`s.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Treat a duplicate as a request-state error and preserve the original batch reference rather than showing two actions as the same operation."},{"id":"eip-5792-optional-capability","constraint":"A wallet that does not support an optional capability may process the request as though that capability were absent.","appliesTo":"application","normativity":"normative","specQuote":"Note that since the `paymasterService` `capability` is marked as optional, wallets that do not support it will still process and handle the request as if the capability had not been present.","specSection":"Specification — wallet_sendCalls — Example Parameters","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls-rpc-specification","designImplication":"Tell the user when an optional acceleration or payment feature was not applied. Do not represent optional support as a guarantee."},{"id":"eip-5792-receipt-order","constraint":"wallet_getCallsStatus returns receipts in the order they were included on-chain.","appliesTo":"application","normativity":"normative","specQuote":"* The receipts in the `receipts` field MUST be in the order that they are included onchain.","specSection":"Specification — wallet_getCallsStatus","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcallsstatus","designImplication":"Render progress and dependencies in receipt order, and do not reorder results into an app-local sequence that hides execution timing."},{"id":"eip-5792-atomic-status","constraint":"An atomically executed batch must report atomic=true and may report one transaction receipt or the included receipt array.","appliesTo":"application","normativity":"normative","specQuote":"If a wallet executes multiple calls **atomically**, `wallet_getCallsStatus` MAY return an object with a `receipts` field that contains a single transaction receipt or an array of receipts, corresponding to how the batch of transactions were included onchain. It also MUST be explicit and return an `atomic` field set to `true`.","specSection":"Specification — wallet_getCallsStatus","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcallsstatus","designImplication":"Use the returned atomic flag to choose the success and recovery language. Do not infer atomicity from a single receipt alone."},{"id":"eip-5792-non-atomic-status","constraint":"A non-atomic batch must report every included receipt, including reverted calls, and set atomic=false.","appliesTo":"application","normativity":"normative","specQuote":"If a wallet executes multiple calls **non-atomically**, `wallet_getCallsStatus` MUST return an object with a `receipts` field that contains **an array of receipts** for all transactions containing batch calls that were included onchain. This includes the batch calls that were included on-chain but eventually reverted. It also MUST be explicit and return a `atomic` field set to `false`.","specSection":"Specification — wallet_getCallsStatus","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcallsstatus","designImplication":"Show per-call and per-receipt outcomes, including partial success and reverted steps. Never collapse a non-atomic batch into one all-or-nothing status."},{"id":"eip-5792-relevant-logs","constraint":"Status receipts must include only logs relevant to the calls submitted through wallet_sendCalls.","appliesTo":"application","normativity":"normative","specQuote":"* The `logs` in the receipt objects MUST only include logs relevant to the calls submitted using `wallet_sendCalls`.","specSection":"Specification — wallet_getCallsStatus","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcallsstatus","designImplication":"Use status logs to explain the requested batch without attributing unrelated bundle activity to the user."},{"id":"eip-5792-upgrade-logs-excluded","constraint":"Status logs must not include logs emitted by an atomicity upgrade before batch submission.","appliesTo":"application","normativity":"normative","specQuote":"* Similarly, if a user upgrades their wallet to support atomicity before submitting a batch of calls from an app, the logs MUST NOT include those emitted as part of the upgrade process.","specSection":"Specification — wallet_getCallsStatus","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcallsstatus","designImplication":"Keep capability setup activity separate from the user's requested operation in history and status views."},{"id":"eip-5792-chain-scoped-capabilities","constraint":"Capabilities are reported in per-chain hexadecimal EIP-155 objects, and unsupported requested chains are omitted rather than returned as an error.","appliesTo":"application","normativity":"normative","specQuote":"Capabilities are returned in key/value pairs, with the key naming a capability and a value conforming to a shape defined for that name, in an object keyed to the relevant [EIP-155](./eip-155.md) `chainId` expressed in hexadecimal notation.","specSection":"Specification — wallet_getCapabilities — RPC Specification","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcapabilities-rpc-specification","designImplication":"Query capabilities for every target chain and show the chain context beside each supported feature. Treat an omitted chain as unavailable, not as a generic wallet failure."},{"id":"eip-5792-no-atomic-assumption","constraint":"Applications must not assume calls are included in one transaction regardless of the atomic value.","appliesTo":"application","normativity":"security-considerations","specQuote":"Regardless of the `atomic` value specified, App developers MUST NOT assume that all calls will be sent in a single transaction.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#security-considerations","designImplication":"Design for sequential and partially completed execution unless a returned status explicitly proves the relevant guarantee."},{"id":"eip-5792-unpredictable-batch-id","constraint":"Wallet-generated batch identifiers must be unpredictable so one app cannot infer another user's transaction information.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets MUST ensure that batch identifiers returned by `wallet_sendCalls` are unpredictable to prevent malicious apps from inferring information about other users' transactions.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#security-considerations","designImplication":"Do not expose sequential or guessable identifiers in a wallet-facing history surface."},{"id":"eip-5792-no-sensitive-capability-leak","constraint":"wallet_getCallsStatus capability responses must not leak sensitive information.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets MUST NOT leak sensitive information in `wallet_getCallsStatus` `capabilities` responses.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#security-considerations","designImplication":"Keep capability status intentionally scoped and avoid displaying internal wallet details as if they were user-facing transaction facts."},{"id":"eip-5792-capability-privacy","constraint":"Wallets should avoid exposing capabilities to untrusted callers or more callers than necessary because capability discovery can fingerprint users.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"wallets are recommended to avoid exposing capabilities to untrusted callers or to more callers than necessary, as this may allow their \"user-agent\" (i.e. client software) to be \"fingerprinted\" or probabilistically identified","specSection":"Security Considerations — Privacy Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#privacy-considerations","designImplication":"Use capability discovery deliberately and avoid turning every passive page visit into a wallet fingerprinting request."},{"id":"eip-5792-unsupported-wallet-fallback","constraint":"Apps may fall back to serial eth_sendTransaction calls or explain unsupported wallet methods when wallet_sendCalls is unavailable.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"Apps MAY attempt to send the same batch of calls serially via `eth_sendTransaction` when a call to these methods fails for lack of wallet support, or they MAY indicate to the user that their wallet is not supported and the request was not processed.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#backwards-compatibility","designImplication":"Make the fallback explicit and disclose the loss of batching or atomicity. Do not silently turn an intended batch into a sequence with different failure behavior."},{"id":"eip-5792-call-capability-metadata","constraint":"A call may carry an optional capability-specific metadata object.","appliesTo":"application","normativity":"normative","specQuote":"Each entity in the `calls` field may contain an optional `capabilities` object.\nThis object allows the applications to attach a capability-specific metadata to individual calls.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Keep call-level capability details attached to the specific action they modify, and label them optional rather than implying that every wallet understands them."},{"id":"eip-5792-from-address-selection","constraint":"When a request omits from, the wallet should let the user view and select the sending address during confirmation.","appliesTo":"wallet","normativity":"normative","specQuote":"If `from` is not provided the wallet SHOULD present the user with an opportunity to view and select the `from` address during confirmation","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Make the selected sending address visible and changeable in confirmation when the app did not preselect one."},{"id":"eip-5792-non-atomic-batch-execution","constraint":"When atomicity is not required, a wallet may execute calls sequentially without atomicity or contiguity guarantees.","appliesTo":"wallet","normativity":"normative","specQuote":"MAY execute all calls sequentially without any atomicity/contiguity guarantees.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Present a non-atomic batch as potentially progressive and partially completed, with per-call recovery rather than one guaranteed all-or-nothing outcome."},{"id":"eip-5792-atomic-capability-choice","constraint":"A wallet with atomicity support may execute a non-required batch atomically.","appliesTo":"wallet","normativity":"normative","specQuote":"If a wallet is capable of providing atomicity guarantees, it MAY execute the batch atomically.","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Do not promise atomic behavior merely because the app allowed it; show the wallet's returned atomic status and tailor recovery language to that result."},{"id":"eip-5792-from-address-mismatch","constraint":"A wallet may reject a request when its from address does not match the enabled account.","appliesTo":"wallet","normativity":"normative","specQuote":"MAY reject the request if the from address does not match the enabled account","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Explain an account mismatch as a recoverable confirmation error and offer account selection or a request correction instead of a generic failure."},{"id":"eip-5792-simulated-call-rejection","constraint":"A wallet may reject a batch when sequential simulation predicts that one or more calls will fail.","appliesTo":"wallet","normativity":"normative","specQuote":"MAY reject the request if one or more calls in the batch is expected to fail, when simulated sequentially","specSection":"Specification — wallet_sendCalls","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletsendcalls","designImplication":"Give simulated call failures a specific pre-signing explanation and preserve the affected call details for correction or retry."},{"id":"eip-5792-reverted-status-outcomes","constraint":"Status codes distinguish complete reversion with possible gas effects from partial reversion with possible batch-call effects.","appliesTo":"application","normativity":"normative","specQuote":"| 500 | Batch reverted **completely** and only changes related to gas charge may have been included onchain (chain rules failure) |\n| 600 | Batch reverted **partially** and some changes related to batch calls may have been included onchain (partial chain rules failure) |","specSection":"Specification — wallet_getCallsStatus — Status Codes for status field","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcallsstatus","designImplication":"Use distinct complete-revert and partial-revert states, explaining whether only gas-related effects or some batch-call changes may remain."},{"id":"eip-5792-capabilities-unauthorized","constraint":"wallet_getCapabilities should return Unauthorized when the requested address has not authorized the app connection.","appliesTo":"wallet","normativity":"normative","specQuote":"This method SHOULD return an `4100 Unauthorized` error if the user has not already authorized a connection between the application and the requested address.","specSection":"Specification — wallet_getCapabilities","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcapabilities","designImplication":"Explain missing capability access as an authorization boundary and provide a reconnect or authorize path before showing unsupported-feature messaging."},{"id":"eip-5792-live-capabilities-canonical","constraint":"Live wallet RPC capability values should be treated as canonical when supplemental capability expressions disagree.","appliesTo":"application","normativity":"normative","specQuote":"If any of these supplemental expressions of capabilities are contradicted by capabilities expressed in live wallet RPC responses, these latter values SHOULD be taken as the canonical and current expression of capabilities.","specSection":"Specification — wallet_getCapabilities","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcapabilities","designImplication":"Resolve capability conflicts in favor of the live wallet response and make stale or out-of-band capability data visibly provisional."},{"id":"eip-5792-global-capability-key","constraint":"The wallet SHOULD include capabilities supported across all chains only once under chainID 0x0 and SHOULD NOT repeat them in nested per-chain objects.","appliesTo":"wallet","normativity":"normative","specQuote":"Capabilities that the wallet supports on all the chains SHOULD be included only once, using a special `chainID` value \"0x0\", and SHOULD NOT be repeated in nested per-chain objects.","specSection":"Specification — wallet_getCapabilities — RPC Specification","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#walletgetcapabilities-rpc-specification","designImplication":"Avoid duplicating global capability badges in every chain section; label 0x0 capabilities as wallet-wide while keeping chain-specific support distinct."},{"id":"eip-5792-atomic-capability-chain-scope","constraint":"Atomic capability status is a guarantee only for batches on the chain where it is reported.","appliesTo":"application","normativity":"normative","specQuote":"This capability is expressed separately on each chain and should be interpreted as a guarantee only for batches of transactions on that chain.","specSection":"Specification — atomic Capability","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#atomic-capability","designImplication":"Keep the target chain beside atomicity status and do not carry a supported badge into a different chain's batch flow."},{"id":"eip-5792-unsupported-method-error","constraint":"Wallets without these methods should return errors when the new JSON-RPC methods are called.","appliesTo":"wallet","normativity":"backwards-compatibility","specQuote":"Wallets that do not support the methods defined here SHOULD return error responses when these new JSON-RPC methods are called.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-5792#backwards-compatibility","designImplication":"Use a named unsupported-method state that can lead to the serial-send fallback, rather than leaving the user with an ambiguous RPC failure."}],"summary":"EIP-5792 defines wallet_sendCalls, wallet_getCallsStatus, and wallet_getCapabilities for wallet-mediated call batches. Atomicity is capability- and request-dependent: use atomicRequired: true only when the wallet advertises the atomic capability for the target chain, and show the status result.","applicability":{"whenToUse":["The selected wallet exposes wallet_getCapabilities for the target chain.","The flow benefits from wallet-mediated call batches and can represent partial or sequential execution.","Your UI can query capabilities before offering batching, atomicity, or paymaster controls.","You are designing a capability detection experience with visible states and recovery paths."],"whenToAvoid":["The wallet does not advertise the required capability for the target chain.","The flow cannot explain or recover from sequential or partially completed calls.","The app needs an all-or-nothing guarantee that the wallet has not returned."]},"designerTakeaways":["Query wallet_getCapabilities per target chain before showing batching, atomicity, or paymaster controls.","Use atomicRequired: true only when the wallet advertises the atomic capability.","Show the returned atomic result and provide a sequential or partial-execution recovery path."],"problemsSolved":[{"problem":"dApps can't know what wallet supports","oldWay":"Try features, catch errors, guess based on wallet name","newWay":"wallet_getCapabilities() returns supported features","impact":"high"},{"problem":"No standard for batched calls","oldWay":"Each smart wallet has different batch interface","newWay":"wallet_sendCalls gives supporting wallets a shared call-batch request shape; atomic execution remains capability-dependent","impact":"high"},{"problem":"Can't check call status after submission","oldWay":"Poll blockchain, hope for the best","newWay":"wallet_getCallsStatus() for bundled operation status","impact":"medium"}],"uxPatterns":[{"name":"Capability Detection","description":"Check wallet features before offering them","userFlow":["dApp connects to wallet","Calls wallet_getCapabilities","Parses supported features","Shows/hides UI based on capabilities","Only offers what wallet supports"]},{"name":"Batched Transaction","description":"Multiple operations in one request","userFlow":["dApp builds array of calls","Uses wallet_sendCalls","Wallet shows combined preview","User approves once","Show the wallet's returned atomic result and update each call state"]}],"uiComponents":[{"name":"CapabilityChecker","description":"Queries and displays wallet capabilities","states":["checking","ready","no-support"],"props":["walletProvider","onCapabilities"]},{"name":"BatchCallBuilder","description":"UI for building batched operations","states":["building","ready","submitting"],"props":["calls[]","onSubmit"]},{"name":"CallStatusTracker","description":"Shows status of batched call","states":["pending","confirmed","failed"],"props":["callId","onStatusChange"]}],"antiPatterns":[{"pattern":"Assuming all wallets support batching","why":"EOAs without 7702 can't batch","instead":"Check capabilities, fall back gracefully","severity":"critical"},{"pattern":"Promising all-or-nothing without checking capability","why":"wallet_sendCalls permits sequential execution when atomicity is not required or unavailable.","instead":"Set atomicRequired: true only when the atomic capability is advertised; otherwise explain sequential or partial results.","severity":"critical"},{"pattern":"Ignoring capability responses","why":"Offering features wallet doesn't support","instead":"Hide unsupported features from UI","severity":"high"}],"keyTakeaways":["EIP-5792 standardizes wallet call submission, status, and capability discovery.","Query wallet_getCapabilities for the target chain before offering a feature.","The capability name is atomic; atomicity is requested with atomicRequired and reported in status.","Render a sequential or partial-execution path when atomic support is absent.","Paymaster service and other capabilities are wallet/service policies, not universal guarantees."],"technicalNotes":"EIP-5792 adds wallet_getCapabilities, wallet_sendCalls, and wallet_getCallsStatus. Calls can request atomicRequired; true requires the wallet to support atomic execution for that chain, while false permits sequential execution. The atomic capability is named atomic and can report supported, ready, or unsupported state. Paymaster service is a separate capability.","lastUpdated":"2026-09-18","sources":[{"label":"EIP-5792 official specification","url":"https://eips.ethereum.org/EIPS/eip-5792","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-5792","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-5792","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-5792","markdown":"https://www.eipsfordesigners.com/standards/EIP-5792/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-5792/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-5792","official":"https://eips.ethereum.org/EIPS/eip-5792","discussion":"https://ethereum-magicians.org/search?q=EIP-5792"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}