Comments (17)
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.
from caips.
Jinx, @oed hit "comment" sooner and said the same thing more succintly haha
from caips.
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!
from caips.
This should be added to the polkadot namespace under CAIP-19 I think.
https://namespaces.chainagnostic.org/
https://github.com/ChainAgnostic/namespaces/
from caips.
@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?
from caips.
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
from caips.
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.
from caips.
@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?
from caips.
@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
from caips.
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?
from caips.
@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.
from caips.
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 😄.
from caips.
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?
from caips.
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
from caips.
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
erc20
token living on a Polkadot-based chain. I never read about any restrictions on the chain-id value for theerc20
definition.
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
from caips.
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.
from caips.
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 😉
from caips.
Related Issues (20)
- Implementer Feedback: CAIP-122<>EIP-4361 mismatch HOT 12
- CACAO v2/v3 confusion and varsig - are v3/varsig stale? HOT 1
- CAIP-122: address or account_id? HOT 2
- CAIP-2: chain ID alias HOT 2
- [CAIP-74] Signature Metadata type is not well defined HOT 1
- https://support.exodus.com/support/en/articles/8598833-walletconnect-in-exodus-mobile#qr-code کیف پول اکسود وس HOT 1
- 2
- 2
- [Publishing] Link to post-final updates, extensions, and proposed replaces from final CAIPs?
- [CAIP-275] - chain-specific resolution corner-case HOT 1
- Browser Wallet Messaging for Extensions (window.dispatchEvent)
- Browser Wallet Messaging for Iframes (window.postMessage)
- Browser Wallet Messaging for Extensions (externally_connectable)
- [CAIP-25] - Pass of editing to clarify "persistance" requirements on both sides
- [CAIP-25] - Refactor "requiredScopes" to suggest but not require connection breakage
- [tracking issue] `wallet_getSession` method needed for feature parity between legacy concurrent CAIP-25 and single-session CAIP-25 (see PR 285)
- [tracking issue] `wallet_revokeSession` method needed for feature parity between legacy concurrent CAIP-25 and single-session CAIP-25 (see PR 285)
- Ууу HOT 1
- [tracking issue] CAIP-25 in sessionId-mandatory mode and sessionId-optional CAIP-25 are confusing HOT 1
- [tracking issue] CAIP-25 needs a clearer definition of trust criterion for sharing informative error handling
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from caips.