Rezva
Integrate

How It Works

Technical overview of the Rezva resolution protocol: how identifiers are normalized, resolved, protected, and returned to integrated wallets.

Resolution model

Rezva maps an identifier type and value to crypto payment destinations through a resolver. It does not settle, custody, or bridge the original payment network tied to that identifier.

Identifier Type + Identifier Value
            ↓
         Resolver
            ↓
  Crypto Payment Destination

Supported identifier types include phone numbers, QR payloads, merchant IDs, email addresses, PayPal usernames, custom identifiers, and protocol-native names. The type system is extensible.

Protocol boundary

The resolver discovers payment options and safety metadata. The integrated wallet validates the result, presents options, signs, and settles onchain.

  • Resolver returns normalized identifiers, payment readiness, safety timestamps, and compatible payment options.
  • The wallet executes the transaction using its existing signing and broadcast infrastructure.
  • Rezva does not initiate, sign, broadcast, custody, or settle blockchain transactions.

Controller model

Registration and management are controller-scoped. A controller owns the mappings attached to their identifiers.

Controller
    ↓
Profile / Name
    ↓
Identifiers
    ↓
Crypto payment destinations

Controller authorization is separate from wallet-provider authorization. An approved provider credential does not grant ownership of a controller's identifiers.

Wallet integration levels

Approved wallet providers integrate one of two capability levels. These are hard capability rules.

Resolver only

  • Resolve identifiers
  • Scan or parse supported identifier carriers
  • Present payment options and safety metadata
  • Pay through the wallet's existing transaction flow
  • Must not expose registration, update, or removal

Resolver + merchant setup

  • Everything in Resolver only
  • Name and identifier availability checks
  • Register identifiers and payment destinations
  • Update or remove controller mappings

Registration paths

Controllers may register and manage mappings through the official dashboard business track (after application approval) or through an approved wallet that implements merchant setup.

  • Official website: connect wallet, sign registration, add names, identifiers, and payment destinations.
  • Partner wallet: the same controller flow may be offered inside an approved wallet application.
  • The controller does not need to use a specific wallet application to maintain a mapping.

Lifecycle and safety

Protocol state affects whether a mapping is payable and how wallets should warn users.

  • New registrations may enter PENDING before becoming payment-active. Wallets must not treat PENDING mappings as normal payable destinations.
  • Payment destination changes may enter UPDATE_PENDING. Wallets must surface recent destination changes using protocol timestamps such as last_payment_update.
  • Important safety fields include registered_at, activated_at, last_updated, and last_payment_update.
  • Production resolver access is permissioned to approved integrations with rate limits and anti-enumeration controls.

External payment systems

Existing networks such as bKash, Nagad, PayPal, Bangla QR, UPI, Pix, and PromptPay are lookup namespaces, not settlement integrations.

  • The original payment network does not process the crypto transaction.
  • The same QR or username may still be interpreted by its original application.
  • A compatible crypto wallet may use the same identifier as a lookup key through Rezva.
  • No cooperation or API access from the original payment provider is required for resolution.