Payment-resolution
Payment is a capability of identity — not the identity itself.
Gao Domain provides the identity anchor. Gao Payment (Layer 4) executes the settlement. The domain resolves who the recipient is; the payment layer handles how value moves. These are distinct responsibilities with a clean boundary.
Version: GD/1.2 — Module: Core Capabilities
The Problem with Sending Crypto Today
Recipient: 0x9a2f4c8d3e1b7a6f2c5d9e0b3a8c4f7d2e6b1a9c
Amount: 50 USDC
Network: Ethereum
Three fundamental problems:
Dangerous. A single wrong character sends funds to an unrecoverable destination. No undo. No support line.
Not human. No person can meaningfully read, remember, or verify a 42-character hex string. Every interaction requires copy-paste.
Surveillance. Giving someone your wallet address gives them permanent access to your complete financial history — every transaction, every balance, every counterparty.
How Gao Domain Solves This
Send $50 USDC to: alex.gao
That is the complete user-facing interaction. The resolution and routing happen invisibly:
User inputs: alex.gao
↓
Gao Resolver Network
├── Looks up alex.gao
├── Retrieves preferred chain and token
├── Returns payment proxy address
└── Constructs transaction
↓
On-chain: Sender → Proxy → Alex's real wallet
Alex's real wallet: never exposed, never on-chain in linkable form
---
### Payment Proxy Architecture
Each domain in Private or Contacts mode has a dedicated **proxy contract** deployed per supported chain. The proxy is the public-facing payment address — it receives funds and forwards to the owner’s real wallet.
merchant.gao proxies: ├── proxy_merchant_base (0xPROXY_BASE...) Base chain ├── proxy_merchant_eth (0xPROXY_ETH...) Ethereum ├── proxy_merchant_sol (PROXY_SOL...) Solana └── proxy_merchant_polygon (0xPROXY_POLY...) Polygon
**The proxy address is stable.** When a merchant changes their real wallet (key rotation, security upgrade), the proxy address stays the same. Customers who have saved `merchant.gao` do not need to update anything.
**The real wallet address is never on-chain in a linkable way.** Senders cannot look up the merchant’s balance. The financial history of the real wallet remains private.
#### Proxy Contract Properties
// Simplified proxy contract
contract GaoDomainProxy {
address private realWallet; // private — not readable externally
bytes32 public immutable domainHash;
address public immutable registry;
// Receives any ERC-20 and forwards to realWallet
function receiveAndForward(address token, uint256 amount) external { ... }
// Only registry can update realWallet (after owner signature verified)
function updateRealWallet(address newWallet) external onlyRegistry { ... }
}
- `realWallet` is `private` storage — not readable via any public view function
- Only the Registry contract can call `updateRealWallet`, and only after verifying a valid owner signature
- An attacker cannot redirect forwarded funds without the owner’s private key
---
### Multi-Chain, One Name
`alex.gao` resolves correctly regardless of which chain or token the sender is using:
Sender on Ethereum → alex.gao resolves to ETH proxy Sender on Base → alex.gao resolves to Base proxy Sender on Solana → alex.gao resolves to SOL proxy Sender using USDC → auto-routes to preferred USDC address Sender using ETH → auto-routes to ETH address
Alex configures a preferred chain and token once. All incoming payments route there automatically, regardless of what the sender is using.
---
### Currency Routing
Routing is deterministic. Priority order:
1. Merchant (payee) preferred network
2. Lowest effective fee for the intent amount
3. Payer wallet compatibility
4. Governance-approved network priority overrides
Cross-chain operations additionally require: whitelisted bridge, slippage within policy tolerance, explicit user approval of cross-chain path, receipt logging of bridge details.
---
### Payment Flow (Full)
┌────────────────────────────────────────────────────────────┐ │ 1. Sender inputs: "Send $50 USDC to merchant.gao" │ │ │ │ 2. Gao Pay queries Resolver: │ │ → Gets: proxy address, preferred chain, preferred token│ │ → Gets: recipient trust level │ │ │ │ 3. Trust check displayed to sender: │ │ ✅ merchant.gao — Business Verified │ │ [Cancel] [Confirm $50 USDC] │ │ │ │ 4. Transaction constructed: │ │ FROM: sender_wallet │ │ TO: proxy_merchant_base (NOT real wallet) │ │ AMOUNT: 50 USDC │ │ │ │ 5. Sender's wallet signs transaction │ │ │ │ 6. Transaction broadcast to Base chain │ │ │ │ 7. Proxy receives funds → forwards to merchant real wallet│ │ │ │ 8. Canonical receipt generated and stored │ └────────────────────────────────────────────────────────────┘
Payment Receipts
Every payment generates a cryptographically signed receipt:
Receipt #GAO-20260415-001
From: alice.gao (Identity Verified)
To: amysnails.gao (Business Verified)
Amount: $80 USDC
Chain: Base
Time: 2026-04-15 14:32:07 UTC
Memo: Manicure April 15
Tx: 0x... (verifiable on-chain)
Receipts are stored in Gao Workspace and accessible to both parties as proof of payment — without either party exposing their real wallet address.
Trust at Payment Time
When a user initiates a payment, Gao Pay displays the trust level of the recipient:
✅ Verified Business
booking.amysnails.gao
Amy's Nail Salon — Houston, TX
─────────────────────────────
Safe to proceed
vs.
⚠️ Unverified Domain
nail-salon-pay.gao
This domain has not been verified.
Gao cannot confirm who controls it.
─────────────────────────────────
[Cancel] [Proceed at own risk]
This trust signal requires no technical knowledge from the user — equivalent to the green padlock on HTTPS.
Payment Request Links
Any .gao domain holder can generate a payment request:
pay.amysnails.gao?amount=80&token=USDC&memo=Manicure+April+15
→ Generates a payment link or QR code
→ Payer scans/clicks → Gao Pay pre-fills all fields
→ One tap to confirm
---
### For Businesses
Use Case
Example
Merchant checkout
`Pay for your order: store.merchant.gao — $24.99 USDC`
Invoice payment
`Invoice #1042 → Pay to: billing.lawfirm.gao — $1,500 USDC`
Payroll
`March salary → employee.gao — $3,200 USDC`
B2B settlement
`Purchase order → supplier.gao — $45,000 USDC`
In every case, the payer sees a name. The payment routes correctly. Neither party needs to understand the underlying blockchain mechanics.
---
### Privacy Modes and Wallet Visibility
Mode
Who sees real wallet
Payment routing
Private (default)
No one
Via proxy
Contacts
Only contacts in Identity Graph
Direct
Public
Everyone
Direct
**Wallet rotation in Private mode:** The owner changes their real wallet in the Resolver (owner-signed, instant, off-chain). The proxy address stays the same. No on-chain link between old and new wallets.
---
### API Integration
POST /v1/pay
{
"to": "merchant.gao",
"amount": "50.00",
"token": "USDC",
"chain": "base",
"memo": "Order #1042",
"from_wallet": "0x123...abc"
}
{
"to_domain": "merchant.gao",
"to_proxy": "0xPROXY_MERCHANT_BASE",
"amount": "50.00",
"token": "USDC",
"recipient_trust": 2,
"recipient_label": "Business Verified",
"unsigned_tx": "0x...",
"status": "pending_signature"
}
The real wallet address of `merchant.gao` is never returned. The client signs `unsigned_tx` and broadcasts it.
---
_Payment resolution depends on Gao Domain (Layer 5) for identity and Gao Payment (Layer 4) for settlement execution. See Gao Payment for the full settlement lifecycle._