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.gao →
Ethereum (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._