Includes:
- List of CAIPs
- List of Namespaces
- CAIPs implemented per namespace
To play on local machine:
npm install && npm run develop
Chain-Agnostic Namespaces host informative specs and profiles of CAIPs (Chain-Agnostic Improvement Proposals) per blockchain ecosystem
Home Page: https://namespaces.chainAgnostic.org/
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:
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-casesMultilocations
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
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.
Monero currently has three types of addresses:
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:
" (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:
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
caip10-like address: namespace + ":" chainId + ":" + address
namespace: mvx
chain Id: 1, D or T
address: bech32 formatted MultiversX address (erd1...)
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.md
s. 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).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.