Futarchy, Private Markets, and the Long Arc of Governance

A Quiet Moment After the Fork

The holiday break creates a rare kind of space. Space away from delivery timelines, governance calls, and the constant pull of near-term decisions. It is often in that pause that older questions resurface, the ones that never fully go away, but are easy to defer when momentum is high.

For me, that meant thinking again about Web3, decentralization, and governance. Not as slogans or abstractions; web3 as systems that real organizations eventually have to operate within.

Those thoughts naturally returned to Ethereum Classic. After the fork, once the network stabilized and attention shifted from execution to continuity, one of the first questions to emerge was not technical at all. It was structural.

How do we decide how to decide?

This question has appeared repeatedly throughout the history of decentralized systems. It surfaced early in Ethereum’s research phase as well, where governance and coordination were debated openly long before formal mechanisms existed. One such discussion I think about, preserved in Ethereum’s public research history, explored incentive-aligned decision-making in decentralized environments and remains a useful reference point today.

At the time, one approach stood out to me because of how uncompromising it was. It offered no procedural ambiguity and no rhetorical escape hatches. Decisions were explicit. Outcomes were enforced. Being right mattered, and being wrong had consequences.

It had a certain clarity to it. Almost a “victory or death” mindset.

That approach was futarchy.

Futarchy as an Idea That Refused to Go Away

Futarchy was originally proposed by economist Robin Hanson as a governance model built around outcomes rather than opinions. His framing was simple and unsettling: communities should agree on what they value, and allow markets to determine which actions are most likely to achieve those values. Hanson’s essay “Shall We Vote on Values, But Bet on Beliefs?” remains one of the clearest articulations of the idea.

The concept later found an audience in the blockchain world, where governance was already an open problem. In Ethereum’s early days, futarchy was discussed as a serious alternative to informal social consensus and simple token voting. Vitalik Buterin explored this explicitly in early Ethereum governance writings, describing futarchy as one of the more rigorous models available at the time.

Even so, futarchy felt premature. Prediction markets were thin. Privacy was difficult. Enforcement mechanisms were brittle. It was easier to admire the idea than to imagine deploying it inside real organizations.

That gap between theory and practice is what makes the present moment different.

Why This Moment Feels Different

What has changed is not the idea of futarchy. It is the mechanics that make it understandable and usable.

At its core, a prediction market is simply a structured way to answer a binary question using capital instead of opinions. The easiest way to understand this is through a familiar analogy.

Consider a championship game between two teams. A market opens with two outcomes: Team A wins or Team B wins. Participants place stablecoin bets on either outcome. As more money flows toward one side, the implied odds shift. The price of each side reflects the crowd’s collective belief about what is most likely to happen.

No one is asked who they want to win. The only signal that matters is where people are willing to put money.

This is powerful because it forces honesty. Participants with better insight or information are incentivized to act. Those without conviction either stay out or lose capital. Over time, the market price becomes a real-time forecast that often outperforms polls, committees, or expert judgment. Decades of research and real-world experimentation support this, including corporate forecasting use cases summarized here: https://www.chicagobooth.edu/review/prediction-markets-explained

Futarchy applies this same mechanism to decisions.

Instead of betting on a sports outcome, participants are asked to bet on whether a decision will lead to better results than an alternative, based on a metric everyone agrees matters. The “teams” are the choices. The “score” is the outcome.

What makes this moment different is that the infrastructure to run these markets cleanly now exists. Stablecoins provide a neutral unit of account. Smart contracts enforce rules and payouts automatically. Private blockchain environments allow participation to be restricted while keeping outcomes auditable.

Privacy has evolved as well. Markets inspired by Dark Forest–style designs show how participants can contribute signals without revealing identity or intent, while still allowing the market itself to remain trustworthy and verifiable.

Together, these advances remove the practical friction that once kept prediction markets and futarchy theoretical.

What follows is a thought experiment, not a product announcement.

ClearPath, as described here, is a fictional future private-market platform used to illustrate how futarchy could work in corporate governance. It does not exist today.

The ideas are real—and increasingly plausible.

