-
Notifications
You must be signed in to change notification settings - Fork 148
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
Extend CAIP 19 to account for assets moved off of their native chain? #27
Comments
From @pedrouid:Problem: CAIP-19 AssetID current formatting doesn’t provide much consideration for multi-hop assets with IBC Proposed Solutions:
My personal conclusion of these 3 solutions could be defined in a table as follows:
Keep in mind that these asset namespace approaches are not necessarily exclusive as they can be used in parallel as different applications will optimize for different use-cases |
After discussing it with @antoineherzog on the ticker-based approach he clarified that the solution is actually intended for the assets issued at their native chain and not necessarily to tackle the multi-hop assets. So the ticker-based could warrant it's own namespace similar to SLIP-44 but with improved readability Regarding both multi-query and single-query approaches to multi-hop assets, from my POV I can see the being referenced with CAIP-19 as follows: Multi-QueryRequires specification of an ICS standard to determine asset resolution from the chain. Let's call it ICS-30 which will map to the asset namespace Example: now let's perform an asset transfer of the asset
This way we make two queries to complete the full provenance of the asset with guarantees of the whole path is live all the way to the native chain. This increases the network bandwidth but also shortens the id format Single-QueryRequires specifrication of an CAIP standard to define how multi-hop assets should be formatted with the whole provenance detailed on the ID itself. Let's call it CAIP-30 which will map to the asset namespace Example: CAIP-19: the advantage of the single-query approach is that reduces the network bandwidth to evaluate the provenance of the asset since it's clearly specified on its longer format id |
That is not technically feasible unless you use a relayer service. For example, consider a token that has been sent A -> B -> C-> D. Chain D that received the token might not be connected to chain A, so any query would return not found. Even in the case that they are connected, the path representation between each chain could be fundamentally different. I wrote some UX suggestions for clients on the ICS 20 - Fungible token transfer spec. |
I really like your approach Pedro of Multi-Query. It is really simple and beautifull. Following this conversation, I have a question which pops into my mind (maybe the question is more an IBC question): What happens to all the linked blockchains and their respective assets if a blockchain decides to rename his native mint asset from cosmos:yolo-chain/ics30:abc to cosmos:yolo-chain/ics30:bettercooltickername Does it break all the dependencies like everything? |
Pedantic example, but how would something like the following be represented?
|
BTC via renBTC would essentially be a ERC20 then via Peggy it would be minted as the fictional ICS30 asset denom on Cosmos Hub which then would refer to another ICS30 denom on Kava Essentially the assets would refer different namespaces from their origin slip44 (BTC) -> erc20 (renBTC) -> ics30 (cosmosBTC) -> ics30 (kavaBTC) |
For IBC assets this is pretty straight forward, but there are some weird edge cases that I'm not totally sure how to handle. For instance renBTC actually uses a separate blockchain to assemble secret fragments, so is BTC first "transferred" to the Ren blockchain or directly to Ethereum? Or what if someone uses state channels to transfer an asset between chains. Is this a direct transfer? Or Celer, which also has a blockchain that "co-signs" events? Solana is even considering using its base layer chain to record rollup transfers that would then ultimately be settled on Ethereum. Not to throw a wrench in things, rather trying to think through how best to generalize. |
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?
The text was updated successfully, but these errors were encountered: