This website is no longer actively supported. Please see the Ripple Developer Center for up-to-date documentation and other resources.

Transaction processing

From Ripple Wiki
Jump to: navigation, search


This provides programmers with the context necessary to submit and process ripple transactions.

Sequence numbers

Every account stores the sequence number of the next transaction to process. Every transaction has a sequence number. The ripple network applies transactions in sequence number order.

When creating transactions with the RPC sign, the server will supply the next sequence number if it is omitted. The sequence number is based on the next sequence number from the server's current proposed ledger.

Ledger closing

Ripple servers work together to determine the next ledger. As long as there is a transaction in-flight (transaction has not been included in a fully-validated ledger, but also is not guaranteed not to be), the servers are working on determining the next ledger. Normally, this only takes a few seconds. If no transactions are in-flight, the network determines the next ledger in 20 seconds.

As the servers are geographically distributed and it takes time for the servers to communicate, messages arrive at different times to the various servers. This makes it impossible for servers to know current state of the ledger. At best, they can know the state of the last closed ledger.

The consensus process works roughly like this:

  1. The current ledger is closed and is now refered to as the last closed ledger.
  2. The server begins work on a new current ledger. The server maintains a proposed ledger.
  3. Transactions are submitted to server or arrive from other servers.
  4. The server outright rejects malformed transactions.
  5. The server will attempt to apply transaction and provide a provision result to the submitter.
  6. The server will attempt to close the current ledger.
    • The server attempts to get the proposed set of transactions to be the set of transactions applied the last closed ledger to determine what the final next ledger will be.
  7. When the majority of servers it cares about are in agreement on the transaction set it computes the final ledger which is then considered closed.
    • Some transactions that were considered successful may now fail. Others that were considered failure may now succeed.
  8. When the sever has received validations from the majority of validators it cares about, it will consider the ledger closed and report it to subscribers.
    • Use the RPC subscribe to determine the final disposition of transactions.

The important take aways:

  • Submitting a transaction gives a provisional or final result.
  • Additional provisional results are possible.
  • The final result is often not known till the ledger closes.
  • The current ledger state is never known due to communications delays.
    • For example: If you are trying to take the best offer, someone might beat you to the offer resulting in a higher price. Alternatively, someone might slip in a better offer, resulting in a lower price.

See also: Transaction errors‎

Fee escalation

It is possible for the required transaction fee to increase after a transaction is submitted. If this happens, the transaction can remain valid but unconfirmed for long periods of time and may or may not be resubmitted when the fee drops back down.

To protect against having a transaction remain in limbo, a "LastLedgerSequence" can be specified in the transaction submission. This optional transaction field defines the highest fully-validated ledger number the transaction can appear in before becomming invalid.