A Fictional Example Using ClearPath

Consider a private manufacturing company evaluating whether to open a new factory. The decision involves meaningful risk. It requires a large capital investment and commits the company to long-term operational exposure under uncertain demand.

The process begins by agreeing on what success means. Stakeholders align on a clear, measurable outcome, such as EBITDA growth over the next twenty-four months. That metric is fixed before any decision is evaluated.

ClearPath then opens a single decision market with two possible outcomes: build the factory or do not build the factory.

Participants are invited into a defined decision window, for example thirty to sixty days. During that period, they place stablecoin-backed positions on the outcome they believe will result in better performance on the agreed metric. They are not voting and they are not expressing preferences. They are committing capital based on belief.

As capital accumulates on each side, the market price moves. By the end of the decision window, the price reflects the collective forecast. If the market consistently values the “build” outcome higher than the alternative, the decision is executed. If it does not, the proposal fails.

This is useful because it produces a clear signal without debate. It allows insight from across the organization and investor base to surface without politics. It rewards accuracy over authority. And it creates an auditable record showing not just what decision was made, but how confident the organization was in that decision at the time.

Once the decision is implemented, the market remains open until the evaluation horizon is reached. When the metric is observed, participants who were correct are rewarded, and those who were wrong absorb the cost. Over time, this creates a feedback loop that favors reliable judgment.

This is the core futarchy rule as originally articulated by Robin Hanson: actions should be taken when markets predict they will improve the agreed outcome.

Why This Is Useful for Governance

For private companies, this approach offers something traditional governance struggles to provide.

It separates decision-making from persuasion. It reduces the influence of hierarchy without removing accountability. It creates a mechanism where being right matters more than being convincing.

ClearPath is fictional. But the model it represents is increasingly realistic.

Sometimes the hardest governance question is not what decision to make, but how to make it in a way that is fair, informed, and durable.

Prediction markets offer one answer. Futarchy gives them purpose.

And for organizations willing to think beyond familiar structures, that answer may finally be actionable.

Happy Holidays

Cody & the Burns family

Logbook Entry #001 — The Rise of Fukuii

(Local Time: 23,271,745 ETC)

The network hums with an eerie calm tonight. My core-geth node is finally stable — the mess flag lit, peers holding steady in the ash-colored silence. Out here, stability is its own kind of magic. I’ve seen networks torn apart by ego and entropy, but tonight Mordor breathes slow and even. The lava rivers of hash flow steady beneath my feet.

I began my training in wastelands like this — barren networks, orphaned forks, half-forgotten clients left to rust in the repositories of time. Mordor is only the latest, another in the long chain of frontiers. There will be others after it, I’m sure. But this one feels different. It feels… haunted.

Core-geth still stands tall, but its armor shows cracks. Each update from upstream lands like a meteor — patches meant for other worlds, adapted by necessity rather than purpose. It’s a fine engine, but built for another road. The longer we drive it, the more I feel the ghosts of its Ethereum ancestry whisper through the code.

There was a time when another giant roamed this land — the Mantis client, forged in Scala, breathing the strange dialect of functional code. Its last roar was Magneto, and since then, silence. Two forks behind now, left behind when the world moved on. Most forgot it ever existed. But the Web3 Pioneer remembers.

“I’ve found its bones in an abandoned repository…”

Link to the Mantis Scala Client

I’ve found its bones in an abandoned repository, dusty and brittle but full of promise. It reminded me of an old kaiju — asleep beneath the volcanic crust, waiting to rise again. So I have decided to wake it.

I’ve moved the code to ChipprBots, where the forges still glow, and I’ve given it a new name: Fukuii — after Chordodes fukuii, the parasite that infects mantises and bends them to its will. Fitting, I thought, for a project reborn from the husk of another.

Already the AI swarm stirs. The agents are at work in the dark, rebranding, refactoring, pulling the monster back together piece by piece. Their glowing cursors flicker like fireflies in a mine shaft — each one a spark of progress, each one a prayer to the chain gods that this time the creature will stand.

When Fukuii rises, it will be more than a client — it will be a sentinel.
A sovereign execution engine for Ethereum Classic, built not in imitation but in defiance.

