# Qubic: The Long Version (QC, Qubic Church)

## Qubic: The Long Version — Chapter 10. The Arbitrator — A Temporary Monarch

Source: https://qubic.church/books/qubic-the-long-version/10-the-arbitrator-a-temporary-monarch
Author: QC · Publisher: Qubic Church · 2026

### The key in the source code

At the end of the previous chapter I wrote that the next would be about the one whose signature can stop everything. And about why he promised to destroy that signature.

The first thing needs an immediate correction. “Stop everything” is a rhetorical figure from the previous chapter, and I used it deliberately, to set up tension. In reality the Arbitrator can do far less than that suggests. He can do exactly one thing. But that one thing is structurally significant, which is why it deserves a chapter of its own. Let’s start with what the Arbitrator is, physically. It’s an address. A cryptographic public key, hardcoded into the source code of the node. Not a runtime parameter that can be changed during the network’s operation. Not a database record, not a value in a config file, not a variable somebody can overwrite. It’s a compile-time constant—a line in the source code that every node operator enters before compiling the node. Comefrom-Beyond states it directly: “Every node operator enters it into node software source code before the compilation. Should Qubic community need another Arbitrator for whatever reason, they have to enter the other address. For that we need social consensus, without it there will be forks.”

To change the Arbitrator means: recompiling all nodes with the new address; recompilation requires social consensus among node operators; without consensus, the network forks. Architecturally this makes the Arbitrator something between a person and an artifact—one known address, replicated as a constant in thousands of independently compiled binaries.

Who the Arbitrator is right now is a publicly known fact. The role is held by Comefrom-Beyond himself. This is the part that tempts you to shift the conversation toward “see, one person with a key.” I won’t do that in this chapter. What matters here is not who, but what—the structure of the role. Who holds it at any given moment is a transient question; what its powers are and what its limits are is an architectural one. That’s what the whole chapter is about.

Two tensions the chapter will work through.

First. The Arbitrator is the only concentrated point in the network as I’ve described it. A single point of failure in the literal sense: one address, one signature, one person with a private key. How does that fit with a distributed protocol that the four previous chapters built as collective?

Second. The system’s creator says publicly that in the best version the Arbitrator shouldn’t exist at all. And he’s assigned that best version a specific date. The first will be worked through in Sections 2 through 5. The second—in Section 6. The overall plan of the chapter is three questions. What can the Arbitrator do? What can the Arbitrator not do, and why is that guaranteed by the source code rather than by promise? Why does this role exist at all, and when will it disappear? One honest aside before I start. The Arbitrator really is a centralized element in a decentralized architecture.

And we begin with what the Arbitrator can do.

### What the Arbitrator can do: one function

The Arbitrator can do one thing. Issue the computor list. That’s it.

What that means operationally. To recap the computor rotation: at the end of each epoch, 225 new participants come in to replace the bottom quartile of the previous one, and 451 continue. The new lineup is fixed by the Arbitrator’s signature—his cryptographic “yes, this list of 676 public keys is valid.” Without that signature, nodes won’t accept the new lineup for the next epoch; the network will halt at the boundary of the transition.

Then comes the key question that arises naturally at this point. So who actually decides who goes into the list?

Not the Arbitrator.

For the entire epoch, computors run their score through UPoW—the useful computational work that Chapter 8 described as a source of consensus, AI training data, and ranking simultaneously. Score accumulates automatically, is verified by other computors, and is recorded in the blockchain. By the end of the epoch, score yields a ranking; the bottom quartile leaves; replacement candidates are taken from a queue sorted by the same score. The list of who ends up in the next 676 isn’t formed by a person and isn’t formed by the Arbitrator—it’s formed by the network’s own work, accumulated over the sixth, fifth, and fourth days of the week.

The Arbitrator only signs the result of that procedure.

