Token Standards Working Group Meeting

2025-02-11, 2025-04-22, 2025-05-06

icp Namespace

• The icp namespace is proposed to be used for referring to all things ICP.
• There is currently no standard defining the namespace usage, which is a big miss for the ecosystem.
• We propose to fix this based on
• the basic principles of URIs,
• normative facts holding true in the ICP ecosystem, and
• best practices used in the broader crypto ecosystem.
• See the following slides for a proposal for the namespacing.
• Assumptions:
• We want to remain compatible to URI / URL syntactic constraints.
• In the longer term, the icp URI scheme should be registered with the official registration authority IANA.

icp Namespace

• Goal: Keep this important standard as simple and open (non-constraining for future developments in this domain) as possible!
• icp:
• ICP namespace. icp is technically a URI scheme (not yet registered, however).
• Everything behind this namespace is up to be defined by the ICP community through this and future ICRCs.
• This is an extremely important ICRC for the Internet Computer.
• Every URI that does not use the https URI scheme uses the icp scheme (unless someone has a strong reason for doing otherwise).

​

icp Namespace — Classes of URIs

ICP URIs can be classified into such that use a hierarchical component and such that don't.

• Namespacing without an authority
• icp:1:icrcy: is used as chain identifier for any form of identifier, e.g., for a smart contract or an account identifier following CAIP principles, where the example defines the namespace for ICRC-y.
• icp:1/icrcy: is a namespace defined by the ICRC-y standard (no hyphen after ICRC). This is an example for an authority-less URI.�This is used for defining resource identifiers where the resource location is expressed as part of the path as done, for example, in CAIP-19. (/ means resource). Colon instead of /?
• Both approaches are technically very similar, but have different syntax for different semantics
• Namespacing with an authority
• CNS: icp://application.app/icrcy/
• DNS: icp://canisterprincipal.ic0.app/icrcy/ or icp://application.com/icrcy/�→ Both examples above are namespaces defined by the ICRC-y standard. This are examples for URIs with authority components. The authority may be based on the upcoming CNS on ICP or standard DNS or other suitable schemes. We may want to include CNS and DNS in the standard already as possible authority schemes. Further schemes may be added with other ICRC standards.
• Canister principal: icp://canisterprincipal/icrcy/�→ This refers to a canister independent of a CNS, DNS, or other hierarchical naming system. As every canister has their principal as id, such scheme is useful for referring to canisters directly without registering a name, e.g., by canisters to refer to resources in other canisters (think of an NFT ledger referring to a large image file in another canister). Using only a canisterprincipal as authority is simple and sufficient as long as canister principal identifiers are not used as CNS or DNS TLD. This is a reasonable assumption considering the length of canister principal identifiers. The hierarchy, which users are used to, is missing here, however. An alternative is to introduce an artificial TLD for referring to canister principals: icp://canisterprincipal.canister/icrcy/. A more catchy alternative would be preferable: .icp, .con, .smc, .sc, .cstr ? Such TLD would not serve any purpose other than introducing a hierarchy resembling DNS for better familiarity to users. We recommend to not introduce such hierarchy.�→ Problem: In the schemes with authority, the public key hash cannot be added as part of the scheme due to URI syntax constraints (icp:1://application.app/…). This is inherent to URIs and schemes. In the case of DNS the hierarchical name unambiguously defines the network the URI refers to, so the network identifier is not necessary. Thus, in some way, in this case the authority component and public key hash are mutually exclusive in determining the network, via different technical means. But in the case of self-hosted naming schemes like CNS, this approach does not work as the network to connect to is not known from the URI. In the case of being used in a URI with authority, the icp: scheme specifier does not default to ICP mainnet, but network resolution is performed by resolving the name.�What about: icp://737ba355e855bd4b61279056603e0550:application.app/icrcy/ (invalid URI) or icp://application.app/737ba355e855bd4b61279056603e0550:/icrcy/ or icp://application.app/:737ba355e855bd4b61279056603e0550/icrcy/ or icp://application.app/:737ba355e855bd4b61279056603e0550:/icrcy/ for the hash-based id? For ICP mainnet, we can again omit the key hash or use 1 as identifier. Canister ids are disjoint across mainnet and UTOPIAs, so maybe addressing is not a problem for this, but for network-hosted name systems.

icp Namespace

• Why not just use the https scheme to refer to concepts such as ids or resources?
• This is indeed an option, the problem with it is that it requires one or hierarchical names using DNS, which does not make it decentralized enough.
• Using CNS may be a better option.
• However, using CNS (or DNS) would mean to lose any CAIP compatibility and have more verbose URIs.
• A basic question is why we want an authority component instead of always using CAIP-19-like authority-less URIs.
• In short: for better human readability and flexibility of URIs
• CNS is a hierarchical naming system similar to DNS, but hosted on chain. It provides for human-readable names, which are much easier to use than a smart contract address. It's also closer to Web2 in terms of addressing resources, so another clear advantage of using an authority. Adding a (32-character) network identifier for networks other than ICP mainnet makes it less readable and not memorable, thus it is questionable whether it makes sense to allow for this in the general case outside of ICP mainnet. Using a naming scheme abstracts from canisters and allows, for example, for re-assigning names to new canister for an implementation upgrade. CNS is always hosted on the network that is addressed by it. Not having a network identifier means that the network needs to be implicitly known. This is an issue. One (the only feasible?) "nice" way to resolve this is with short network ids for networks of interest:�icp://application.app/:1000:/icrcy/… for the registered UTOPIA network with id 1000. Note that the ":"s are used to make explicit that the following entity is the network identifier, relating to the syntax of icp:1000:icrc1234:.... First proposal, up for further discussion. Without this chain identification mechanism, we cannot embed a chain id in an easily-readable string.
• icp:/icrcy/…-style resource URIs can handle many of the things we need without an authority, but without human-readable names for canisters or applications. For a blockchain world that is intended to augment or replace Web 2, this is clearly not enough and CNS or at least DNS are required. Another drawback is that the implementing canisters are fixed and names cannot be assigned to new canisters, so gives less flexibility to a maintainer of a system.

icp Namespace

• Proposal (continued)
• The /icrc…/ or :icrc…: prefix SHOULD NOT be used for other purposes than the corresponding ICRC, even in a namespace controlled fully by an application. E.g., icp://example.com/icrcy/ should not be used by the owner of application.ic0.app in order to not lead to confusion.
• Any other path prefix than /icrc…/ can be used by parties that control the respective namespace, e.g., a specific CNS or DNS name for an application. icp://example.com/some-path-prefix/ may be arbitrarily used unless it conflicts with other ICRCs because it is a non-conflicting name in a controlled namespace.
• In URIs without an authority, non-ICRC-defined path prefixes SHOULD NOT be used. E.g., icp:1:some-namespace… SHOULD (or rather MUST?) NOT be used without a corresponding ICRC or stable draft of such. There should be no need to use such namespace without an ICRC standardizing it. This leaves the door open for future namespace extensions.

Challenges

Potential CNS issues

• CNS names currently are defined per ICP network and independently of DNS
• DNS names can be reused in each CNS network
• This can lead to huge confusion and attacks

Network id

• The network id is a concept that is alien to the https and DNS world
• It does not fit nicely anywhere in an authority-ful icp:// URI
• Changing the semantics of CNS to have a global namespace for all ICP networks like in DNS for all networks of the Internet would allow us to ignore the network id in authority-ful icp URIs and thus simplify the modeling