XRPPayment

Information about a Payment transaction on the XRP Ledger transferring native XRP from a source address to a receiving address.

Unlike the chain-agnostic Payment attestation type, XRPPayment exposes XRPL-specific fields directly in the response: the source r-address (XRPL addresses) as a string, raw bytes of the first Memo's MemoData, and the destination tag. This avoids the need for off-chain helpers when a consumer contract needs to act on these fields.

Supported chains

Network Type	Supported Chains
Mainnet	XRP (XRP Ledger)
Testnet	testXRP (XRPL Testnet)

Request

Field	Solidity Type	Description
transactionId	bytes32	ID of the payment transaction.
proofOwner	address	Address authorized to use the proof, where applicable. The verifier lower-cases this value.

Response

Field	Solidity Type	Description
blockNumber	uint64	Number of the ledger in which the transaction is included.
blockTimestamp	uint64	The timestamp of the ledger, derived from close_time converted to UNIX time.
sourceAddress	string	The XRPL r-address of the source.
sourceAddressHash	bytes32	Standard address hash of the source address.
receivingAddressHash	bytes32	Standard address hash of the receiving address. Zero bytes32 if status is not success.
intendedReceivingAddressHash	bytes32	Standard address hash of the intended receiving address (the Destination field). Relevant when the transaction failed.
spentAmount	int256	Amount in drops actually spent by the source address.
intendedSpentAmount	int256	Amount in drops the source intended to spend (Amount + Fee). Relevant when the transaction failed.
receivedAmount	int256	Amount in drops received by the receiving address.
intendedReceivedAmount	int256	Amount in drops the receiving address would have received had the transaction succeeded.
hasMemoData	bool	true if the transaction has a MemoData field.
firstMemoData	bytes	Raw bytes of the MemoData field of the first Memo. Empty when hasMemoData is false.
hasDestinationTag	bool	true if the transaction has a destination tag.
destinationTag	uint256	Destination tag of the transaction. 0 when hasDestinationTag is false. XRPL currently only supports uint32 destination tags.
status	uint8	Transaction success status.

Differences from Payment

XRPPayment is XRPL only and replaces the inUtxo / utxo request fields with proofOwner. The response drops standardPaymentReference, oneToOne, and sourceAddressesRoot (always implied for XRPL Payment transactions) and adds sourceAddress, hasMemoData, firstMemoData, hasDestinationTag, and destinationTag.

Verification process

1. The transaction identified by transactionId is fetched from an XRPL node or indexer via the tx method.
2. If the transaction cannot be retrieved, or its ledger lacks the required confirmations, the request is rejected.
3. A payment summary is computed for the transaction.
   • Only XRPL transactions of type Payment produce a summary; other types are rejected.
   • A successful payment has exactly one sender and at most one receiver. Multi-output payments are rejected.
4. blockNumber and blockTimestamp are extracted from the ledger if not present in the transaction data. blockTimestamp is the ledger close_time converted to UNIX time.
5. The first Memo's MemoData (if any) and the DestinationTag (if any) are surfaced unchanged in the response.

Lowest used timestamp

For the lowestUsedTimestamp parameter, the blockTimestamp of the transaction is used.

Transaction success status

Transactions on different blockchains have various success statuses. Some blockchains may include transactions even if they failed to execute as intended.

Status	Code
SUCCESS	0
SENDER_FAILURE	1
RECEIVER_FAILURE	2

Bitcoin and Dogecoin

It is not possible to include an unsuccessful transaction in a Bitcoin or Dogecoin block. Hence, if a transaction is included on a confirmed block, its status is "SUCCESS."

XRPL

On XRPL, some transactions that failed (based on the reason for failure) can be included in a confirmed block. The success of a transaction included in a confirmed block is described by the TransactionResult field.

• tesSUCCESS: Transaction successful, status is SUCCESS (0).

• tec-class codes: Indicate reasons for failure. The following codes indicate a failure that is the receiver's fault (status RECEIVER_FAILURE, 2):

  • tecDST_TAG_NEEDED: A destination tag is required by the target address but is not provided. Tagging this as the receiver's fault means the Payment attestation type does not fully support transactions that require a destination tag.
  • tecNO_DST: Considered the receiver's fault if the specified address does not exist or is unfunded.
  • tecNO_DST_INSUF_XRP: Considered the receiver's fault if the specified address does not exist or is unfunded.
  • tecNO_PERMISSION: Considered the receiver's fault only if the transaction has no DomainID. Tagging this as the receiver's fault means the Payment attestation type does not fully support transactions to accounts that require DepositAuth. If the transaction failed with tecNO_PERMISSION and has a DomainID, it is considered the sender's fault.

  All other codes indicate a failure that is the sender's fault (status SENDER_FAILURE, 1).

Standard address hash

The standard address hash is the keccak256 hash of the XRPL standard address as a string:

keccak256(bytes(standardAddress))

XRPL r-addresses are case-sensitive, so the address has a single canonical form (no lower-casing applied).

Example:

Chain	Standard Address	Standard Address Hash
XRPL	rDsbeomae4FXwgQTJp9Rs64Qg9vDiTCdBv	0xa491aed10a1920ca31a85ff29e4bc410705d37d4dc9e690d4d500bcedfd8078f

Finality

XRPL ledgers must reach the required confirmation depth before the transaction can be proven.

Chain	chainId	Confirmations required	Confirmation time
XRPL	3	3	≈12 seconds

Contract Interface

For the complete interface definition, see IXRPPayment.