bonus points if there's some kind of auto-generated table of contents matrix that shows status of caip for each file from YAML frontmatter!

for guidance/template, look at how EIP repo does this

Thanks to @ntn-x2 for point out the new GenesisHash function in xcm v3 , and patiently explaining to me the problems with existing CAIP-2 spec!

I merged the existing draft to allow @ntn-x2 to take the pen on an overhaul PR, which as I currently understand it needs the following issues addressed:

• when more detailed xcm v3 docs go live, update links in readme.md
• are there any chains that cannot be addressed by genesis hash?
• should there be a section warning people about migrations? does losing a parachain auction or changing id and restarting as mentioned by joe create a new CAIP-2? if there is any way to find out from a node about a previous NetworkID/CAIP-2 it might be worth mentioning here since the target audience may never have thought about these corner-cases
• Given that 32 char CAIP-2s are allowed, would it make sense to use the whole genesis hash instead of truncating it? it feels like translating to and from absolute-referenced CAIP-2s to relative-referenced Multilocations would necessitate being able to define NetworkID as ByGenesis, so having the whole one might be needed.

As @silverpill pointed out in another thread, the example in CAIP-122 lists an address in Solana-native format, NOT in CAIP-10 format as specified above in the spec. Shouldn't it line 116
read
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp:GwAF45zjfyGzUbd3i3hXxzGeuchzEZXwpRYHZM5912F1
instead of
GwAF45zjfyGzUbd3i3hXxzGeuchzEZXwpRYHZM5912F1
?

@haardikk21 @ukstv @zachferland someone who knows solana help me out here :D

Looks like some work already started in ChainAgnostic/CAIPs#43

Supercedes CAIPs 3, 21, 22

CAIP-2

Suggested namespace: monero.

There is one mainnet and two public testnets: https://monerodocs.org/infrastructure/networks/. These networks don't have universally-agreed chain IDs. Most of the time people use labels mainnet, stagenet and testnet, and the software returns these labels in some RPC responses, for example here:

https://www.getmonero.org/resources/developer-guides/daemon-rpc.html#get_info

nettype - string; Network type (one of mainnet, stagenet or testnet).

Internally, software defines NETWORK_ID constants for each network, but I don't know where these identifiers are used:

https://github.com/monero-project/monero/blob/v0.18.1.2/src/cryptonote_config.h

It is also possible to create a private testnet, often referred to as regtest.

There's a number of Monero forks, most notable of them is Wownero: https://wownero.org (as far as I know it is a separate chain which has a different genesis block).

Wownero community uses the same network labels (mainnet, stagenet, testnet), but in the source code Wownero has different NETWORK_ID constants:

https://git.wownero.com/wownero/wownero/src/tag/v0.10.0.3/src/cryptonote_config.h

If forks will not be included in the namespace, we can just use network labels. Otherwise, it might make sense to use NETWORK_ID, truncated hash of genesis transaction or some other identifier.

CAIP-10

Monero currently has three types of addresses:

• https://monerodocs.org/public-address/standard-address/
• https://monerodocs.org/public-address/subaddress/
• https://monerodocs.org/public-address/integrated-address/

