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

## Qubic: The Long Version — Chapter 6. 676 Voices

Source: https://qubic.church/books/qubic-the-long-version/06-676-voices
Author: QC · Publisher: Qubic Church · 2026

The number 676 isn’t aesthetic. It isn’t pretty. It isn’t symbolic. It’s the exact number of participants who simultaneously make up the main load-bearing structure of Qubic at any given moment in time. Six hundred and seventy-six computers, connected into a single network and voting every few fractions of a second on one and the same question: “what will be the next state of the whole system.”

If you want to picture this construction in a single image, picture a parliament with 676 seats. The parliament has a rule: to pass any decision, you need to gather no fewer than 451 votes in favor. Four hundred fifty-one is just over two-thirds of 676. Less than that — the decision doesn’t pass.

The parliament has no speaker with special powers. It has no factions with privileges. No party discipline. No lobbyists whose role in the corridor differs from the role of deputies on the floor. Each of the 676 has exactly one vote, and that vote can’t be bought, bought out, pooled, or converted into two votes, no matter how much work that deputy did over the past week.

Once a week, the composition of the parliament partially changes. Not entirely — gradually, by a fixed rule. Those who showed the worst result over the past week yield their seats to those who, over the same week, performed more useful work and are now claiming entry. The number of deputies replaced at one time is rigidly capped — it can’t be inflated by a one-off decision, and it can’t be reset to zero. The parliament refreshes on a regular rhythm, the way leaf cover turns over, only not in autumn but every seven days.

That, at the level of a rough analogy, is how the Qubic network is built. The analogy, as always, has a limit beyond which it shouldn’t be stretched. 676 computers don’t argue, don’t deliver speeches, don’t vote against their convictions under pressure. They execute a precise sequence of cryptographic operations in which a “vote” is a signature and a “decision” is the new state of the network being accepted. But the basic principle — a fixed small circle, a two-thirds threshold for any change, regular partial rotation — is exactly the one described above. That’s the frame to start from. There’s another, more organic metaphor worth mentioning here once and returning to closer to the end of the book. Beneath the mushrooms in a forest ecosystem lies the mycelium — a network of fine threads stretching tens of meters in every direction. Mycelium has no center. It has no owner. Individual sections of it die off and regenerate continuously; the whole, meanwhile, goes on existing longer than any of its fragments. When I first saw a diagram of Qubic’s 676 computors next to a diagram of mycorrhiza, I was struck by the topological similarity. This isn’t mysticism, and it isn’t poetry; it’s simply a statement of the fact that distributed systems without a center — biological or engineered — converge on the same architectural solutions.

This chapter is about the mechanics. How the 676 actually vote. Why any decision requires a threshold of 451, rather than, say, 339 (a simple majority) or 676 (unanimity). What a tick is — the basic time unit of the network in which all of this manages to happen. How the weekly rotation of membership works, and why it’s precisely this rotation that makes the network structurally resistant to capture from within.

In the previous chapter I compared Qubic to Murdoch in 1792 — the man who first collected the gas being wasted from blast furnaces and channeled it into a pipe. The 676 voices aren’t Qubic’s “gas pipe” itself. The gas pipe is the next chapter after this one, on useful computational work. But for the pipe to hold and not be captured — first you need a construction that holds it. Floor, walls, foundation. Coalbrookdale of the digital age, day one: assembling the frame.

Let’s start with the threshold of 451.

### A Quorum of 451 out of 676

If a parliament has 676 seats and any decision requires a minimum of 451 votes in favor, then what a hypothetical coalition capable of coordinating would hold is not a majority of seats but a supermajority. A majority is when 51 out of 100 back you. A supermajority is when two-thirds back you. Formally: 2/3 of 676 is 450.67. Round up, because a vote is a discrete quantity: there are no fractional votes. You get 451. Where did the two-thirds logic come from in the first place, rather than, say, threequarters or a simple majority of 50% + 1? Two-thirds is the classical threshold in distributed systems where some participants may behave dishonestly or simply fail. It came from a field that computer researchers began developing in the late 1970s under the name “the Byzantine generals problem.” The name is conventional; it’s taken from a parable about a group of Byzantine generals who, having surrounded a city, must agree on a common plan (storm or retreat) through messengers, knowing that some of the generals may be traitors and will pass on contradictory messages. The essence of the problem: at what maximum number of “traitors” in the group are the honest participants still able to arrive at a single correct decision? The mathematical answer turned out to be hard. If traitors can number up to onethird of the group, the honest two-thirds can work out a common decision that the traitors are unable to derail. If there are more traitors than one-third — no protocol trick can save the situation; the group is in principle incapable of guaranteed agreement. Two to one is the mathematical boundary of a distributed system’s resilience to dishonest or failed participants.

