Skip to main content
XRPL policies evaluate decoded transaction fields signed via xrpl_signTransaction.
  • Your app uses xrpl_signTransaction for RPC transaction signing. Rules for this method can use the xrpl_transaction field source below.
  • Your app uses raw_sign for raw hash signing. Rules that apply to raw_sign requests can only use system conditions, since there’s no decoded transaction to evaluate.
  • XRPL policies also apply to the exportPrivateKey and exportSeedPhrase methods. No other method is supported — * is not a valid method for the xrpl chain type.
The policy engine inspects fields on these transaction types: Payment, OfferCreate, OfferCancel, and TrustSet. All conditions use the xrpl_transaction field source. Other transaction types can still be signed — field conditions are not available for them, so constrain them with a TransactionType condition and rely on the engine’s default deny. For wallets that should sign only a known set of transaction types, write ALLOW rules scoped to those types and let everything else fall through to the default deny, rather than adding an unconditional ALLOW.

Restrict to Payment transactions only

Allowlist Payment destinations

Cap XRP payment amount

XRP amounts are expressed in drops (1 XRP = 1,000,000 drops). Cap native XRP transfers with the Payment.Amount.drops field.

Restrict IOU payments by currency and issuer

For issued currency (IOU) payments, constrain the token, issuer, and amount. Use Payment.Amount.value, Payment.Amount.currency, and Payment.Amount.issuer.
Payment.Amount.drops and Payment.Amount.value are mutually exclusive — a condition using .drops matches only native XRP payments, while .value matches only IOU payments.

Cap OfferCreate amounts

Your app can constrain DEX offers with the OfferCreate.TakerPays and OfferCreate.TakerGets fields.

Restrict TrustSet limits

Your app can control which trust lines a wallet establishes and set a maximum amount.

Denylist destinations with condition sets

Reference a dynamic address list with in_condition_set. Manage the list via the condition sets API.
The policy engine denies a request by default when no rule matches, so a DENY rule needs a companion ALLOW rule or every request is denied. Scope that ALLOW to the transaction type the wallet should sign, as the Payment condition below does. DENY takes precedence for sanctioned addresses, legitimate payments fall through to the ALLOW, and every other transaction type is denied by default.
A Payment.Destination denylist only screens Payment transactions. It does not stop value reaching the same address through a CheckCreate, EscrowCreate, or PaymentChannelCreate, and it does not cover account-control transactions such as SetRegularKey, SignerListSet, AccountDelete, or DelegateSet. The engine evaluates only the top-level transaction, so a Batch that wraps a Payment is not inspected either. Never pair a denylist with an unconditional ALLOW, which would permit all of these. For agent-controlled wallets, prefer a default-deny allowlist that permits only the specific transaction types the wallet needs.
Store classic r-addresses in condition sets, not X-addresses — an X-address item, tagged or untagged, never matches, so a sanctions-list DENY rule silently fails to catch that address. Condition sets also can’t match on destination tags; use a separate Payment.DestinationTag condition for that.
To let the wallet sign other transaction types as well, add a separate scoped ALLOW rule for each type the wallet legitimately needs, rather than widening this rule to an unconditional ALLOW.

Only allow signing after a certain date

Your app can gate signing on the current timestamp with system conditions.

Combine transaction and system conditions

Deny all signing requests

* is not a supported method for the xrpl chain type. To deny every xrpl_signTransaction request, use an empty-conditions DENY rule for that method instead.

Supported policy fields

address type fields accept both classic r-addresses and untagged X-addresses — Privy normalizes X-addresses to classic format before comparing. Tagged X-addresses are rejected when the policy is created. To restrict by destination tag, add a separate Payment.DestinationTag condition alongside Payment.Destination.