CAIPs
CAIPs copied to clipboard
ChainAgnostic
How to refer to attestations as asset class?
Hello!
We have released a new feature that allows to issue credentials to assets that are identified by CAIP-19 identifiers. Of course, a credential could also be issued to a previous credential, hence the need to define a CAIP-19 identifier for such credential. In our (KILT) context, a credential is composed of two parts: the credential itself, with the information about the subject, and its on-chain attestation, which is a hash of part of the credential content.
Because an asset namespace should be as generic and broad as possible, I wanted to bring this matter up for discussion.
I was thinking of something like <chain_id>:attestation:<kilt_reference>/<kilt_identifier>, so for instance for our two different types of credentials, we would have <chain_id>:attestation:kilt-credentials-v1:<credential_hash> and <chain_id>:attestation:kilt-public-credential-v1:<public_credential_hash>.
Any opinion on this? Should we have a new CAIP describing on-chain attestations?
This should be added to the polkadot namespace under CAIP-19 I think. https://namespaces.chainagnostic.org/ https://github.com/ChainAgnostic/namespaces/
@oed thanks for the prompt response. I don't think on-chain attestations are something that concern only Polkadot. If anything, Polkadot does not care about attestations at all. It's us, KILT, that do that, but I know of other projects that use some sort of on-chain attestation. So I thought this would be a generic asset class that can be used across blockchains. A blockchain that uses a smart contract would use the same asset class as a blockchain that uses the pallet architecture, such as Polkadot-based chains.
Or is an asset class, i.e., a CAIP-19-based identifier, always only valid within the context of a CAIP-2 chain?
NB ntn-x2: attestate just joined and another onchain attestation project proposed a CAIP so i think we have quorum for a new working group? particularly if @vallexyz has bandwidth to join
I would be down for it. I was always assuming that the asset namespace would be generic enough to basically declare anything we want as an asset class. But I've hit the same limitations a couple of times, since it seems to only be referring to smart contract-based assets. So I would be up for defining a more generalised definition of asset, since, at least in the ecosystem I work with, there is already a concept of MultiLocation and MultiAsset which can be used to identify literally anything within and across a given consensus system.
@ntn-x2 but Kilt is on polkadot right? CAIP-19 is per blockchain. I don't understand why CAIP-19 wouldn't meet your needs? It should be sufficient for any type of asset?
@oed i think this is because CAIP-19 is only for addressing tokens, whereas on-chain attestations are written into metadata. I'm thinking all the "transaction / NFT / block metadata" usecases should share a new identifier type, a superset of what's proposed here by the ISCC guys
We already use CAIP-19 for NFTs. I don't understand why we would need a new standard for non-trasferable NFTs (attestations, metadata, etc). If the wording "Token" is confusing we could just update the wording of CAIP-19?
@oed I have gone the key CAIP specs few times, and never found a mention that CAIP-19 is per blockchain. Where is that mentioned? Cause my assumption was that you take a CAIP-2 chain on one said, you take the asset part of an asset on the other side, and you combine them into a CAIP-19 identifier. I did not know that a given CAIP-19 asset namespace would only be valid within the context of the CAIP-2 chain specified in its spec.
EDIT: For instance, I thought it would theoretically be possible to have a CAIP-19 identifier for an erc20 token living on a Polkadot-based chain. I never read about any restrictions on the chain-id value for the erc20 definition.
So if assets are only valid within a given chain, then how would we define the concept of "attestation"? Should we need two different specs to refer to Ethereum-based and Polkadot-based chains? If Cosmos needs one, we would have another one for Cosmos? I am just asking out of curiosity to get better insights into the process: it seems I got it all wrong so far 😄.
We already use CAIP-19 for NFTs. I don't understand why we would need a new standard for non-trasferable NFTs (attestations, metadata, etc). If the wording "Token" is confusing we could just update the wording of CAIP-19?
NFTs and ERC20s are both smart contract based-- CAIP-19 just points you to the smart contract where ownership information is stored. Pulling metadata from a block (such as a miner's message on BTC) and pulling metadata from an NFT are two different examples of a more specific interface, non?
Should we need two different specs to refer to Ethereum-based and Polkadot-based chains? If Cosmos needs one, we would have another one for Cosmos?
No, one CAIP describes the general pattern, while Polkadot-, Cosmos-, EVM-specific profiles clarify any further validation rules, syntax, etc specific to a given ecosystem. See the namespaces table of contents for examples of multiple profiles of a given CAIP
NFTs and ERC20s are both smart contract based-- CAIP-19 just points you to the smart contract where ownership information is stored.
For bitcoin and others it's not smart contract based, but namespace based.
bip122:000000000019d6689c085ae165831e93/slip44:0
Cause my assumption was that you take a CAIP-2 chain on one said, you take the asset part of an asset on the other side, and you combine them into a CAIP-19 identifier. I did not know that a given CAIP-19 asset namespace would only be valid within the context of the CAIP-2 chain specified in its spec.
This is because tokens are different on different chains and need to be referenced in different ways. e.g. Eth vs Cosmos
Cause my assumption was that you take a CAIP-2 chain on one said, you take the asset part of an asset on the other side, and you combine them into a CAIP-19 identifier. I did not know that a given CAIP-19 asset namespace would only be valid within the context of the CAIP-2 chain specified in its spec.
If the polkadot based chain is EVM compliant such that it would support erc20, then it would be part of the eip155 namespace, not the polkadot namespace.
Thanks for those clarifications, OED! I'm having trouble figuring out where the confusion is, and hopefully not over-explaining the obvious. A non-breaking clarification PR to CAIP-19 would be welcome, as an outcome of all this!
EDIT: For instance, I thought it would theoretically be possible to have a CAIP-19 identifier for an
erc20token living on a Polkadot-based chain. I never read about any restrictions on the chain-id value for theerc20definition.
Actually, ERC20 conformance is profiled in the EVM caip-19 profile; that said, somewhat implicit in the way CAIP-19 was written is that each namespace/ecosystem has an ERC20 and ERC721 "equivalent", which is what CAIP-19 is made to address equivalently. https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md#semantics
Jinx, @Oed hit "comment" sooner and said the same thing more succintly haha
I see, thanks to both for the clarifications! Then I agree we definitely need to nail down the chain ID definition for Polkadot, then we can start defining one or more CAIP-19 "profiles".
Actually, ERC20 conformance is profiled in the EVM caip-19 profile; that said, somewhat implicit in the way CAIP-19 was written is that each namespace/ecosystem has an ERC20 and ERC721 "equivalent", which is what CAIP-19 is made to address equivalently. https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md#semantics
I see that this was updated only 4 months ago, and it's now much clearer to understand 😄 Last time I went through the document it wasn't as clear, hence my confusion.
Last time I went through the document it wasn't as clear, hence my confusion.
It's almost like our conversations informed the subsequent editorial PRs 😉
NB @TimDaub -- ~~maybe a picnic meeting in Tempelhoferfeld is in order?~~ nevermind, thought we were all Berlin-based at the moment. Will have to be a teleconference!