Conversation
Adds a CAN for the icon ecosystem with a CAIP-2 Blockchain ID profile. Drafted by the maintainers of FAR, an open cross-reference between CAIP-19, CoinGecko and ISO 24165 identifiers, which needs a CAIP-2 for this chain to name assets that exist on it. The authors do not represent the icon ecosystem and offer this as a starting point for its community to correct, adopt or replace. Discussion: 0xcounting/FAR#1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a CAN for ICON with a CAIP-2 Blockchain ID profile.
Who wrote this
I do not represent the ICON ecosystem. I maintain FAR, an open cross-reference between CAIP-19, CoinGecko and ISO 24165 identifiers. Offered as a starting point for ICON's maintainers to correct, adopt or replace.
Proposal
icon:+ the NID as canonical decimal.Why decimal, when ICON publishes hex
ICON's JSON-RPC returns the NID as
"0x1". Using that verbatim would admiticon:0x1,icon:0x01,icon:0X1andicon:0x001for one network. The spec gives an explicit three-step hex→decimal derivation and listsicon:0x1among the invalid test cases.Verified live (2026-09-14)
icx_getNetworkInfoagainst two independent endpoints that agreed —https://ctz.solidwallet.io/api/v3andhttps://api.icon.community/api/v3, both returning{"platform":"icon","nid":"0x1","channel":"icon_dex"}. Soicon:1is current mainnet, post-ICON 2.0.What I could not verify, stated in the draft rather than glossed
0x2) and Berlin (0x7) testnets are documentation-only.lisbon.net.solidwallet.ioandsejong.net.solidwallet.iohave no DNS A record, andapi.lisbon.icon.community/api.berlin.icon.communityreturned 502. The Well-Known Networks table footnotes this.github.com/icon-project/goloopreturns 404 (the org andicon-project/IIPsare fine, so the node repo appears to be gone or private). That means the CID-vs-NID distinction in goloop is described from secondary documentation rather than source. Flagged in Additional Considerations rather than citing a dead link — a maintainer confirming the CID/NID semantics would be the single most useful review comment here.Addressing
hx= EOA,cx= contract, 40 lowercase hex each. Worth noting for cross-chain tooling: the prefix identifies a contract without an equivalent of an EVMgetCodecall.BTP Network Addresses (
btp://0x1.icon/hx…) embed the same NID, which corroborates the value, but they are not themselves CAIP-2 references —icon:0x1.iconis an invalid test case.discussions-to: 0xcounting/FAR#1