The length varies between 95 and 106 characters, so it exceeds 64-char limit set by CAIP-10 (which is being discussed in ChainAgnostic/CAIPs#179).
The public spend key has the size of 32 bytes, so it potentially can be used as CAIP-10 account identifier, though I'm not sure if it's safe to do that.

The Rationale section says P2SH address types map well enough to EVM accounts for the purposes of CAIP-10 interop, but the examples start with 1 and are thus P2PKH addresses.

https://bitbox.swiss/blog/what-are-bitcoin-address-types/

Also, the regexp doesn't constrain the first byte of the address with an enum, and probably should if only certain BTC address types are valid...

Speaking of which, what about taproot and segwit addresses?

not intuitive, but will save us a hassle if this has to move off GH some day. also SEO/pagerank

Checked the Solana docs for some basic materials about accounts, and found:

"
A key may be one of:

• an ed25519 public key
• a program-derived account address (32byte value forced off the ed25519 curve)
• a hash of an ed25519 public key with a 32 character string

" (Src)

and also

"
Keypairs are stored in wallets. Before receiving tokens, you will need to create a wallet. Once completed, you should have a public key for each keypair you generated. The public key is a long string of base58 characters. Its length varies from 32 to 44 characters.

" (Src)

The only corner case that needs a bit of thinking is what to do with the 44-character Ed25519s-- all other address types could be CAIP-10s as is, without need of transformation, and leaving the type "sniffing" out of scope, right? since we've got solana:{32-char CAIP-2}: already, I'm assuming 44char is too many...

This is ticket is about the details of the Radicle interface for (PR in the works)

Name
The name of this namespace should be "radicle", referring to the radicle code collaboration protocol.

Reference definition
The definition is delegated to Radicle. The format corresponds to the commonly used abbreviation for each VCS that will be supported by the Radicle protocol.

Examples

# git
rad:git

# Mercurial 
rad:mercurial

# pijul
rad:pijul

Contributors have been tripped up a lot recently on what a new namespace is in two different ways:

• An L2 with new capabilities, different consensus, etc could be a namespace unto itself, or just a set of caveats/additions to the namespace of its L1-- the major difference seems to be whether the L2 speaks its own RPC (in addition to the L1s). Does this mean there is a 1:1 RPC<>namespace definition that should be made more explicit?
  • corner case: as more and more L1s support "EVM-mode" (a second set of RPC commands and endpoints), and particularly when only ONE chain within that namespace (e.g. Moonbeam in Polkadot) does so, should there be some kind of new CAIP-X for "extensions"? would evm/caipx.md become an infinite list of special cases, if so?
• should the CAIP-104 and/or the template make all of this more explicit?

PRs welcome!

I am not sure this is the right repo, or if I should open an issue on the CAIP repo.

I know there's an open ticket for updating the CAIP-2 and CAIP-10 for Polkadot based on the new XCM v3 format.
Nevertheless, we are currently working on a cross-chain identity solution where we would need to rely on the Polkadot feature that lets users use the same account on multiple chain, by simply encoding the public key differently. Specifically, there is a "generic Substrate address" which always starts with the number 5, e.g., 5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr. This means that given a public key, it could be encoded in a lot of different ways, but also always to something that starts with 5.

This goes beyond the concept of a CAIP-10 identifier being "anchored" to a CAIP-2 chain, and I was wondering if there is discussion in this direction already, given the increasing popularity of cross-chain interactions.

I guess a blockchain account would still have to be bounded somehow, but I would rather see it bound to a namespace, than to a specific chain ID. For instance, while a specific Polkadot blockchain account could still be identified by a CAIP-10, anchoring it to a specific chain and nowhere else, it must also be possible NOT to anchor it to a specific chain. Do you think making the reference component of a chain ID optional would be a way? Or would this call for a new CAIP that indicates "a group of related chains"? Something like polkadot:<account> would include any chain-specific account that can be encoded from the starting account, on any Polkadot chain, while a polkadot:<chain_reference>:<account>, would still refer to a specific chain, for which the discussion was opened in the ticket linked above.

Add CAIP-2 for Reef chain.

Reef is a modular layer 1 blockchain for DeFi, NFTs and gaming. It is built with Substrate, has EVM support and uses Nominated Proof of Stake consensus.

Track any discussions related to the MultiversX namespace

MultiversX namespace PR

Proposed Syntax

caip10-like address:    namespace + ":" chainId + ":" + address
namespace:              mvx
chain Id:               1, D or T
address:                bech32 formatted MultiversX address (erd1...)

Test Cases

MultiversX Mainnet
mvx:1:erd1uapegx64zk6yxa9kxd2ujskkykdnvzlla47uawh7sh0rhwx6y60sv68me9
mvx:1:erd1qqqqqqqqqqqqqpgqhe8t5jewej70zupmh44jurgn29psua5l2jps3ntjj3 ( Smart Contract )

MultiversX Devnet
mvx:D:erd1devnet6uy8xjusvusfy3q83qadfhwrtty5fwa8ceh9cl60q2p6ysra7aaa

MultiversX Testnet
mvx:T:erd1sea63y47u569ns3x5mqjf4vnygn9whkk7p6ry4rfpqyd6rd5addqyd9lf2

The generic CAIP-19 spec takes a very generous stance to what a tokenId should look like when talking about Asset ID's. Basically anything that is between 1-78 characters long flies (alphanumeric, hyphen, underscore, periods)

The EIP155 namespace spec however is only concerned with ERC-721 - which necessitates a uint256 type for tokenId. It should not allow alphabets, periods, hyphens, underscores, or periods - and simply be a numeric Regex string for 1-78 characters long.

Courtesy of ChatGPT, here's a Regex that seems reasonable:

^(?=.*\d)[\d]{1,78}$

• ^ asserts the start of the string.
• (?=.*\d) is a positive lookahead assertion, ensuring that at least one digit is present in the string.
• [\d]{1,78} matches any digit character (0-9) between 1 and 78 times.
• $ asserts the end of the string.

If this looks good, happy to make a quick PR to fix.

See this comment from 2020. @chunningham what you know about this?

Hello 👋

I believe one of the examples mentioned in Solana CAIP-19 is incorrect

Instead of

# One Solana Mainnet NFT：Pesky Penguins #398
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/token:Fz6LxeUg5qjesYX3BdmtTwyyzBtMxk644XiTqU5W3w9w

the example should be

# One Solana Mainnet NFT：Pesky Penguins #398
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/nft:Fz6LxeUg5qjesYX3BdmtTwyyzBtMxk644XiTqU5W3w9w

In the process of transforming 12 CAIPs into 11 Namespaces, I gradually realized that since many developers will be encountering new ecosystems for the first time, a link to the EIP/BIP-equivalent protocol-upgrade governance process/archive may be as important as links to the Developer Docs for SDKs and node APIs. I already included links to these in most of the ## References sections, but someone (maybe me, if no one else does it) should go through and add a "## Governance" section to all the README.mds. I added this to the template at the very last minute, the only README that already has one is the Hedera one.

no one knows this niche link style we use

1.) DIDs and VCs are examples of very blockchain-like capabilities that a blockchain wallet might want to support, without requiring any communications with nodes. Currently, CAIP-169 tries to update some work done by Mircea and Oliver at Veramo/Mesh to bring VC protocols into the toolkit of Wallet-Connect wallets. These are namespace-independent, and entirely node-free. So where do dapps put these methods when calling CAIP-25 on the wallet? A scope object called wallet, I'm thinking.

