Going cross-chain with the Solana Name Service

We have been deeply humbled by the success of SNS. It has become one of the foremost web3 naming services in little more than a year. At more than 200k registered addresses, its user base has grown beyond our wildest expectations. With this growing community in mind, we have made it our priority to add value to SNS.

At its core, SNS is infrastructure. What we want are more and more third-party apps to integrate natively with SNS. To facilitate this, we want developers to have incentives to integrate and lower barriers to entry. For Solana-native builders, the sheer size and influence of the SNS community is already a powerful incentive.

If we want SNS to continue growing we need to do the following:

• Improve dev experience for all web3 engineers
• Onboard more users and app developers onto the Solana ecosystem
• Support new features and use cases for existing users

We have come to the conclusion that the natural path forward is to partner with the amazing Wormhole team and launch SNS-warp, an open-ended initiative to take SNS cross-chain. Using the Wormhole bridge, users will be able to export their domains to an alternative chain. We're first supporting an EVM-based chain. This means that apps built around the EIP-137 (ENS) specification on supported chains will be able to resolve SNS natively, with practically no change to their codebase.

Motivation

Stimulating the Solana ecosystem

At first glance, this may seem as though it encourages Solana users to migrate to other chains. It doesn't. Right now, there is nothing stopping a Solana user from migrating away. The way we see it, the problem is that they would do so anonymously, essentially assimilating themselves into another chain's community.

It just so happens that all SNS-warp users have a measure of their identity anchored to the Solana ecosystem. Devs on other chains will be able to tell how many of their users are Solana-native. Knowing that a market exists might just be the trigger they needed to seriously consider building on Solana.

Solana will remain the source of truth for all SNS domains and associated records. For instance, users have to interact with Solana to keep their records up to date when rotating wallets. Any sale or transfer of domain names will only be possible on Solana itself. Our ambition is to grow SNS into a first-class Decentralized Identity (DID) system, which users can keep coming back to as they explore the broader web3 ecosystem and become de facto Solana ambassadors.

Bringing value to existing users

Going cross-chain enables existing users to identify with their SNS domain on more apps, increasing utility through deeper composability. Conversely, users on other chains will be exposed to SNS through their interactions with .sol domain name holders. This will stimulate protocol adoption and overall value.

Investing in Solana's future

Right now, it is quite hard to build a truly cross-chain application on Solana. There is no reason for this to be the case, especially since the basic building blocks for such applications already exist.

We have chosen to partner with the Wormhole team to leverage their awesome bridge. Together we intend to prove that it is possible to build an application on Solana with reach beyond the ecosystem itself.

We can show app developers that they can build their own apps and leverage Solana's performance, reliability and cost-effectiveness without actually picking an ecosystem to market for. Naturally, users from foreign chains will start to use SNS-warp-enabled services and will notice that they can have faster and cheaper transactions by just going Solana-native. Wallets themselves might choose to support and transparently offer users to buy some SOL, bridge some of their assets and transact on Solana to make use of their favorite apps at cheaper rates and with increased reliability. Developers and engineers are the best advocates for Solana, and a cross-chain approach empowers them to switch to Solana without leaving users behind.

Problems being solved, problems to solve

Going cross-chain complicates an application's architecture and creates several constraints to solve around:

• Smart contracts have to be written for two chains
• A messaging protocol over the bridge itself has to be designed
• Fees have to be predicted and transferred from one chain to the other

Writing smart contracts

The first challenge is to write smart contracts on foreign chains. For rust-based chains, this is not too challenging. However, EVM-based chains have a very different security model from Solana's, which means that we need to be careful.

Our strategy here is to have foreign smart contracts be thin wrappers over the bridge itself: all the core logic and security will always be on Solana. All instructions which result in a change of state will have to go through the Solana Virtual Machine. Once the state changes on Solana, an update is communicated back to the foreign smart contract which will hold a replicated version of the state. In case a vulnerability is found, it should always be possible to restore a foreign state to Solana's source of truth.

Handling gas fees

Wormhole only allows us to publish messages on one chain and access them on another. This means we still have to process (crank) this information on the destination chain. Cranking will incur gas fees which have to be covered by the user.

In order for this to be possible, we need to reliably model and invoice cranking gas fees. This is somewhat challenging because cranking gas fees are always in the destination chain's native currency. Therefore, we can either direct users to DeFi protocols in order to acquire those fees, or we can use an oracle to invoice in SOL. We have chosen to use the Pyth oracle for a smoother user experience.

After this, we need to transfer those fees from the emitter contract's vault to the destination chain crankers. We should be able to handle this using the bridge itself and wrapped assets, which enables complete decentralization of the cranking protocol. However, we will initially be using a centralized vault and permissioned cranking to limit the complexity of transaction fee models. Once a message is emitted on the Wormhole bridge, a swarm of crankers will pick it up and crank it on the foreign chain, recouping their costs using the predicted cross-chain fee.

Closing remarks

Beyond the cycles of hype and doubt, Solana's core technological proposition is as impressive and functional as it has ever been. Engineers wanting to build their web3 apps will naturally take a look at the different available blockchain solutions and pick one based on a variety of factors. Unfortunately, they might go with another blockchain for reasons other than reliability, cost and performance.

Wormhole enables us to think differently about these kinds of problems. It will prove an invaluable catalyst for protocol adoption.

Unsurprisingly, SNS is and will always remain a Solana-native protocol, tied to its titular chain. As such, our incentive is to do our best to stimulate Solana's growth by bringing in new users and builders. This is why we are incredibly excited to take the Solana Name Service cross-chain with SNS-warp. We hope you like it.

None of the above is financial advice.

Bonfida does not provide services to residents of Belarus, the Central African Republic, the Democratic Republic of Congo, the Democratic People’s Republic of Korea, the Crimea region of Ukraine, Cuba, Iran, Libya, Somalia, Sudan, South Sudan, Syria, Thailand, the UK, the USA, Yemen, Zimbabwe and any other jurisdiction in which accessing or using this website is prohibited