A natural question may come up: why not get by with a simple majority, that is, 51%? In ordinary voting in a live parliament, where everyone voting is in the same hall and can ask one another to repeat themselves, a simple majority works fine. In a distributed network, connected only by messages, things get more complicated. Imagine for a second the following scenario. 339 computors sent in their votes for one version of the new state; another 337 voted for a different, conflicting one. Who’s right? If there are 226 malicious participants in the network, a situation is theoretically possible in which those 226 sent half the network one vote and the other half the opposite vote. Each part of the network sees a local majority for its own version and accepts it as canonical. The network splits into two parallel worlds, each of them confident of its own rightness. This is the classical “Byzantine” problem in action. The two-thirds threshold eliminates this possibility: under any arrangement, if 451 participants voted the same way, a second group of 451 in the network physically cannot exist, because 451 + 451 = 902 > 676. Therefore, any decision that gathered 451 votes is unambiguously canonical. An alternative branch, having pulled together the same level of support in parallel, doesn’t exist by arithmetic.

This boundary is wired into the Qubic protocol literally. Of the 676 computors — those same “parliamentary deputies” — up to 225 participants can be unavailable, broken, caught in a network partition, or colluding against the network at the same time. That’s less than one-third. The remaining 451 are already a supermajority; they continue to make decisions, and any decision they make is canonical for the network. But if 226 or more go against the network, then the network, by protocol, cannot reach consensus; it freezes, waiting for a workable mass to be restored. It doesn’t start accepting “alternative” blocks, doesn’t split into warring branches, doesn’t drift into a state from which it would later need to vote on its own rescue. It stops. This is, in a sense, a safety technique opposite to Bitcoin’s: Bitcoin keeps working even under a strong concentration of hashrate, just with degraded protection. Qubic either works with guaranteed protection, or doesn’t work at all.

Now an important, subtle, often misunderstood detail.

Each computor has exactly one vote. Not “one vote per unit of capital.” Not “votes proportional to a computer’s power.” Not “the more I earned in the previous epoch, the more votes I have in this one.” One participant — one vote. It’s a protocol rule that can’t be circumvented, no matter how many resources one participant has accumulated. This, if you step back a moment, is the main structural difference between Qubic and systems in which the weight of a decision is proportional to the resource invested. In Bitcoin, a large pool that has concentrated a big share of the hashrate gets a proportionally larger probability of determining the contents of a block; the more equipment you have, the more weight you have. In classical Proof-of-Stake, a large coin holder gets a proportionally larger probability of becoming a validator; the more money you have, the more weight you have. In both models, accumulated resource is converted into the right to participate in shaping the rules of the next step. In Qubic this conversion is forbidden by the protocol. A computor with a huge fleet of servers and a computor with the minimum configuration that still lets it hold its seat have, in every vote, equal weight — one vote. The only thing many resources buy you is a chance to stay among the 676 and not be displaced in the next epoch. But while you’re in the 676, your weight is exactly the same as anyone else’s.

Here, I think, the attentive reader will recall one of the conditions from chapter three. We formulated it back then in these words: a win in the game must not give the player the ability to change the rules of the game itself. The formulation was abstract; this is its concrete engineering embodiment. Within a single vote, no accumulated advantage converts into votes. Let’s figure out what, exactly, gets voted on. The Tick: The Moment at Which the Network Makes a Decision In ordinary life we think of time as continuous. Week passes into week, day into day, with no clear seams. Distributed networks can’t do that. For 676 computers scattered across the planet to arrive at a common decision about “what is the network’s current state,” they need a common discrete time grid. They need moments when all of them simultaneously look at the world and simultaneously vote.

In Qubic this unit is called a tick.

A tick is one completed round of voting. Roughly the following sequence happens in each tick. First, one of the 676 computors is selected to play the role of “leader” for this tick — it gathers the transactions that came in over the previous micro-interval, orders them, and proposes the resulting bundle as the network’s next state. Then its proposal is broadcast to all the other 675. Each of them, on receiving the proposal, checks it against the protocol — the transactions don’t contradict each other, the leader had the right to propose anything, the signatures are correct — and votes “yes” or abstains. When 451 “yes” votes are collected, the proposed state is accepted as canonically new. The network has taken one step. The next tick begins.

