The Hard Questions

I did not make a blockchain because I love blockchains. I made it because of what is happening to everything else. Every year, more of your online life passes through a man in the middle. Someone else's server delivers your mail, hosts your site, stores your files, routes your messages, decides what you see, and can change the rules, read the traffic, or shut the door whenever it suits them. We did not vote for this, it just accreted, service by convenient service, until control over our own choices, information and actions quietly moved to a handful of companies. The point of ZooBC is to take the middlemen out, one function at a time: mail, web serving, storage, networking, anything that today requires trusting an intermediary gets rebuilt as something no single party controls. A blockchain is simply the only tool we have for coordinating strangers without appointing a new middleman to do it.

The reason this sounds tired today is that blockchain got hijacked by its first application. People hear the word and think coins, charts, pump and dump, because for a decade the loudest projects were tokens looking for a story. That is also why so many failed: they were investments pretending to be infrastructure, and they died as investments. Strip the branding off that graveyard and you find hundreds of tickers but only a handful of actual designs, most of them forks of the same few codebases inheriting decisions made in 2014. The failure of a thousand copies tells you nothing about the parts of the design space nobody tried. ZooBC is not one of the copies. It is written from scratch in C++, with a different consensus, Proof of Participation, that shares block rewards and fees across many contributing nodes instead of winner takes all, no slashing anywhere in the protocol, and a node admission queue that makes taking over the network a slow, visible attack instead of a fast, quiet one. Those decisions live at the bottom of the stack, where no fork can reach them. And it is a platform for real decentralised applications, actual programs running across the network, not smart contracts in a virtual machine. The apps and games already in the testnet wallet are small, but they are there to make exactly this point: this is a computer, not a coin.

If you want to see where centralisation is heading, look at AI. The models everyone now relies on, for answers, decisions, sometimes the direction of their lives, run in the hands of a few companies, and that dependence deepens daily. So one of the first big goals on the ZooBC roadmap is decentralised AI: a peer to peer network where every node runs a small model, and the nodes cooperate like synapses, a mixture of experts spread across machines nobody owns together, producing answers no single party curates. Ambitious? Yes. Will all of it work? I do not know, and I distrust anyone in this industry who claims they do. That is what the testnet is for. But the direction does not depend on any single feature landing: as long as online life keeps centralising, building the alternative keeps being the point. That is why this project continues no matter what the market thinks of blockchains this year.

Two reasons, one human and one technical.

The human one: the promise was never really tried, because nearly everyone who walked in through the blockchain door fell into crypto and stopped there. Trading was supposed to be the doorway and it became the destination. A decade of talent, money and attention went into moving tokens around, and that hid everything else the technology could do. Ironically, the spotlight moving to AI is what makes this the right moment: for the first time in ten years, a decentralised platform can be judged on what it does rather than on what its chart looks like.

The technical one: blockchain was never designed to be a platform. It was invented so that Bitcoin could exist, electronic money that cannot be stopped by going to somebody's house and switching off a server. For that scope, correctly, it anchored all of its security to the value of its own currency. Almost everything built since inherited that coupling. Try to use an existing chain, Ethereum included, to let the hospitals of a country share medical records, or to run loyalty points for a hotel group. Every node and every account has to be provisioned with coins to stake, or has to burn electricity, or has to dedicate storage, resources that have nothing to do with the job you are trying to do. Nobody had built a public blockchain whose security is decoupled from the value of its coin, a chain that is secure, safe and functioning simply because its participants keep it so. That is what ZooBC is, and it is the difference between a platform and a token with an API.

No, and the difference is the whole point. Proof of Stake gives priority to whoever holds the most funds: the rich decide, the network follows. Proof of Participation keeps a registry of nodes that are present, ready and doing their work, and being in that working group is the authority. A node that misbehaves loses participation score and gets pushed out of the circle, and new nodes can always come in. What orders the queue to enter the registry is just a measurement, and on a public chain we use the chain's own coin because that is the measure people recognise. But the mechanic does not depend on it: if this were the blockchain of a country, with every city or region running nodes to serve its citizens, the number of residents could be the measure that orders admission instead. Try doing that with Proof of Stake.

