The Problem: Standard Resolution Can't Handle the Load
Imagine a DApp with 100,000 daily users. Each call to provider.resolveName() hits an RPC node. Without caching, you'll quickly hit request limits—typical Infura/Alchemy tiers allow 100,000 requests per day. At a peak of 10,000 concurrent users, resolution can take up to 500 ms per name, and batch-processing a list of 1000 addresses sequentially using ethers takes 2–5 minutes. That's unacceptable for real-time applications. Moreover, you need to support multi-chain addresses (ETH, BSC, Polygon), handle wildcard domains (ENSIP-10), and off-chain data via CCIP-Read (EIP-3668). Standard libraries are not optimized for these scenarios.
We develop custom ENS resolvers that solve these problems. Our team has completed 30+ projects where we deployed robust ENS integration under high loads. Caching reduces resolution time to 1–5 ms, and batch processing of 1000 addresses completes in 2 seconds. RPC provider costs drop by up to 40%, saving up to $500 per month at scale. At 200,000 requests per day, the savings reach $6,000 per year. With over 30 successful projects and certified blockchain experts, we guarantee a resolution time under 10ms and provide a 100% satisfaction guarantee on all deployments.
The ENS Resolution Process
The full ENS lookup chain includes: name normalization (UTS-46), namehash computation (keccak256), query to the ENS Registry for the resolver address, wildcard support check (ENSIP-10), query to the resolver with coinType, and if the resolver returns OffchainLookup (EIP-3668), executing CCIP-Read. Each step can be a bottleneck. Our custom service handles the entire chain, caching intermediate results.
Custom Resolver Service with Caching
For production systems, we implement a custom resolution service with distributed caching (Redis + in-memory cache). Example in TypeScript using viem (v2.x) and node-cache:
Click to expand code example
import { createPublicClient, http, normalize } from "viem";
import { mainnet } from "viem/chains";
import NodeCache from "node-cache";
class ENSResolutionService {
private client = createPublicClient({ chain: mainnet, transport: http(RPC_URL) });
private cache = new NodeCache({ stdTTL: 300 }); // 5 minutes TTL
async resolveName(name: string): Promise<string | null> {
const normalized = normalize(name);
const cacheKey = `addr:${normalized}`;
const cached = this.cache.get<string>(cacheKey);
if (cached !== undefined) return cached;
try {
const address = await this.client.getEnsAddress({ name: normalized });
this.cache.set(cacheKey, address ?? null);
return address;
} catch (e) {
return null;
}
}
async lookupAddress(address: `0x${string}`): Promise<string | null> {
const cacheKey = `name:${address.toLowerCase()}`;
const cached = this.cache.get<string>(cacheKey);
if (cached !== undefined) return cached;
const name = await this.client.getEnsName({ address });
this.cache.set(cacheKey, name ?? null);
return name;
}
async batchLookup(addresses: `0x${string}`[]): Promise<Map<string, string | null>> {
const results = new Map<string, string | null>();
const uncached: `0x${string}`[] = [];
for (const addr of addresses) {
const cached = this.cache.get<string>(`name:${addr.toLowerCase()}`);
if (cached !== undefined) {
results.set(addr, cached);
} else {
uncached.push(addr);
}
}
await Promise.allSettled(
uncached.map(async (addr) => {
const name = await this.lookupAddress(addr);
results.set(addr, name);
})
);
return results;
}
}
This code integrates easily into any backend. A cache with a 5-minute TTL reduces RPC load tenfold. For distributed environments, we use Redis with the same TTL. For complex scenarios, we also develop Solidity resolvers that can be deployed as custom contracts. Our custom ENS resolver supports ENSIP-10 wildcard resolution, CCIP-Read handling, multi-chain addresses, ENS caching, and is built with Solidity and integrated with Web3 using ethers and viem.
How to Implement Multi-Chain Addresses?
ENS supports storing addresses for different blockchains via coinType (SLIP-44). For example, ETH = 60, BTC = 0, SOL = 501, MATIC = 966. Our service allows you to retrieve addresses for any coinType with a single function:
const COIN_TYPES = { ETH: 60, BTC: 0, SOL: 501, MATIC: 966, ARB: 9001 };
async function getMultiChainAddresses(name: string) {
const resolver = await provider.getResolver(name);
if (!resolver) return null;
const eth = await resolver.getAddress(COIN_TYPES.ETH);
const btc = await resolver.getAddress(COIN_TYPES.BTC);
const sol = await resolver.getAddress(COIN_TYPES.SOL);
return { eth, btc, sol };
}
You can add any coinType, including MATIC, ARB, OP. We provide a unified interface for working with multiple networks.
How to Handle CCIP-Read in a Custom Resolver?
CCIP-Read (EIP-3668) allows a resolver to return a link to off-chain data instead of an address. The client must make an HTTP request to that link and verify the signature. In our service, we automatically handle OffchainLookup: after receiving the error, we extract the URL and data, download them, verify the signature (if required), and cache the result. See EIP-3668 for details. For wildcard resolvers (ENSIP-10), we have full support—see ENSIP-10 documentation.
Speed Gains with a Custom Service
Take a real case: a client application resolves names for 10,000 users on load. With ethers sequentially—~50 seconds. With our custom service using cache and parallel requests—2 seconds. A 25x improvement. This is achieved by caching frequently requested names, parallel batch processing via Promise.allSettled, and avoiding duplicate RPC calls for known addresses. Every millisecond counts at peak load, so we optimize the service for maximum performance. Our custom service is 25x faster than using ethers sequentially for batch resolution.
Advantages of a Custom Service Over Libraries
Ready-made libraries (ethers, viem) work in the browser, but on the backend without caching, they quickly exhaust RPC limits. A custom service gives full control over caching, wildcard support, parallel batch resolution, and a single integration point for multiple networks. Here's a comparison:
Click to see comparison table
| Criterion | ethers/viem | Custom Service |
|---|---|---|
| Caching | No (or manual) | Built-in with TTL |
| Batch resolution | Sequential | Parallel |
| Wildcard (ENSIP-10) | Partial | Full support |
| Multi-chain | ETH only | Any coinType |
| Timeouts | Default | Flexible configuration |
Our custom service processes batch requests 5–10 times faster than ethers/viem.
How to Implement Custom ENS Resolution in 4 Steps
- Architecture analysis: Evaluate your current load, caching needs, and chain requirements. (0.5 day)
- Service design: Design API, caching schema, and error handling. (1 day)
- Core implementation: Build the resolver with caching, multi-chain, and CCIP-Read support. (2-3 days)
- Integration & testing: Integrate with your backend, conduct load testing, and deploy monitoring. (1-2 days)
Development Stages of a Custom Resolution Service
| Stage | Duration | Result |
|---|---|---|
| Architecture analysis | 0.5 day | Technical specification with metrics |
| Service design | 1 day | API documentation, caching schema |
| Core implementation | 2–3 days | Working resolver with tests |
| Backend integration | 1–2 days | Ready endpoint |
| Monitoring and optimization | 1 day | Dashboard, alerts, load testing |
What's Included in the Work
- API documentation of the resolver—REST or JSON-RPC specification with request examples
- Service deployment on your infrastructure (Docker, Kubernetes, Lambda) with monitoring and alerting
- Integration with existing backend—adaptation for fastify, express, serverless
- Team training—workshop on using the resolver and troubleshooting
- Technical support—one month after deployment
Timeline and Cost
Development of a custom resolution service with caching and multi-chain support takes 3 to 5 working days. Integration into an existing backend takes another 1–2 days. Cost is calculated individually based on scope of work. Typical project cost ranges from $5,000 to $15,000, with ROI achieved within 3–6 months. Get a consultation for your project—we'll assess the architecture and propose optimization. Contact us for an analysis of your current ENS integration: we'll identify bottlenecks and speed up resolution.