Composable Address Books Across Chains: Indexing the ‘User’ Not the Chain

Designing a Chain-Agnostic Contact Layer

A composable address book lets you see people and organizations as key players that you can reference across various chains, wallets, and apps. In this guide, we’ll show decision-makers how to set up a chain-agnostic contact layer using the newest standards.

What You'll Learn

Here’s what we’ll be diving into:

• CAIP‑10: This is your go-to standard for making address formats work together smoothly.
• did:pkh: A handy way to recognize users across various protocols.
• SIWE/ReCaps: Fresh approaches that help keep your interactions secure.
• Name Systems: Think ENSv2 and CCIP‑Read for all your naming needs.
• Attestations: Using EAS to help verify information reliably.
• Account Advances: Tapping into EIP‑7702 and ERC‑7579 to boost functionality.

Concrete Examples and Tips

Throughout this guide, you'll come across some handy examples and practical tips to ensure your journey is a breeze. So, let’s dive in and get started on building an address book that truly works for everyone!

---

Why a “user-first” address book now

• Nowadays, folks are hopping between L1 and various L2s all the time, often juggling externally owned accounts (EOAs) on one chain and smart accounts on another. This makes having a chain-specific address book pretty impractical.
• The bright side? We’ve got some awesome standards that make a cross-chain contact layer totally feasible. We’re talking about cool stuff like CAIP‑10 “account IDs,” did:pkh, SIWE (EIP‑4361), ReCaps (EIP‑5573), WalletConnect Namespaces, and ENS for resolving offchain/L2. If you want to dive deeper, check it out here.
• Plus, Ethereum's Pectra upgrade on May 7, 2025, introduced EIP‑7702. This nifty feature lets EOAs tap into smart-account capabilities without needing to change their address. This change seriously clears up a big usability issue, making chain-agnostic identity and payments much smoother. For more details, swing by the Ethereum blog.

The bottom line: your “contact” should be a user object that features stable, chain-agnostic identifiers. This way, it can connect to multiple on-chain accounts in a way that’s easy to verify.

---

The building blocks

1) Canonical identifiers for accounts: CAIP‑10 and did:pkh

• CAIP‑10 provides you with a chain-agnostic account string, such as eip155:1:0xabc… or cosmos:cosmoshub-4:cosmos1… This means you can tie every contact method in your app to this string, whether it’s for EOAs, smart accounts, Solana, Cosmos, BTC, and beyond. You can explore more about it here.
• The did:pkh takes CAIP‑10 and bundles it into a Decentralized Identifier (DID), like did:pkh:eip155:1:0xabc… This comes in handy when you need a DID Document or want to play around with VC/SSI stacks. If you're curious to learn more, check it out here.

Practical tip: Make sure to have both options ready for each entry--use CAIP‑10 for those speedy machine lookups and pull out did:pkh when you really need to guarantee compatibility with DIDs and VCs.

2) Wallet and session interoperability: WalletConnect Namespaces and CAIP‑25

• WalletConnect v2 Namespaces are game-changers! They help streamline everything by combining chain, method, and event permissions with CAIP chain identifiers. When you align your address book permissions with these namespaces, it makes for a smoother user experience across various dapp sessions and your contact layer. Take a look at the details here: (specs.walletconnect.com).
• CAIP‑25 sets up a great groundwork for a “create session” JSON‑RPC handshake. This is super useful if your address-book service is acting like an agent for wallets or dapps to connect to. Check it out more at (chainagnostic.org).

3) Offchain/L2 resolution for names: ENS CCIP‑Read and ENSv2

• Now, ENS is focusing on CCIP‑Read (EIP‑3668), allowing resolvers to pull records from Layer 2s or even off-chain APIs. This means your address book should easily resolve ENS names without a hitch. For the scoop, check it out here.
• With ENSv2, we’re taking a fresh look at ENS for a multi-chain world, embracing the motto “One name. Any chain.” Thanks to the new Namechain and unique registries for each name, cross-chain profiles are now not only more affordable but also super flexible. It’s the perfect moment to make ENS your primary handle in your contact list. Check out more details here.

4) Attested links: Ethereum Attestation Service (EAS)

• Dive into EAS schemas to understand relationships like “user ↔ wallet” or “brand ↔ payout address.” They’re also great for confirming claims from third parties (think along the lines of “Supplier A’s verified USDC settlement address on Base”). EAS runs on the mainnet and all the popular L2s, and you can easily snag the official contract addresses that are up for grabs. Take a look here: (attest.org).
• Plus, there's a cool option to tap into community resolvers, such as the attestations from Farcaster wallets. This allows you to turn a social identifier (FID) into a verified list of addresses. Pretty awesome, huh? If you want to learn more about it, check it out here: (github.com).

5) Authentication and capability grants: SIWE + ReCaps

• Using Ethereum to sign in (EIP‑4361) remains the simplest method for authenticating users who want to access your contact-service API. On top of that, ReCaps (EIP‑5573) empower users to grant your service certain permissions, such as “read contacts,” “write label,” or “add verification.” Take a look at the details here: (eips.ethereum.org)

6) Account models are changing: EIP‑7702 and ERC‑7579

• EIP‑7702 (Pectra) lets externally owned accounts (EOAs) hand off tasks to contract logic without changing their usual address. This means your address book will still recognize that address, even if its features evolve over time. If you're curious to learn more, take a look at this post: (blog.ethereum.org).
• ERC‑7579 is quickly becoming the must-have modular smart account interface. Those nifty modules--like validators, executors, and hooks--can now be swapped out between wallets. When you're working on a project, don’t forget to tag smart accounts with their module features. For example, you might want to label them as “supports passkeys” or “session keys installed.” If you're curious to learn more, check it out here: (eips.ethereum.org).
• Passkeys: We’re starting to see P‑256 (secp256r1) verification become super popular, all thanks to RIP‑7212/EIP‑7951 and a bunch of L2/mainnets. Get ready for a wave of passkey-native smart accounts - you can even save that function right on your contact! Curious to dive deeper? Take a look here: (eips.ethereum.org).

---

Reference data model for a composable, chain-agnostic contact

Keep your contact info neat, tidy, and respectful of privacy. Here’s a straightforward JSON record you can store on either the server or the client side, but remember to encrypt it when it’s not being used:

{
  "name": "John Doe",
  "email": "john.doe@example.com",
  "phone": "123-456-7890",
  "address": {
    "street": "123 Main St",
    "city": "Anytown",
    "state": "CA",
    "zip": "12345"
  }
}

{
  "name": "John Doe",
  "email": "johndoe@example.com",
  "phone": "+1234567890"
}

{
  "id": "did:pkh:eip155:1:0xA1b2...fE",
  "displayName": "Alice Nguyen",
  "handles": {
    "ens": ["alice.eth", "alice.base.eth"],
    "farcaster": { "fid": 12345 },
    "dns": ["alice.example.com"]
  },
  "accounts": [
    { "caip10": "eip155:1:0xA1b2...fE", "kind": "EOA", "proofs": ["eas:0xUID1"] },
    { "caip10": "eip155:8453:0x9C8...12", "kind": "Safe", "capabilities": ["erc7579:validation:v1"], "proofs": ["eas:0xUID2"] },
    { "caip10": "solana:mainnet:3h9...XJ", "kind": "SVM", "proofs": [] }
  ],
  "policies": {
    "preferredSettlement": ["eip155:8453", "eip155:42161"],
    "risk": { "status": "clean", "sources": ["chainabuse:0 reports", "scamsniffer:0"] }
  },
  "metadata": {
    "createdAt": "2025-11-20T12:00:00Z",
    "ownerProof": "siwe:msg-hash", 
    "labels": ["supplier", "priority"]
  }
}

• Your id serves as your main user key (did:pkh).
• The accounts section is a bunch of CAIP‑10 entries, along with proofs that connect them back to you. These include EAS attestations, SIWE signatures, and links from Farcaster.
• In the policies part, you’ll find all the routing and risk controls laid out.
• The handles are there to help you discover things more easily, all user-friendly and neat. They use ENS/CCIP‑Read, DNS (you might want to check out ENSIP‑17), or social IDs. (docs.ens.domains)

---

Resolution pipeline: how your app turns “Alice” into the right address on any chain

1. Normalize Input

• When someone enters an ENS name, use CCIP‑Read to resolve it and cache the corresponding CAIP‑10(s). For subnames like cb.id or base.eth, make sure you're following the Coinbase/ENS guidelines. Since a lot of this info is offchain, you'll need to access it via CCIP‑Read gateways for now. (docs.ens.domains)
• If the input is a chain address, convert it to CAIP‑10 and, if needed, calculate the checksum (EIP‑55/1191) before saving it. (eips.ethereum.org)

1. Fetch the contact record

• Start by searching with the canonical did:pkh ID. Not sure what that is? No biggie! You can also "compose" a contact using public info like ENS records (addresses, text), Farcaster custody/signers, and the latest EAS attestations. Check it out here: (docs.farcaster.xyz)

3) Verify Link Proofs

• First things first, take a look at those EAS attestations using the schema(s) you’ve accepted, and compare them against the EAS contracts for the target chain. Don’t forget to note down the UID and the block timestamp while you’re at it. You can check out the contracts here.
• For the next step with Farcaster, you’ll need to connect the FID to the custody address and check the signer authorizations on OP Mainnet (Farcaster contracts). If you’re looking for more info, you can dive into the docs here.

1. Choose the perfect account for the target chain

• If the contact already has a chain-native account ready for the destination, definitely use that one.
• If they don’t, try to select accounts with smart-account features (like 7702 delegated EOAs or ERC-7579 accounts). These are great because they can operate across different chains using modules or intents. (blog.ethereum.org)

1. Risk Screen and Finalize

• Take a good look at the destination using tools like Chainabuse, ScamSniffer, and your own allowlist. To steer clear of “address poisoning” tactics, it’s best not to auto-suggest from recent mempool neighbors; instead, focus on verified contacts and attestations. (docs.chainabuse.com)

---

Two concrete patterns you can ship this quarter

Pattern A -- Supplier payouts that “just work” across chains

Scenario: Your Treasury Team’s Payment Process

Picture this: your treasury crew is juggling monthly payments for around 300 suppliers, and they all insist on getting paid in USDC. But here's the twist: every supplier has their own go-to blockchain. Now that's what I call a lively situation!

• Discovery: To kick things off, the supplier registers an ENS name and sets up an EAS attestation for their "preferred settlement" on chains X and Y, including verified addresses. Your app will then take that “supplier.eth” name and fetch the EAS UIDs to connect those CAIP‑10 accounts. You can dive deeper into it here.
• Routing: Alright, let’s break this down. Your payout engine checks out the supplier’s preferred settlement list. If there isn’t an L2 address on that list but the supplier’s EOA has the 7702 delegation (shoutout to the post-Pectra updates), you have the option to route it through a smart-EOA policy wallet, all using the same address. This keeps everything running smoothly for the user. Curious to learn more? Check it out here.
• Safety: Before we kick anything off, the engine performs a safety check on all destination accounts using the Chainabuse and ScamSniffer APIs. If something doesn’t pass the test, a human has to come in and give the green light. To dive deeper into this, take a look at the Chainabuse Docs.

Benefits

• Operations can effortlessly switch settlement chains without having to deal with the headaches of a new onboarding process.
• Finance gets the perk of viewing a single “Supplier A” identity, regardless of which chain is in play.

Pattern B -- Consumer app: map social identity to wallets safely

Scenario: Your App Uses Farcaster IDs (FIDs) as User Handles

Alright, imagine your app is all set up to use Farcaster IDs (FIDs) for user handles. It’s a pretty neat way to assign a unique identifier to each user, and it makes everything easier to handle!

What are Farcaster IDs?

Farcaster IDs (FIDs) are unique identifiers that help you keep tabs on users in a decentralized network. Think of them as digital fingerprints that allow everyone to recognize each other while keeping privacy intact.

Why Use FIDs?

Using FIDs has a lot of perks:

• Unique Identification: Every user receives a unique ID, ensuring there’s no confusion.
• Decentralization: FIDs aren’t linked to just one platform, giving users greater control over their data.
• Easy Integration: They’re super easy to integrate into your app, simplifying things for you and your users.

How to Implement FIDs

If you're all set to dive into using FIDs in your app, here’s a handy guide to get you started:

1. Set Up Your Database: Ensure your database is ready to store FIDs alongside other user info without a hitch.
2. Modify User Registration: Revamp your signup process to add a step for generating or collecting those FIDs.
3. Integrate FIDs into Your User Interface: Show off those FIDs in a way that’s easy to understand--think profiles, leaderboards, or any spot where it feels right.
4. Handle FID Linking: If needed, give users the option to link their FIDs with other accounts or services.

Example Code Snippet

Check out this handy code snippet to kick things off:

function generateFid(username) {
    return `fid_${username}_${Date.now()}`;
}

This will generate a straightforward FID using the username along with the current timestamp.

Conclusion

Adding Farcaster IDs to your app can really boost the user experience and provide a solid method for managing identities. Plus, it’s a great move towards a more decentralized future! If you want to dive deeper, take a look at the official Farcaster documentation.

• Identity: When you create your account, you verify that you have control over your FID and submit an EAS attestation that connects your EOA/Smart Account to your FID. If you prefer, you can also use community resolvers that take care of verifying the FID to wallet connections for you. You can take a look at it here: github.com.
• Resolution: When you're sending value, your app takes care of converting “@alice” into an FID. This FID points to a verified wallet list. It first goes for the chain-native account, but if that's not an option, it falls back on EOA+7702. And don’t forget, with Farcaster's on-chain registries on the OP Mainnet, checking custody and signer status is a breeze. For all the nitty-gritty details, just head over to docs.farcaster.xyz.

Benefits:

• You get to keep your real name private.
• Your handles remain consistent across platforms.
• Swapping wallets is a breeze with attestations, so you can skip the hassle of support tickets.

---

How to back your address book with real onchain data

• Index once, reuse everywhere: With subgraphs or Substreams, pulling together data like “Contact → Accounts → Last activity → Risk tags” has never been easier. The Graph is really making a name for itself across 40+ blockchains, providing real-time Substreams for those speedy high-TPS networks like Solana and TRON, plus cross-chain token flows. You can check out the full scoop on CoinDesk.
• Cross-chain verification: If you're looking to validate information from a different chain--like checking if “this address owns X on chain B”--you’ll want to rely on trusted proofs or solid messaging systems:
  • Proofs: Check out light client/state-proof solutions like Lagrange State Committees and Herodotus storage proofs. They really help reduce any trust issues you might have. For a deeper dive, swing by Lagrange's blog.
  • Messaging: Think about using Chainlink CCIP for programmable token or data transfers, LayerZero v2 for OFT/ONFT, or Axelar GMP to make cross-chain calls smoother. These tools are super useful for keeping labels in sync or connecting attested data across different chain-local registries. For more details, check out the Chainlink documentation.

---

Security hardening against address-book poisoning

• Always make it a habit to enforce checksums and chain IDs (EIP‑55/EIP‑1191) for every EVM address. It’s important to steer clear of storing any lower-case raw addresses. You can take a closer look at it here: (eips.ethereum.org).
• It’s best to steer clear of recommending “recently interacted” addresses. We’ve noticed a rise in poisoning attacks that are getting harder to spot. Instead, stick to showing only allowlisted contacts, ENS names you can verify on your own, or EAS‑verified links. For more details, check out this article on Chainalysis.
• Be sure to combine different threat feeds: Chainabuse (which gives you reports across multiple chains) and ScamSniffer (offering delayed open feeds along with a real-time API choice). Don't forget to cache the verdicts and make sure users get clear explanations for those verdicts. You can dive into more details here: (docs.chainabuse.com).
• Keep tabs on provenance: For every address entry, jot down the resolver, the data source, and the block/time. That way, if any disputes pop up, you’ll have solid proof of what you resolved and when.

---

Implementation snippets

Normalize input to CAIP‑10 (TypeScript with viem)

When you're diving into CAIP-10, getting your input normalized is key. In this guide, I’ll show you how to tackle it using TypeScript and the viem library.

Step 1: Install the Necessary Packages

First things first, you’ll want to install the viem library. It’s a breeze to do this with either npm or yarn:

npm install viem

or

yarn add viem

Step 2: Define Your Normalize Function

Next up, let’s whip up a function that normalizes the input. This function will take a string and give back a cleaned-up version in CAIP-10 format.

import { isAddress } from 'viem';

function normalizeCAIP10(input: string): string | null {
    // Check if the input is a valid address
    if (!isAddress(input)) {
        console.error("Invalid address");
        return null;
    }

    // Normalize by converting to lowercase
    const normalized = input.toLowerCase();

    return normalized;
}

Step 3: Use Your Function

Now that you’ve got your function all set up, you can use it to normalize any input you need. Here’s a quick rundown on how to do that:

const address = '0xAbC123...';
const normalizedAddress = normalizeCAIP10(address);

if (normalizedAddress) {
    console.log(`Normalized CAIP-10: ${normalizedAddress}`);
} else {
    console.log("Failed to normalize address.");
}

Conclusion

And that’s a wrap! You’ve got a straightforward method to normalize input to CAIP-10 using TypeScript and viem. Just a quick reminder: always double-check if the address is valid before moving on with the normalization--trust me, it’ll save you a ton of trouble later! If you’re looking to dig a little deeper into CAIP standards or viem, don’t forget to check out their documentation.

import { getAddress } from 'viem'; // EIP-55 checksum
export function toCaip10(namespace: string, chainRef: string, addr: string): string {
  if (namespace === 'eip155') addr = getAddress(addr); // checksum
  return `${namespace}:${chainRef}:${addr}`;
}

Resolve ENS via CCIP‑Read and Prefer L2 Records When Present

When you're diving into Ethereum Name Service (ENS) and looking to use CCIP-Read for name resolution, it's smart to lean towards Layer 2 (L2) records whenever you can. Here’s a quick guide on how to make that happen.

Steps to Resolve ENS Names

1. Get Your Environment Ready

Before we jump in, let’s make sure your environment is ready to go. Here’s what you’ll need:

• A web3 provider
• ENS and CCIP-Read protocols

1. Use CCIP-Read to Resolve an ENS Name

To resolve an ENS name using CCIP-Read, just follow these straightforward steps:

1. Install Dependencies
   Make sure you have the necessary packages installed. If you haven't done this yet, you can set it up by running:

   npm install @chainlink/ccip 

2. Set Up the Provider
   You need to set up a provider to interact with the blockchain. Here’s a quick example using ethers.js:

   const { ethers } = require("ethers");
   
   const provider = new ethers.providers.JsonRpcProvider(YOUR_RPC_URL);

3. Create a CCIP Client
   With your provider ready, you can create a CCIP client. This will help you get the ENS data:

   const { CCIPClient } = require("@chainlink/ccip");
   
   const ccipClient = new CCIPClient(provider);

4. Resolve the ENS Name
   Now it’s time to use the client to resolve the ENS name. Here’s how to do that:

   const ensName = "yourname.eth";
   
   const address = await ccipClient.getAddress(ensName);
   console.log(`The address for ${ensName} is ${address}`);

With these steps, you should be able to easily resolve any ENS name using CCIP-Read! Just make sure to replace YOUR_RPC_URL and yourname.eth with your actual values. Happy coding!

Sure thing! Here’s a handy little snippet for you:

const ensName = "yourname.eth";
const resolvedAddress = await ccipRead.resolve(ensName);

1. Look for Layer 2 Records

   When you get the response, keep an eye out for L2 records. If you spot them, definitely take advantage of them! They usually offer better scalability and can save you some bucks. To see if L2 is supported in the response, you can check it out like this:

   if (resolvedAddress.layer2) {
       console.log("L2 address:", resolvedAddress.layer2);
   } else {
       console.log("Using default address:", resolvedAddress.default);
   }

Why Prefer L2 Records?

• Speed: L2 solutions are typically faster, meaning you'll get your transactions done in no time.
• Lower Fees: Who doesn't love saving a buck on gas fees? L2 transactions usually come with a smaller price tag compared to L1.
• Scalability: Thanks to L2, you can manage a lot more transactions, which means better performance for the whole network.

Final Thoughts

When you're diving into ENS names using CCIP-Read, don’t forget to check out those L2 records. They can really simplify things for you and help your transactions flow more smoothly. Happy coding!

import { createPublicClient, http } from 'viem';
import { mainnet } from 'viem/chains';

export async function resolveEnsToCaip10(name: string, chain='1') {
  const client = createPublicClient({ chain: mainnet, transport: http() });
  const addr = await client.getEnsAddress({ name }); // viem unwraps CCIP-Read
  if (!addr) throw new Error('ENS not resolvable');
  return toCaip10('eip155', chain, addr);
}

Verify an EAS Attestation Linking a Contact to an Account

To verify an EAS (Enterprise Account Services) attestation that links a contact to an account, just follow these easy steps to ensure everything is in order.

Step 1: Gather Necessary Information

Before you dive in, just double-check that you’ve got these handy:

• The email address of the contact
• The account ID or the name tied to the contact
• Access to the EAS dashboard or API

Step 2: Access the EAS Dashboard

Head over to your EAS dashboard and log in. If you’re going the API route, just make sure everything’s set up properly in your environment. It’s a good idea to double-check your authentication tokens or keys, too.

Step 3: Retrieve the Attestation

1. Head over to the "Attestations" section on your dashboard.
2. Use the search bar to find the specific contact by either their email or ID.
3. Check out the associated attestation that’s linked to their account.

If you’re working with the API, here’s a handy code snippet to help you grab the attestation:

import requests

url = "https://api.example.com/attestations"

params = {
    "contact_email": "contact@example.com",
    "account_id": "123456"
}

response = requests.get(url, params=params)
attestation_data = response.json()

Step 4: Verify the Details

After you've got the attestation, make sure to double-check the details:

• Contact Email: Does this match what you’ve got saved?
• Account ID: Are we looking at the correct one?
• Status: Is the attestation good to go or has it expired?

Step 5: Document Your Findings

Verification Process Notes

• Document Everything: Keep a detailed log of your verification steps. This includes dates, what was checked, and any findings.
• Identify Discrepancies: If you spot any issues, note them down right away. Be specific about what doesn’t add up and why it’s important.
• Escalation Protocol: If you need to bring an issue to someone’s attention, have your notes ready. A clear record makes it easier to explain what happened and why it matters.
• Follow Up: After escalating, check back in to see how things are progressing. It’s important to stay in the loop and ensure the issue gets resolved.

Keeping all this organized will save you time and help others understand the situation better if it comes to that!

Step 6: Follow Up

If everything seems to be in order, go ahead and confirm the attestation. But if you hit any bumps along the way, feel free to reach out to your support team or check out the EAS documentation for more help.

And that’s a wrap! You've nailed it by verifying an EAS attestation that connects a contact to an account. If you have any questions or want more info, just give me a shout!

import { ethers } from 'ethers';
import EASAbi from '@ethereum-attestation-service/eas-contracts/deployments/EAS.json';

export async function isLinkedByEAS(easAddr: string, uid: string, provider: ethers.Provider) {
  const eas = new ethers.Contract(easAddr, EASAbi.abi, provider);
  const att = await eas.getAttestation(uid);
  return att?.revocationTime === 0 && att?.time > 0;
}
// Mainnet EAS: 0xA1207F3BBa224E2c9c3c6D5aF63D0eb1582Ce587; SchemaRegistry: 0xA7b392...BDF

Reference: EAS Mainnet Contract Addresses

Take a look at the official EAS mainnet contract addresses over on GitHub. You can grab all the info you need right here: github.com.

---

Emerging best practices we apply at 7Block Labs

• For your main keys, go with CAIP‑10 and did:pkh, and don’t forget to use ENS and social handles to make things easier to find.
• Ensure that every link you include has solid proof to back it up:
  • For ENS resolution, use CCIP‑Read (and get excited for ENSv2/Namechain that’s on the horizon).
  • Utilize EAS schemas for stuff like “Verified payout address” and “Verified signer,” etc. (docs.ens.domains)
• Let’s chat about 7702 and modular accounts:
  • It’s a smart move to keep a user’s stable EOA address even while adding more advanced smart behaviors (like batched transactions or sponsored gas) through EIP‑7702 delegations.
  • Check out those ERC‑7579 modules to see what capabilities are out there (think passkeys, session keys) without getting tied to a specific vendor. (blog.ethereum.org)
• Make passkeys your top priority: If your users dig Face ID or YubiKey sign‑ins, it’s key to note where P‑256 precompile support is offered and spotlight those options first. (eips.ethereum.org)
• Index once, serve many: Boost your address book analytics with The Graph (using Subgraphs/Substreams) and stash some handy rollups for each contact, such as “last active chain,” “avg fee chain,” and “risk flags.” (coindesk.com)
• Stay safe with a defense-in-depth approach:
  • Put in place multi-feed risk checks (think Chainabuse, ScamSniffer).
  • Stick to strict checksum validation.
  • Steer clear of auto-suggestions for “recent transactions.” (docs.chainabuse.com)

---

A note on cross-chain “synonyms” for the same user

• EOAs, or Externally Owned Accounts, usually have the same address across various EVM chains. In contrast, smart accounts tend to be set up as separate deployments on each chain, meaning they can have different addresses. Here’s a handy way to keep your address book organized:
  • Group all accounts for a specific user together but sort them by chain. Use the did:pkh for the main EOA and rely on attested links for any additional smart accounts. If you want to dive deeper, check it out here.
  • When you have a choice, it's better to go with the “on this chain” accounts. If that’s off the table, consider routing instead--like using a 7702-enabled EOA or tapping into cross-chain actions (CCIP/L0/Axelar) to ensure you reach your destination safely. For more details, you can explore the official documentation here.

---

KPIs and SLOs for a production address-book service

• p95 resolution time: We're hitting under 150 ms (with a warm cache) for ENS/CCIP‑Read and EAS checks.
• False-positive rate on risk blocks: We're sitting comfortably at less than 0.5%, based on what we've gathered from human reviews.
• Link freshness: A whopping 99% of “verified address” links are refreshed within a week of an update event. Thank EAS event streams and subgraphs for that!
• Coverage: Over 95% of sends are sorted through verified identities (like ENS/EAS/Farcaster) instead of just raw addresses.

---

What to watch in 2026

• Exciting news! The ENSv2 migration toolchain and Namechain are now live! We're all about “One name. Any chain.” setting the new standard. Make sure to check it out on ens.domains.
• Mainnet is expanding its support for the P‑256 precompile (EIP‑7951), which means that passkey-native wallets are going to be super important from here on out. You can find all the details on eips.ethereum.org.
• There’s some really interesting stuff happening in the module ecosystem with ERC‑7579 (validators/executors/hooks), and we're also seeing deeper integrations of 7702 in some popular wallets. If you want to dive deeper into the details, head over to eips.ethereum.org.

---

How 7Block Labs can help

We've just launched some super user-friendly, chain-agnostic address books designed specifically for consumer apps, DAOs, and payment operations. Our approach combines CAIP-10/did:pkh identifiers, ENSv2 resolution, EAS attestations, Farcaster mappings, and 7702/7579 account detection--it's all powered by Subgraphs/Substreams and risk feeds. If you're in the market for a flexible address book that your product teams and auditors will love, we've got you covered!

---

Sources and further reading

• Dive into the CAIP‑10 account IDs, WalletConnect Namespaces, and the CAIP‑25 session handshake for some awesome insights. All the juicy details are waiting for you over at chainagnostic.org.
• Check out the awesome realm of ENS CCIP‑Read, where you can learn all about the ENSv2 “One name. Any chain.” idea and the nifty Gasless DNS Resolution (ENSIP‑17) feature. You can find everything you need over at docs.ens.domains.
• If you want to get the lowdown on the EAS overview and what’s happening with those mainnet contracts, check out attest.org for all the juicy details.
• Curious about Farcaster contracts and the schema docs that go along with them? Have a look at docs.farcaster.xyz.
• Check out SIWE (EIP‑4361) and ReCaps (EIP‑5573) to keep yourself in the loop with the newest proposals at eips.ethereum.org.
• Don't forget to watch out for EIP‑7702 (jot down May 7, 2025, for the Pectra mainnet launch) and ERC‑7579 modular accounts. You can find all the juicy details over at blog.ethereum.org.
• Make sure to check out the P‑256 precompile (EIP‑7951/RIP‑7212) and the newest updates on chain support at eips.ethereum.org.
• The Graph is growing with multi‑chain indexing and Substreams. If you're curious about which blockchains are part of this expansion, check out the details at coindesk.com.
• Lastly, make sure to familiarize yourself with the Chainabuse API, dive into the ScamSniffer lists, and pick up some insights on address checksums (EIP‑55/1191) at docs.chainabuse.com.

---