update syntax and example after 5792 syntax changes #139

bumblefudge · 2025-03-04T10:28:56Z

Updated the 5792 wallet_getCapabilities equivalence spec language and examples of eip155/caip25.md following the introduction of the "chainId 0" convention in Alex Forshtat's PR on 5792 here.

Eyes from ReOwn (@jakubuid @pedrouid) and MM Snaps (@adonesky1 @vandan @ffmcgee725) appreciated so I can update the commit-specific link in 5792 before final call!

eip155/caip25.md

bumblefudge · 2025-04-03T10:06:06Z

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

jakubuid · 2025-04-04T05:57:15Z

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

@bumblefudge before merging, according to the last 5792 updates (https://github.com/ethereum/EIPs/pull/9529/files#diff-7a494500c37dc4b57613207d62874322198a4ced215f4a0457a0af908bb6364eR353) can we add example of "atomic": true being sent in sessionProperties/scopedProperties?

jakubuid · 2025-04-04T07:49:43Z

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

@bumblefudge before merging, according to the last 5792 updates (https://github.com/ethereum/EIPs/pull/9529/files#diff-7a494500c37dc4b57613207d62874322198a4ced215f4a0457a0af908bb6364eR353) can we add example of "atomic": true being sent in sessionProperties/scopedProperties?

E.g. in scopedProperties:

caip2:{
       "atomic":{
           "supported":true
        }
   }

CC @llbartekll

bumblefudge · 2025-04-04T08:59:33Z

OK i just added it in the commit above to match the open PR you linked to, although I'm still confused why the other capabilties are:
{ "supported": true }
and atomic is
true
! I opened a "change request" on that PR to be notified if it was just an oversight and the author updates the PR

llbartekll · 2025-04-04T12:11:45Z

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

@bumblefudge before merging, according to the last 5792 updates (https://github.com/ethereum/EIPs/pull/9529/files#diff-7a494500c37dc4b57613207d62874322198a4ced215f4a0457a0af908bb6364eR353) can we add example of "atomic": true being sent in sessionProperties/scopedProperties?

E.g. in scopedProperties:
caip2:{
       "atomic":{
           "supported":true
        }
   }
CC @llbartekll

@bumblefudge
should this be allowed?:

caip2:{
    caip10A: {
       "atomic":{
           "supported":true
        }
     }
   caip10B: {
       "atomic":{
           "supported":false
        }
     }
   }

bumblefudge · 2025-04-04T14:13:59Z

should this be allowed?:

lol no that was a typo on my part, thank you for not making me feel more embarassed than I need to

jakubuid · 2025-04-04T15:00:11Z

should this be allowed?:

lol no that was a typo on my part, thank you for not making me feel more embarassed than I need to

the point is that we need an address (caip10), because wallets can have many addresses on given chain and some of them could support atomic batches and the others not

bumblefudge · 2025-04-04T15:46:49Z

we need an address (caip10), because wallets can have many addresses on given chain and some of them could support atomic batches and the others not

Oh sorry, I missed that part. EIP-5792 only allows this to be set per-chain, and leaves it up to the wallet to manage which addresses on that chain can do it, and whether or not "from" address in the batch is one it controls (and is an onchain-address). so maybe the solution here is to leave this complexity OUT of the examples in the CAIP-25 profile, but include a solution/workaround in the WC docs, e.g. multiple namespaces for the same chain (with different addresses) where one returns true and one returns false for atomicity?

jakubuid · 2025-04-07T07:22:05Z

we need an address (caip10), because wallets can have many addresses on given chain and some of them could support atomic batches and the others not

Oh sorry, I missed that part. EIP-5792 only allows this to be set per-chain, and leaves it up to the wallet to manage which addresses on that chain can do it, and whether or not "from" address in the batch is one it controls (and is an onchain-address). so maybe the solution here is to leave this complexity OUT of the examples in the CAIP-25 profile, but include a solution/workaround in the WC docs, e.g. multiple namespaces for the same chain (with different addresses) where one returns true and one returns false for atomicity?

The 5792 wallet_getCapabilities request allows a dapp to specify the address on which it needs the capabilities: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md#wallet_getcapabilities-example-parameters

In CAIP-25 handshake, the wallet can define 5792 capabilities in front for all of the addresses it supports, hence the thinking is that scopedProperties can be used for that as @llbartekll suggested:

caip2:{
    caip10A: {
       "atomic":{
           "supported":true
        }
     }
   caip10B: {
       "atomic":{
           "supported":false
        }
     }
   }

It should be convenient for wallets to do it this way

multiple namespaces for the same chain (with different addresses) where one returns true and one returns false for atomicity?

I'm not sure if I follow how that structure would look like but I'm open for any suggestions

bumblefudge · 2025-04-07T08:13:18Z

oh god you're totally right, i forgot that the REQUEST specifies a wallet, and optionally chains, and the response specifies chains (with the per-address implicit). yeah modeling this inside CAIP-25 (where addresses are properties of namespaces) is... always going to be a little lossy/chaotic. forgive me for complicating things but I think the EIP5792 exchange

req:
getCaps( address1, [chainX, chainY])
res:
chainX: {
   <caps>
}, chainY: {
   <caps>
}

as a CAIP-25 handshake would be more accurate to translate as:

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}

(risky/potentially broken if multiple addresses are being requested) or

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}

(more faithfully roundtrip-translateable, less risky of malforming, but extremely verbose).

although it's repetitive, I actually prefer the second of the two options I just gave, because the capabilities are being expressed PER ADDRESS inside of a namespace object (and repeated for every chain that address operates on, unless it's a 0x00/sessionProperties cap available on any eip155). that is, at least, the functional complete-equivalent of the EIP5792 model. i don't like the idea of just throwing CAIP-10 partitions into scopedProperties, because each entry in sessionProperties is specified to map to a scope (i.e. a "namespace" in Reown SDK terms) and some implementations (like I believe MM's) would just drop them if they were keyed to anything else. does that make sense?

