Skip to main content
Search

Integration Overview

Overview​

Wallet Verify is a GTR solution that enables VASPs (usually a Centralized Exchange) to verify the ownership of wallet addresses before processing transfer transactions.

A Wallet Verify Travel Rule request could happen in 2 situations:

TypeDescription
Pre-transaction Wallet Verify Travel Rule- The transaction has not yet been submitted to the blockchain.
- This is usually part of a Withdrawal process.
- Your VASP initiated this request to verify the ownership of beneficiary address before processing the withdrawal.
Post-transaction Wallet Verify Travel Rule- The transaction has already been recorded on the blockchain.
- This is usually part of a Deposit process.
- Your VASP initiated this request to verify the ownership of originator address after receiving a deposit.

Expiration Semantics​

Wallet Verify returns two timestamps for expiration handling:

  • qrcodeExpiredAt: the expiration time of the current single QR code session. After this time, your service may request a new QR code again with the same requestId.
  • verifyExpiredAt: the hard expiration time of the whole wallet verification request. After this time, your service must not re-issue another QR code with the same requestId.

Address is case-sensitive​

When you submit a wallet address to Wallet Verify (both beneficiaryAddress.address and originatorAddress.address), the address must be preserved in its original casing — exactly as the wallet owner will present it when signing.

  • This rule applies to every supported network, including EVM-compatible chains (Ethereum, BSC, Polygon, etc.) whose addresses are not case-sensitive at the protocol level.
  • The Wallet Verify mechanism performs case-sensitive matching for all networks. If the casing submitted here does not match the casing the wallet owner signs with, GTR cannot broadcast / dispatch the signing request to the target wallet, and the verification will silently fail to reach the wallet.
  • Do not lowercase, uppercase, or otherwise normalize the address before submission. Keep the checksummed / mixed-case form (e.g. EIP-55 for EVM chains).

See API: Create Verify for the exact payload location.

Address Screening Result​

Wallet Verify also supports an address screening result as an extra compliance signal.

  • The Wallet Verify creation API itself returns the QR code session information only.
  • After the wallet owner successfully completes message signing, GTR may perform address screening on the verified address.
  • That screening result is then included when GTR sends the callback to your service.

This screening result is advisory only. Your final business decision should still consider the wallet ownership verification result together with your own compliance rules.

Diagram Flow​

  1. Your VASP, as the Travel Rule Initiating VASP, calls the Wallet Verify API 1: Create Verify to generate a QR code and display in your Deposit or Withdrawal screen.
  2. Your user shares this QR code with the Unhosted Wallet Owner.
  3. The Unhosted Wallet Owner scans the QR code and signs a message to prove wallet ownership.
  4. GTR notifies you when the verification is completed or expired via Wallet Verify Callback 1: Wallet Verify Result
  5. Your VASP can make the final decision whether to proceed with or cancel this transfer
  6. If this is a pre-transaction Travel Rule, make sure to call Submit TXID to update GTR with your tx_id after you submit the transfer to the blockchain.

Supported Chains​

Please refer to Wallet Verification Supported Networks.