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.
1 Like
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.
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.
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.