What Percolation Theory Has to Do With Moving Money

Last year my team entered a fintech hackathon and decided to build a router for stablecoins.

A stablecoin is a cryptocurrency designed to hold a steady value, usually pinned to one US dollar. Moving one from where you have it to where you want it is rarely a straight shot. You often cannot go directly between two exchanges, so a payment hops through a chain of other exchanges and liquidity pools along the way, trading at each step. Something has to choose that chain. Our project, which we named Liquid, was that something: hand it a starting point, a destination, and a tangled web of places money can pass through, and it picks the path the payment should take.

The trouble is that there is almost always more than one path, and they are not equally good. Some are short. Some run through exchanges that are fast and dependable. Some are cheap. Those are three separate things, and a connection that looks perfect right now can dry up a minute later. Choosing which path to trust, inside a network that keeps rearranging itself underneath you, turned out to be the entire problem.

Liquid ended up winning the hackathon, which was a good day for a team of high schoolers standing next to college students. But the part that stuck with me was a question the project kept circling back to: if every connection in a network can fail, when does the network stop being useful at all?

That question has a name. It is called percolation, and most people run into it through coffee or forest fires long before they ever run into it through money.

A route is a property of the whole network

Draw the network as dots and lines. Each dot is a place a dollar can sit: an exchange, a wallet, a liquidity pool. Each line is a transfer that could happen between two of them. Mathematicians write this as

$$G = (V, E),$$

where $V$ is the set of dots (vertices) and $E$ is the set of lines (edges). You can forget the letters almost immediately. The picture is what matters.

A line is open if that transfer is working right now, and closed if it is not. Connections close for ordinary reasons: an exchange runs low on a coin, a bridge between blockchains gets congested, a price moves too far to be worth it. A route from start to finish is nothing more than a chain of open lines you can walk end to end.

Here is what I had backwards at first. I kept thinking of a route as a fixed road, something that either exists or does not. It is not that. A route only exists because of the connections sitting around it. Cut a link in the network below and see how little happens:

Cut the wires

Click any link to open or close it. The usable route from A to F lights up on its own.

Money can still get through: A → B → D → F (3 hops).

One cut usually does nothing, because another path quietly takes over. Keep cutting and at some point A and F come apart for good. Notice that no single line was ever “the” line. The route held until the network as a whole could no longer support one.

The word for falling apart

That sudden break is what percolation theory is about. It studies what a network does when its connections open and close at random, and it keeps returning to one unintuitive fact: the change from connected to broken is not smooth. You can remove failures for a long time and watch nothing happen, because there is always a backup. Then you pass some tipping point and the whole structure comes apart at once.

The textbook version is a pot of coffee. Water only finds its way through the grounds if enough little gaps happen to line up. Too few open gaps and it just pools on top. The same math describes a wildfire jumping between trees, a rumor spreading through a school, or a payment crossing a network of exchanges. Different story, identical skeleton.

Before we can talk about tipping points, we need a way to say how likely each connection is to work. So far a link has been either open or closed. Real ones live somewhere in between.

Every link is a maybe

Give each connection a number between 0 and 1 for how often it works. A link with $p = 0.98$ goes through about 98 times out of 100. Written formally,

$$P(\text{link is open}) = p.$$

For now I will assume links fail independently, meaning one failing tells you nothing about whether another fails. That assumption is convenient and often wrong, and I will come back to exactly how wrong at the end. As a place to build intuition, it is fine.

How reliable is one route?

A route works only if every link along it works. When the failures are independent, the chance of that is just the product of the individual chances:

$$P(\text{route works}) = p_1 \times p_2 \times \cdots \times p_k.$$

Three healthy-looking links, say 0.98, 0.95, and 0.99, already land below any one of them on its own:

$$0.98 \times 0.95 \times 0.99 \approx 0.922.$$

Multiplying numbers below 1 always shrinks the result. That is the quiet cost of a longer route: every extra hop is one more thing that has to go right. Drag the links below, then add a hop and watch the total drop even when the new link looks perfectly healthy.

Multiply the maybes

Each hop has a chance of working. The whole route works only if every hop does.

hop 1

0.98

hop 2

0.95

hop 3

0.99

Add a hopRemove a hop

route succeeds0.92

Watch what happens when you add a healthy-looking 0.97 hop: the total still drops. Every extra link is another thing that can fail.

This is close to the first thing I got wrong during the hackathon. My instinct was to route along the fewest hops, as if the number of steps were the only thing that could hurt me. But a two-hop path through shaky exchanges can easily lose to a three-hop path through solid ones.

The shortest route is not the safest

Take that seriously for a moment. Here are two ways from A to F. One is shorter. Before you read the numbers off the links, commit to the route you would actually trust:

Pick a route, then check

Both start at A and end at F. Every number is that link’s chance of working.

Short routeLong route

The longer route wins because the short one stakes everything on a single 0.80 link, while the long one spreads the same trip across three strong ones. Fewest hops is a fine rule of thumb and a bad rule of law.

Turning reliability into a distance

Here is a small trick that made the routing problem click for me. The tools that already exist for finding good routes, the same family of thing that powers driving directions, are built to do exactly one job: add up the lengths along a path and keep whichever path has the smallest total. They are addition machines. Hand them a product of probabilities and they have no idea what to do.

So we give them something they can add. A logarithm has the one property we need. It quietly turns multiplication into addition:

