Protocol specification

The protocol separates identifier resolution from registry management and keeps payment execution inside the user’s wallet.

Request and response model

identifier + type
        ↓
normalization
        ↓
registry or authoritative resolver
        ↓
status + trust metadata + payment options
        ↓
wallet transaction flow

POST /v1/resolve
{ "type": "email", "value": "pay@example.com" }

→ {
    "status": "active",
    "payment_ready": true,
    "payment_options": [...]
  }

Normative rules

• Identifier types are explicit; a value without a type is ambiguous.
• Only active, payment-ready mappings are immediately payable.
• Pending and changed destinations must fail closed.
• Resolution must not mutate registry state.
• Protocol infrastructure does not custody or settle funds.

Implementation checklist

1. Keep the identifier type next to the value at every boundary.
2. Normalize and validate input before displaying a resolver result.
3. Check both top-level and option-level payment readiness.
4. Show chain, asset, contract, recipient, and amount constraints.
5. Re-resolve after a meaningful delay or state transition.
6. Let the wallet sign and broadcast only after user confirmation.