It’s worth emphasizing that the “check” here is not a formality. Each computor holds a complete current picture of the network: which addresses exist, how many coins are on each one, which obligations are already pending, which transactions were accepted in previous ticks. When a proposal from the current leader reaches it, it itself, with its own code, applies all the proposed transactions to its own state and sees whether it gets the same result the leader claimed. If it does — it votes “yes.” If not — it doesn’t vote. For a malicious leader there’s simply no way to push through a false proposal: 675 independent verifiers will run his calculation through themselves at the same time and independently see the discrepancy. The only proposal that survives is one that’s objectively correct by the rules of the protocol.

Two key points of this mechanic are worth singling out.

First — the leader role isn’t fixed. It rotates by a deterministic rule known to all 676 participants in advance. This isn’t an “auction for the right to propose a block,” as in Bitcoin, where the contents of a block are formed by whichever miner first happened to solve a cryptographic puzzle — and that means, with high probability, a large pool. In Qubic, for each tick the leader is known in advance and changes for the next tick. No computor can stably control the flow of proposals; the most it can do is be the leader in its own tick, and in the next one the next computor in the order replaces it. Over a thousand ticks, each of the 676 computors gets to be leader roughly the same number of times.

Second — the decision requires the agreement of a supermajority, not the leader. The leader doesn’t make the decision. The leader proposes. The decision is made by 451 votes. If a leader tries to propose something incorrect — a transaction that breaks the rules of the protocol, or a block with a double spend — then 451 honest computors simply won’t vote in favor. The proposal won’t pass; one tick later, its place will be taken by a proposal from the next leader, and the network’s work will continue. A spoiled leader can’t hold up the network for longer than one tick.

If you translate this into the language of more familiar distributed systems — in Bitcoin every block is formed by exactly one miner (more precisely, by exactly one pool), the one that got lucky finding a hash with the required prefix. The rest of the network can accept that block or reject it, but it’s always one entity that forms it. In Qubic every decision is formed collectively: the leader only puts forward a hypothesis; the supermajority approves it. The difference is in where the decision is concentrated. In Bitcoin — at the point of formation. In Qubic — in distributed voting across the whole network. The exact frequency of ticks — exactly how many of them happen per second — is set by a protocol constant and described in the Qubic technical specification. What matters for this chapter is one thing: there are many ticks per unit of time, the count runs into single digits per second and higher, and each tick is a full round of voting by 676 participants. On the scale of a single day, the Qubic network makes tens or hundreds of thousands of collective decisions, each of which has gone through the quorum of 451.

Now to the most interesting part. Imagine you wanted to capture such a network. What would you need to do?

Rotation: Why the 676 Can’t Be Captured from Within To control the Qubic network, it isn’t enough to buy more equipment than your competitors. It isn’t enough to rent more cloud than the strongest computor. It isn’t enough to band together into a pool. None of these moves will increase your weight in voting — all 676 votes are equal.

What you need is to take as many of the 676 seats as possible. Ideally — 226, to paralyze the network (by making a quorum impossible), or 451, to start forming your own decisions.

This is where the weekly rotation mechanism comes into play.

Time in Qubic is broken into weekly intervals called epochs. An epoch is a unit larger than a tick. Within a single epoch, the composition of the 676 computors is fixed: whoever made it into the epoch works in it until the end. At the boundary between two epochs, part of the composition is replaced: the worst by the results of the past epoch yield their seats to the best of the candidates who have submitted an entry application. “Worst” and “best” — by a single metric: the volume of useful computational work performed over the epoch. As to what “useful work” is in Qubic and why it’s even possible, that’s the next two chapters of the book; here it’s enough to know that each computor, at the close of an epoch, has an unambiguous numerical assessment of its contribution, and that assessment is what decides whether it stays or leaves.

An important structural fact: no more than 225 participants can be replaced at the same time in one epoch transition.

Not 300. Not 400. Not 676. The maximum is 225 out of 676. It’s a protocol constant. Let’s see what follows from this.

Imagine you’re a coordinated group that wants to capture Qubic. You’ve prepared 676 of your own computors, optimized them for maximum performance, and you’re ready to take all 676 seats with your nodes. How many epochs — that is, weeks — will it take you?

