Withdraw CAIP-20 and/or extend CAIP-19 to special-case native assets

[u59149403]

I propose to withdraw CAIP-20.

We should refer to native currencies of chains (I mean word "chain" in CAIP-2 sense) just by using word "native".

I. e. we should refer to ether as eip155:1/native.

Why? The main reason is this: some native currencies simply don't have SLIP-44. For example, let's consider eip155:199 (BitTorrent chain). Its native currency BTT is not listed in SLIP-44. SLIP-44 contains ByteTrade BTT (slip44:34952, https://bytetrade.io ), but it is completely different from BitTorrent BTT ( https://bt.io/btt ). (In fact, link https://bytetrade.io is broken now, so it seems that this project is dead.)

Moreover, it seems BitTorrent BTT simply will never be added to SLIP-44. SLIP-44 says: "Coin types will be added only if there is a wallet implementing BIP-0044 for desired coin". There is no such wallet for BTT, so it will never be added. In fact, page https://app.bt.io/wallet , titled "BitTorrent Chain Wallet", doesn't offer any desktop wallet, but instead simply offers to connect MetaMask.

So, currently CAIP-19 cannot refer to BitTorrent BTT, and, assuming CAIPs will not change, will never be able.

But my proposal allows to refer to it simply as eip155:199/native.

Okay, now let me provide other arguments.

As well as I understand, every chain (in CAIP-2 sense) have exactly one so-called native currency. (I'm not aware of any chains, which have no native currency or have multiply native currencies.)

As well as I understand, SLIP-44 lists native currencies. Thus, every entry in SLIP-44 also indirectly describes chain (in CAIP-2 sense) of that currency. But some SLIP-44 currencies are native currencies of multiple chains. For example, ether (slip44:60) is native currency for Ethereum (eip155:1) and Base (eip155:8453). But still every SLIP-44 native currency has some designated main chain. For example, main chain for ether (slip44:60) is Ethereum (eip155:1).

Okay, so, in short: SLIP-44 lists native currencies, and every chain (in CAIP-2 sense) has exactly one native currency. Thus, CAIP-2 id is enough to identify that currency. Thus SLIP-44 id is not needed, it is okay to just use word "native".

Using word "native" is simpler for implementations. I plan to write trading bot, which will operate across different EIP-155 chains. Also I want to maintain my accounting system. And I want my bot to write to that accounting system automatically. Also, I want my accounting system to be future-proof in case I will later switch to non-EIP-155 chains. So, I plan to use CAIP-19 ids to refer to assets in that accounting system. My bot obviously will know EIP-155 id of every chain it works with. Because EIP-155 is natural way to refer to chains in Ethereum ecosystem. Even if I for some reason don't know chain EIP-155 id, I can always learn it using eth_chainId JSON-RPC method. I can even get it on-chain using CHAINID opcode. But there is no robust way to get SLIP-44 id. Yes, I can get SLIP-44 from https://github.com/ethereum-lists/chains . But, as I said above, some native currencies don't have SLIP-44, for example, BTT. Sometimes SLIP-44 is absent in that Github repo. For example, it did not contain SLIP-44 for TRX until I submitted PR some days ago: ethereum-lists/chains#7223 . Sometimes information in that repo is outright wrong, for example, SLIP-44 for World Chain native currency (ether) was specified wrongly. I submitted PR and it is not yet accepted as of now: ethereum-lists/chains#7238 .

In short, requirement to know SLIP-44 is complication for developers. It is way easier to just write "native".

I think all this applies not only to EIP-155 chains, but also to all other. So I propose to remove CAIP-20 and instead create new CAIP, which allows using word "native" for all CAIP-2 chains.

Current wording creates unnecessary complications for me, so this is one single reason why I may decide not to use CAIP-19 for my project.

(But I'm not opposed to using SLIP-44 to refer to chains in CAIP-2 sense. In such scheme bitcoin chain would be slip44:0 and bitcoin currency would be slip44:0/native. But I'm just thinking out loud. I'm not sure about this, so you can just ignore this paragraph.)

If you want, I can write PR

[bumblefudge]

Hey! I would be OK with withdrawing SLIP-44 if it were officially "dead", and as far as I know there are no production implementations using CAIP-20, but i'm also OK leaving it in "DRAFT" because someone still could finalize it later if they built on SLIP-44, which AFAIK is not literally inactive, just less influential in mainstream crypto circles.

The related issue of whether a new CAIP for /native makes sense as an extension of CAIP-19 is a distinct issue. I would support such a CAIP extending CAIP-19, but I'm a tiny bit worried we're just porting ethereumisms into the generic decentralization space, since even the term native currency (as opposed to ERC-20) was coined in the Ethereum community. Other ecosystems have analogous concepts, but it would require a bit of profiling since the semantics and guarantees of "native" currencies or "gas/compute" tokens vary widely, making another CAIP that is as vague as CAIP-10 and CAIP-19 that have to define all their semantics and canonicity behavior at the profile level.

And even in ethereum, aren't there "gasless L2s" that use mainnet eth as their "native" token, or abstract away gas entirely from both onchain users and wallets? This would have to specified at the eip155/caipXX.md level as well, because I've never been entirely clear on what a system that makes use of /native should do when applied to a gasless/tokenless EVM chain...

(As for slip44:0/native, I feel like it's syntactically feasible, but breaks assumptions of the SLIP44 model, which predates this whole conversation in the ethereum world... i'm unclear on how sound it is semantically)

[bumblefudge]

Sidenote, thanks for contributing so much and sharing your interests/research goals here, and helping others with open PRs. I hope I am not too much of a buzzkill, these are great ideas and we're open to the PRs!

[u59149403]

@bumblefudge

but I'm a tiny bit worried we're just porting ethereumisms into the generic decentralization space

This term is used by Solana, too. https://solana.com/docs/references/terminology#sol says: "SOL - The native token of a Solana cluster".

abstract away gas entirely

I just checked: every chain listed in https://github.com/ethereum-lists/chains has a field nativeCurrency. I verified this using this Linux command:

wget -O - 'https://chainid.network/chains_mini.json' | jq -c '.[]' | grep -v '"nativeCurrency"'

And every native currency there has a name. Verified using:

wget -O - 'https://chainid.network/chains_mini.json' | jq -c '.[].nativeCurrency' | grep -v '"name"'

that use mainnet eth as their "native" token

Some chains indeed use mainnet ETH as their native currency. But users still need to transfer mainnet ETH to that chain. For example, OP docs say: "Users will often begin their L2 journey by depositing ETH from L1. Once they have ETH to pay fees, they'll start sending transactions on L2" ( https://specs.optimism.io/background.html ). So, native currencies for some chains indeed are convertible to/from mainnet ETH 1:1, but they are still different currencies.

---

So, what are next steps? May I author CAIP for "native"? Also: I just have read in CAIP-19 that CAIP-19 should have form chain_id + "/" + asset_namespace + ":" + asset_reference. String eip155:1/native doesn't match this. What to do? Change CAIP-19 pattern? Or introduce some artificial asset namespace? eip155:1/native:native???

[bumblefudge]

Oh, for sure, the concept of "native" currency has become "tablestakes" for all VMs that have a generic token concept (or ERC-20 analogue), it is already being ported widely. Not an argument against the CAIP, just something I'm sensitive to; the broader conversation about what ever happened to SLIP44 is, I think, pertinent here as well.

So, what are next steps? May I author CAIP for "native"?

Yes, I would say you have exhausted my reserves of context and advice worth giving, you're as qualified as anyone to write the CAIP! I'm not sure the ":" + asset_reference analogy holds, except in some hypothetical VM or chainId (I can't think of any!) where native currencies need a reference/address to be usable? I personally think eip155:1/native makes sense, and is equivalent to eip155:1/erc20:0x{address of erc20 contract} logically and semantically, unless I'm missing something? As for the special case of "bridged native" tokens as in optimism chains, i think that's just a special-case you could explain in the eip155 profile of your future caip, i.e. eip155/caipxxx.md in the namespaces repo after you've crafted the general-purpose CAIP that extends 19 😄

Feel free to tag me in a draft PR if you get stuck!

[u59149403]

I personally think eip155:1/native makes sense, and is equivalent to eip155:1/erc20:0x{address of erc20 contract} logically and semantically, unless I'm missing something?

You mean that eip155:xxx/native unambiguously identifies asset? Yes, it does. (Well, there is EIP PR ( ethereum/EIPs#9026 ), which introduces possibility of many native currencies for single chain, but I'm not aware of any chain, which actually does this.)

As for the special case of "bridged native" tokens as in optimism chains, i think that's just a special-case you could explain in the eip155 profile of your future caip, i.e. eip155/caipxxx.md in the namespaces repo

Ok, I will do.

I personally think eip155:1/native makes sense

Ok, so in addition to writing new CAIP I will also patch CAIP-19 to allow such grammar, right?

---

Also, may I write in CAIP-19 that native is recommended and slip44 is not? 😄

[u59149403]

i think that's just a special-case you could explain in the eip155 profile of your future caip, i.e. eip155/caipxxx.md in the namespaces repo

I will describe this in eip155/caip19 instead

[silverpill]

+1 for /native or equivalent, it would be useful for identifying native assets on chains that don't have a SLIP-44 identifier.

But I think CAIP-20 should not be withdrawn, because it is already used in production systems.

[tristan-bp]

Please consider that there are in fact chains that have multiple native tokens. Two examples that come to mind are:

• Quai (has native tokens QI and QUAI)
• Kinesis (has native tokens KAU and KAG)

So, what are next steps? May I author CAIP for "native"? Also: I just have read in CAIP-19 that CAIP-19 should have form chain_id + "/" + asset_namespace + ":" + asset_reference. String eip155:1/native doesn't match this. What to do? Change CAIP-19 pattern? Or introduce some artificial asset namespace? eip155:1/native:native???

I would encourage against changing the CAIP-19 pattern here, if you want to move forward with using native instead of the slip44 number then consider a format like this eip155:1/native:eth that includes the token symbol. This has two benefits:

1. It would allow you to handle the above cases where a chain has multiple native tokens. For example for Quai you can have quai:mainnet/native:quai and quai:mainnet/native:qi
2. The CAIP-19 format would stay the same (useful for regexs)

As a side note I completely agree with the frustrations around slip44, not all native tokens have a slip44 number and you must match native tokens based on symbol/description, which as pointed out above with the BTT example can be unreliable and difficult to automate. I work on a production system that uses CAIP-19 and I have to manually match a lot of the slip44 numbers to ensure that their accuracy.

[bumblefudge]

Also, may I write in CAIP-19 that native is recommended and slip44 is not? 😄

So, I think the best path forward would be a new CAIP that extends CAIP-19, defining "native" the way CAIP-20 defines "slip44". Any single-namespace extension of CAIP-19 is better defined in that namespace's /caip19.md. And I like tristan-bp's recommendation that there be at least an optional [:eth/qi/quai] component. If no one here opens the PR i'll get around to it eventually myself!