Maybe i don’t understand what you mean by incompatible. With each other?
If dapp requests “atomicBatch”:“true” && “atomicity”:“none”, are they contradictory? Or are they just expressing that, in YoavW’s words, atomicity is “a good to have” but not tactical?
Or if they request “atomicBatch”:“false” and “atomicity”:“strict”, are you saying the wallet should be forced by the spec to assume the request is malformed and drop it for safety’s sake? I feel like how all future capabilities will interact is hard to define in advance, and “contradiction” feels pretty hard to spec out here IMHO (not discouraging you from continuing to try, I’m just not seeing the logic yet)
I’m only suggesting that EIP-5792 pick an error code to use when the wallet refuses a request because of conflicting capabilities, regardless of what the capabilities are or why they are conflicting.
2 Likes
Ah, OK, giving the wallet an optional way to express this specific fail-case would be great, I totally agree! I thought you were saying the wallet SHOULD or MUST return that error code if {hard-to-specify condition}.
I don’t see anything that maps to “contradictory/malformed-request” in the generic EIP-1193 error codes and in the CAIP-25 error codes 5000 is “unknown error” (at authorization-request level) and 5204 is “ambiguous/contradictory request” (having to do with overlapping CAIP-217 scope objects, i.e. CAIP-25-internal contradiction), which is probably the closest analogy to overlapping capability objects.
1 Like
The new changes in the naming are welcomed, and good we took the atomicity comments from Sam into consideration. Having the capabilities in separate ERCs is also a step in the right direction.
1 Like
One thing that is sorely missing from the specification, is a recommendation on the “atomicity”:
Trying to be “un-opinionated” on sending a batch leaves a lot of room for apps to hang themselves: e.g. an app sends a batch of 3 transactions through a “best effort” wallet, needs to handle all cases (that is, only 1, only 2, all 3) transaction succeeded - otherwise, the wallet can be left in limbo (or worse, in a vulnerable) state.
At a minimum, atomicity capability should be specified as SHOULD, while explaining the app has to understand and handle the consequences of sending a non-atomic batch.
wallet_sendCallsExample Return ValueThe identifier can be any string. The only requirement is that for a given session, users should be able to call
wallet_getCallsStatuswith this value and expect a call-batch status to be returned.
The term “session” is not defined in the EIP and I don’t think there is a clear implied meaning. It would be great to provide more clarity on that.
Returning capabilities per chain id might be necessary, but in the case that a capability is globally supported for all chains, how is the wallet supposed to respond? Does it make sense to ask the wallet to enumerate all supported chains?
In the previous AllERCDevs call we discussed how this EIP opens an opportunity to solve a current UX pain point in Ethereum: the problem of displaying transaction parameters to users.
In eth_sendTransaction, the parameters are expressed as an opaque calldata bytestring. Ideally the wallet would show a detailed view of the transaction parameters the user is agreeing to, but there is no simple and robust way for wallets to decode calldata. One option is to rely on databases of function signatures, but function selectors are small and clashes are easy to find. Another option is to rely on verified source code and ABIs, but this currently depends on centralized providers, essentially on Etherscan. Function selector databases by extension also depend on those providers.
wallet_sendCalls has inherited the opaque data parameter. One idea that came up in the call was to specify the data for each call not as a bytestring but as a function ABI spec and the array of function arguments to be encoded by the wallet.
I think that would be very nice but is a relatively large departure from the current spec, which is currently already in Last Call, as well as a departure from eth_sendTransaction which might hinder adoption.
As an alternative, we could keep the EIP as is, with data as a bytestring, and use the capabilities mechanism to specify an ABI per target address so that the wallet can decode it. This is an improvement over the current state of things because the dapp already knows the ABI, it just needs to communicate it to the wallet.
A couple of things to note:
- The mechanism should not be Solidity-specific. It should be possible to use different ABI formats and encoding/decoding procedures.
- This mechanism would allow a dapp to provide a false ABI that could mislead a user as to what they’re signing. I’m not sure if this is a worse outcome than being shown opaque bytes. We may conclude that the wallet should check to see if the ABI has been verified, in which case we are back to relying on verification and the mechanism doesn’t really make sense. Curious to hear other’s opinions on this.
1 Like
From some discussion in All Wallet Devs today:
MetaMask is working towards an MIP to support regular JSON-RPC batching (non-atomic) for EIP 1193
2 Likes
Hi,
Thank you for putting together this proposal!
Does EIP-5792 have considerations for disconnection between the dapp and wallet while a call is in progress (e.g., if the user goes offline for a few days or if the laptop battery runs out)? Specifically, does the dapp have a way of tracking the call in such cases? Is this seen as a potential problem, and if so, should it be addressed within this EIP?
A suggestion: it would be helpful to clarify the benefits for dapps using wallet_sendCalls over eth_sendTransaction for sending and tracking individual transactions and not just batches. You could highlight simplified transaction tracking and better handling of transaction replacements.
A quick question:
status: 'PENDING' | 'CONFIRMED';
Should we also include a status for indicating if a transaction was DROPPED or FAILED?
Thanks!
1 Like
Since all of these methods are Ethereum-specific, I’m wondering if it wouldn’t be better if they were prefixed with eth_ instead of wallet_? eth_ is not merely for clients; eth_requestAccounts has been in production for 5-6 years (ref: EIP-1102).
Also, the specification mentions CAIPs, but did the authors discuss how to reconcile these methods with CAIP-25 and CAIP-27? For instance:
- How should a dapp call
wallet_sendCallsusing CAIP-27?- Does the CAIP-27
chainIdhave to match that ofwallet_sendCalls?
- Does the CAIP-27
1 Like
One reason I think it should remain in the wallet_ namespace is that the wallet should decide how to proceed with this; there could be different options on different networks/wallets, etc.
From a dapp and wallet perspective, you cannot perform a meaningful estimate gas on batch transactions when following/utilising the json rpc spec. Let’s say you have an approve and swap and wish to submit them as a batch. You can perform the estimate gas on the approval but not the swap. When you perform the estimate gas on the approval, it will fail with a revert.
Without something like eth_multicallV1, is there an expectation that the wallet will take care of it in a non-standard way?
I can see that lately eip-5792 added a major change, which tries to make it cross-chain API.
While cross-chain wallet API might be useful, it is much more complex than moving the chainid field.
when handling cross-chain, the application must be aware of the different technical features of the different chains, like block times, gas payments, and even account addresses which might differ.
I suggest deffering cross-chain capabilities to a separate EIP.
Are there any wallets and applications already using this api?
I think there are some points where the api is not fully specified.
atomicBatch - while there is such capability, there is no way for an app to require a batch to be atomic. Missing something like “requireBatch”, to imply the TX should be aborted if the wallet can submit a single batch.
wallet_getCallsStatus is very ambigous if calls can be non-atomic.
The top level “status” can’t describe partial completions (and in fact, I don’t see how app can take action after partial completion, except for indefinite wait, since it doesn’t have any other id to track those independent requests
wallet_showCallsStatus - cannot be used generically. Since the app has no way to define what information is shown to the user (if at all), it can’t use it unless the app already knows this wallet implementation and what information it shows.
gas not including gas at all leaves the apps unable to constrain calls in any way - unable to estimate the gas, and unable to limit max used gas.
At its present state, I don’t think the API is usable, let alone close to “final”.
I agree, I assumed this would be somewhere in the EIP but it isn’t.
The EIP says this:
gives developers the option to only submit batched calls if they are executed atomically
The only way that I can see this done with the EIP as specified is to get the capabilities and if atomicBatch is reported as “supported” then assume that batches are automatically atomic? This is not what I’d interpret from “supported”, which sounds more like it is supported if requested.
From AllWalletDevs today, it looks like MetaMask (via @vandan) and WalletConnect are investigating/using these proposals for chain-specific method calls:
Seems relevant to the per-chain calls being specified here.
1 Like
I believe that making the encoding process of hex data an optional feature would greatly enhance wallet security. Users fall victim to phishing because the interaction process of the wallet pop-up window is generally incomprehensible. If this option were available, the wallet could analyze the risks involved in the interaction and then alert the user.
Hi, I have a few concerns with respect to the draft of this EIP.
First is that it seems like capabilities as returned by wallet_getCapabilities are per-chain, but capabilities as specified for wallet_sendCalls is chain agnostic. Since a wallet_sendCalls request can include calls to multiple chains, I think it would make more sense to move the capabilities parameter into the call structure so that each call can specify its own capabilities based on what its chain actually provides.
My second concern is that some functionality such as the atomicBatch capability might be provided by default on all every chain a wallet supports, which could be numerous, especially for smart contract wallets. So I think it also makes sense to add a special wildcard * in place of the chain ID for those cases where a capability is universally available.
Lastly, are there any wallet implementations of this specification in the wild at this moment? It seems like this EIP addresses a missing piece of the UX puzzle, but it sounds like it’s been in development for a couple of years so it would be good to know if it’s on the road to being finalized.