XRPL Security Upgrade? Ripple CTO Emeritus Pitches Anti Front-Running Plan

Ripple CTO Emeritus David Schwartz highlighted concerns about the possibility of front-running or transaction sandwich attacks on XRP Ledger payments and offer crossing in a recent X post.

The X handle of XRP Ledger-based marketplace XRPresso revealed these concerns in a post, noting that a “serious front-running issue” continues on the XRP Ledger that disadvantages regular users.

Validators and well-connected nodes can view transactions in the pre-validation queue before a ledger closes and quickly analyze a pending trade to determine if front-running or sandwiching it is profitable. They then spam their own transactions to try to game their position in the canonical order for that ledger.

XRPL documentation indicates that the order of transactions is designed to be unpredictable to discourage front-running. However, research and real-world observation have shown that this protection is not sufficient. The mechanism can still be exploited, especially by those with faster or privileged visibility into pending transactions.

This has been a known topic in the community for years, with discussions around transaction queue visibility and potential privacy improvements.

Ripple CTO Emeritus proposes fix

Schwartz proposes a fairly simple scheme that might eliminate concerns about front-running or sandwich attacks: a transaction reservation scheme to ensure that a transaction executes before any transaction created after it was disclosed.

Here, a new ledger object is proposed, “ReservedTxns,” which contains a ledger sequence number and an array of transaction IDs. It is stored at an index that is formed from a hash of a fixed string and the ledger sequence number.

In addition, a new transaction is proposed, “TxnReserve,” to reserve an execution slot for a transaction that takes a ledger number and transaction ID as parameters.

This succeeds if it pays a fee of at least twice the normal transaction fee and meets all the normal transaction execution requirements. Also, the ledger sequence number specified in the transaction must be greater than the current ledger sequence number and not more than 16 ledgers greater than it.

The ReservedTxns object for the specified ledger sequence number either does not exist, or, if it exists, must contain fewer than 32 transaction IDs and not include the specified transaction ID.