G

Multi-Chain Identity Mapping

Multi-Chain Identity Mapping

Version: GD/1.2 — Module: Identity Model


Principle#

A .gao domain maps to multiple blockchain identities simultaneously. One identity. Multiple chains. No fragmentation.

merchant.gaoEthereum (eip155:1)     → 0xETH...
  Base (eip155:8453)      → 0xBASE...    ← preferred
  Solana (solana:mainnet) → SoL...
  Polygon (eip155:137)    → 0xPOLY...

The domain owner configures a preferred chain and token once. All incoming payments route there automatically, regardless of what chain the sender is on.


Mapping Schema#

{
  "wallets": {
    "eip155:1":       { "address": "ENCRYPTED", "proxy": "0xPROXY_ETH"  },
    "eip155:8453":    { "address": "ENCRYPTED", "proxy": "0xPROXY_BASE" },
    "solana:mainnet": { "address": "ENCRYPTED", "proxy": "PROXY_SOL"    },
    "eip155:137":     { "address": "ENCRYPTED", "proxy": "0xPROXY_POLY" }
  },
  "preferred_chain": "base",
  "preferred_token": "USDC"
}

In Private mode (default), wallet addresses are encrypted in the resolver. The proxy address is public — it receives payments and forwards to the real wallet. The real wallet address never appears on-chain in a linkable way.


Routing Logic#

When a payment is initiated to merchant.gao, the Currency Router selects the settlement path deterministically:

1. Recipient (payee) preferred network
2. Lowest effective fee for the intent amount
3. Payer wallet compatibility (available balance on network)
4. Governance-approved network priority overrides

If no path satisfies all constraints, the intent is rejected. Routing is never ambiguous — same inputs always produce the same routing decision.


Cross-Chain Settlement#

Cross-chain settlement (sender on Ethereum, recipient prefers Base) is supported when:

  • The bridge is on the governance-approved bridge whitelist

  • Slippage is within the policy-defined tolerance

  • The additional bridge fee is disclosed before user signing

  • The user explicitly approves the cross-chain path

Cross-chain intents are automatically classified as Tier 3 (out-of-band human authorization required) regardless of amount, due to the additional confirmation complexity.


Wallet Rotation — Privacy-Preserving#

When a domain owner changes their real wallet (key rotation, security upgrade), the proxy address stays the same. Senders who have saved merchant.gao or the proxy address do not need to update anything. No on-chain link between old and new wallets is created.

Before rotation:
  proxy_merchant_base  forwards to  wallet_OLD

After rotation (off-chain, owner-signed, instant):
  proxy_merchant_base  forwards to  wallet_NEW

proxy_merchant_base: unchanged
On-chain transaction linking OLD  NEW: none

---

### Key Properties

Property

Description

Chain-agnostic identity

The domain identity is independent of any specific chain

Zero-gas record updates

Wallet mapping changes are off-chain and owner-signed

Seamless UX

Senders type a name; routing resolves transparently

Forward-compatible

New chains can be added to the mapping at any time

Privacy-preserving

Real wallet addresses encrypted; only proxy addresses public

---

### Why Traditional Systems Fail

**Traditional problem:** One wallet address per chain. A user on Ethereum has `0xabc...`. On Solana they have `9sd...`. On Base they have `0xdef...`. There is no unified identity  and sharing any address reveals the full transaction history of that chain.

**Gao solution:** One `.gao` name resolves correctly for any chain. Privacy is preserved by default. The identity is the same regardless of which chain the transaction settles on.

---

### Supported Chains (V1)

Chain

Chain ID

Status

Base

eip155:8453

 Primary

Ethereum

eip155:1

 Supported

Solana

solana:mainnet

 Supported

Polygon

eip155:137

 Supported

Arbitrum

eip155:42161

🔄 Planned V2

Optimism

eip155:10

🔄 Planned V2

Any ERC-20 token on a supported chain can be sent to a `.gao` domain. Token preference is set by the recipient in their resolver record.

---

_Multi-chain mapping is one capability of the identity container. See Identity Container for the full identity model and Payment Resolution for the complete payment flow._