My plan is simple:
First, bring Fukuii to life on Mordor.
Then, test the treasury functions Charles once began.
And finally, prove the worth of EIP-1559-style treasuries in a network built on proof of work and proof of will.

The lava is stirring again. I can feel it under the floor of my node.
Something old and powerful is waking.

To be continued…

— Forger of Fukuii

🜂 Technical Artifacts
Chippr Core-Geth Node on Mordor
Mantis Client Legacy Docs
Ethereum Classic Safe Core Contracts Overview
Mordor Blockscout Explorer

Ai stylized fron notes on blockchains

Logbook Entry #000 — Genesis


“Ethereum Classic has always been that stubborn flame in the storm…”— from Why Ethereum Classic Endures

(Local Time: 23,271,745 ETC)

The first thing you notice when you cross into Mordor is the silence.
Not the absence of sound, but the kind that hums beneath the code, the quiet ticking of consensus, the distant rumble of proof-of-work engines grinding away in forgotten nodes. The testnet horizon glows with the faint orange of unconfirmed transactions, each one a spark that never quite becomes a flame.

I came here to remember what it means to build — not for profit, not for applause, but for the principle that computation can be free. Ethereum Classic has always been that stubborn flame in the storm, the last bastion of immutability in a world that prefers revisionism dressed as progress. But even the eternal must evolve, and to evolve we must explore. So I packed my digital saddlebag: a miner’s pick, a few scripts, a wallet with no name, and the conviction that decentralization still matters.

The landscape of Mordor is unforgiving. Forked chains rise like jagged peaks, each promising truth but offering chaos. I pass the ruins of old deployments — contracts lost to time and malformed bytecode, their addresses now nothing more than ghosts in the mempool. Somewhere in the distance, a lonely Safe core contract stands like a watchtower, its bytecode casting a shadow across the uncharted frontier. It will become my anchor, the foundation for the first stronghold: a treasury forged in code and guarded by keys — two of four signatures to open the vault, a fragile covenant of trust.

Mining will fund the mission. There is poetry in that — value emerging from the work itself, not minted by decree but earned by hash. From dust to hash, from effort to coin. The plan is simple: mine the ore, smelt it in the furnace of proof, and pour it into a multisig treasury. From there, we will build a faucet — the wellspring for every traveler who follows, a small mercy in this volcanic wilderness. But the process must remain honest, verifiable, and human. I will place a sentinel in the loop — a GitHub Action that awaits a human’s hand, ensuring that automation does not become abdication.

This record is for the futurists who may walk this path after me.
You will find the ground uneven. Mordor’s RPCs shift like dunes in a storm. Some nodes whisper in deprecated dialects; others pretend to listen but never respond. You will learn patience. You will learn failure. You will learn that decentralization is not a feature — it is a discipline. There will be no comfort here, only the satisfaction of seeing something real persist in a world that forgets.

In time, the Troll Army will rise — not of flesh, but of code. Each troll a daemon, each daemon a keeper of some truth buried in the chain. We will laugh at the absurdity of it all — the notion that meaning can be mined, that purpose can be signed with a key — but we will keep building. Because we must.

So here it begins.


The dust has settled, the hash hums beneath my boots.
The ledger waits to remember me.

Reference Links
Ethereum Classic Community Blog
Mordor Testnet Blockscout Explorer
Core-Geth Client Repository


(End of Entry )


Ai stylized notes from Cody on blockchain research

🔍 Exploring the Depth of Zero Knowledge Applications

2023 has been an exceptional year for the realm of Zero Knowledge applications. If you’re unfamiliar with the term, at its heart, Zero Knowledge is about proving you possess specific knowledge without revealing the content of that knowledge.

Imagine the profound implications such a concept can have for businesses:

🔹 Identity Verification: Safeguarding user identity while validating their authenticity.

🔹 Private Finance: Facilitating confidential transactions without revealing financial details.

🔹 Private Computing: Processing data without exposing its content.

🔹 Gaming: Ensuring fair play without revealing game secrets.

