Ripple 'Require Destination Tags' Configuration


Destination tags are a feature of XRP Ledger payments that can indicate specific purposes for payments from and to multi-purpose addresses. Destination tags do not have direct on-ledger functionality; destination tags merely provide information about how off-ledger systems should process a payment. In transactions, destination tags are formatted as 32-bit unsigned integers.

Destination tags indicate the beneficiary or destination for a payment. For example, a payment to an exchange or stablecoin issuer address can use a destination tag to indicate which customer to credit for the amount of the payment in that business's own systems. A payment to a merchant could indicate what item or cart the payment is buying.

The Require Destination Tag setting is designed for addresses that host balances for multiple people or purposes, to prevent people from sending money and forgetting to use a destination tag to identify whom to credit. When this setting is enabled on your address, the XRP Ledger rejects any payment to your address if it does not specify a destination tag.

For more information please read XRP official documentation

'Require Destination Tags' Configuration in Fireblocks

By default, 'Require Destination Tags' Configuration is not enabled for XRP accounts created in Fireblocks. However, you can activate this setting for a specific XRP account within a specific Fireblocks Vault Account. This function is not directly supported by the Fireblocks system but can be implemented through the Raw Signing feature.

Ensure you review the Raw Signing Overview guide before proceeding.

Enabling 'Require Destination Tags' Configuration with Raw Signing

You can utilize the Raw Signing script for enabling or disabling the 'Require Destination Tags' configuration offered by Fireblocks.

Please ensure the following prerequisites are met before executing the script:

  1. Raw Signing is activated in your workspace
  2. A Transaction Authorization Policy rule for Raw signing is in place
  3. You possess API access, and the API user is assigned at least an 'EDITOR' role