How will the functionality of ENS be affected if names were transferred to Solana via bridge ?
I’m reading the bridge only supports ERC-721.
Are there plans for a cross chain interoperability contract that’s supports usability for ENS names ?
4 Likes
Our CCIP-read off-chain resolver can work with any external storage.
One example is Lens profile where the chain is on Polygon but stani.lens is also extended as stani.lens.xyz
Bear in mind that the current implementation is all based on trusted solution where you have to trust the gateway service that fetches the data offchain. We are working on so called l2 resolver which is more minimised but only work on rollup chains like Optimism, Arbitrum, Linea, Starknet, etc. I explained the more detail at my recent Ethcc talk here
Without these integration, bridging the ENS name to other chain alone has no effect.
When the name (as NFT) is bridged to other chain, the token is often owned by the bridge contract but ENS name resolution is irrelevant to the name ownership (it just looks up ENS record on the resolver contracts).
3 Likes
So how would one use an ENS name on Solana? is there any resolution tools for this yet?
2 Likes
ENSIP-9: Multichain Address Resolution - ENS Documentation allows users to set non ETH coin addresses to ENS. Wallets that want to integrate ENS with Solana can simply query Solana cointype against Ethereum Mainnet.
2 Likes
Seems like there could be a potential for sending assets cross-chain if there isn’t a method to check against the ENS resolver on ethereums chain.
for example;
If a provider using ENS resolution on Solana may not always provide the correct or up to date resolution of a name if there isn’t an interface implementation to check cross-chain to an Ethereum side resolver. Is that correct?
If that is correct then there needs to be cross-chain resolver check to verify that the address resolution is in fact up to date and or correct. Would this be an issue in some rare cases that the registered address may change or has changed before or during the cross chain transfer of assets?
1 Like
I don’t quite understand your question nor why this is only issue for Solana. If address is not set nor up to date, it will have issue resolving whether the record is set on l1 or offchain
1 Like
The resolver on ethereum has direct access to on chain data and is able to access information stored freely. Where as a request from solana would have to open a request to ethereum sort of like a web socket to retrieve updated information or else rely on stale data that resides on solana.
So unless there is a constant open data line to and from, then there is a potential for error in resolution when resolving on solana.
1 Like
You just make two separate RPC connections, one to Ethereum to resolve Solana address and another one to Solana. I explained the basics at these two posts in the past
- How to Support ENS for Multi-Chain Dapps | by makoto_inoue | Medium
- Improved ENS Support for EVM-Compatible Chains | by makoto_inoue | Medium
This method should apply regardless of the storage chain (aka offchain) being EVM compatible or not (the only difference is that non evm chain has to have coinType defined in SLIP44 which Solana already has).
This method obviously doesn’t incorporate crosschain synchronous lookup (as you mentioned, Etherem L1 has no direct access to “other” chain data whether it’s EVM compatible or not) but again CCIP-read is designed to be asynchronous
3 Likes
125 records on etc is interesting…
why no talk about Durin ever?
1 Like
Durin is what’s called CCIP-read/EIP3668 now. We rebranded a few years ago when we partnered with ChainLink for the collaboration.
2 Likes