Using NNS Adapter

You can use our NNS Adapters to use existing api from viem or wagmi or any ENS compatible without writing new code. Just change ensRegistry and ensUniversalResolver in your library config and you're ready to go

For adapters smart contract addresses, please check this page:

Contract addresses

Example:

export const monadDevnet = defineChain({
   id: 41454,
  name: 'Monad Devnet',
  nativeCurrency: {
    decimals: 18,
    name: 'Monad',
    symbol: 'MON',
  },

  rpcUrls: {
    default: {
      http: [...],
    },
  },

  contracts: {
    ensRegistry: {
      // NNS Adapter
      address: '0x...',
    },
    ensUniversalResolver: {
      // NNS Universal Resolver Adapter
      address: '0x...',
    },
  },
})

const client = createPublicClient({
  chain: monadDevnet,
  transport: http(),
})

async function main() {
  const ensAddress = await client.getEnsAddress({
    name: normalize('test.nad'),
  })

  const avatar = await client.getEnsAvatar({
    name: normalize('test.nad'),
  })

  const ensName = await client.getEnsName({
    address: '0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
  })

  const resolver = await client.getEnsResolver({
    name: normalize('test.nad'),
  })
  const avatarStr = await client.getEnsText({
    name: normalize('test.nad'),
    key: 'avatar',
  })

  console.log(ensAddress)
  console.log(avatar)
  console.log(ensName)
  console.log(avatarStr)
  console.log(resolver)
}

Pros & Cons

✅ Pro

• Zero Code Changes: Simply swap contract addresses in existing ENS integrations

• Seamless ENS compatibility: minimal code changes if you already use ENS clients library like Ethers or Viem.

• Low integration friction: no new SDKs or coding required, just adapter config.

• Broad tooling support: works with any ENS-aware tooling and ecosystem.

⚠️ Cons

• ENS Limitations: Constrained by ENS API design choices