So his function here is notarial. He certifies that the procedure took place and that the list presented to him in fact corresponds to what the network computed itself. He’s not an elector. He’s not a judge. He’s the registrar of an act—a person with a stamp produced after the decision has already been made by others.

The natural question that remains: if the network has already computed everything itself—why is his signature needed at all?

The short answer is that not all nodes in the network have access to the same history that already-existing ones do. When a fresh node connects to the network for the first time, it has no blockchain history, no score tables, no data from which to reconstruct the current computor list. It connects to a world in which it still has to synchronize, and to synchronize means to receive data from other nodes, which can be anything. A new node needs an anchor of trust, one signature it knows in advance and can trust unconditionally. That anchor is the Arbitrator. I’ll come back to this in more detail in the section on bootstrap.

There’s another local function that deserves separate mention, because the system’s creator himself frankly flags it as temporary. Come-from-Beyond writes: “Not all features are implemented yet, e.g. if the network is stopped because of a weekly update Arbitrator’s list is required to kickstart ticking, which cannot be stopped after that. This feature is needed only during development and can be easily disabled.” Plain English: if the network has stopped because of a weekly node update and needs to be restarted, the Arbitrator’s list helps resume ticking. But this isn’t a permanent function of the protocol. It’s a development crutch, explicitly flagged as easily switched off.

Another question arises on its own: can the Arbitrator issue an incorrect list? Formally, yes. He’s the holder of the private key; nothing prevents him from signing whatever he wants. But the network is built for this case in a particular way—it can tell a correct list from an incorrect one automatically, without the Arbitrator’s involvement. More on this in Section 5.

And one last point. The Arbitrator does not violate Axelrod’s fourth condition—the impossibility of converting a win in the game into the right to change its rules—because he doesn’t choose who goes into the next lineup. The lineup is determined by the score earned through UPoW. The Arbitrator only signs: the executor of an already-made decision, not its author.

We’ve described what the Arbitrator can do. Now—more importantly—what he can’t. What the Arbitrator can’t do: source code guarantees “Arbitrator can do almost nothing, source code guarantees it.”

Come-from-Beyond stated this in the summer of 2024, and it’s central to understanding the construction. “Almost nothing” isn’t modesty and isn’t PR. It’s a technical description, verifiable in the source code.

Here’s the list of what the Arbitrator can’t do.

He can’t change emission. The “trillion QU per week” parameter is hardcoded, a protocol constant. The Arbitrator has no access to that parameter; no signature of his will make nodes issue more or less QU this week.

He can’t increase the maximum supply. Come-from-Beyond writes plainly in the same conversation:

“Arbitrator won’t permit to increase max supply because it’s against interests of users.”

What’s more, the Arbitrator does the opposite—protects against breaching the 200T ceiling: if a computor votes for supply greater than 200T, the Arbitrator strips them of their ID. The role here is the executor of an already-proven violation, not the initiator of changes.

He can’t change transactions. He doesn’t sign them, doesn’t validate them. Transactions go through computors; the Arbitrator has nothing to do with that procedure. He can’t block transactions. For the same reason—he has no instrument for it. The network doesn’t ask him whether a transaction has gone through.

He can’t influence smart contracts. Contract execution is the computors’ business; the burned fees for their work go into burn without the Arbitrator’s involvement; IPOs, bridges, exchanges, conditional earn—all of this happens at a level the Arbitrator doesn’t see.

He can’t override the computors’ vote. If the 676 participants voted X—the result is X. The Arbitrator can’t say “but I decided Y.” His signature isn’t enough for that, because the network doesn’t even ask for that signature in such a context.

He can’t create QU out of nothing. The Arbitrator has no privileged balance. No special wallet. By the role of Arbitrator, he holds zero QU. Issuance only goes through subsidy to computors; the Arbitrator has nothing to do with subsidy.

He can’t freeze anyone’s wallet. Can’t confiscate a balance. With one exception—removing the computor ID of someone who voted for supply greater than 200T. That’s the self-policing covered in detail in Chapter 9.