jakubuid · 2025-04-07T10:29:36Z

oh god you're totally right, i forgot that the REQUEST specifies a wallet, and optionally chains, and the response specifies chains (with the per-address implicit). yeah modeling this inside CAIP-25 (where addresses are properties of namespaces) is... always going to be a little lossy/chaotic. forgive me for complicating things but I think the EIP5792 exchange
req:
getCaps( address1, [chainX, chainY])
res:
chainX: {
   <caps>
}, chainY: {
   <caps>
}
as a CAIP-25 handshake would be more accurate to translate as:
req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}
(risky/potentially broken if multiple addresses are being requested) or
req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}
(more faithfully roundtrip-translateable, less risky of malforming, but extremely verbose).

although it's repetitive, I actually prefer the second of the two options I just gave, because the capabilities are being expressed PER ADDRESS inside of a namespace object (and repeated for every chain that address operates on, unless it's a 0x00/sessionProperties cap available on any eip155). that is, at least, the functional complete-equivalent of the EIP5792 model. i don't like the idea of just throwing CAIP-10 partitions into scopedProperties, because each entry in sessionProperties is specified to map to a scope (i.e. a "namespace" in Reown SDK terms) and some implementations (like I believe MM's) would just drop them if they were keyed to anything else. does that make sense?

Makes sense to me and I also prefer the second option 🙏
Can you update the PR with the example? I'll ping the Reown team to review and we should aim to merge it this week!

llbartekll · 2025-04-07T10:43:55Z

oh god you're totally right, i forgot that the REQUEST specifies a wallet, and optionally chains, and the response specifies chains (with the per-address implicit). yeah modeling this inside CAIP-25 (where addresses are properties of namespaces) is... always going to be a little lossy/chaotic. forgive me for complicating things but I think the EIP5792 exchange
req:
getCaps( address1, [chainX, chainY])
res:
chainX: {
   <caps>
}, chainY: {
   <caps>
}
as a CAIP-25 handshake would be more accurate to translate as:
req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}
(risky/potentially broken if multiple addresses are being requested) or
req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}
(more faithfully roundtrip-translateable, less risky of malforming, but extremely verbose).

although it's repetitive, I actually prefer the second of the two options I just gave, because the capabilities are being expressed PER ADDRESS inside of a namespace object (and repeated for every chain that address operates on, unless it's a 0x00/sessionProperties cap available on any eip155). that is, at least, the functional complete-equivalent of the EIP5792 model. i don't like the idea of just throwing CAIP-10 partitions into scopedProperties, because each entry in sessionProperties is specified to map to a scope (i.e. a "namespace" in Reown SDK terms) and some implementations (like I believe MM's) would just drop them if they were keyed to anything else. does that make sense?

maybe 2 options should be allowed?
option 1 if wallet supports given capabilities for all the addresses and option 2 for granular approach.

jakubuid · 2025-04-09T09:58:47Z

@llbartekll @bumblefudge Should we update the example with the 1st and 2nd approaches and merge this week?

to allow in response:

scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}

or

scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}

…ments

llbartekll

lgtm

jakubuid

Thank you! @bumblefudge

cryptotavares

Looks good to me, just wondering if you want to include the changes just added to 5792

adonesky1 · 2025-04-11T18:14:12Z

eip155/caip25.md

-Similarly, wherever possible, session properties should align closely with information passed as JSON objects by `wallet_` RPC methods, like capabilities or permissions. For example, the capability objects keyed to hexidecimal [EIP-155] `chainId`s defined as the expected return content of the `wallet_getCapabilities` method in [EIP-5792] should also be valid keyed the same way in `sessionProperties.capabilities`.
+Similarly, wherever possible, session properties should align closely with information passed as JSON objects by `wallet_` RPC methods, like capabilities or permissions. 
+For example, the capability objects specified in [EIP-5792] get requested per-address via the `wallet_getCapabilities` RPC method, and the returned objects are partitioned by the hexadecimal chainId when chain-specific, and inside of an object keyed `0x00` (following the chainId 0 convention; see the [`eip155`/caip2 profile](caip2)) when universal to the `eip155` namespace.
+Should an application request these capabilities and a wallet choose to pre-declare at time of connection, both parties can put such objects in the appropriately-keyed `scopedProperties` partition for chain-specific capabilities and in the `sessionProperties` (unpartitioned) for `eip155`-wide capabilities;


