Extend CAIP-10 with CAIP-69, designating chainID 0 for EOAs #268
Conversation
CAIPs/caip-69.md
Outdated
| ## Specification | ||
|
|
||
| The account id specification will follow CAIP-10, but for EOAs use the | ||
| prefix `eip155:10:` before teh EOA account address |
There was a problem hiding this comment.
Potential type, do you mean 0 instead of 10.
I would suggest also adding the case for 1 to be designated as a contract, or non-eoa account? If so lets also add that to the examples
There was a problem hiding this comment.
Greg's idea of representing contracts or non-EOA accounts also sounds good. as per CAIP-10, eip155:1:
represents ethereum mainnet address. so the case for 1 is already taken. we would need alternative for the case of contract.There was a problem hiding this comment.
Actually we're fine, because CAIP-10 only contains one colon, where this CAIP contains two. So you would just need to pre-check the string for number colons to perform the match :)
There was a problem hiding this comment.
Potential type, do you mean
0instead of10.
YEP! Fixing!
I would suggest also adding the case for
1to be designated as a contract, or non-eoa account? If so lets also add that to the examples
Hmmmm would there be a challenge for backwards compatibility? I think its cleaner to reserve the chainID of 0 for EOAs than to add another param to the standard... however, it might make sense if this is a pattern that we can use for other ecosystems like cosmos or polkadot.
Actually we're fine, because CAIP-10 only contains one colon, where this CAIP contains two. So you would just need to pre-check the string for number colons to perform the match :)
I don't think I understand... there are 2 colons in CAIP-10:
# Ethereum mainnet (canonicalized with [EIP-55][] checksum)
eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb
There was a problem hiding this comment.
yes, in Test Cases section in https://chainagnostic.org/CAIPs/caip-10, all addresses have two colons. Would appreciate if you could clarify if there are gaps in our understanding @GregTheGreek
There was a problem hiding this comment.
I think this makes sense, but in my opinion it should be a PR on the namespaces repo.
In particular I think it could just be added as a new section to eip155/caip10
CAIPs/caip-69.md
Outdated
|
|
||
| This proposal aims to facilitate specifying EOAs as multichain accounts | ||
| extending CAIP-10 chain id specification. This is useful for both | ||
| decentralized applications to communicate that EOAs can be used for multiple |
There was a problem hiding this comment.
Possibly you meant this: " Decentralized applications can use this to specify EOA as an address with chainID 0"
There was a problem hiding this comment.
Great improvement, will revise
Oh wow I didn't know this existed... Yep, I think we should namespace against EVM based networks only |
Fixed some typos, added some clarifications thx to Krati & Greg for the suggestions
GREAT CALL! We will add it there too.
Yeah we were wondering if we can change it or not since it is marked "Final" I made the assumption that it would need to be extended with a new CAIP instead of amended.... but honestly a new paragraph there is great, if we can make it as simple as that. |
|
I think we probably need @pedrouid's input on the namespaces PR, but pretty sure it wouldn't break anything. Worst case we can figure out a different way of doing an extension spec in the namespaces. |
- Added the changes from Greg's PR here with the exception that 1 is mainnet ethereum only, not specifically a non-EOA 66166e3 - Made each paragraph 1 line
|
Honestly I don't have any objection with allowing ZERO as a chainId to flag EOAs But this definitely should not be its own CAIP and instead it should be part of the EVM namespace profile Let's move this conversation to ChainAgnostic/namespaces |
|
There isn't a ton of precedent for opening PRs on eip155/caipX.md files, so i'm happy to help on github or in DM/backchannel, @GriffGreen ! I like the basic idea and implementers have been asking for some kind of wildcard/offchain entry in the CAIP-10 namespace for a while, so I'm glad to see someone proposing a path forward. |
|
@ligi has anyone ever tried registering a NEGATIVE chainId, or a float/decimal chainId? it's kind of odd how little eip155 actually says about the data type or domain of chainId qua variable. there was an EIP to make it more explicitly typed as BIGINT and thus define a maximum value but it seems to have gotten lost and never merged. @GregTheGreek wow i just saw this for the first time. you might need to update it or withdraw it, lest some trickster add themself as co-author and revive it in a way that confuses or confounds OP's proposed behavior 😅 |
|
No I have never seen a negative or floating point chainId - my CI for ethereum-lists/chains should also fail in this case. |
I'm still standing strong with that one |
hey @bumblefudge ! I would like to raise the PR on behalf of @GriffGreen , in the correct repo.. could you please help Based on the discussions from last 2 weeks, I have raised a PR for EOA support in CAIP 10 in namespaces repo ChainAgnostic/namespaces#107, would appreciate any help/suggestions for same @GregTheGreek @GriffGreen @oed @pedrouid . |
|
Closing because addressed by ^ the corresponding PR (now merged) on |
No description provided.