In one epoch transition, you can bring at most 225 of yours into the network. Fine; after the first Wednesday you have 225 seats out of 676. The remaining 451 are still the old ones, not yours. At the next epoch transition — at most another 225. Total: 450 out of 676. Still not 451. At the third transition — another 225. Total: 675. At the fourth — one last one. Four weeks minimum, even under absolutely ideal conditions for you, when you take exactly the maximum allowable number of seats every epoch.

But even this is the most favorable scenario for you, and it assumes that in each of four epochs in a row all 225 available seats were filled by precisely your candidates and no one else. It requires that, in performance, your 225 computors be better than all the other honest candidates in the world, simultaneously, week after week. If even in one of those epochs you lose the competition by even fifty positions, your 175 won’t give you the step you need, and the reckoning shifts. If you lose in each epoch by even a hundred positions, the takeover stretches out to two months and more, and all this time the network stays in the hands of the old supermajority.

But this is the hypothetical minimum. In reality you have no guarantee that your 225 candidates will land at the top by work performed. Other computers are working too; they’re submitting entry applications too. Your candidates compete with them not on the basis of “whose team is whose,” but on the basis of who has more useful output for the week. You have to not just prepare 676 machines but make it so that every week your machines steadily outplay all the other applicants in the world. Four weeks in a row. Without a single miss.

And now let’s recall the main thing: as long as you hold fewer than 451 seats, the network is still controlled by the old computors. Any decision goes through the quorum of 451; while you have 225, or 450, or 450 — that decision isn’t made by your people. The old network keeps working normally. The old computors keep noticing the newcomers coming in. If they notice that a coordinated pool of nodes behaving the same way is entering the network, they can react. At the protocol level, no — they have no mechanism to “block the suspicious one.” But at the level of the community watching what’s happening, yes. Qubic has a public market, public communication channels, public technical decisions about the roadmap. Over four weeks of a coordinated attack, the community will have time to see this, discuss it, and possibly respond — with a technical upgrade, a change to the selection rules, the recruitment of new honest computors. There’s also an arithmetical symmetry worth noting. 676 minus 225 equals 451. Exactly the number needed for a quorum. This is no coincidence. It’s a form of symmetry chosen consciously by the developers: even if you imagine the maximally extreme scenario in which all 225 allowable seats have been replaced in a single epoch transition and all of them are malicious, the remaining 451 old, honest computors still hold control over all decisions of the epoch. They make quorum without a single vote from the newcomers. That is, even under the maximum simultaneous invasion, the network doesn’t lose the ability to make decisions on the strength of its prior composition. This is the formulation from which the structural resilience of Qubic follows. Not “the creators hope that no one will attack.” Not “decentralization is our value.” But mathematically: under any sequence of actions permitted by the protocol on the part of an attacker, the network preserves the ability to operate as before for at least one full epoch per every 225 captured seats. And during that epoch, a real network of real people has time to see, discuss, and, if necessary, respond.

Here, at this point, it’s worth restating once more what we discussed in chapter three in connection with GHash.IO — the pool that in the summer of 2013 amassed 55% of the Bitcoin network’s hashrate. There the gap between concentration and unblocking the network played out within one turn of the cycle: today 55%, tomorrow a block with a double spend — technically possible. What stopped it was only public pressure, the departure of part of the miners from the pool, reputational damage. There was no mechanical brake.

In Qubic the mechanical brake exists. It requires no public pressure, no voluntary decisions by participants. It’s built into the protocol by the constant “no more than 225 replacements per epoch transition.” Even if the entire community kept silent while an attacker methodically built up its presence month after month, it would still take it no fewer than four weeks to reach 451 of its own seats, and the whole time the network would keep working normally.

This is the very structural mechanism I was building toward in chapter three when I said that mining must produce decentralization, not concentration. A mechanism of negative feedback, which Bitcoin didn’t have and which, if you leave Bitcoin as it is, won’t arise on its own.

### Why 676, Specifically

The attentive reader who has read this far has surely already asked themselves: why 676? It looks, to put it mildly, unusual.

The first answer: 676 is 26 squared. A square number. A number convenient for representation as a 26 × 26 table, where each computor occupies one cell and has a row number and a column number. This indexing, as the Qubic technical specifications show, allows the protocol’s internal algorithms — those that handle the distribution of tasks among participants, the routing of votes, the exchange of intermediate data — to work significantly more efficiently than if computors were simply numbered 0 through 675. This is a computational argument, and it entered the network by way of engineering considerations, not aesthetics.

But the main answer is not in the square of 26. The main answer is that 676 turns out to be the golden mean across three conflicting requirements.