and in the sessionProperties (unpartitioned) for eip155-wide capabilities;

Hmmm I'm realizing that my gut feeling is that sessionProperties should be reserved for properties that live fully outside of any given namespace and that scopedProperties should allow you to map things to a namespace or a full CAIP-2 chainId scope.

yeah, i feel you, but full CAIP-2 scopes are out, remember? hehe

full CAIP-2 scopes are out, remember

in what context? They're clearly still the keys in scopedProperties?

bumblefudge · 2025-04-11T19:00:38Z

Looks good to me, just wondering if you want to include the changes just added to 5792

oh man it never ends! does this work? it's a little far-fetched as an example, but i wanted the reader to notice the heirarchy/override stuff.

update syntax and example after 5792 syntax changes

31c7e0a

jakubuid reviewed Mar 4, 2025

View reviewed changes

eip155/caip25.md Show resolved Hide resolved

update example per ReOwn input

37dc500

llbartekll reviewed Mar 31, 2025

View reviewed changes

eip155/caip25.md Outdated Show resolved Hide resolved

good catch llbartekll

37b91a3

add atomic cap equivalent to new example added by erc#9529

482f615

good catch llbartekll

a2967fb

make response example slightly clearer

333a477

match most recent syntax change on 5792

357fa87

bumblefudge added 2 commits April 10, 2025 11:02

include every variation on getCapabilities objects and add inline com…

4bb0801

…ments

finesse spec text to match new exhaustive example re: 5792 capabilities

848dc26

llbartekll approved these changes Apr 10, 2025

View reviewed changes

llbartekll reviewed Apr 10, 2025

View reviewed changes

jakubuid approved these changes Apr 10, 2025

View reviewed changes

cryptotavares reviewed Apr 11, 2025

View reviewed changes

adonesky1 reviewed Apr 11, 2025

View reviewed changes

update atomic syntax to most recent PR on 5792

b43ffb5

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

update syntax and example after 5792 syntax changes #139

update syntax and example after 5792 syntax changes #139

bumblefudge commented Mar 4, 2025 •

edited

Loading

bumblefudge commented Apr 3, 2025

jakubuid commented Apr 4, 2025

jakubuid commented Apr 4, 2025 •

edited

Loading

bumblefudge commented Apr 4, 2025

llbartekll commented Apr 4, 2025

bumblefudge commented Apr 4, 2025

jakubuid commented Apr 4, 2025 •

edited

Loading

bumblefudge commented Apr 4, 2025 •

edited

Loading

jakubuid commented Apr 7, 2025 •

edited

Loading

bumblefudge commented Apr 7, 2025 •

edited

Loading

jakubuid commented Apr 7, 2025

llbartekll commented Apr 7, 2025

jakubuid commented Apr 9, 2025 •

edited

Loading

llbartekll left a comment

jakubuid left a comment

cryptotavares left a comment

adonesky1 Apr 11, 2025

bumblefudge Apr 11, 2025

adonesky1 Apr 11, 2025 •

edited

Loading

bumblefudge commented Apr 11, 2025

update syntax and example after 5792 syntax changes #139

Are you sure you want to change the base?

update syntax and example after 5792 syntax changes #139

Conversation

bumblefudge commented Mar 4, 2025 • edited Loading

bumblefudge commented Apr 3, 2025

jakubuid commented Apr 4, 2025

jakubuid commented Apr 4, 2025 • edited Loading

bumblefudge commented Apr 4, 2025

llbartekll commented Apr 4, 2025

bumblefudge commented Apr 4, 2025

jakubuid commented Apr 4, 2025 • edited Loading

bumblefudge commented Apr 4, 2025 • edited Loading

jakubuid commented Apr 7, 2025 • edited Loading

bumblefudge commented Apr 7, 2025 • edited Loading

jakubuid commented Apr 7, 2025

llbartekll commented Apr 7, 2025

jakubuid commented Apr 9, 2025 • edited Loading

llbartekll left a comment

Choose a reason for hiding this comment

jakubuid left a comment

Choose a reason for hiding this comment

cryptotavares left a comment

Choose a reason for hiding this comment

adonesky1 Apr 11, 2025

Choose a reason for hiding this comment

bumblefudge Apr 11, 2025

Choose a reason for hiding this comment

adonesky1 Apr 11, 2025 • edited Loading

Choose a reason for hiding this comment

bumblefudge commented Apr 11, 2025

bumblefudge commented Mar 4, 2025 •

edited

Loading

jakubuid commented Apr 4, 2025 •

edited

Loading

jakubuid commented Apr 4, 2025 •

edited

Loading

bumblefudge commented Apr 4, 2025 •

edited

Loading

jakubuid commented Apr 7, 2025 •

edited

Loading

bumblefudge commented Apr 7, 2025 •

edited

Loading

jakubuid commented Apr 9, 2025 •

edited

Loading

adonesky1 Apr 11, 2025 •

edited

Loading