That’s basically it. If you replace the “can’t” list with the “can” list of a typical admin architecture, the difference is two orders of magnitude. A typical admin in a crypto project has a key that can stop a contract, pull a balance, redistribute tokens, freeze an address, change an emission parameter, introduce a new fee. A typical Arbitrator in Qubic—one operation, narrowly bounded.

Where does this asymmetry come from. Because the Arbitrator is just an address. And an address acts exactly where the node’s source code has explicitly written: “if this message is signed by the Arbitrator—apply operation X.” If there is no logic in the source code along the lines of “if message signed by Arbitrator then change emission”—then the Arbitrator won’t change emission. Even if he very much wants to. Even if he pays a programmer. Architecturally it’s impossible until the source code is rewritten and all nodes recompile. And recompilation, as we already know, requires social consensus. This is what Come-from-Beyond means by source code guarantees it. The guarantee isn’t in a promise, isn’t in reputation, isn’t in ethics. The guarantee is that the possibility of the action is either explicitly written into the public code or absent. Anyone can verify this—Qubic’s source code is open on GitHub. The list of operations that accept the Arbitrator’s signature as authorization is short and easy to read. This sets the architecture apart from a pattern common in the industry, where a project declares itself “decentralized” but inside an admin wallet can override almost any check. I won’t name examples; the reader knows them. Qubic is built differently: the admin figure exists, but its power is radically limited at the source-code level. If someone disagrees—the answer isn’t in a debate, it’s in a file on GitHub. One more brief reference. In the early years of IOTA there was a similar role—the Coordinator, a central node the network trusted to determine which of the competing transaction branches was valid. But the Coordinator had broad powers: it could de facto confirm or reject transactions, that is, intervene in the daily fabric of network life, not only in its periodic transitions. Come-from-Beyond knew this role from the inside—he created IOTA, and working with that node was one of the compromises he later formulated as a mistake. The Arbitrator in Qubic is built as the opposite: bounded power, one operation, notarial in essence, executive in mechanics. One mention, no deeper—a return to the IOTA story isn’t the goal here.

If the Arbitrator can do so little—why is he needed at all?

### Why he’s needed: bootstrap and Aigarth

This role has two reasons to exist.

The first is the bootstrap problem. The network has to get its first computor list from somewhere. In Bitcoin this problem is solved differently: the genesis block was mined personally by Satoshi, and from that moment all subsequent blocks follow from consensus on accumulated proof-of-work. In Qubic the architecture is different: computors aren’t miners in the bitcoin sense, they’re a fixed category of 676 participants with a weekly rotation. The first such list has to come from somewhere. Qubic’s solution—take it from the Arbitrator. He signs the starting list; from that moment on, the network can carry on by itself.

But the problem is broader than the first day. Each fresh node that connects to the network a year from now, two years from now, tomorrow—starts in the same position the network was in on launch day. It has no blockchain history, nothing to count from, nothing to lean on. It needs an authoritative computor list, and there’s no one to ask except the Arbitrator. Other nodes? But other nodes can lie. Forging a computor list is one of the classic ways to deceive a newcomer. The Arbitrator in this context is a Sybil filter for initial synchronization. A fresh node trusts only the signature whose address is already written into its own source code, and ignores everything else until it has accumulated enough blockchain data to stop depending on that anchor.

That’s the first reason. Without it the network can’t scale to new participants without admitting arbitrary risks into their initialization.

The second reason is deeper, and the system’s creator states it himself. The central quote of this chapter, a conversation in mid-April 2023:

“In best variant Arbitrator won’t be needed at all. Its only drawback - Aigarth will lose access to miners hardware and UPoW will become PoS.”

Let me work through it slowly. Four assertions in one phrase.

