EOS.IO Technical White Paper

The five-minute read

One action, walked through

1. Holders stake tokens and cast votes for producer candidates.
2. The protocol ranks producers. The active schedule of the top set is what signs blocks.
3. Each producer in the schedule has a slot. They broadcast a block, and the next producer builds on it.
4. After enough subsequent producers have acknowledged a block, it is treated as irreversible under the paper's rule.
5. A user action declares which account permission signed it. Resource billing is checked against the stake or the market the implementation uses.

The argument, unpacked

What has to be true

• Token holders vote, and votes are not entirely purchased by the producers being elected.
• The active producer set stays online in rotation. One absent producer is a skipped slot. Many absent producers are a halt.
• Users understand which permission signed. Account recovery and multisig only help if they are configured.
• Resource prices or stake requirements are knowable before a user needs to transact.

What happened after the paper

EOS launched from this paper, saw concentrated producer votes, resource crunches, and later changes including to its resource model and governance. The 2018 paper is the delegated-producer design. It should be read with that record, not as a promise the record automatically fulfilled.

What to check before you use the idea

• How many producers sign blocks, and how concentrated is the vote that elected them?
• After how many subsequent producers is a block irreversible in this implementation?
• What must a user hold or rent before an action is included?
• Which authority can freeze an account, and is that authority in the paper's constitution, the code, or both?

Terms

Block producer

An elected operator scheduled to produce blocks. The active set is small on purpose.

Delegated proof of stake

A system in which token voting appoints the producers, rather than each holder producing with their own weight.

Irreversible block

A block the schedule has acknowledged deeply enough that the protocol tells applications to stop expecting a reversal.

Resource stake

Tokens committed so an account may use CPU, bandwidth or state. It is a ration, not a tip.

The problem the paper names

General-purpose chains that bill every action through a volatile fee market are hard to use as an application host. EOSIO's paper proposes named producers and explicit allocations of CPU, network and state, so an application can reason about resources.

What the design proposes

• Token holders vote for block producers. A small active set produces blocks in a schedule.
• Accounts have permission hierarchies, rather than a single key that can do everything.
• Resources are framed as staking for capacity. That is a product choice with its own failure modes.

How the mechanism is specified

• BFT-style finality among the active producers is the confirmation story, under the assumption that they do not collude past the threshold.
• The paper's 'operating system' language means accounts, permissions and inter-process messages. It does not mean a desktop OS.
• Delegation concentrates power by design. The paper treats voter oversight as the check.

What this page does not treat as proven

• Later events on EOS public networks — governance, resource markets, block-producer politics — are outside the 2018 text.
• A small producer set is easy to name and easy to pressure. The paper does not remove that.
• We do not describe the original token sale. The historic ICO notes on this site are a separate archive.

Why a venture studio still reads it

Read EOSIO when a venture wants 'no user fees' and a permission system that looks like an organisation chart. Then ask who the producers are, how they are removed, and what happens to state when the stake that bought capacity is gone.