There is also a matter of timing, and this is not a blame: the pioneers did not build the perfect thing because nobody ever does on the first try. The first car engine ever built cannot compare with the engines built today, because experience takes time to accumulate. Proof of Stake was an early engine. Proof of Participation was designed years later, after watching a decade of chains run, stall and get attacked, and it is built from everything that decade taught us.

You have the problem backwards, because the blind trust is on the other side. Every time someone uses an ERC-20 token on Ethereum, USDT, USDC, any of them, they are trusting a smart contract that somebody deployed, which may contain functions they have no idea about, including functions that can empty their account. In theory you audit every contract before touching it. In practice, real life touches many applications in a single day: a doctor issues you a health certificate, the gym accepts the certificate to let you train, the invoice from the gym goes on to your accountant. On an EVM chain, every step of that runs through a different contract you are forced to trust blindly. Auditing your way through daily life is impossible.

ZooBC reverses this. A huge amount of functionality is embedded directly in the node code itself. When someone creates a new token on ZooBC, they are not deploying their own contract for others to audit; they are using the same embedded, chain level code as every other token. Everyone trading with any token has a hard guarantee that there are no secret backdoors in how that token works, because there is no per token code in which to hide one.

For custom applications, by mainnet there are two ways to deploy. One is WebAssembly: nodes run a small WebAssembly engine, users deploy code that others can interact with, and even the user interface of the application can be deployed on ZooBC itself. The other is for organisations that have secrecy requirements around their processes: attach a physical machine to a subset of nodes, do the processing and the database work privately, encrypt what goes in and what comes out, and let the consensus verify only that the majority of the nodes produced the same encrypted answer. A bank with a hundred branches gets an internal blockchain validated by consensus, in which the validators can see nothing.

Nobody knows yet how far a subset of ZooBC nodes can go in processing AI models, me included, and I will not pretend otherwise. But convenience is not the only axis, and it never has been. Ask one of today's big centralised models for help with something perfectly legitimate and you can hit a wall of limits that no user ever chose, decided somewhere you have no access to. There is real demand for answers that are democratic, produced by a network that no single party curates, even if they arrive slower. Add that people will build small models highly specialised in one thing, and a specialist is often faster than a giant generalist at its own game. Will the first version beat a data center on speed and polish? Certainly not. Neither did the first version of anything that mattered. If we do not start somewhere, we never arrive at the destination, and a peer to peer network where every node runs a small model and the nodes cooperate like synapses in one brain is a destination worth starting toward.

Because the project does not depend on the coin, and the coin is not the product. If a coffee consortium came to me tomorrow wanting to track their supply chain on ZooBC, from the farmer to the client drinking the cup, I would not ask them for coins: the whole project can be implemented on the public chain without needing any. And if somebody financed the entire development tomorrow, without a single coin being purchased, not one line of the implementation would change. The genesis sale exists because building this takes funding, and, honestly, because people engage with what they feel they have a stake in.

The difference is what the coin is for afterwards. In Bitcoin the coin is the end use: there is nothing to do on the chain except move it around. In the projects I criticise, the coin was the exit. In ZooBC the coin is a utility, the thing you use to access the services that hundreds, eventually thousands, of applications will run on the chain. It is fuel, not the destination.

You do not have to believe anything, and that is precisely the answer. The testnet is live now. You can use the wallet, run a node, play with the applications, look at the code of everything around the core node, and, like Saint Thomas, put your fingers in it. This is not a whitepaper with a countdown; it is a working system in public. What remains between here and mainnet is perfecting, not inventing: the community hammers it, we fix what falls over, and when it holds, mainnet is largely a change of name. What is testnet becomes mainnet, minus the things a main chain must not allow, like coins with no value flowing out of a faucet. That is why the date is a plan and not a prayer.

Two reasons, one about understanding and one about position.

Running a node is the deepest way to understand what this technology actually is. You stop repeating other people's explanations and start giving your own, because you have operated the thing with your hands. That understanding is a gateway into the community, and the people who hold it are the ones others will learn from later.