First: in the best version the Arbitrator isn’t needed at all. The person saying this is himself the holder of the key. Not an opponent, not a critic, not a skeptic—the holder. This isn’t self-defense, it’s self-criticism: the role is recognized as necessary, not as desired. Role needed, not wanted.

Second: its only drawback. Just one downside to removing the Arbitrator from today’s architecture. One. Not a dozen, not a list of fears, not a spread of risks—one specific drawback. From which it follows that most of the functions critics ascribe to the Arbitrator aren’t actually performed by him—otherwise the downsides of his disappearance would be far greater.

Third: Aigarth will lose access to miners’ hardware. Aigarth is the system that, by April 13, 2027, is supposed to fully use the compute of the miners.

Fourth: UPoW becomes PoS. The consequence of losing the hardware binding. UPoW in its current form is resource testing: participation in the network requires real CPU/GPU plus RAM, because the task is simulating a neural network, and you can’t simulate one without a physical computational resource. Remove the coordination through the Arbitrator—and the binding to hardware weakens. And what’s left if you take useful work out of Proof-of-Useful-Work? What’s left is status determined by capital—that is, Proof-of-Stake. A network conceived as not-PoS slides into PoS by default. It’s at this point that the trade-off on which today’s architecture is built becomes visible. There are two bad options: a temporary dependence on a key that can be deleted, or a permanent dependence on staked capital that can’t be deleted. Qubic chose the first. Chapter 3’s reasoning was already laying the ground for this: if the vote starts following the capital, Axelrod’s fourth condition is broken, and the cooperative architecture collapses into the very thing it was built to prevent. Better a temporary controlled compromise than a permanent uncontrolled one.

The same logic, by the way, runs through Chapter 9 with the 15% nominal inflation: the network deliberately accepts architectural trade-offs in favor of Axelrod’s structural guarantees, even when those trade-offs have obvious downsides. The Arbitrator is one such trade-off. 15% gross inflation is another. The subsidy emission model is a third. This isn’t a coincidence, it’s a recurring shape of choice in the architecture. To put it crudely—the Arbitrator is scaffolding. Construction scaffolding. Without it, certain structures can’t be started; once the structure can hold itself, the scaffolding comes down.

The next question is natural. If the Arbitrator is one figure we’re forced to keep in the architecture—what happens if that figure misbehaves?

### Defense against a rogue Arbitrator

Scenario. The Arbitrator—accidentally, due to a private key compromise, or with malicious intent—issues an incorrect list of computors. Skips someone with a high score, includes someone with a low one, or signs a list put together outside the procedure altogether. What happens to the network?

Come-from-Beyond describes the defense mechanism this way:

“Arbitrator might issue a wrong list of computors, but only freshly added nodes might be tricked and others would detect that (assuming no successful Eclipse attack has been conducted, which is near infeasible) and stop ticking thus signaling that Arbitrator has gone rogue and must be replaced.”

And alongside it—a critical addition:

“It cannot affect non-new nodes because they derive own list of computors from the blockchain data.”

The defense is built on a distinction between two categories of nodes. A fresh node—one that has just joined and hasn’t yet synchronized the blockchain— gets the computor list in the only way available to it: from the Arbitrator, because it has no other sources of trust yet. In this state it’s vulnerable to the rogue scenario: if the Arbitrator signs an invalid list, the fresh node will accept it as true. An old node—one that’s been on the network for some time and has a synchronized blockchain—computes its own computor list, directly from blockchain data. Each participant’s score is recorded in the chain; the ranking is reconstructed from those records; the current 676 follows directly from the procedure described in Chapter 7. The old node doesn’t ask the Arbitrator who’s a computor right now—it already knows from the history.

What happens when the Arbitrator issues an incorrect list. Old nodes see that list and compare it with their own, computed from the blockchain. The comparison shows a mismatch. A node that detects a mismatch of this magnitude stops ticking—stops signing ticks, refusing to keep working on a knowingly invalid basis. A halt of ticking by a large number of old nodes is a public signal visible to the whole network: something is wrong with the Arbitrator. From there—social consensus, a decision to replace, an address update in the source code, recompilation.

