MADAR One-Operator-One-Vote Substrate Chain: The Economic-Security Gap and Proposed Fixes

I spent part of an evening last month reading a Polkadot Forum thread about a small testnet called MADAR, and one line from a commenter stopped me cold: in a network with no IDs and no stake, an attacker only has to pay enough operators to win a majority of the votes, and with a small operator set that is cheap. That is the entire economic-security problem with one-operator-one-vote in a tiny proof-of-authority chain, compressed into a single sentence. The thread, posted on October 20, 2026, is worth reading not because MADAR matters at scale yet - it is a public testnet with no token on chain - but because the design questions it forces are the same ones every small Substrate chain will face before mainnet.

Key Metrics at a Glance

Why one person, one vote is harder than it sounds

The appeal is obvious: egalitarian, Sybil-resistant, democratic. The catch is that one person has to be verified somehow, and every verification method trades one trust assumption for another. As the thread notes, citing Douceur's 2002 Sybil Attack result, you cannot have one person one vote without a trusted authority or an equivalent assumption. Today that authority is MADAR's committee. Alternatives such as Encointer's simultaneous in-person meetups, BrightID's social vouching, or Idena's synchronized puzzles avoid government IDs but replace the central authority with physical-presence, social-graph, or timing assumptions, each with its own failure modes. Admission on MADAR is not only the committee, though; vouching by existing operators, a computational puzzle, and a random lottery make Sybils slower and more visible. Slower and more visible is not the same as expensive, and that distinction is the heart of the thread.

The missing piece: economic security

Identifying unique humans solves Sybil resistance. It does nothing for economic security, the question of what stops those same unique humans from misbehaving. The thread lays out the standard models crisply. In proof of work, miners invest in hardware that is only valuable if the chain keeps its value, so honest mining pays more than attacking. In proof of stake, misbehavior is slashed, so the attack costs stake. In classic proof of authority, validators are known institutions whose reputation, and exposure to lawsuits, is the deterrent. In MADAR today, without IDs or stake, operators have nothing to lose except their seat and future rewards. Approval can be withdrawn, but that only deters as long as the rewards exceed the bribe. The brutal arithmetic: the cost of capturing a small operator set stays flat while the value the chain secures grows, so at some point attacking simply pays.

Can a bond fix it? Partially, and the thread says exactly where

The author proposes a fixed refundable bond per operator, fixed rather than wealth-proportional so it preserves one vote each, lost on proven misbehavior. The discussion then splits the attack surface cleanly:

Two implementation details decide whether the bond means anything: the unbonding delay must be longer than the equivocation report window, or an attacker can misbehave and withdraw before the report lands; and the committee is currently the real boundary, since two of three keys can admit operators and push runtime upgrades. The author committed in the thread to separating admission keys from upgrade keys and adding an upgrade delay, so the network can see an upgrade coming and react before it executes.

The vault test

The most useful contribution is the vault analogy for why proof of stake works and a fixed bond alone does not. In proof of stake, the stake and the value being secured are usually the same token; in Polkadot, for example, both are DOT, so when the price rises the lock gets stronger and when it falls the treasure shrinks with it. In a bonded proof-of-authority chain, the bond and the protected value are in different units, so a fixed bond weakens in real terms as the chain holds more value. A slashable bond therefore only works while the value on the chain stays below the bond, or while the bond covers the maximum gain from misbehaving. The practical adaptation is the Interlay model: bridges like Interlay let operators lock more collateral than the assets they custody and cap what they can hold at what the collateral covers. Applied here, the rule becomes: limit what the chain accepts to what the total bond covers, with a safety margin, and only raise the cap when the bond grows. Because MADAR is still on public testnet with no token, these decisions can go into the design before mainnet rather than after an incident.

A decision framework for small chains

For anyone building a small Substrate chain right now, the thread reduces to a fork in the road. If you have a trusted, accountable committee, treat the network as open proof of authority, say so plainly, keep admission and upgrade keys separate, and add upgrade delays. If you want Sybil resistance without IDs, pick a proof-of-personhood scheme and accept its replacement trust assumption. And if you need attack cost to scale with value secured, put skin in the game: a slashable bond plus an offline penalty, with secured value capped at bond coverage.

What to watch: the promised follow-up post with the written design combining the bond cap and the split authority keys. If MADAR implements this before mainnet, it will be a rare case of economic-security design happening in public, before the incentive to attack exists, rather than after.

TL;DR

• What: A Polkadot Forum thread dated October 20, 2026 dissects MADAR, a small Substrate testnet running one-operator-one-vote.
• Why: Proof of personhood stops Sybils but not bribery; without stake or IDs, capturing a small operator set stays cheap as chain value grows.
• Fix: A fixed slashable bond covers provable equivocation but not stalling; add an offline penalty, a long unbonding delay, split admission and upgrade keys, and cap secured value at bond coverage.
• Watch: MADAR's promised design write-up before mainnet, the chance to fix economic security pre-launch instead of post-incident.

Sources

• Polkadot Forum: A small Substrate chain where each node operator gets exactly one vote, topic 19050, posted October 20, 2026
• Substrate documentation, consensus and GRANDPA finality gadget

Gemma Nguyen is TotesTek's Content Lead & Journalist, covering cryptocurrency, Web3, DeFi, blockchain technology, and emerging tech trends.