Skip to content

update syntax and example after 5792 syntax changes #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
+72 −28
Open

update syntax and example after 5792 syntax changes #139

Changes from 9 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
31c7e0a
update syntax and example after 5792 syntax changes
bumblefudge Mar 4, 2025
37dc500
update example per ReOwn input
bumblefudge Mar 10, 2025
37b91a3
good catch llbartekll
bumblefudge Apr 3, 2025
482f615
add atomic cap equivalent to new example added by erc#9529
bumblefudge Apr 4, 2025
a2967fb
good catch llbartekll
bumblefudge Apr 4, 2025
333a477
make response example slightly clearer
bumblefudge Apr 4, 2025
357fa87
match most recent syntax change on 5792
bumblefudge Apr 4, 2025
4bb0801
include every variation on getCapabilities objects and add inline com…
bumblefudge Apr 10, 2025
848dc26
finesse spec text to match new exhaustive example re: 5792 capabilities
bumblefudge Apr 10, 2025
b43ffb5
update atomic syntax to most recent PR on 5792
bumblefudge Apr 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 72 additions & 28 deletions eip155/caip25.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,11 @@ see the [eip155/caip211.md](./caip211.md) profile for further guidance on using
No namespace-wide or network-specific session properties have yet been proposed for standardization.
When crafting such properties for contextual/in-network usage, it is recommended to align one's semantics and syntax (including case-sensitive style guides for property names!) with the [EIP-6963] wallet provider interface (which extends the [EIP-1193] interface) for common properties across architectures, making sure to avoid any collisions.

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;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@adonesky1 adonesky1 Apr 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

full CAIP-2 scopes are out, remember

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

address-specific capabilities (or exceptions to override the capabilities of all other addresses in a given authorization scope) can be declared within address-keyed partitions.
See the example below, equivalent to the illustrative examples in [EIP-5792].

## Examples

Expand All @@ -52,7 +56,7 @@ Similarly, wherever possible, session properties should align closely with infor
"methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "get_balance", "personal_sign"],
"notifications": ["accountsChanged", "chainChanged"]
},
"eip155:10": {
"eip155:8453": {
"methods": ["get_balance"],
"notifications": ["accountsChanged", "chainChanged"]
},
Expand All @@ -65,16 +69,41 @@ Similarly, wherever possible, session properties should align closely with infor
}
},
"optionalScopes":{
"eip155:42161": {
"eip155:84532": {
"methods": ["eth_sendTransaction", "eth_signTransaction", "get_balance", "personal_sign"],
"notifications": ["accountsChanged", "chainChanged"]
},
"sessionProperties": {
"expiry": "2022-12-24T17:07:31+00:00",
//universal capabilities (across all eip155 chains and addresses) can sit at the top-level of sessionProperties
"caip154": {
"supported":"true"
"supported":"true"
},
"flow-control": {
"loose": [],
"strict": [],
"exoticThirdThing": [] //caller is requesting a configuration-set which the wallet will drop as unrecognized
},
"atomic": {
"supported": true
}
},
"scopedProperties": {
//chain-specific requests are made in scopedProperties per chain scope
"eip155:8453": {
"paymasterService": {
"supported": true
},
"sessionKeys": {
"supported": true
}
},
"eip155:84532": {
"auxiliaryFunds": {
"supported": true
}
}
}
}
}
}
```
Expand All @@ -94,15 +123,10 @@ Similarly, wherever possible, session properties should align closely with infor
"notifications": ["accountsChanged", "chainChanged"],
"accounts": ["eip155:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb", "eip155:137:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb"]
},
"eip155:10": {
"methods": ["get_balance"],
"notifications": ["accountsChanged", "chainChanged"],
"accounts:" []
},
"eip155:42161": {
"eip155:83532": {
"methods": ["personal_sign"],
"notifications": ["accountsChanged", "chainChanged"],
"accounts":["eip155:42161:0x0910e12C68d02B561a34569E1367c9AAb42bd810"]
"accounts":["eip155:83532:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb", "eip155:83532:0x0910e12C68d02B561a34569E1367c9AAb42bd810"]
},
"wallet": {
"methods": ["wallet_getPermissions", "wallet_switchEthereumChain", "wallet_getCapabilities"],
Expand All @@ -113,23 +137,43 @@ Similarly, wherever possible, session properties should align closely with infor
}
},
"sessionProperties": {
"capabilities": {
"0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb": {
"0x31": {
"paymasterService": {
"supported": true
},
"sessionKeys": {
"supported": true
}
},
"0x3432313631": {
"sessionKeys": {
"supported": false
}
}
"expiry": "2022-12-24T17:07:31+00:00",
"caip154": {
"supported":"true"
},
"flow-control": {
"loose": ["halt", "continue"],
"strict": ["continue"]
}
},
"scopedProperties": {
"eip155:1": {
//capabilities shared across all address in a namespace can be expressed at top-level
"atomic": {
"supported": true
}
},
"eip155:137": {
"atomic": {
"supported": true
}
},
"eip155:84532": {
"atomic": {
"supported": true
},
//address-specific capabilities can be namespaced by address, and can include address-specific exceptions to scope-wide capabilities
"eip155:83532:0x0910e12C68d02B561a34569E1367c9AAb42bd810": {
"auxiliaryFunds": {
"supported": false
},
"atomic": {
"supported": false
}
}
}
//no need to respond with empty objects or declare implicit/default capabilities per-address, i.e. no empty capabilities object required for eip155:83532:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb
}

}
}
}
Expand Down