Extend CAIP 19 to account for assets moved off of their native chain?

[chainagnostic]

Extend CAIP 19 to account for assets moved off of their native chain?

[okwme]

From @pedrouid:

Problem: CAIP-19 AssetID current formatting doesn’t provide much consideration for multi-hop assets with IBC

Proposed Solutions:

• Antoine proposed a ticker-based solution maintained by an Asset registry to make it human-readable and user-friendly to more easily identify asset provenance without providing a long format ID
• Pedro proposed a multi-step solution that required querying chains down the provenance path to identify the origin of the asset, reduced user experience yet still short format but with more bandwidth requirements
• Josh proposed a single-step solution that required only querying the origin chain since the long format ID would be able to reduce bandwidth requirements and be more decentralized as wallets can easily query a single chain directly

My personal conclusion of these 3 solutions could be defined in a table as follows:

Approach	Readability	Registry Requirement	ID Format	Bandwidth Requirement	Provenance Guarantees
Ticker-based	easy	yes	short	low	low
Multi-query	hard	no	short	high	high
Single-query	hard	no	long	low	low

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

[pedrouid]

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-Query

Requires 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 ics30. Let's say that standard defines an endpoint called getOriginAsset that returns if the asset has been minted from an IBC transfer and if so it would return its origin assetId.

Example:
we have asset with denom abc and it was natively minted on cosmos chainId yolo-chain and therefore it would have a CAIP-19 assetId cosmos:yolo-chain/ics30:abc when you query the endpoint getOriginAsset it would return a falsy value indicating that this asset is indeed native to this chain

now let's perform an asset transfer of the asset abc to another chain with cosmos chainid carpediem-mainnet and it will mint this asset in its own chain with the denom yabc therefore it would have a CAIP-19. assetId cosmos:carpediem-mainnet/ics30:yabc when you query the endpoint getOriginAsset it would return a truthy value with the respective assetId of the native chain (cosmos:yolo-chain/ics30:abc)

cosmos:carpediem-mainnet/ics30:yabc -> carpediem-mainnet.getOriginAsset("yabc") -> cosmos:yolo-chain/ics30:abc -> yolo-chain.getOriginAsset("abc") -> undefined

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-Query

Requires 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 caip30. Let's say that the last asset at the native chain is specified with the namespace denom as it reached the origin of its provenance

Example:
let's use the same asset denominations and cosmos chainId's specified above for this example as well

CAIP-19: cosmos:carpediem-mainnet/caip30:cosmos:yolo-chain/denom:abc

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

[hxrts]

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.

[fedekunze]

Josh proposed a single-step solution that required only querying the origin chain since the long format ID would be able to reduce bandwidth requirements and be more decentralized as wallets can easily query a single chain directly

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.

[romeo4934]

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?

[hxrts]

Pedantic example, but how would something like the following be represented?

BTC via renBTC to Ethereum via Peggy to Cosmos Hub via IBC to Kava

[pedrouid]

BTC via renBTC to Ethereum via Peggy to Cosmos Hub via IBC to Kava

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)

[okwme]

we're gonna need a lot of room on the screen to show the wrapped path