While the roots of Zero Knowledge sprouted in the blockchain ecosystem, the technology has now evolved, expanded, and stands as a robust pillar on its own. Its applications are broadening the horizons of privacy, security, and trust in our digital age.

This article is a great introduction to the space for anyone looking to start at the beginning:

The State of Zero-Knowledge Applications in Ethereum Part 1: Introduction

🔍Redefining Reach: The Next Revolution in Social Media

Title image shouling surrealist decentralized social media network with a gold and green color pallette

In a digital age where control, data sovereignty, and genuine connection are increasingly sought after, the future of social media is taking a pivotal shift. Gone are the days where monolithic platforms held the reigns. Enter the decentralized era – where power, control, and innovation are democratized.

🌐 What’s on the Horizon?

  • Dive deep into the mechanics of decentralized social media.
  • Unpack the building blocks of the fediverse.
  • Understand ‘activitypub, super connectors, and distributed file systems in the context of tomorrow’s publishing.
  • And most importantly, explore what all this means for business strategy in an interconnected, decentralized world.

🚀 Why Should Executives Care?
Innovation and adaptability have always been at the heart of business success. Decentralized social media is not just a tech trend; it’s a seismic shift in how we connect, communicate, and conduct business.

📅 Coming Soon
Stay tuned for our comprehensive series, “Redefining Reach: An Executive’s Roadmap to the Decentralized Social Media Revolution.” Let’s embark on this journey together and redefine the future of online connection.


Continuity for an Augmented world

Let’s preface this article with a bit of hand waving. Please assume that we live in a world 5 minutes into the future where we have figured out AR implants or non-ridiculous glasses. However, for now your mobile exo-brain(phone) will work.

I will begin by saying I have felt robbed for some time now. Something is missing. I was promised the future would be a late-stage capitalism state where I would be inundated with interactive 3d advertisements in a gloomy Phillip K. Dick urban sprawl. Granted we are close. I build and trade imaginary internet coins, work for a multinational tech conglomerate, carry a super computer in my pocket, and have a handful of nonhumans living in my house. But I know we can do better. Also <*handwaving intensifies*> in a more decentralized way! Free market persistent advertisements should be everywhere now. Since no one seems interested in making this a reality, I guess I will have to step my game up. Be the change.

On of the most common pitfalls of modern AR is the lack of continuity with actual reality and even itself. I believe this disconnect can be remedied with modern public blockchains. In order for the system to be robust enough for wide spread usage, it will need distributed file storage for rapid access of the advertisements, a public market for advertising space, and a simple recognizable target for the advertisement(to project on, obviously YOU are the real target). And it also goes without saying this will all need to be open source. With these requirements in mind: lets do this!

Burns Capital: Research and Development

For this proof of concept we will be using a the Burns Capital . The success criteria will be if you, the reader, are able to see this logo on demand anywhere in the world. I am using a simple image for demo, however it is just as easy to make 3d objects and any other aframe.io objects using the same method. That will hopefully be covered in another article. Also, This is living code so it will be updated likely by the time you are reading this. The repo link is at the bottom, its open source, help yourself to the latest code base.

If your impatient; on your mobile, go here https://tinyurl.com/y8o5f4ml

and point your phone at this:

Ethereum Classic ad on the network

System overview

System overview

Before we get too deep into the coding aspect of the system lets briefly look at the network design. 1) A user is served a lightweight web application from ipfs, 2)the webpage uses a public api to access a 3) contract on the ETC network to get information about targets and 4) the advertisements are then retrieved from ipfs and 5) displayed at the target. I refer to this as zero weight architecture.

Dive deep!

File storage:

This one is the easiest of the four requirements. If you are unfamiliar with the interplanetary file system (IPFS), stop everything you are working on, learn about it, and start using it now. When a file is added to the ipfs, it is given a unique identifier. This identifier is used to distribute the file to other ipfs nodes and recall it as needed. Super useful in our case.

$ ./ipfs.exe add ~/Pictures/bclogo.png
added QmRYrsq4uHk3AuVapdyoPtbF4zuzw7dbkc4r8HBKssB3De bclogo.png

