Hodor's profile banner
Hodor's profile picture

HodorCheck MarkOG Supporter šŸ’Ž

@Hodor

Blogger
Flat Earth
10 min read
Xahau Network

Xahau: Random Number Generation

Updated

In March 2026, a crypto speculator traded $220,764 of USDC for USDT on Uniswap, a trade that should have returned almost exactly the same amount.

They received $5,271. šŸ˜Ÿ

Within about eight seconds, an automated trading bot had extracted more than $215,000 from the transaction. The bot saw the trade, positioned itself on both sides of it, and collected the difference. This is known as a sandwich attack, one of the most common forms of what the industry calls MEV (Maximal Extractable Value).

The story caught the attention of Richard Holland, an architect of the Xahau network, who pointed to on-chain randomness as a potential solution.

Using Randomness To Prevent MEV AttacksUsing Randomness To Prevent MEV Attacks

To understand why randomness matters, we first need to understand how the attack worked.

How Did That MEV Attack Happen?

Picture a currency exchange booth at an airport. This booth is automated: it holds a supply of USDT and sets its prices with a simple rule. The less USDT it has left, the more expensive each remaining USDT becomes. Today it holds about 250,000 USDT, priced at roughly $1 each.

Now picture the line in front of the booth.

On Ethereum, that line is public. Anyone can see who is waiting and what they plan to trade. And for a fee, you can cut to any spot in line you want.

Our trader, let's call her Alice, steps into line holding 220,000 USDC. Her order contains a critical mistake: it says, in effect, "I'll accept whatever amount of USDT the booth gives me." She set no minimum (in trading terms, no slippage protection).

A bot spots Alice's order and pays to arrange three transactions in a precise order:

  1. The bot cuts in front of Alice and buys nearly all the booth's USDT, about 245,000 of it. The booth is now almost empty of USDT, so its price skyrockets.
  2. Alice reaches the window. Her 220,000 USDC can only buy the scraps: roughly 5,000 USDT. Because she agreed to accept anything, the trade goes through.
  3. The bot steps back up right behind her and sells its 245,000 USDT back to the booth, which is now stuffed with USDC, including Alice's. The bot walks away with far more USDC than it started with.

Alice was effectively robbed by this bot. All three steps happened inside a single block, in seconds.

MEV Attack During Currency ExchangeMEV Attack During Currency Exchange

Several things had to go wrong at once: a pool with thin liquidity, an order with no minimum price, and a public line where seats are for sale. But the bot's whole strategy rested on one guarantee: it could choose exactly where it stood in line.

How Randomness Solves It

Imagine the booth works differently.

Everyone drops a ticket into a box. The tickets are shuffled together in front of everyone, and then selected in a random order. The sequence of tickets simply doesn't exist until after they're shuffled.

If we look back at our example, and apply that concept, we'll process Alice's trade ... and the bot's three transactions ... in random order. In most outcomes, the plan backfires: Alice trades first at a fair price, or the bot tries to sell USDT it hasn't bought yet, or the bot buys at an inflated price and becomes the one who overpays. The sandwich turns from a sure thing into a bet that usually loses money.

The key requirement is that the shuffle be truly unpredictable and that no single party ... including the network's own validators ... can see or steer it in advance. That is a hard problem to solve on a blockchain.

The XRP Ledger & Xahau

MEV attacks are not common on the XRP Ledger or on its smart-contract-enabled sister chain, Xahau, but they are not impossible.

Both networks start with structural advantages over Ethereum:

  • No pay-to-cut-in-line. Transactions aren't ordered by who pays the highest fee. Once a ledger closes, transactions are arranged by a fixed "canonical ordering" rule, and the XRPL's AMMs inherit that ordering.
  • Less visibility. There is no large public waiting room of pending transactions for bots to scan.
  • Speed. Ledgers close every three to four seconds, leaving little time to react compared to most other chains.

"Harder" is not "impossible."

The XRPL's documentation acknowledges that its ordering makes front-running more difficult ... but without eliminating it. In late June 2026, a community member raised claims that front-running and sandwich attacks were still affecting payments, DEX trades and AMM swaps on the XRPL, arguing that they disadvantage regular users. Validators and well-connected nodes can watch pending transactions. The canonical shuffle, while hard to game, follows deterministic rules. In response, David Schwartz, Ripple's CTO emeritus, proposed a system of reserved transaction slots so protected trades would be placed ahead of transactions disclosed later.

Ordering Proposal By David SchwartzOrdering Proposal By David Schwartz

Richard Holland has described a different route for Xahau: using consensus-generated randomness to shuffle transaction order only after a ledger has closed, so nobody can know or influence the order in advance.

