We name things that have meaning. From people, organizations, and neighborhoods to countries, planets, and galaxies, names convey value and reinforce social consensus about what makes their bearers unique.
These identities need a name that can travel. ICNS provides the framework for interchain accounts to mint their own opt-in passports: legible, permissionless, decentrally verified identifying marks that make it easy to build a composable identity capable of moving seamlessly between chains.
A Multichain Native Nameservice
ICNS is a nameservice designed from the ground up with the unique needs of a multichain IBC ecosystem in mind. While every Cosmos chain is distinct, it is simply terrible UX for them to have independent, fragmented name services. Indeed, just as unique addresses are not required to interact with different apps on Ethereum, neither should they be required to interact with different chains in Cosmos. Interchain Nameservice (ICNS) aims to make this a reality by providing a fair, readily adoptable naming protocol for any chain connected with IBC.
With ICNS, users will be able to own a single name that represents their identity across the entire Cosmos ecosystem, while also differentiating between their accounts on different chains. Much like bech32 prefixes identify an address’ corresponding chain (e.g. osmo1 for Osmosis, cosmos1 for Cosmos Hub,), ICNS names attach to suffixes that represent different chain-level domains, thereby allowing one name to specify resolution addresses in many name spaces. For example, a user that owns the @dogemos ICNS name, will be able to set their dogemos.osmo resolution for Osmosis, dogemos.cosmos for Cosmos Hub, and dogemos.juno for Juno.
This explicit declaration of which chain an address represents can also help users and developers protect against multi-chain mistakes such as the one in the Wintermute Optimism exploit, in which an address that had been claimed as part of a multi-sig arrangement on one EVM chain (Ethereum) had not been claimed on another (Optimism), leaving it open to be claimed and exploited by an attacker. This sort of multi-chain error can be hard to spot due to the impossibility of chain domain differentiation among identical EVM addresses on different chains (being simple hex strings). Without explicit naming, multi-chain EVM users must check and double-check the environment in which their transactions are taking place in order to guard against similar errors.
For these explicit declarations, ICNS cannot rely on the usual bech32 re-encoding of a single address for every chain. This process only works for coin-type 118, secp256k1 public key accounts, and as we move towards a world of contracts, smart wallets, and new cryptography, it is likely that many chains will use different elliptic curves, different coin-types. ICNS, on the other hand, is a forward-compatible standard that will allow users to specify an address for every supported suffix of their ICNS name, whether or not that address was created using coin-type 118.
Bootstrapping Web2 onto Web3
Bootstrapping a new namespace from scratch is difficult. Every time a new nameservice is launched, it triggers a land grab phase, where people try to squat on popular names. If too many of these are claimed by speculators, a new protocol becomes unattractive to users with existing online identities, and their failure to adopt makes the service less useful for everyone. On the other hand, adjudicating between impersonators and rightful owners during the bootstrapping phase can be a UX nightmare, which also hinders adoption.
Both of these problems, however, can be avoided by discarding the typical first-come-first-served auction in favor of a more efficient mechanism for bootstrapping previously established identities.
We therefore propose initializing ICNS as a hard spoon of an existing username base — Twitter.
Twitter is, without a doubt, the most crypto-native of the web2 social media platform giants. With internal projects such as Bluesky and NFT profile pictures, it continues to evolve as a bridge between the existing web and the new frontiers of web3.
In the ICNS bootstrapping phase (which is expected to last roughly 1 year), users will be able to claim their ICNS names by verifying their Twitter handles.
Oracle verifiers watching the Twitter API for this information will then relay it to the ICNS contracts on Osmosis, which will in turn issue a “dogemos” OwnerNFT to the account osmo1dummyaddress. This owner can then set the resolution of the dogemos name for any supported suffix(dogemos.osmo, dogemos.juno, dogemos.umee, etc). Each suffix name can point to a different address, since a user may want to use a different account on each blockchain. The owner of a name can change the resolution addresses at any time.
Initially, all name resolution will take place on the Osmosis blockchain, but in the future each chain’s namespace will be native to itself, both to allow local resolution by contracts on each chain, and to promote better UX for cross-chain routing. Owner NFTs will be able to be transferred between accounts or even IBC’d to other chains using ICS721, in order to be sold on secondary markets like Stargaze or Omniflix.
Leveraging the Twitter namespace, while not a perfect solution, provides ICNS with a relatively fair mechanism to allocate namespace to users who will maximize its value. This Twitter bootstrapping phase is intended to last 1 year, allowing ample time to kickstart the protocol. After 1 year, ICNS will transition to a more open system, with mechanics around fees, auctions, distribution, and the like to be developed in conjunction with the community.
Multichain Deployment
The initial on-chain logic of ICNS consists of three main contracts:
- NameNFT contract that manages the ownership of the namespace as NFTs
- Registrar contract that registers a name based on the Twitter verifier
- Resolver contract(s) which manages the resolution between names and addresses
The ICNS and its core logic will be housed on the Osmosis blockchain initially. However, it is expected that ICNS will switch to using an outpost model that allows each chain’s name resolution to happen locally by deploying address resolution contracts on other CosmWasm enabled blockchains.
Governance
At launch, ICNS will be governed by a council of builders in the Cosmos user identity space including:
Each member is committed to supporting ICNS within their respective products in order to provide a cohesive name-service experience across the Cosmos ecosystem.
This committee will continue to decentralize and DAO-ify itself over time by inviting new members to participate: companies, DAOs, and even individual chains, represented by their governance. The committee itself will initially function by rough consensus and compromise, formalizing its rules as it decentralizes.
The governance committee has 3 initial mandates:
- Select the Twitter verifier oracles
- Approve new suffixes for ICNS
- Govern the ICNS contract parameters and upgrades
- Decide on future economic distribution of treasury
- Set future roadmap and decentralization of the ICNS protocol with community input
Future decisions to be made by the ICNS DAO is expected to include:
- Minting Fees: During the initial adoption phase of Year 1, domains will not be auctioned, but claimed for a relatively low flat rate, just enough to discourage potential griefing, e.g. 1 OSMO or 1 USDC per owner NFT. The DAO can establish higher flat fees and auctions when adoption and demand seem to call for it.
- Renewal Fees: Similarly, NFTs will have to be renewed according to a schedule, and this renewal will require some sort of sliding fee scale. Beyond this, we as yet take no stance on how the fee should be structured: a flat rate based on letters in the name and length of renewal, Harberger taxes, etc.
- Fee Sharing: Once fee structures become clearer, after the initial year of being held below market price, the DAO will also need to establish how ICNS revenues are to be reinvested and/or split among the various parties, with emphasis on incentivizing user-facing applications that integrate ICNS.
- Disputes: Deciding who has the better claim to a disputed name can be fraught. Different entities may have built up brand capital in the same name on different platforms. Despite protections against interchain name squatting, some amount will inevitably occur and need to be resolved. Tough cases such as these are often impossible to resolve both fairly and algorithmically, making them an issue for governance.
Chain Support
ICNS, in its integrator-driven nature, will be a chain-agnostic personal identity protocol that supports all Cosmos SDK-based and IBC-enabled chains that have registered their bech32 prefixes on the SLIP-173 repo. Suffixes (i.e. ‘.osmo’) will in most cases match their chains’ bech32 prefixes. Future suffixes included after launch will be approved by the committee.
However, some chains may already have existing nameservices built into their protocols. Since conflicting namespaces can cause issues for UX and security, and in line with the sovereignty-first nature of Cosmos, we allow chains to explicitly opt out of ICNS by signaling this via governance. If a chain opts out of ICNS, their suffixes will not be supported.
ICNS: Portable Identity for the Interchain
ICNS is being developed and integrated by a broad coalition of user application developers in the Interchain, including the ecosystem’s largest wallets, block explorers, dapps, and governance tools. With each of these partners integrating Interchain Names into their native UX, ICNS is best positioned to become the standard interchain name service.
With ICNS, existing on-chain identities can be extended across many chains: by transacting in DeFi, by participating in social media linked through token-gating bots and the like, by acquiring POAPs to prove attendance, and by interacting with NFTs — collecting them, curating them, and using them to show off one’s tastes and affiliations. These uses of NFTs will continue to expand beyond images into music, gaming, and all facets of our increasingly online lives. ICNS will let people, DAOs, organizations, and even contracts tell a coherent story from chain to chain.
All of this, of course, is opt-in. Some transactions and accounts are not meant to tell their stories. Fortunately, ICNS can be used in tandem with various privacy solutions being built in the ecosystem. Clearly labeled addresses will help users keep better track of what should be public and what should be private across their accounts on many chains.
Moreover, the ability to create cohesive identities across the interchain will help us rival, and surpass, the composable identity frameworks that have been so successful in enhancing the tribal appeal of fat protocols like Ethereum.
Constructing an on-chain identity can be joyful, productive, and meaningful. More importantly, it can be fun, provided the UX is intuitive and the complications are abstracted away. ICNS is poised to do just that, extending the game of identity across the interchain, making it easier for everyone to forget the tech and just play.
We invite the Cosmos community to take this next step of Interchain UX with us!