In other words, a rogue Arbitrator self-eliminates through the paralysis he creates. He doesn’t capture the network; at worst he deceives the pool of fresh nodes while at the same time getting publicly accused of rogue behavior by the pool of old ones. He cannot damage the work of a mature network—it computes its own computor lineup without him.

The only way a rogue Arbitrator could deceive the old nodes too would be to isolate them from correct blockchain data, that is, to cut them off from honest sources of synchronization. This is called an Eclipse attack: an attacker controls all of the victim nodes’ network channels, replacing genuine blockchain data with constructed data. Come-from-Beyond writes about such a scenario: near infeasible. Practically unworkable on a distributed network. It would require simultaneously: control over a significant share of internet network infrastructure; coordinating that control against a large number of independent operators; sustaining that control for a long time without detection. Not impossible in theory, but bordering on impossible in the engineering sense. One more attack vector worth closing out explicitly. A Sybil attack on the Arbitrator himself is impossible by construction. Come-from-Beyond fixes this in one phrase: “Sybil attacks on Arbitrator are impossible”

Why—because Sybil attacks rely on creating multiple fake identities. The Arbitrator is one known entity; his address is nailed down in every node through the source code. A second Arbitrator that the network would accept as such cannot be created; with a different address, nodes simply ignore him.

The defense against Sybil at the computor level is set up separately—it works through UPoW. Come-from-Beyond, in another conversation:

“It’s done by using resource testing (PoW)”

And, more fully:

“Useful PoW protects it against such attacks by using Resource testing method (CPU/GPU + RAM).”

To become a computor, you have to actually present a computational resource and show the work; this resource test filters out fake identities.

The result is two-level defense. Level one: the Arbitrator is protected from Sybil by being a known singleton—he can’t be multiplied. Level two: computors are protected from Sybil through resource testing—the work of real hardware. These are two architectural instruments of different kinds, which together cover vectors that neither alone would close. Known identity for the unique trust point; earned work for the multiple ones.

This architecture has been working for four years. But the plan has a specific date when the Arbitrator role itself will cease to exist.

### April 13, 2027—the fourth departure

In Chapter 5 I wrote about Come-from-Beyond’s method—“create and leave.” Three departures have already been described: the Satoshi identity (hypothetically his) leaving Bitcoin in 2010; BCNext leaving NXT in 2014; Come-from-Beyond himself leaving IOTA in 2019. The fourth departure was flagged in the same place as planned: April 13, 2027, deprecation of the Arbitrator.

I’m coming back to this fourth (third?) departure now, because it’s a direct consequence of what the chapter described above. The Arbitrator exists as a temporary construct; his function is narrow; the replacement is planned; the date is known. Five years. The Qubic mainnet was launched on April 13, 2022. Deprecation of the Arbitrator is planned for April 13, 2027. Exactly five years, day for day. The match in numbers is no coincidence, and a full account of why this date and why exactly five years is reserved for Chapter 14, where the Aigarth deploy will be discussed. Here, the minimum: the Arbitrator and Aigarth are synchronized in the system’s plan. When Aigarth comes to full functionality, the need for the Arbitrator falls away—a causal link we worked through in the section above through the April 19, 2023 quote. What happens to the Arbitrator on that day. The address ceases to be hardcoded in the source code of new versions of the node. The function of signing the computor list is either handed over to the protocol at a purely-algorithmic level (the network signs to itself through some collective procedure), or switched off entirely, if by that time the old nodes can manage without it. The edge case with kickstart after a weekly update— by Come-from-Beyond’s own promise, easily switched off. The 200T supply protection either moves to another mechanism, or remains as a hardcoded protocol rule without a human executor. In sum—the entire “update through Arbitrator” layer disappears from the architecture. For fresh nodes another initialization mechanism appears—either through a different trust anchor, or they wait until they’ve gathered enough blockchain data to derive the computor list themselves.