Xahau's RNG Amendment

The RNG amendment, as shipped in Xahau's October 2026 release, does not currently randomize transaction order.

What it does is give Xahau's smart contracts - called 'hooks' - access to random numbers that the validators produce together. With iron-clad randomness built into the protocol, a future protocol-level change to transaction ordering becomes far more achievable.

Here is how it works: Each validator generates a secret and publishes a sealed commitment to it. In the next ledger, it reveals the secret, and the network checks the reveal against the commitment. All the revealed secrets are mixed into a shared random seed for that ledger. Because each validator commits before seeing anyone else's contribution, no single validator can predict or steer the result. And if fewer than 80% of validators contribute, the network refuses to hand out random numbers at all rather than offer weak randomness.

Better Than Ethereum

On Ethereum, developers who need trustworthy randomness typically pay an outside oracle service such as Chainlink VRF, then wait for the answer to arrive in a later transaction through a "callback." It works and is widely used, but it adds cost, delay, and an extra outside service to the application.

On Xahau, the randomness is part of the network itself.

A developer calls one of two built-in functions:

  • dice(sides) returns a random whole number, like rolling a die with any number of sides.
  • util_random returns up to 512 random bytes for more complex needs.

There's no outside service and no waiting for a callback; the answer is available in the same transaction.

Safeguards

Hooks can draw random numbers but can never peek at what the next draw will be.

If a transaction fails after drawing, the randomness still moves forward, so nobody can keep retrying until they get a result they like. And every draw is recorded in the transaction's permanent record, so anyone can audit it afterwards. āœ…

Other (Fun) Applications

Defending against bad actors is only part of its purpose. Reliable, protocol-level randomness opens the door to a wide range of applications.

Lotteries and Drawings

Ekiserrepe published a hands-on tutorial showing how approachable this is, with two working examples on Xahau's test network.

The first is a dice roller: a hook that rolls a die with anywhere from 2 to 255 sides each time someone pings it, and records the result on-chain.

The second is a fully automated lottery:

  • Players buy tickets by sending a fixed amount of XAH to the lottery account.
  • The administrator schedules the drawing using Xahau's built-in Cron feature.
  • At the scheduled time, the Hook draws a winning ticket using on-chain randomness and automatically pays the entire pot to the winner.

Nobody - not even the administrator - can know or choose the winner in advance, because the random seed used for the draw didn't exist when the drawing was scheduled. Ekiserrepe also suggests extensions such as weekly recurring draws, administration fees, and multiple prize tiers.

The randomness itself takes just a few lines of code. The surrounding work, written in C, requires skill, but the hardest part - generating randomness nobody can cheat - is handled entirely by the network.

Other Potentials

  • Prize-linked savings. Everyone deposits, and the pooled rewards go to a randomly drawn depositor each week, while nobody loses their principal. This fits naturally with Xahau's existing reward features and Cron scheduling.
  • Fair NFT drops. Traits are assigned randomly at mint time, so neither the creator nor early minters can pick out the rare ones.
  • Raffles for scarce allocations. Event tickets, limited products, or token sale spots can be awarded by provable draw rather than to whoever has the fastest bot.
  • Random selection in governance. A random jury of token holders can resolve a dispute, or committee members can rotate randomly, so nobody can stack the panel in advance.
  • Random spot-checks and audits. A Hook could randomly select, say, 5% of claims or escrow releases for extra review, making it impossible to predict which ones will be checked.
  • Games. Card shuffling (512 random bytes is more than enough for a deck), loot drops, matchmaking, and tie-breakers.
  • App-level fair ordering. A Hook-based exchange or auction could collect orders over a period, then process them in random order or break ties randomly.
  • A public randomness source. Anyone can read the network's random seed after each ledger closes, so outside systems could use it as a verifiable source of randomness for audit sampling, community giveaways, and more.

The last one is the most fascinating to me - and the most open-ended; there are many occasions in existing fields and industries that could leverage audit-able, on-chain random number generation.

āš ļø The usual caveat: lotteries, raffles, and similar games of chance are regulated or restricted in many jurisdictions. Consult a lawyer if you need to know the rules for your project & jurisdiction.

Set Your Imagination Free

By Xahau baking consensus-generated randomness directly into the protocol, available to any developer through a simple function call, it has created a foundation that could one day help secure transaction ordering itself, and today enables fair drawings, games, governance, audits, and more.

Imagine Dependable Randomness On-ChainImagine Dependable Randomness On-Chain

The most interesting applications are probably the ones nobody has thought of yet. When a capability this fundamental becomes easy to use, applications will tend to surprise people.

X>

Sources

randomRNGXahauorderingrandom number generation

Loading...