Direct XAG Payments

The basis of any financial system is transferring value: or, in one word, payments. The simplest type of payment in the XAG Ledger is a direct XAG-to-XAG payment, which transfers XAG directly from one account in the XAG Ledger to another.

About Direct XAG-to-XAG Payments

Generally, any address in the XAG Ledger can send XAG directly to any other address. The address on the receiving side is often called the destination address, and the address on the sending side is called the source address. To send XAG directly, the sender uses a Payment transaction, which can be as concise as the following:

{
  "TransactionType": "Payment",
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
  "Amount": "13000000"
}

These transaction instructions mean: Send a payment from rf1Bi... to ra5nK... delivering exactly 13 XAG. If the transaction is successfully processed, it does exactly that. Since it usually takes about 4 seconds for each new ledger version to become validated, a successful transaction can be created, submitted, executed, and have a final outcome in 8 seconds or less, even if gets queued for the ledger version after the current in-progress one.

Caution: The Payment transaction type can also be used for some more specialized kinds of payments, including cross-currency payments and partial payments. In the case of partial payments, it is possible that the Amount shows a large amount of XAG even if the transaction only delivered a very small amount. See partial payments exploit for how to avoid crediting a customer for the wrong amount.

Direct XAG-to-XAG payments cannot be partial payments, but partial payments can deliver XAG after converting from a different source currency.

Funding Accounts

Any mathematically-valid address can receive a payment, even if the XAG Ledger has no record of that address existing beforehand, as long as the payment delivers enough XAG to meet the minimum account reserve. If the payment would not deliver enough XAG, it fails.

For more information, see Accounts.

Address Reuse

In the XAG Ledger, addresses where you can receive payments are permanent, and have a non-trivial reserve requirement of XAG that they cannot spend. This means that, contrary to some other blockchain systems, it is not a good idea to use a different, disposable address for every transaction. The best practice for the XAG Ledger is to reuse the same address for multiple transactions. If you use the address regularly (especially if it's managed by an internet-connected service), you should set a regular key and proactively change keys on a regular basis to reduce the risk of a key compromise.

As a sender, it is best not to assume that your intended recipient is using the same address from the last time you sent them a payment. Inevitably, sometimes security compromises happen and a person or business has to change addresses. Before sending money, you should ask the recipient for their current receiving address, so you don't accidentally send money to a malicious user who has taken control of a compromised old address.

How Direct XAG Payments Are Processed

From a relatively high level, the XAG Ledger's transaction processing engine applies a direct XAG payment as follows:

  1. It validates the parameters of the Payment transaction. If the transaction is structured to send and deliver XAG, the transaction processing engine recognizes it as a direct XAG-to-XAG payment. Validation checks include:

    • Checking that all fields are formatted correctly. For example, for Direct XAG Payments, the Amount field must be drops of XAG.
    • Checking that the sending address is a funded account in the XAG Ledger.
    • Checking that all provided signatures are valid for the sending address.
    • Confirming that the destination address is different than the sender address. (It is not sufficient to send to the same address with a different destination tag.)
    • Confirming that the sender has a high enough XAG balance to send the payment.

    If any check fails, the payment fails.

  2. It checks whether the receiving address is a funded account.

    • If the receiving address is funded, it checks whether the receiving address has any limitations on receiving payments, such as DepositAuth or RequireDest. If the payment does not meet any such limitations, the payment fails.
    • If the receiving address is not funded, it checks whether the payment would deliver enough XAG to meet the minimum account reserve. If not, the payment fails.

  3. It debits the sending account by an amount of XAG specified by the Amount field plus the XAG to be destroyed for the transaction cost and credits the receiving account for the same amount.

    If necessary, it creates a new account (AccountRoot object) for the receiving address. The new account's starting balance is equal to the Amount of the payment.

    The engine adds a delivered_amount field to the transaction's metadata to indicate how much was delivered. You should always use delivered_amount, not the Amount field, to avoid being tricked about how much XAG you received. (Cross-currency "Partial Payments" can deliver less XAG than stated in the Amount field.) For more information, see Partial Payments.

Comparison to Other Payment Types

  • Direct XAG Payments are the only way to both send and receive XAG in a single transaction. They are a good balance of speed, simplicity, and low cost.
  • Cross-currency payments also use the Payment transaction type, but can send any combination of XAG and non-XAG issued currencies except XAG-to-XAG. They can also be partial payments. Cross-currency payments are good for payments not denominated in XAG or for taking arbitrage opportunities in the decentralized exchange.

See Also