The Fire Truck Law For Blockchain Emergencies

By now the concept of Black Swan events (via Nassim Nicholas Taleb) is reasonably familiar. In brief, no one thought black swans existed until they were discovered in Australia. When they were discovered it rocked the swanian world, and swan-ologists everywhere had to reconfigure their understanding of swan color.

For our purposes, we’ll use “Black Swan” to refer to an unpredictable event that has large impacts. The technical definition also includes the idea that after the fact you’ll have a ton of people who will tell you that “anyone could have seen that coming”. That’s so common in crypto we’ll just set it aside for now.

If, in the course of your normal day, you browse through the basics of fractal mathematics, you’ll know that unpredictable events in the real world are inevitable. Still, knowing that something will happen some time in the future isn’t particularly helpful when you’re trying to plan for it.

What helps make a system like a DePIN project robust enough to withstand Black Swan events is building in the flexibility to adjust to the evolving ecosystem, then knowing how to adjust it when the time comes.

Let’s go through an example from history. In 1908, when the Ford Model T started rolling off the lines, there were no provisions for traffic lights, traffic signage, or emergency vehicle access. There was no need.

As time went on, more and more vehicles used the new infrastructure being built to support the technology of the automobile. With more users came both opportunity and challenge. We incrementally built in laws for traffic management we thought should be universal and everlasting, like staying inside lane lines, stopping at a stop sign, or waiting at a red light.

What the original plan didn’t include were some of the nuances you’d need to build a system that allowed for all situations. Rather than scrapping the whole system every time we found a nuance, we needed a way to keep the core of a working system AND enhance it by allowing for nuances.

As an easy example, we’ll take fire trucks (and more broadly, emergency services.)

As far back as 1487, special vehicles have been used to navigate emergency situations. Provisions such as temporary changes to traffic law (like giving way, or pulling over) weren’t codified into US law until after the landmark publishing of a paper in 1966 by the National Academy of Sciences titled Accidental Death and Disability, The Neglected Disease of Modern Society.

At the national level (and to be fair, I’m generalizing and skipping over a ton of detail), it was recognized that we needed a way for fire trucks (and ambulances and any emergency services) to get through traffic much faster than they could if they followed the normal rules.

This wasn’t something that could be programmatically changed, where whenever a fire truck came by with lights and sirens a stop sign would just flop over and hide, a traffic light would blink out. That technology didn’t exist yet. We needed a way to operate in the real world right now, a structure for people to think a little on their own but within a set of special cases rules.

We built that way by improving the system we already had, made it into law, and made sure everyone understood it.

We decided that it made sense to pull over and give way for lights ‘n sirens. No one needs to call the cops to report that a fire engine racing to a fire just ran a red light. The system needed to change, and we changed it.

What didn’t make sense was to try and build a whole separate system just for emergencies, like parallel roads. Building that would have been a huge hindrance.

What we needed was a mechanism that existed to allow for unforeseen changes.

This mechanism allowed us to build a safer society. You know that when it’s your life on the line, you’ll get prioritized over Karen on her way to Whole Foods for organic shade-grown bird friendly carrots. Her carrots can wait.

That same mechanism creates a path to more productive, more efficient, and more effective methods across society. The mechanism and ability to allow small changes without disrupting the entire systems is a competitive advantage. DePIN project is literally following an evolutionary blueprint. If it it doesn’t explore new territory, adapt to conditions, and improve, it doesn’t survive.

Remember, these changes won’t be optional. No one in their right mind will block a fire truck or ambulance these days. We figured that out decades ago, and no one argues with it. It wasn’t something we knew when were first building roads, but it’s something that became self-evident and inarguable.

When someone in your Discord server rightly points out some of the obvious downsides of a change the project is making, the default should be to empower them to help figure out how you can fix it, rather than throwing out the entire system and starting over.

If you’re running a DePIN project, you’ll need to be looking for those “fire truck” issues, then laying the solutions on top of your improvements to enhance what you’re doing, rather than hindering it.

The question now for a DePIN project is: How will you correctly identify and recognize these special situations when they arise, and what will allow your system to effectively respond?