Skip to content
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

update syntax and example after 5792 syntax changes #139

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

update syntax and example after 5792 syntax changes #139

Changes from all commits
Commits
Show all changes
2 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
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
74 changes: 45 additions & 29 deletions eip155/caip25.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,10 @@ 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 passed via the `wallet_getCapabilities` RPC method inside of partition objects keyed to 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 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.
See the example below, equivalent to the illustrative examples in [EIP-5792].

## Examples

Expand All @@ -52,7 +55,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 +68,36 @@ 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",
"caip154": {
"supported":"true"
"supported":"true"
},
"flow-control": {
"loose": [],
"strict": [],
"exoticThirdThing": [] //caller is requesting a configuration-set which the wallet will drop as unrecognized
}
},
"scopedProperties": {
"8453": {
Copy link

Choose a reason for hiding this comment

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

why not caip2?

"paymasterService": {
"supported": true
},
"sessionKeys": {
"supported": true
}
},
"84532": {
"auxiliaryFunds": {
"supported": true
}
}
}
}
}
}
```
Expand All @@ -94,15 +117,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:0x0910e12C68d02B561a34569E1367c9AAb42bd810"]
},
"wallet": {
"methods": ["wallet_getPermissions", "wallet_switchEthereumChain", "wallet_getCapabilities"],
Expand All @@ -113,23 +131,21 @@ 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": {
"84532": {
"auxiliaryFunds": {
"supported": false
}
}
}
}
}
Expand Down