$$\log(p_1 \times p_2 \times \cdots) = \log p_1 + \log p_2 + \cdots$$

Probabilities are less than 1, so their logarithms come out negative. Flip the sign and treat each link’s

$$c_i = -\log(p_i)$$

as its “length.” A dependable link, with probability near 1, gets a length near 0. A flaky link is long. A route’s total length is just these lengths added up, and here is the payoff: the shortest route by this length is the same thing as the most reliable route.

We did not have to invent anything to use this. We turned “multiply the probabilities and take the biggest” into “add up the lengths and take the smallest,” then handed the problem to an ordinary shortest-path finder that has been around for decades. Reusing a tool that already works is most of the trick.

When does the whole network stop working?

Back to the tipping point. For one fixed route we can just multiply. For a whole network, with many possible routes weaving through it, the exact math gets ugly quickly. So instead of solving it, we cheat honestly: we try it thousands of times.

Set every link to open with probability $p$, roll the dice separately for each one, and check whether the start can still reach the destination. Repeat that many times, and the fraction of runs that stayed connected estimates the true probability:

$$\widehat{P}(\text{connected}) = \frac{\text{trials that stayed connected}}{\text{total trials}}.$$

This is a Monte Carlo estimate, named after the casino, because it leans on randomness instead of a formula. The whole thing is short in code, and the only real ingredient is a breadth-first search that walks outward from the start to see what it can reach:

import random

def has_path(start, end, open_edges):
    # walk outward from `start` across the links that happen to be open
    seen = {start}
    queue = [start]
    while queue:
        node = queue.pop(0)
        if node == end:
            return True
        for a, b in open_edges:
            nxt = b if a == node else a if b == node else None
            if nxt and nxt not in seen:
                seen.add(nxt)
                queue.append(nxt)
    return False

def estimate(edges, start, end, p, trials=2000):
    successes = 0
    for _ in range(trials):
        open_edges = [edge for edge in edges if random.random() < p]
        if has_path(start, end, open_edges):
            successes += 1
    return successes / trials

Slide $p$ below. Each position reruns hundreds of random networks and plots how often A still reaches F:

When the whole network tips over

Every link is open with probability p. For each p, this runs 400 random networks and counts how often A still reaches F.

p = 0.60

0.60

Notice there is no clean cliff. On a small network the change is gradual, and a lucky layout can stay connected below the crowd while an unlucky one falls apart above it. The bigger the network, the sharper this bend becomes.

Two things are worth sitting with. First, there is no clean cliff. On a small network the curve bends instead of jumping, and where it bends depends on the shape and size of the network, not on some single magic number that holds everywhere. The famously sharp thresholds in percolation theory belong to enormous networks; a nine-node grid only gives you a hint of the same shape. Second, even at a middling $p$, whether you get through is luck. The curve is an average over many parallel versions of the network, and you only ever live in one of them.

“Best” depends on what you are counting

By now the routing problem has three answers, and all of them are correct. The fewest-hop route, the cheapest route, and the most reliable route can be three different paths through the very same network. Flip between them:

Which route is “best”?

Same network, three different goals. Each link shows its fee and its reliability.

Fewest hopsLowest feeMost reliable

route

A → M → F

hops

2

total fee

$6

reliability

0.85

On the hackathon project this was the actual design decision, not a footnote to it. Choosing a route means first deciding what you are optimizing, and only then drawing the line. Optimize for fees and you might route through a link that fails half the time. Optimize for reliability and you might overpay for a trip that a cheaper path could have handled. There is no route that is simply “best.” There is only the route that is best for the thing you chose to measure.

What the toy model leaves out

I want to be careful here, because a clean model is easy to oversell. Everything above assumes links fail independently and that a link is either fully on or fully off. Real payment networks break that in ways that matter:

• Failures are often correlated. Several connections might depend on the same provider, the same blockchain, or the same pool of liquidity. When that shared thing goes down, they all go down together, which the independent model does not see at all.
• A link is more than a coin flip. Real transfers carry fees, limited liquidity, exchange-rate slippage, and confirmation times that shift by the second.
• Some risks are not random. Counterparty risk, smart-contract bugs, and regulation do not behave like dice, and no amount of resampling will make them.

Percolation gives you one specific lens: is the network even connected, and how fragile is that connection? That is a genuinely useful thing to know. It is also not the whole story, and pretending it were would be its own kind of mistake.

What we actually decided

So what did Liquid end up doing? We stopped ranking routes by distance or fees alone and made a route’s chance of actually going through part of the score itself, sitting right next to speed and cost. The reliability-as-length trick from a moment ago is one clean way to fold that in. In plain terms, we taught the router that a slightly longer or slightly pricier route is often the right call when it is far more likely to succeed. A shortest line that vanishes the instant one exchange stalls is not really a route. It is a guess that has not failed yet.

The broader lesson is smaller and more honest than “every payment system reduces to one percolation number.” It is that a route only exists because the network around it is holding together. Optimize a single path without looking at how the whole thing fails, and you can hand yourself something that looks perfect on paper and disappears the moment one link closes.

Building Liquid made me realize I had been thinking about routing wrong. Finding the shortest path between two points is the easy part. The real problem is figuring out which parts of a network you can trust when its links keep changing, and whether enough of it will stay up for the route to work at all.