The first requirement is diversity. The more participants in the parliament, the harder it is for a single group to capture a majority. From the standpoint of this logic, the bigger 676 is, the better. 10,000 computors would give substantially greater resistance to concentration.

The second requirement is mutual verification. Each of the 676 checks proposals coming in from each of the remaining 675. In every tick. At a frequency of several ticks per second. If there were 10,000 computors, each one would have to check 9,999 others in every tick, and that would create a computational load that ordinary equipment simply couldn’t handle within a single tick. The network would slow down. From the standpoint of this logic, the smaller 676 is, the better. 100 computors would be able to check each other even faster.

The third requirement is fault tolerance. In any physical network, some nodes are unavailable at any given time — because of power outages, internet provider issues, an update that went sideways. For the network to always have 451 working computors for a quorum, 676 has to be noticeably greater than 451. If the network had only 451 computors (right at the quorum), then any one of them going down would stop the network. The more computors above the minimum quorum, the larger the margin of safety. From this standpoint — the bigger, the better.

676 is a compromise. Enough to provide diversity of participants and a reserve for some of them failing. Few enough that each computor can in real time monitor the behavior of each of the remaining 675. The square of an integer, so that internal algorithms work more efficiently. Double two-thirds (451 and 225), so that the construction has the symmetry we discussed above.

If the developers had taken 700, the 2/3 symmetry would have disappeared (700 × 2/3 = 466.67, rounding gives 467, and the formula “maximum replacements per epoch equals the difference between 676 and the quorum” wouldn’t work as neatly). If they had taken 625 (that’s 25²), you’d get less resilience at comparable computational complexity. 729 (27²) — more verification load without proportional gain. 676 is the point where mathematical, computational, and engineering requirements converge in a single number.

### Two Orders of Decentralization

It’s useful to see the figure 676 alongside an analogous figure for Bitcoin. In chapter three we mentioned that by 2026 effective control over Bitcoin’s hashrate is concentrated in the four to five largest pools, which together hold around 70–75% of the network’s computational power. Foundry USA — about 29%, AntPool — about 21%, another three or four notable pools — the rest. If you imagine Bitcoin as a “parliament” in which votes are distributed in proportion to invested hashrate, then in this parliament four or five players make most of the decisions. That’s the realistic upper estimate for the effective number of consensus participants in Bitcoin in its current state. 676 to 4–5 is not “a hundred times more.” It’s a different order of magnitude. It’s a structural change in the nature of the network: from one where the big decisions are made by a handful, to one where they’re made by a mid-sized parliament. If you look at this difference through a metric that the crypto community sometimes calls the “decentralization coefficient” (Nakamoto coefficient — the minimum number of participants whose union is capable of attacking the network), then for Bitcoin in 2026 this coefficient equals 3–4. The union of the three largest pools gives the attackers 51%. For Qubic, this coefficient is by construction equal to 226. Two hundred twenty-six is the number of computors that have to be coordinated simultaneously to paralyze the network. Not 3. Not 4. Two hundred twenty-six.

The difference between “three coordinating players” and “two hundred twenty-six coordinating players” is the difference between “possible to come to terms in one evening in one room” and “impossible without a serious organizational structure that itself becomes publicly visible long before the moment of agreement.” Twenty-six people you can still seat at one long table. Two hundred twenty-six — you can’t. Any attempt to assemble such a number of coordinating participants becomes noticeable simply by logistics.

There’s another way of looking at the same gap. Imagine a conspiracy — correspondence, a Telegram chat, a closed meeting. The more participants, the higher the probability that one of them will turn out to be disloyal, accidentally let something slip, or leak the correspondence. For a group of three this probability is small; for a group of twenty it’s already noticeable; for a group of two hundred and twenty-six it’s practically inevitable. The sociology of conspiracies is well studied; historians know that any conspiracy with more than a few dozen participants comes to light within a few weeks or months. This is a property of human nature, not of Qubic; but the construction of Qubic uses this property. It turns an attack that in Bitcoin requires coordinating four players into an attack that in Qubic requires coordinating roughly a hundred times more players. The requirements for organizational complexity grow accordingly, as does the probability of a leak, as does the inability to stay below the radar.

A qualification is in order. This comparison is not “Qubic beat Bitcoin.” Bitcoin wasn’t built to have a high decentralization coefficient in 2026; it was built to launch, in 2009, in complete isolation, without investors, without a team, without an exchange, without legitimacy, the first network of electronic money in history that couldn’t be shut down by a single administrative decision. It met that task. The structural detail by which hashrate consolidates over time is the price paid for an architecture in which anyone can join or leave at any moment. That price was invisible in 2009 because no one was there yet. By 2026 it had become noticeable.