The BC logo is now available EVERYWHERE!!!!!! Not super impressive, the internet has existed for some time now but we can now access our unique image using an ipfs API point on our machine or any other machine attached to the ipfs system using its id. The file is also publicly available at the ipfs api point is located at: https://ipfs.io/ipfs/QmRYrsq4uHk3AuVapdyoPtbF4zuzw7dbkc4r8HBKssB3De

Distributed access

Constantly passing around QmRYrsq…. is painful and scales poorly. Being a blockchain architect by trade, this is obviously the job for my baby: Ethereum Classic! We will need a contract which we are able to write to once, and read many times. It would also be nice if no one could over write my logo with out my permission. Other nice to have features include: public rating system like movies and games have, the ability to resell my ad space, and a one to one mapping. To do this we will create a structure and an enum.

enum ratings{G,PG,PG13,R,NC17}
struct arTarget {
string logo;
bool owned;

address owner;

bool forSale;

uint price;

ratings rating;

}

For simplicity in this demo, we will only be using uint8. This gives us 255 unique seats to map advertisements to which should be plenty to demonstrate the concept.

mapping (uint8 => arTarget) public targets;

A bit on targets

We will be using a 3×3 matrix format without error detection or correction, allowing up to 64 different markers to be identified. They 3×3 targets can be downloaded from this link for your convenience. Yes we are only using 64 of the 255 available seats. In a real future world production environment we can easily scale this up to many many more seats and use a slightly larger grid. The idea is to avoid overly complex structures like qr codes and keep it human readable and if need be drawable.

Reading data from a target

We will need a simple getter to allow users to access the stored information. The two most important pieces of information we will need are the image identifier and the content rating. Some sort of nanny monitoring software should be able to read the content rating and block sensitive viewers from seeing age inappropriate items if desired(out of scope).

function getLogo(uint8 _scan) public view returns(string ipfs, ratings rating){
ipfs = targets[_scan].logo;
rating = targets[_scan].rating;
return (ipfs, rating);}

Buying(and selling) a Seat

This is where things get a little tricky. We need a way for owners to update their seats, new users to buy seats, and both to buy and sell.

function updateLogo(uint8 _arID, string _ipfs) payable public returns(bool success){}

We will take an ID and a string with the unique identifier. This function is payable so we can allow users to buy seats. If everything goes well, we will return a successful result.

The easiest case, a seat is not owned and someone wants to occupy it; we let them. That would look like this:

if(!targets[_arID].owned){ 
targets[_arID].logo = _ipfs;
targets[_arID].owned = true;
success = true;}

To save space we will combine the actions that an owner can do and what a stranger can do to an unowned asset. Just pass everything you need to claim a seat

if(targets[_arID].owned && msg.sender == targets[_arID].owner || !targets[_arID].owned){
targets[_arID].logo = _ipfs;
targets[_arID].forSale = _forSale;
targets[_arID].price = _price;
success = true;}
}

If a seat is for sale and a stranger sends enough ether to buy the seat, we will pay the owner and change the seat info.

if(targets[_arID].owned && msg.sender != targets[_arID].owner && targets[_arID].forSale && msg.value >= targets[_arID].price){
targets[_arID].owner.transfer(msg.value);
targets[_arID].owner = msg.sender;
targets[_arID].logo = _ipfs;
targets[_arID].forSale = _forSale;
targets[_arID].price = _price;
success = true;
}

Simple enough for this use 😊

The Police!

As I have no desire to host a distributed crush film repository or any other hyper-objectionable content we will also add a rating review board and give them the ability to remove content. They are free to make their own system if they like, but I won’t be complicit in supporting it. So to accomplish this we will map the account address of our police union to a boolean variable(true for police, false for non police) and create a modifier we can add to some function that only the content police should be able to do. And in the spirit of transparency, we will publish an event whenever the pigs take something down. It will report the action(“removed item”), which public servant removed the content, and a comment string if we want to capture a reason.

mapping(address => bool) contentPolice;
modifier onlyContentPolice(){
require(contentPolice[msg.sender]);
_;
}
event squeal(string action, address officer, string comment);