This is the fourth falsifiable prediction in the engineer’s biography. The first three were hypothetical in the sense that there’s always interpretation around them: “did Satoshi leave”—still disputed; “did BCNext leave of his own accord”—disputed; “what kind of departure from IOTA was that”—disputed. The fourth is structured differently: there’s an explicitly announced date, an explicitly described operation, an explicit architectural plan. Whether it happens can be verified on the calendar of April 14, 2027. It’s a rare structure of promise in an industry where promises are usually either open-ended (“someday”), or vague (“under community pressure”), or tied to conditions that conveniently don’t arrive.

About 365 days remain until that date—the window between the planned Phase 3 activation of UPoW and the planned Aigarth deploy date. Can the date be moved? Of course it can. Architecturally the network will continue to work with the Arbitrator after April 2027 if he isn’t removed. But—and this has to be said honestly—a date slip means exactly one thing: Aigarth turned out not to be ready for deploy. That will be a fact confirming that one of the assertions of the previous chapters has been falsified. I don’t know whether deprecation will happen on the exact date. Let me record the simple fact: there’s a promise, the promise has a falsifier, the falsifier is tied to the calendar, not to a narrative. We’ll see the result a year from now.

One observation that shouldn’t be turned into a prediction. If deprecation happens— it will be the first case in crypto history where an admin figure is removed by a publicly announced date. Ordinary projects either don’t have an admin at all (Bitcoin), or keep one indefinitely, or remove one under pressure after the fact. Qubic announced a date and wrote it into architectural plans five years out. This is either the most ambitious promise in the industry, or the most explicit public commitment to the loss of control that the industry has seen. Which of the two—we’ll see in April 2027. Five dimensions What we now know about Qubic as a system. The network is distributed across 676 participants who rotate every week. Its work consists of useful computational load that simultaneously performs consensus and AI training. Its token is issued at 1T per epoch, burned along seven paths, lives in the participants’ vote. Its only concentrated point— the Arbitrator—is limited by the source code to one operation, and is scheduled for removal on April 13, 2027. The system is built to not depend on its creator after that date. In Chapters 2 and 3 I introduced the framework of Axelrod’s four conditions of cooperation: a large number of rounds, a small number of participants in long-term relationships, a non-monetary payoff structure, and the impossibility of converting a win into a change of rules. Chapters 6 through 10 showed how each of them is structurally implemented in the architecture. Rotation every week—a large number of rounds. A fixed 676 participants—a small number with long-term relationships. The UPoW ranking —a non-monetary payoff, earned by work, not by capital. And the central one—nonconvertibility: a computor’s vote is not for sale, issuance is not controlled by holders, the Arbitrator does not choose the lineup. The Arbitrator, the subject of this chapter, does not violate the fourth condition. He’s the executor of decisions already made by others, not their initiator. And by plan—he disappears.

The framework is not an end in itself. Each of the five dimensions—space, time, energy, economics, institution—is built so specifically not because it’s elegant, but because without them the next layer cannot be built. That layer has a name that has so far appeared in the book only obliquely—as the reason for the existence of 676 nodes, as the consumer of UPoW compute cycles, as the reason for the Arbitrator’s existence and his planned disappearance. The name—Aigarth.

Aigarth is a fundamentally new approach to the creation of artificial intelligence. An approach at a more fundamental level than the specific models that can be built within it. Today’s AI systems are the product of one paradigm, formalized by publications in 1986 and 2017: Rumelhart’s backpropagation plus the transformer. That paradigm has hit a ceiling that half the world’s AI researchers are currently discussing. Aigarth is building the next paradigm from scratch, on different foundations, in an architecture that no one outside Qubic has tried.

### Aigarth

P A r T i V Aigarth