Qubic was built from a different starting point. By 2022 the Bitcoin lesson was in plain view for everyone. Qubic’s developers had the option of laying in a structural anticonsolidation mechanism from the very beginning, at the cost of the network not being, in principle, a “anyone can become a computor at any moment” network — you have to pass through epoch selection and take a seat within the 225 available. This is a tradeoff: openness to arbitrary connection in exchange for guaranteed distributedness. Whether to throw this tradeoff one way or the other is a question that’s not only technical but historical. In 2009, one option was chosen; in 2022, with the experience of 2009–2022 in hand, the other was chosen.

In chapter three I formulated this as a structural requirement. For cooperation in the network to be sustainable, a win inside the network must not be convertible into the right to change its rules. Bitcoin doesn’t provide this isolation: accumulated hashrate is converted into a share of voice in choosing a block, and through support for this or that client, this or that developer, this or that direction of development — into a share of voice in choosing the future trajectory of the protocol, too. Qubic restores this isolation: one participant — one vote, no accumulation increases his weight in the votes of the current epoch, and the ability to become a participant in the next epoch depends not on accumulated capital but on work performed in the previous one.

At this point it’s worth saying separately that “useful work performed” in Qubic is not the same kind of work as in Bitcoin. In Bitcoin, work is the solution of a meaningless cryptographic puzzle whose only function is to prove that you’ve spent electricity. In Qubic, work is something different. It’s that very “Murdoch’s gas pipe” I promised in earlier chapters. But how it’s built is the topic of the chapters that follow, not this one. Here it’s only important to fix one thing: selection into an epoch happens by a metric tied to a contribution useful to the network, not to an abstract expenditure of resources. A computor that has spent a great deal of electricity on meaningless hashes wins nothing by it in Qubic. It has to perform work the network needs. Exactly which work — we’ll see in chapter eight.

And one more remark before closing this chapter. The whole 676 mechanism we’ve described here is one side of Qubic. The second, no less important — is what counts as “useful work” and how its result reaches the hands of users. 676 computors without useful work are just a distributed counter. Useful work without 676 computors is distributed computation without a guarantee that someone hasn’t substituted the result. Together, they’re what Qubic was conceived for, and it’s their union that makes the network something more than the sum of its parts. But first the frame holding the whole construction had to be described.

### What’s Next

To sum up.

The Qubic network rests on a fixed pool of 676 computers simultaneously playing the roles of observers, verifiers, and voters. Any decision requires the support of at least 451 participants — that’s two-thirds, the mathematically calibrated boundary beyond which the network is resilient to the collusion or failure of a third of its members. Within a single vote, each of the 676 participants is equal to every other; accumulation of resources doesn’t convert into voting power. The unit of time is the tick; in each tick one proposal is considered from one of the 676, rotated deterministically. The unit for refreshing membership is the epoch; once a week part of the membership is replaced, but no more than 225 at a time, which guarantees that any coordinated invasion will take at least four epoch transitions, and the whole of that time the network will be controlled by the prior supermajority.

This construction is the foundation. Everything else rests on it that the remaining chapters of part three will be about: how useful work turns into a defensive structure for the network, and how the token is issued and burned, and how the last remaining point of human governance works — the figure of the Arbitrator, who, by plan, is to disappear on April 13, 2027.

But before talking about what gets built on this foundation, it’s worth closing one question that was left open in this chapter.

We said that once a week part of the computor composition is replaced. That the “bad” yield their seats to the “good,” that no more than 225 out of 676 are replaced at a time. But the transition itself — the very moment when one epoch ends and another begins — has so far been described from the outside, from the standpoint of statistics. Who, exactly, ends up among those leaving, and by what rule? How does the selection happen among the candidates for the open seats? At what point in time does this happen — what if during the transition someone sent a transaction, does it go to the old epoch or the new one? What happens to the unfinished obligations of a departing computor? How does the network manage not to stop in the moment when a quarter of its voting members is changing?

These are questions about time in Qubic. About how the network exists not in a continuous present but is divided into discrete weekly cycles, each of them a small life of its own, with its own birth, development, and end. About the mycelium that regenerates not once a year but every Wednesday evening, and meanwhile keeps living as a whole.

The next chapter is about weeks of epochs.