To give our thought police something to do we will give them this function:

function clearSeat(uint8 _seat, string _comment) public onlyContentPolice returns(bool success){
targets[_seat].owned = false;
targets[_seat].logo = “”;
emit squeal(“removed”, msg.sender, _comment);
return true;
}

Now we have a short public storage database contract for our advertisements!

Compile and deploy using your favorite blockchain interface and were ready to go!

The AR part!

Welcome to the world of tomorrow! Aframe.io and AR.js will be doing all the heavy lifting for us. These opensource projects are working to bring vr/ar to the masses by building out the webVR frame work. For a quick intro on making an AR project with 10 lines of code check out: http://aframe.io/blog/ar.js

<disclaimer: I’m not a frontend developer>

We will be adding web3.js to the ar demo so we can interact with our blockchain. To do that we need to add the following to the html:

<script type=”text/javascript” src=”https://rawgit.com/ethereum/web3.js/develop/dist/web3.min.js"></script>
<script>
console.log(“ o Establishing WEB3”)
var uri = ‘http://localhost:8545';
var web3 = new Web3(new Web3.providers.HttpProvider(uri));
console.log(web3);

Of course; changing the uri to your preferred api point. For the demo page I will be using the etc commonwealth public api point. Add the contract logic :

console.log(“ o Setting up contract”)

var contractAddress = “0x9868a675D36E2554F559771539F00Ed188A33e69”;
var abiArray =[{"constant":false,"inputs":[{"name":"_seat","type":"uint8"},{"name":"_comment","type":"string"}],"name":"clearSeat","outputs":[{"name":"success","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"_arID","type":"uint8"},{"name":"_ipfs","type":"string"},{"name":"_forSale","type":"bool"},{"name":"_price","type":"uint256"},{"name":"_rating","type":"uint8"}],"name":"updateLogo","outputs":[{"name":"success","type":"bool"}],"payable":true,"stateMutability":"payable","type":"function"},{"constant":true,"inputs":[{"name":"_scan","type":"uint8"}],"name":"getLogo","outputs":[{"name":"ipfs","type":"string"},{"name":"rating","type":"uint8"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"uint8"}],"name":"targets","outputs":[{"name":"logo","type":"string"},{"name":"owned","type":"bool"},{"name":"owner","type":"address"},{"name":"forSale","type":"bool"},{"name":"price","type":"uint256"},{"name":"rating","type":"uint8"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"address"}],"name":"contentPolice","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"view","type":"function"},{"inputs":[],"payable":false,"stateMutability":"nonpayable","type":"constructor"},{"anonymous":false,"inputs":[{"indexed":false,"name":"action","type":"string"},{"indexed":false,"name":"officer","type":"address"},{"indexed":false,"name":"comment","type":"string"}],"name":"squeal","type":"event"}];
var arContract = web3.eth.contract(abiArray).at(contractAddress);

When the viewer loads we want to call the “getLogo” function to get our advertisements and assign them to their respective targets. If no one is the owner of an object, we will show a “for sale sign”

console.log(“ o Assigning assets”);
for( i = 0; i < 6; i++){
console.log(“ response from contract”+arContract.getLogo(i)[0]);
if(arContract.getLogo(i)[0] != “”){
document.getElementById(“tgt”+i).innerHTML = “<a-box src = \”https://gateway.ipfs.io/ipfs/"+ arContract.getLogo(i)[0] + “\”></a-box>”;
} else {
document.getElementById(“tgt”+i).innerHTML = “<a-box src = \”https://gateway.ipfs.io/ipfs/QmVGMspGVeNB4tyVPGToUXnGoaqg3iKgYts1DMq24pujfV\"></a-box> “;
}
}

More to come

This is a very simplistic system for demonstration purposes. Don’t let its simplicity fool you though, this is a live system on the public block chain. The contract can be found and interacted with at: 0x9868a675D36E2554F559771539F00Ed188A33e69 using the abi in the github repo.

BurnsCapital/ETC-public-Works
ETC-public-Works – public works bots for etcgithub.com

Cheers!