-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to refer to attestations as asset class? #215
Comments
This should be added to the polkadot namespace under CAIP-19 I think. |
@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. 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: |
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 |
@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? |
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 |
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 😄. |
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? |
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 |
For bitcoin and others it's not smart contract based, but namespace based.
This is because tokens are different on different chains and need to be referenced in different ways. e.g. Eth vs Cosmos
If the polkadot based chain is EVM compliant such that it would support erc20, then it would be part of the |
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!
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. |
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".
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. |
It's almost like our conversations informed the subsequent editorial PRs 😉 |
NB @TimDaub -- |
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?
The text was updated successfully, but these errors were encountered: