I have been in smart contract security since early 2023, I have been moving with the trend, till 2024, when I read the story of a guy that lost 25 Million dollar to wrong crypto transfer (that is the value at the time). see this: https://www.bitget.com/amp/news/detail/12560604345633

I went and read the contract to see whether there is a possible way out as the person offered 10% if his money was recovered. Since then, I have been seeing instances of wallet address user error and I discovered this is a preventable issue we have inherited from blockchain design trade-off.

I started researching crypto Ux, and in Superteam Earn I saw a Hackathon by Civic Auth, on creating a crypto app that uses their API, and Instantfolio was birthed.
https://instantfolio.gitbook.io/instantfolio/

I started working on a wallet app that uses Google sign in, completely unrelated to the current version of Nominal.

However, I could not successfully submit my project since only nine days were left to submit and I did not finish working in nine days.

I started thinking deeper about the issues. In my security research journey, I was previleged to go deeply through Ethereum Name Service contracts looking for bug to submit on Immunefi, so I knew what the design looks like. I also learned that all other blockchains have their name services which adhere to DNSSEC as they treat them as domains.

I decided that we can do something in crypto UX by making wallet names affordable for all users, interoperable across blockchains, and usable on most wallets crypto people use. I iterated it to the current text you see on the gitbook page.

Web3 identity is fragmented beyond common sense, the same human ends up with five blockchains they use everyday, ten public key schemes, and a lot of unreadable wallet addresses.

These long, alphanumeric strings are not only confusing and difficult to remember but also prone to costly errors. A single mistyped character can result in the permanent loss of funds, creating a significant barrier to entry and a constant source of friction for even seasoned users.

Blockchain name services tried to solve the issue but they are still silos for their parrticular chains. The blast radius grows every month, EIP-712 here, Ed25519 there, schnorr variants tomorrow, while state and trust splinter across L1s/L2s.

Ignoring this problem isn’t neutral; it compounds fraud, churn, and integration cost, and it caps growth because nothing portable and human-readable binds keys across chains. The necessary problem to kill is simple to state and hard to solve: establish a single, verifiable, human-readable identity that can attest across any chain and signature scheme, or keep bleeding usability, security, and composability forever.

Nominal is a cross-chain naming system for wallets, that can be used by anyone on all dapps, explorers, wallets and anything.

why are we building on Base

The smart contract managing the whole system is in Solidity, which means it can run on any evm chain, but which chain has low gas cost to handle all those cryptographic operations, has a support for builders like me, and has the potential to amplify our efforts as we distribute the solution to the world? I believe Base is the answer.

• Registry-of-record lives on Base (cheap, stable, EVM-native). All writes happen here.

• Every other chain reads from Base. No fragmentation, no split-brain. You get one truth, globally addressable

• Patterns for non-Base chains:

  • Client-read: wallets/dapps query the smart contract with Base RPC

  • Mirrors: high-traffic apps can mirror select records onto Solana/Sui/Aptos for local reads (indexers/oracles/bridges). Mirror is a cache, not the source of truth as names can expire and lapse.

  • Subscriptions: indexers listen to Base events to build autocomplete, search, analytics.

core value (what people actually use it for)

• Wallets can Send by name, not by address, on any supported chain.

  pay("dave", "solana")

  or

  pay("alice", "sui")

• Safer UX: dapps can warn on homoglyph lookalikes and recent record changes before signing.

naming model

• Name: a string
• Wallet address: wallet address on a particular chain, like b58 public key in Solana, SUI wallet address, and Aptos waddress.
• Record: keyed address + text records. smart contract on Base holds it all.

Challenge 1

In beginning of the idea, I designed the architecture similar to LayerZero, with smart contract on all supported chains. That means when registering names for any wallet, we will call a smart contract on that chain and the record will be on the chain. For example, a move contract will verify Aptos wallet ownership, receive payment and store record on Aptos, a rust contract will do the same and record on Solana blockchain for a Solana wallet.

This is a terrible design for the following:

1. dealing with many native tokens for gas on multiple chains.
2. Possibility of race condition between choosing a name and owning it, due to length of time taken before finishing all chain registrations.
3. Attack surface and terrible debugging
4. It means we will deploy a soldity contract on all EVM chains, L1s and L2s

I talked to a developer team for help to create something on top of that stack that will mitigate all those issues. They wanted to charge a lot of money that we could not afford. So, I went back to the drawing board, learning more cryptography, reading EIPs, learning more about how wallets work on all major chains and then a magic happen.

So, I decided we will use one smart contract, so that one registration for evm wallet is enough for all other chains, and other wallet signatures can be verified by the same smart contract and registered. But then I made a dumb and naive choice. I stored all wallet addresses as a mapping:
mapping(string=>address)
Have you seen the bug?
Address type on evm holds a 20-byte value. I sui for example, address is 32 bit value.

This means queries to resolve names will always be wrong. When I discovered that, I treated all wallet addresses as unique bytes with their specific chain requirements.

Challenge 2

Also, think of what it means for 25 yo to convince 45 yo and 42 yo to be his team members. That is what I did in the beginning and now we are 7 in the team.

Challenge 3

Our smart contracts were fine, until we created the frontend and wired them, then some followers suggested a significant improvement to the business model. After adding yearly expiry and renewal logic, stack too deep kept coming.

I refactored the code to use structs, then the whole size of the contract is more than the EVM contract size limit.
I used solx compiler and ditched solc. It deployed successfully but Etherscan (on which Basescan is built), does not support solx for contract verification.

To date, I am working on making the contract either modular or smaller. This is the challenge not solved today.
Also, we are battling backward compatibility to support additional chains and their verification of wallets in the future.
For now, we are only planning to support EVM, Solana, Aptos, and SUI at Mainnet launch.

github.com/Misbah-Engr/Nominal

app.nominalid.com

We provide a usable cross-chain names at affordable yearly subscription.
Nominal stands out because it kills cross-chain fragmentation with a single source of truth on one Base smart contract,. A name maps to (chain => canonical account bytes), so wallets/dapps resolve once and route anywhere.

It’s built for devs: small ABI, deterministic strict normalization, reverse lookup, and EIP-712 operations for clean signing. Business model is boring-strong: low yearly subscription plus optional referral cuts for wallets, so distribution is incentives.

Contract (on Base Sepolia testnet) with register/renew, resolve(name, chainId), and addressToName.

Strict name normalization + uniqueness checks to curb look-alikes and collisions.

End-to-end demo dapp: search => register => resolve across multiple chains via canonical bytes, no bridging.

Check feedback here:

1. https://x.com/Designer_Misbah/status/1970158285752836315
2. https://x.com/Designer_Misbah/status/1970427932935066036
3. https://x.com/Designer_Misbah/status/1966829325895774265

Alpha validation:

The alpha validation plan for Nominal focuses on stress-testing product-market fit through early, hands-on adoption across multiple ecosystems. In the first phase, we’ll onboard 500 power users from Base, Aptos, SUI, Optimism and Solana communities who actively manage multiple wallets or developer profiles. Using a closed invite system, we’ll test Nominal’s universal name resolution, cross-chain identity linking, and renewal UX. Every on-chain interaction, registration, resolution, will be monitored via analytics dashboards to measure latency, success rate, and wallet retention. We’ll also track qualitative metrics such as perceived simplicity and trust during user interviews with early community testers and ecosystem partners.

In the second phase, validation will expand to protocol-level integrations. We’ll collaborate with 3–5 partner dApps (DEXs, NFT markets, and wallets) to integrate Nominal names as an identifier layer. The goal is to confirm Nominal’s interoperability and measure reduction in wallet-switching friction. Data gathered, conversion rates, user engagement, and API call volume, will serve as evidence of adoption readiness. Success criteria include 80% of testers completing renewals without support, 70% reporting improved usability over ENS, and at least two dApps retaining Nominal post-test.

Target users who pay us money

They are web3 wallet users that want to more easily receive crypto without copying every wallet every time, very similar to SUINS, ENS, and Solana Name service users, but the ones that want one name for all chains.

Then the consumers of our data

Multi-chain wallets & SDKs (Base-first, EVM + non-EVM support): need one handle to many chains.

Cross-chain dapps/routers/DEX aggs/intents: want deterministic name - > address for routing without forcing wallet addresses everything. To make ux better for users.

Consumer apps (social, gaming, NFT markets): want human-readable logins in names in place of wallet addresses.

Custodians/CEX/fintech: deposit whitelists + compliance logs tied to a single canonical name.

AA toolkits & infra: simpler, contract-level resolution for smart accounts, fewer moving parts.

All these consumers get name resolution for free for their users. But, they can allow name claiming on their platforms to earn a percentage fee from user registrations.

Ethereum Name Service (ENS) - https://ens.domains

Ethereum-based .eth names; records live on Ethereum; supports multi-coin address records; standard yearly renewals.
support.ens.domains

Unstoppable Domains - https://unstoppabledomains.com

One-time purchase (no renewals), minted on Polygon; markets “no gas/renewal fees.”

Solana Name Service (SNS / Bonfida) - https://www.sns.id

Native .sol domains on Solana; wallet/dApp integrations via Bonfida.

SPACE ID - https://www.space.id (TLDs page: https://www.space.id/tld)

Multi-chain name platform (.bnb, .arb, etc.); register/trade/manage across supported chains.

Aptos Name Service (ANS) - https://www.aptosnames.com

.apt names for Aptos wallets; Aptos-native identity.

Sui Name Service (SuiNS) - https://suins.io

Sui-native names; names are NFTs that can be transferred/traded.

Our Differentiators

• We merge lots of chain for the user into one name without a suffix, e.g 'vitalik' instead of vitalik.eth, vitalik.sol, vitalik.apt, vitalik.bnb

• Dapps and integrators can simply use base rpc and get the wallets from the names

• One-contract global registry (Base-first). Single source of truth for all chains - no per-chain registries or name NFTs.

• flat rate for all names based on number of chains a user wants to connect.

• Bridge-free cross-chain mapping. name - (chainId - account bytes) incl. non-EVM (Solana/Sui/Aptos) without wrappers.

• One-call resolver + global reverse. resolve(name, chainId) and addressToName work across chains from the same registry.

• EIP-712 typed operationss by default. Clean, predictable signing for register/renew/update.

• Protocol-native wallet revenue-share. Renewals pay integrator wallets automatically, distribution is economically aligned.