The position: nodes that register and run on the testnet in the months before mainnet earn the right to be in the mainnet registry from the genesis block. And in ZooBC the coinbase of every block is not paid to a single lucky miner like in Bitcoin: it is shared among the participating nodes, weighted by contribution, and so are the transaction fees. Everyone helping run the chain collects a return from the first block onwards, to use inside the chain or to sell to another party. Being early here does not mean buying early. It means working early. The exact eligibility rules and deadlines are published on the roadmap page, which is the only place they are maintained.

If people respected licenses, ZooBC would have been open source from day zero, and I mean that literally: the philosophy of this project demands it, and the intention was always there. The problem is not philosophy, it is experience. I have watched what happens to code that opens early: it gets copied and pasted with the license stripped off, by people who face no consequences because the author has neither the position nor the resources to go after them. A young chain that publishes its core on day one is handing its own technology to whoever wants to outrun it with more money and more marketing. So the sequence is deliberate: mainnet first, so ZooBC takes its position as the chain; then the foundation builds the resources to actually defend the license against those who ignore it; then the code opens. It is a delay, not a secret, and the timing is on the roadmap.

And "trust me" is not what you are asked in the meantime. The testnet is public, you can run a node, and everything around the core node is already there to read. An independent audit of the core is part of the path to mainnet. If your personal rule is to run only software you can read down to the last line, that is a rule I respect: wait. The chain will still be here when the code is open, and I would rather have a patient user than a blind one. The difference between me and the middlemen this project exists to remove is simple: for them, the closed position is the business model, permanent by design. Mine is a protection with an expiry date, announced in advance.

The project continues without me, and I built it that way on purpose, because I asked myself this question before anyone else could. I am not the only holder of the source code, and by the time mainnet starts the ZooBC Foundation will count seven members, with no lock, legal or technical, preventing any of them from carrying ZooBC forward if something happens to any other member, me included. On top of that there is a dead man's switch, literally: if I stop confirming, week after week, that I am here and able, everything needed to continue, the code, the access, the plan, is delivered automatically to the next person in line, and eventually to the whole foundation.

Let me be clear about why I take this so seriously. ZooBC is my legacy. I am doing this to leave something to humanity, something that can help it grow without being manipulated. A legacy that can die with its author is not a legacy, it is a hobby. So nobody is more motivated than me to make sure that nothing here depends on me staying alive, or on any other single person. And once the code is open source, even the foundation stops being a dependency: from that point, if all of us vanished, the network and its code would be in the hands of everyone running it. A bus can take out a person. The whole point of this architecture is that it cannot take out the chain.

The bigger part of the cost, from 2019 until today, I covered personally. I do not publish the figure, but it is in the millions: the kind of amount that changes somebody's life, and I chose to spend it on this. So there is no fund behind the curtain, no early backer with a board seat, no hidden allocation waiting to be dumped on you. The rest is the genesis sale, and it is entirely in the open: the tokenomics page shows exactly what is for sale, at what prices and vesting terms, and how the collected funds are going to be used. Those funds will be under the control of the ZooBC Foundation, kept deliberately separate from my own company, so that the network's money and my money never sit in the same pocket. And what buyers get is exactly what the page says: coins at genesis, at the published terms, the same terms available to everyone. If someone is funding this and getting something for it, you can read what, how much, and under which conditions, all in one place.

Nothing stops you from creating a thousand nodes. What stops you is that they would be a thousand spectators. In ZooBC, a node that is not in the registry does not create blocks and does not collect rewards: it only takes part in the peer to peer gossip, passing messages around like everybody else. The rewards flow to the registry, and the registry has a door with a queue. A node that wants in must wait its turn, and the wait is not fixed: the smaller the registry, the longer the queue takes. So the early days of the network, exactly when flooding it would be cheapest, are exactly when flooding it is slowest.

This is the same design choice behind the first answer on this page: taking over ZooBC is not made impossible on paper, it is made slow and visible, and a slow, visible attack is one the whole network sees coming and can answer before it lands. Your thousand nodes would not be collecting rewards; they would be standing in a public line, for a long time, telling everyone exactly what you are trying to do. The full mechanics are explained on the security page, together with a tool that lets you simulate this exact attack yourself and see for yourself how far it gets.