Hey all, looking for feedback on a cross-chain resolution pattern I haven’t seen done before.
The problem
Recipients publish stealth meta-addresses (ERC-5564 / ERC-6538) on Ethereum via ENS. But a lot of senders I care about are on Solana, in wallets with no Ethereum RPC in their signing path. They need to resolve alice.opq.eth to the same meta-address an Ethereum sender would get, without a CCIP-Read gateway (not viable for non-EVM VMs) and without hitting an Ethereum node.
The approach: a read-only bridge mirror
Ethereum stays canonical. Every state change on the registry emits a guardian-signed cross-chain message via Wormhole. On Solana, a program holds one PDA per name, derived from keccak256("alice.opq.eth"), writable only by verified messages from the canonical emitter. No direct write path exists from the Solana side.
A Solana sender derives the PDA client-side and reads one account. That’s it. No Ethereum RPC, no getProgramAccounts scan, no gateway, no server.
Consistency model is intentionally boring: eventually consistent, canonical-chain-wins. The mirror lags by bridge latency (Ethereum finality + guardian signing + relay). Clients that can reach Ethereum may prefer canonical and treat the mirror as a fast path. Mirror-only clients accept the lag. No atomicity claims.
Claims can also originate from Solana
Since some users only have a Solana wallet, names can be claimed from Solana too. The claim travels back over the bridge to the Ethereum registry, which registers it only if the name is still free. If an Ethereum registration won the race, the cross-chain claim is silently consumed. The name never resolves while a claim is provisional.
Trust model
Resolution on both chains is a pure on-chain read. The only added trust assumption over plain ENS is the bridge’s guardian threshold, and only for sync. If the bridge halts, existing records on both chains keep resolving fine. A malicious relay can delay messages but never forge them.
Why Opaque needed this
Opaque is a cross-chain stealth payment protocol running on Ethereum and Solana. The core flow is standard DKSAP: recipients publish a single meta-address (a viewing key + spending key pair), and senders derive a fresh one-time address per payment using secp256k1 ECDH. The sender and recipient are cryptographically unlinkable on-chain.
The problem is that Opaque’s user base spans both chains. A recipient might register their meta-address on Ethereum via ERC-6538, but a large share of senders are in Solana wallets, in a Phantom-style environment with no Ethereum RPC anywhere in the signing path. They need to look up alice.opq.eth and get the same meta-address an Ethereum sender would, without leaving their native environment.
Opaque already uses Wormhole for its Universal Announcement Bus (cross-chain payment announcements), so the bridge infrastructure was already trusted and in place. The question was just: can we use the same transport to keep name resolution working natively on Solana?
What I’d like feedback on
-
Is bridging a read-only mirror a reasonable way to let a non-EVM chain resolve an ENS name, or is there a path I’m missing?
-
Anything structurally wrong with the eventual consistency model here?
This is live on Sepolia + Solana devnet powering opaque.cash. Happy to share contracts and client resolution code. Really after the “you’re reinventing X, go look at Y” responses as much as anything.