2.) I'm presuming there are other offchain capabilities (PassKey comes to mind, or FIDO, or on-device biometrics) that it might behoove us to abstract and standardize some day! These would also go in the wallet scope space, right?

3.) Note, in the evolution of the EVM RPC methods, wallet_changeEthereumChain and a few other wallet_-prefixed methods have been defined by EIPs. These should probably live in eip155, confusingly enough, since wallet::changeEthereumChain doesn't make much sense for the non-EVM world!

Please chime in if you have objections, or if you have other use-cases, or if you just want to bikeshed the name of the scope:

• wallet
• offchain
• nodefree

Hello 👋

I'm bringing up what I believe is a discrepancy between Solana CAIP-2 and Solana CAIP-10. Specifically, the Chain IDs do not match up, and I believe CAIP-2 has the correct values and CAIP-10 does not.

According to the Chain ID Resolution Method in CAIP-2:

To resolve a blockchain reference for the Solana namespace, make a JSON-RPC request to the RPC Endpoints of a blockchain node with method getGenesisHash, for example:
// Request
{
"id": 1,
"jsonrpc": "2.0",
"method": "getGenesisHash"
}
// Response
{
"id": 1,
"jsonrpc": "2.0",
"result": "5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d"
}

And in fact, executing this resolution method on the Solana Mainnet RPC endpoint:

curl https://api.mainnet-beta.solana.com -X POST -H "Content-Type: application/json" -d '
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getGenesisHash"
}
'

yields this result

{"jsonrpc":"2.0","result":"5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d","id":1}

So the Chain ID for Solana Mainnet is 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d, as stated in CAIP-2, and the Chain ID stated in CAIP-10 is wrong. This is reproducible with the stated Chain ID for Solana Devnet.

Please let me know if I'm missing something, otherwise I'd be happy to open a Pull Request to correct this. Thanks!

Both as a template for other caip25 profiles and as a test-case for L1-vs-L2 RPC dictionaries 😬

it might not require much thought, just reformatting? @haardikk21 @ukstv @wyc

https://namespaces.chainagnostic.org/bip122/caip2#resolution-method :

To query for a Chain ID to represent or checksum a BIP122 reference, make a JSON-RPC request to the blockchain node with method getblockhash, for example:
[...]
The response will return as a result value the hash for the block with height 0 that should be sliced to its first 16 bytes (32 characters for base 16) to be compatible with the reference syntax defined above.

This is inconsistent with BIP 122 for forked chains:

The chain ID of a chain is the block hash of the corresponding genesis block. For forked chains, it's the block hash of the first block after fork.

So querying the hash will typically give the height of the fork, not height 0. Also, this method typically will not return any height if the chain has block hashes that are not expressed as 32 hex digits (or its nodes do not have a getblockhash JSON-RPC method).