Includes:
- List of CAIPs
- List of Namespaces
- CAIPs implemented per namespace
To play on local machine:
npm install && npm run develop
Chain Agnostic Improvement Proposals
Home Page: https://chainagnostic.org
License: Creative Commons Zero v1.0 Universal
As discussed on CASA Meeting 2 we are going to register on IANA our own URI scheme under a single scheme caip:
which will then be described under our standard to identify how to part different identifiers
In order to register on IANA we need to include the following
I propose that we create a CAIP standard for describing all of these which can then be linked on IANA as a Reference
Some blockchains such as NEAR uses names such as abc.near
or abc.testnet
for account ids. See https://docs.near.org/docs/concepts/account.
ENS is another example, such as abc.eth
.
It would be desirable to allow such account ids with CAIP-10.
The required change is to relax the regexp for account_address ( [a-zA-Z0-9]{1,64}
). It should allow characters such as .
and _
.
Where do Merkle-DAGs, DAGs, Ceramic fit?
Where do GPG(+VKS), Radicle, etc fit?
Where does Eth2 sharding fit in?
An editorial PR to define which crypto systems are in scope for this group; "sequential ordering of hashed commitments" would include git systems, disjoint/sharded chains, and DAGs...
cc @wyc @oed @pedrouid @ligi will tag all in review
relevant issue 479
Originally posted by @zTgx in FindoraNetwork/findora-wiki#29
This has been previously discussed and something that should be done asap
CAIP-2 should require namespaces to reference how to resolve chain references from its node endpoints
moved from ethereum-lists/chains#135
Would be great to define a CAIP standard for Arweave. @ceramicnetwork would use this CAIP standard to link an Arweave address to a DID using an account-link document. @samcamwilliams
So that people can know that it exists.
Hi there,
Taken from CAIP-2: "CAIP-2 defines a way to identify a blockchain (e.g. Ethereum Mainnet, Görli, Bitcoin, Cosmos Hub) in a human readably, developer friendly and transaction-friendly way."
I could not find any reference on how to link to a transaction on a specific blockchain. I can imagine in most cases a CAIP-2 blockchain definition is used, a reference to one or multiple transactions is relevant as well.
I would like to refer to bridges in a similar way to how CAIP-2 refers to chains. A naive way to refer to a bridge may be to refer to it's contract address on the chain the contract is deployed. But, this lacks important information about how to interpret the data.
Is there an effort to name bridges? If not, is that something that would be worth pursuing here as a CAIP? Does anyone have opinions on things that would need to be considered?
cc @bumblefudge
Readme is out of date and doesn't contain all current CAIPs.
There's been a bit of grumbling around DIF github repos [edit: and now on the re-charter repo of the VC WG] and slack lately about how to handle the recovery bit in ES256K-R - it seems it was never registered publicly? the COSE working group at IETF registered regular ES256K, but no one attempted to register it. Is there interest in the CASA community to do this, or is there interest to set up a grant through gitcoin or DIF or any other grant-managing org to outsource it? if so, we might want to sketch such a grant in pencil before amsterdam!
As pointed out from this PR ceramicnetwork/specs#12, there is no standard way currently to reference polkadot chains so I thought it would be best to start a discussion for a new CAIP to tackle this.
From the suggestion of @joshua-mir and @shawntabrizi on the PR mentioned above, the best way to reference Polkadot chains would be to use the genesis-hash similar to how Bitcoin namespace uses BIP122 as a reference for chainId.
I will start a draft for this proposal using CAIP-4 as a template.
This is ticket is about the details of the Radicle interface for #53
Interface name
The name of this interface 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
Referring to: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md
The following claim is made:
The following secondary goals can easily be achieved:
- Can be used unescaped in URL paths
with e.g. an identifier like
eip155:1/slip44:60
However, I doubt this claim. If e.g. I was to design a RESTful HTTP API that'd allow users to query for chain-agnostic ERC721 tokens, I'd probably design the endpoint as
/api/v1/nfts/:caip-22id:
and a user would then fill in the :caip-22id
portion themselves with e.g. eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d
. So combined, it'd look like this:
/api/v1/nfts/eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d
However, going back to the original claim that CAIP-19 ids can be used unescaped in URL paths, I doubt this is the case as between eip155:1
and erc721:
, a slash /
interferes with the routing scheme on the hypothetical API.
Following the upcoming scheduled merge, having clear CAIP-2 blockchain identifiers can be greatly beneficial for navigating the ambiguities for both the humans and the machines involved in this space.
What will be the CAIP-2 identifier for:
Best,
Oren
At starname.me, we are happy to use CAIP-25 to get the list of all accounts of a wallets to synchronise wallet addresses into a starname in a very smooth way (https://docs.starname.me/for-wallets/integration-with-wallet-connect-and-the-starname-manager). However two things pops into my mind:
it would be great to be able to get the list of accounts of a wallet without specifying the list of chain-id (CAIP-2) the wallet is currently supporting, otherwise you need to know on advance which chain-id to query for each wallet. How to solve this issue with CAIP-25? or Should we create another CAIP to query a wallet and get the list of the chain-id the wallet support?
to synchronise accounts into a starname, we don't need any method permission so we would have "method" set to an empty array like []. We just want to get the list of accounts that the wallet supports and being returned as a result by CAIP-25.
What do you think @pedrouid ?
This is ticket is about the details of the Cosmos Hash interface for #2.
The name of this interface is "cosmos-hash", where "cosmos" refers to the wider Cosmos ecosystem and "hash" to the fact that native chain IDs are hashed in order to fit in the general format.
The reference
uses the format hex(sha256(utf8(chain_id)))
, with
chain_id
from the genesis file (a JSON-compatible unicode string)utf8
being the UTF-8 encodingsha256
being the the SHA256 hash functionhex
being a lowecase hex encoder[-a-zA-Z0-9]{3,47}
: no real world example known yetchain_id
is compatible to the Cosmos interface, that one must be used.# Example chain with chain_id "wonderland🧝"
cosmos-hash:843d2fc87f40eeb9198e0c2416be28a6c31a01eb9cc32499b030723d662c006f
Open questions:
Suggestion by @oed to index existing CAIPs on the README and make it requirement to update it for new CAIPs before merging
Hello people!
We at KILT, a digital identity infrastructure, are undertaking a big effort in trying to build a trust layer for assets by leveraging our existing trusted identity infrastructure. In short, we allow attesters to issue digital verifiable credentials to people that request them, with everyone being identified by a KILT Decentralized Identifier (DID).
We are now trying to move into the asset world, where entities might not necessarily be active (i.e., capable of interacting themselves with other entities). And since we define an identity as the combination of an identifier and some information attached to such identifier (the aforementioned credentials), we are trying to come up with a way to define unique and global asset identifiers.
CAIP-19 represents a very good starting point for this purpose, but we think that it lacks the "last mile" effort, being CAIP-19 just identifier that does not define any way to get useful information from such identifier.
As we are more or less deep into DIDs and Verifiable Credentials (VC), we are trying to come up with a DID definition representing a thin wrapper around CAIP-19 identifiers, but that would provide all the capabilities DIDs provide, including a standardised resolution process, a uniform representation, and the flexibility of JSON-LD. An example of that would be the possibility to resolve an Asset DID at a given block hash, without having to make the block hash part of the identifier (as there is an ongoing discussion about the subject). Another potential advantage, would be the possibility to use information specified in the DID specification, such as the alsoKnownAs
, canonicalId
, and equivalentId
properties, to link multiple CAIP19-based assets together and support inter-chain asset teleports, where needed.
I am therefore asking the CAIP community to provide (no rush 😃) feedback to our ongoing standardisation effort for the new Asset DID method, of which a draft (still a PR) can be found here -> https://github.com/KILTprotocol/specifications/blob/76f66d8f8ef75fbdc6999914056bb7a7b18c5340/docs/did/asset-did-spec.md. Not sure if this is the best place, but I am willing to move the conversation over some other channel, if needed.
The initial version of the spec is willingly basic, because we want to avoid making it KILT-centric and would love this to be a community effort to write something that is extensible and flexible enough to accommodate multiple resolvers and multiple use cases.
Thanks in advanced for any feedback!
This is just a note that some parallel or overlapping work might be going on in W3C CCG: https://github.com/w3c-ccg/blockchain-links.
I created a Github issue here: w3c-ccg/blockchain-links#1 to raise awareness in W3C CCG and avoid duplicative work in either of these groups. Note, I'm not part of blockchain-links.
I'd like to highlight an issue with the current CAIP-2 chain identification format. There may be room for another such chain identification schema to be created, possibly as a CAIP-2 compatible extension (via a new prefix).
The issue is that the current schema treats chains as singletons, but without appreciation for the possibility of forks. The power of hard fork is an incredibly powerful social tool that is only present if the tooling all the way up and down the stack allows users to easily participate in exercising their own fork preference.
The current schema, for example, ensures that by encoding ethereum as eip155:1
, if there is any contentious hard-fork on ethereum, it is unclear what identifier would apply to which end of the fork, and this can result in a variety of issues:
There are many other reasons to make fork-friendly software, and I think I put off writing this post in part because I never felt ready to make the full case, and here I will just accept that I have not made the full case, but instead claim that this is valuable, and if you disagree then I or others can continue to explain why. I'm not sure if it's a contentious point.
Historically chain_id assignment has gone to the stronger chain claims the prior identifier, and the smaller chain then hard-forks to give itself replay protection, but maybe we could design a solution that does not require squatting identifiers, but instead identifies chains by their ongoing uniqueness?
I don't have a simple solution to this, but I have seen approaches, and so I'd like to start this thread to discuss possible fork-friendly chain identifiers: Chain identifiers that can retain as much specificity as possible in a fork-tolerant world.
An example of this I've seen is the truffle blockchain-utils library, which proposed an ethereum-chain identifying schema that identifies a chain by both its genesis block and a later block, like: blockchain://<genesis hash>/block/<latest block at uri creation>
(Credit to @timcoulter)
A limitation of this strategy is that a parser needs to be aware of any block that may be used as <latest block at uri creation>
, but I could imagine an optimized version where the second block-hash referenced is the block after a contentious fork.
Anyways, looking forward to seeing how others might imagine identifying chains in fork-tolerant architecture.
This is ticket is about the details of the Ethereum interface for #2.
The name of this interface should either be "ethereum", referring to the wider Ethereum ecosystem.
The definition is delegated to EIP155. The reference format is eip155-%d
, where %d
is an unsigned integer in decimal represenation and corresponds to CHAIN_ID
of EIP155.
Note: due to length restrictions of the reference
field, the largest supported CHAIN_ID
is 9999999999999999999999999999999999999999.
# Ethereum mainnet
ethereum:eip155-1
# Görli
ethereum:eip155-5
# Auxilium Network Mainnet
ethereum:eip155-28945486
Open questions:
ethereum
or evm
?ethereum
, see #3 (comment)Over the last weeks, I've been busy figuring out
But now the more I think about it, the better it'd be if we had a unique identifier for blocks.
So far, in CAIP19 and the #119, I had proposed adding a #123 (aka #<block number) fragment to the identifier. But really, the block number isn't just a place in time like e.g. 2022-07-08. A block number plus a network name also refers to a piece of data on a blockchain. And a block number by itself, e.g. "123" isn't all that useful without the respective network.
In #119, I did a survey for how block numbers on different networks look like and it suggests that it's a natural & incrementing number. Similar to CAIP-19 on asset types/ids, should we have a block number?
# Ether Token
eip155:1#block:123
# Bitcoin Token
bip122:000000000019d6689c085ae165831e93#block:123
# ATOM Token
cosmos:cosmoshub-3#block:123
On solana, all contracts are stateless and state is instead represented using "accounts". More specifically, all fungible and non-fungible tokens are using the same instance of token contracts and for each token:
And the difference between fungible token and non-fungible token is that non-fungible token mint has a total supply of 1 and zero decimal place.
So maybe we could use mint address and account address for solana here. Based on CAIP-19 and CAIP-30
note Solana support semi-fungible token where 1 mints have multiple token account
As a reference OpenSea beta is also using mint as "token ID" :
https://opensea.io/assets/solana/3Fif3sYuL7vfVifb3gDYQym8THCfaU3DQo1ctuXMu7dz
eg.
# CryptoKitties Collectible ID
eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769
# One Solana Mainnet NFT
solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ/spl-mint:{the-token-mint-address}/{the-token-account-address}
The current specification for Ethereum NFTs (both CAIP-22 and CAIP-29) silently assumes that token id can be represented as integer, like eip155:1/erc1155:0x28959Cf125ccB051E70711D0924a62FB28EAF186/0
or eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769
. It is worth noting that token id in the respective ERCs are uint256
which exceeds usual number representation of almost every programming language.
In order to parse large token id, one has to rely on some sort of big integer support, be it a library or language-provided feature. For JS, which is the predominant language and platform to interoperate with blockchains, this requires either ES2020 (which is a big pain for library authors, because of deficient bundlers used downstream) for native BigInt
or using some heavy library like BigNumber.js
. At the same time, if the token id is passed as hex-string, i.e. 0xbc6b9
for 771769
, there is no need for the dangerous tricks. Moreover, it seems, like hex representation for token id is already commonly used in applications.
So, here is a request for comments. Let's adjust the specifications for EIP1155 and EIP721, so that token id is represented as a hex-string.
CC @mikehroth, @oed
I'm working on a go implementation of CAIP i'd love to contribute to the organization if you are interested: https://github.com/tarrencev/go-caip
Currently the index of CAIPs in the readme frequently get out of date. It would be great if we had a github action that updated the index after a PR is merged or something like that.
For any evm-compatible chain, by generating the data necessary to execute a JSON-RPC "eth_call", combined with a block number, this may yield a unique identity.
Say in block x+1 I commit the following contract on-chain
contract {
function foo(uint8 bar) public returns (uint8) {
return bar + 1;
}
}
then I by hashing the function signature:
bytes4(sha3("foo(uint8)"))
I can generate the commonly known 4 byte function signature. But with the help of the contract abi specification I can also generate a specific call signature that combines the function signature with actual inputs. In a library of mine, I'm doing this using web3-eth-abi.
So e.g. combining the result of bytes4(sha3("foo(uint8)"))
and a uint8 5
yields another hash that uniquely identifies calling an on-chain function with a certain value.
That in itself isn't interesting yet as this type of identifier can change depending on when you call the RPC endpoint as e.g. new blocks could alter the outcome of the call. However, if you were to make this call towards a specific confirmed block, then you'd always get the same deterministic outcome, which means that "eth_call" signature and block number are a unique identifier for a datum on an evm chain.
If e.g. I wanted to know the price of a Uniswap pool pair e.g. ETH/USDC 2 weeks ago (or x blocks ago), if we had a CAIP identifier, we could start identifying the exact price using a CAIP ID. E.g. we could use a similar structure as CAIP-22
eip155:1/contractAddress/blockNumber/callSignature
Additionally, this would translate nicely into JSON RPC calls too.
Line 50 in 6beec4d
tokenURI(0)
: https://etherscan.io/address/0x9CB7712C6A91506e69E8751fcb08e72e1256477D#readContractfrom EIP-721: https://eips.ethereum.org/EIPS/eip-721
NFT Identifiers
Every NFT is identified by a unique uint256 ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair (contract address, uint256 tokenId) will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a “black box”. Also note that NFTs MAY become invalid (be destroyed). Please see the enumeration functions for a supported enumeration interface.
This is a refinement of #1 and especially #1 (comment) and kudos go to everyone envolved.
The goals of the general chain ID format is:
5.-8. are open questions to me and I'd love to hear feedback on those. Especially the requirement for a case-insensitive format seems seems to limit the implementation of reference
.
chain_id = a case-sensitive string in the form: interface + ":" + reference
interface = a case-sensitive string in the form: [-a-z]{3,16}
reference = a case-sensitive string in the form: [-a-zA-Z0-9]{3,47}
where interface
identifies a document describing how reference
is composed.
The interface
typically corresponds to a class of blockchains and allows delegation of
the reference
format to an ecosystem-specific standard.
Example interfaces are "ethereum" for all the blockchains that can be identified by EIP-155,
"bitcoin" for Bitcoin and closely related projects as Litecoin, or "cosmos" for projects that
build on top of Tendermint.
reference
should strive for uniqieness within the interface. For user-choosen chain IDs
(e.g. EIP-155 or Tendermint chain ID), uniqueness cannot be guaranteed and it is reponsibility
of registries and communities to resolve collisions.
# Ethereum mainnet
ethereum:eip155-1
# Bitcoin mainnet (see https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki#definition-of-chain-id)
bitcoin:bip122-000000000019d6689c085ae165831e93
# Litecoin
bitcoin:bip122-12a765e31ffd4059bada1e25190f6e98
# Feathercoin (Litecoin fork)
bitcoin:bip122-fdbe99b90c90bae7505796461471d89a
# Cosmos Hub (Tendermint + Cosmos SDK)
cosmos:cosmoshub-2
cosmos:cosmoshub-3
# Binance chain (Tendermint + Cosmos SDK; see https://dataseed5.defibit.io/genesis)
cosmos:Binance-Chain-Tigris
# IOV Mainnet (Tendermint + weave)
cosmos:iov-mainnet
# Lisk Mainnet (LIP-0009; see https://github.com/LiskHQ/lips/blob/master/proposals/lip-0009.md)
lisk:lip9-9ee11e9df416b18b
# Random max length (16+1+47 = 64 chars/bytes)
blockchain1-hash:xip3343-8c3444cf8970a9e41a706fab93e7a6c4-xxxyyy
Open questions
_
as an alternative separator in reference
?Thoughts?
Hey,
we are currently working on implementing the CAIP-2 and CAIP-19 standards at the ITSA.global.
I realized that it is difficult to find out, which chainIds are actually community-approved and which are not.
Could we brainstorm on how to list those standards? We were also not sure about the case-sensitive spelling. For example: is it EIP155 or is it eip155 like in the examples?
When we can agree on a process to approve this and, more importantly, on a place to list the chainIds, the ITSA could reference and circulate this.
Hello! I work at Okta/Auth0, am an advisor to Dynamic, and maintain various Node.js packages for identity-related functionality (Passport.js, OAuth2orize, etc.)
I've put together a proposal on how to represent blockchain accounts and assets in a JWT. As off-chain applications adopt Web3 technologies, through specifications such as CAIP-122, this allows services to have a common way to do authorization based on accounts or assets owned (token-gating).
I'd love to get this communities feedback on the proposal. If there's interest, I will submit a PR to this repo consideration as a CAIP. Thanks!
This would allow on-chain assets to be referenced in a chain-agnostic way! 🚀
I started a Rust implementation of CAIP, currently supporting CAIP-2 and 19: https://github.com/public-awesome/rs-caip. Before I publish the crate, I wanted to check if the code should live in this organization instead of Public Awesome.
CAIP-10 has received a lot of feedback within the last year including some criticisms over its structure. Many Twitter and Discord threads have been written about what would constitute an ideal multi-chain account identifier from which it has also generated new CAIP proposals (#50).
A lot of feedback has also been generated recently in an Ethereum Magicians thread: https://ethereum-magicians.org/t/chain-specific-addresses/6449
Additionally some polls were also created on Twitter:
Poll 1 - https://twitter.com/SchorLukas/status/1404831686714613769
Poll 2 - https://twitter.com/pedrouid/status/1404869512512606218
From my perspective there is essentially a division between 3 main identifiers:
A - "0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1" (current CAIP-10)
B - "evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb" (updated CAIP-10)
C - "zUJWDxUnc5gJJSWFzxyKkmLp1dgyxiPYT3BrT4" (proposed CAIP-50)
From both polls and also from the Ethereum Magicians thread, the majority supports the identifier with format B.
This would mean that it would require the following changes:
specific@generic:middle → generic:middle:specific
bip122 → btc
eip155 → evm
cosmos → cosm
polkadot → dot
I propose that we make these changes to respective CAIP standards which are in DRAFT status with two separate PRs for each change and follow up with discussions for each.
This is ticket is about the details of the Cosmos interface for #2.
The name of this interface is "cosmos", referring to the wider Cosmos ecosystem.
The reference
uses the Tendermint chain_id
from the genesis file directly (a JSON-compatible unicode string), assuming it matches the case-sensitive pattern [-a-zA-Z0-9]{3,47}
. Otherwise the Cosmos Hash interface must be used.
[-a-zA-Z0-9]{3,47}
: Cosmoshub, Binance, Cosmos Testnets, …During the development of this chain ID definition, we came across changing chain IDs for Cosmos Hub (cosmoshub-1
, cosmoshub-2
, cosmoshub-3
). A new chain ID is assigned every time Cosmos Hub dumps the current blockchain state and creates a new genesis from the old state. Technicalls this leads to different blockchains and can (and maybe should) treated as such. For this specification, we treat them as different blockchains. It is responsibility of a higher level application to interprete some chains as sequels of each other or create equality sets.
# Cosmos Hub (Tendermint + Cosmos SDK)
cosmos:cosmoshub-2
cosmos:cosmoshub-3
# Binance chain (Tendermint + Cosmos SDK; see https://dataseed5.defibit.io/genesis)
cosmos:Binance-Chain-Tigris
# IOV Mainnet (Tendermint + weave)
cosmos:iov-mainnet
Open questions:
[-a-zA-Z0-9]
be whitelisted (see also #2)This is ticket is about the details of the Algorand interface for #2.
The name of this interface should be "algorand", referring to the algorand blockchain networks.
The Chain ID, as defined by Algorand, is the genesis hash of the respective Algorand network.
The MainNet, TestNet, and BetaNet Algorand networks.
# Algorand MainNet
algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=
# Algorand TestNet
algorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=
# Algorand BetaNet
algorand:mFgazF+2uRS1tMiL9dsj01hJGySEmPN28B/TjjvpVW0=
Began discussing this topic within the document for the Interchain UX working group here.
Basically CAIP-19 identifies an asset by its origin but doesn't include anything about whether the asset is being accessed in it's native setting or in a new setting, reached via bridges or IBC. An ATOM that is on the Cosmos Hub is similar but fundamentally different from an ATOM that has been moved to Kava via IBC. It is also different from an ATOM which has been moved to Terra after being moved to Kava. There will likely be multiple bridges to the Cosmos ecosystem from Bitcoin and Ethereum, which means there will be different versions of Eth and BTC that have different features and security assumptions based on the path they took.
This information is important for a user to understand for the sake of valuing the assets properly, but also for client software to understand how to interact with the assets.
Should CAIP-19 be extended to contain asset path information? Should there be a new CAIP for asset path resolution? What should be the recommended method for resolving an asset's path? What should be the recommended method for user interfaces to display the different varieties of non-native assets?
Hi @ligi
I wrote a message on the chain agnostic discord. Can we create a repo to onboard new members of the chainagnostic initiative?
Adli and Myself propose to help to get more blockchains member particularly to get their namespace for CAIP-2 and also we can structure a little bit the different working groups.
I did that as a draft that we could put in a chain agnostic repo:
https://github.com/antoineherzog/casa
Maybe we can organize a quick call to talk about it :)
This is ticket is about the details of the EOSIO interface for #2.
The name of this interface is "eosio", referring to the EOSIO open-source blockchain platform.
The definition is delegated to the EOSIO Transactions Protocol Documentation, the Chain API Plugin Documentation of the EOSIO Developers Manual and the pull request that implemented its generation Chain ID generation implementation pull request.
The Chain ID, as defined by EOSIO, is the SHA256 hash of the genesis state of the chain, represented as lower case hexadecimal number of 64 digits. In order to fit the reference restrictions, the format is a 32 character prefix of the Chain ID.
All blockchains using the EOSIO blockchain platform.
This is a list of manually composed examples
# EOS Mainnet
eosio:aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906
# Jungle Testnet
eosio:e70aaab8997e1dfce58fbfac80cbbb8fecec7b99cf982a9444273cbc64c41473
# Telos Mainnet
eosio:4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11
# Telos Testnet
eosio:1eaa0824707c8c16bd25145493bf062aecddfeb56c736f6ba6397f3195f33c9f
Both Hedera and Hive encode heirarchies and/or checksums into their native addressing schemes with .
and/or -
characters-- should CAIP-10 be upgraded at some point to expand their regex to include those two characters for more straight-forward support of Hedera, Hive, and perhaps other chains I know nothing about? (note to self: old regex should go into Backwards Compat section if so!)
See #95 and the hedera/caip10.md file
This ticket is about the details of the GPG interface
The idea behind this CAIP is that we should be able to define e.g. in a agnostic way a GPG fingerprint or other GPG primitives of a user.
The name of this interface should be "gpg", referring to the GNU Privacy Guard (aka GnuPG or GPG).
I would suggest to use the different primitives as reference definitions.
Examples
# GPG fingeprint
gpg:fpr
Hive and Hedera both use .
s and -
s in their native addresses-- there may also be corner-cases or testnets or checksums or other places where CAIP-10 is too constrictive. Would be worth discussing:
It would be good to discuss this at our next meeting!
See #95 and the hedera/caip10.md file
This is ticket is about the details of the Bitcoin interface for #2.
The name of this interface should be "bitcoin", referring to the wider Bitcoin ecosystem, including multiple forks of the chain and the code.
The definition is delegated to BIP122. The reference format is bip122-%s
, where %s
is a 32 character prefix of the block hash from BIP122 (lower case hex).
# Bitcoin mainnet (see https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki#definition-of-chain-id)
bitcoin:bip122-000000000019d6689c085ae165831e93
# Litecoin
bitcoin:bip122-12a765e31ffd4059bada1e25190f6e98
# Feathercoin (Litecoin fork)
bitcoin:bip122-fdbe99b90c90bae7505796461471d89a
Open questions:
zkSync has the same chain id as Ethereum(Mainnet:1, Ropsten:3), how will the Blockchain ID of zkSync be defined?
Possible examples:
# zkSync Mainnet
zksync:1
From discussions at CASA Berlin, MetaMask is deprecating eth encrypt / decrypt https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686
More generally, as a CAIP, we believe it would be useful to document a secure way for blockchain key material to be used for encryption and decryption.
This is sort of a CAIP-25 method, but is very much not chain specific as it can be accomplished with just wallet client interaction, without having to connect to an online blockchain.
This is issue is an "intent to write a CAIP". If you are interested in participating in the process, please leave a comment as we organize calls and a working group.
This is ticket is about the details of the Lisk interface for #2.
The name of this interface should be "lisk", referring to the wider Lisk ecosystem.
The definition is delegated to LIP9. The reference format is lip9-%s
, where %s
is a 16 character prefix of the hash from LIP9 (lower case hex).
# Lisk Mainnet (https://github.com/LiskHQ/lips/blob/master/proposals/lip-0009.md#appendix-example)
lisk:lip9-9ee11e9df416b18b
# Lisk Testnet (echo -n "da3ed6a45429278bac2666961289ca17ad86595d33b31037615d4b8e8f158bbaLisk" | sha256sum | head -c 16)
lisk:lip9-e48feb88db5b5cf5
Open questions:
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.