| Authors | Block.one |
|---|---|
| Year | 2018 |
| Project | EOS |
| License | MIT |
| Official Source | https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md |
This page is an educational summary and analysis of an official whitepaper or technical paper, written for reference purposes. It is not a verbatim reproduction. CryptoGloss does not claim authorship of the original work. All intellectual property rights remain with the original author(s). The official document is linked above.
“EOS.IO Technical White Paper” (v2, 2018) was published by Block.one, with core technical design attributed to Dan Larimer (creator of BitShares, Steemit, and EOSIO) and implemented with a team led by Brendan Blumer and others at Block.one. The paper describes a Delegated Proof of Stake blockchain optimized for running decentralized applications at scale, with the claim of millions of transactions per second through vertical and horizontal scaling.
EOSIO’s core design choice — zero transaction fees, resource-based access, and 21 elected block producers — represented a sharp departure from both Bitcoin’s energy-heavy mining and Ethereum’s gas fee market.
> PDF hosting: The EOSIO Technical Whitepaper is hosted at GitHub (EOSIO/Documentation) and was released under an MIT license as an open technical document.
Publication and Context
Dan Larimer had built two prior blockchains before EOS: BitShares (2014, a decentralized exchange using DPoS) and Steemit (2016, a social media blockchain). Both used DPoS and were fast but had specific use cases.
EOSIO was Larimer’s attempt at a general-purpose platform. Block.one raised $4.1 billion in a year-long ICO (June 2017–June 2018) — the largest blockchain ICO in history. Despite this fundraise, Block.one deployed relatively little capital toward EOS ecosystem development, which became a major criticism.
Key facts:
- Whitepaper v1: 2017; v2: published 2018
- EOS mainnet launch: June 2018
- Block.one ICO: $4.1B raised over 12 months
- Block time: 0.5 seconds
- Block irreversibility: ~3 minutes (after 2/3 + 1 BP confirmations)
Delegated Proof of Stake (DPoS)
EOSIO’s consensus mechanism is DPoS, inherited from Larimer’s earlier designs:
- 21 block producers (BPs): EOS token holders vote continuously for a set of BPs. The top 21 by vote count are active BPs; the next 101 are “standby” BPs.
- Block production schedule: Each of the 21 active BPs produces 6 blocks in sequence, then passes to the next. A full round takes 63 seconds.
- Block time: 0.5 seconds per block (500ms)
- BP rotation: Standby BPs enter the active set as votes shift. BPs can be voted out instantly if they misbehave.
- Irreversibility: A block becomes irreversible after 2/3 + 1 BPs have confirmed the block at a subsequent height (~15 blocks, ~7.5 seconds in ideal conditions).
The Resource Model: No Transaction Fees
EOSIO eliminated per-transaction fees, replacing them with a resource staking model:
| Resource | Description | Replenishment |
|---|---|---|
| RAM | Storage for account state and contract data; purchased once via bonding curve | Permanent (until sold back) |
| CPU | Computation time measured in microseconds; proportional to staked EOS | Renews daily (3-day average) |
| NET | Bandwidth in bytes; proportional to staked EOS | Renews daily (3-day average) |
The intent: dApp developers stake EOS on behalf of their users, absorbing the resource costs. End users can transact for free. This model was designed to make consumer dApps viable.
The problem in practice: RAM prices became highly speculative (RAM bots bought all RAM at launch, creating artificial scarcity). CPU and NET bandwidth calculations proved complex for developers. The “free transactions” model broke down under high load.
Smart Contracts and WASM
EOSIO smart contracts compile to WebAssembly (WASM) — the same bytecode format used in web browsers. This allows contracts to be written in C++, Rust, or other WASM-targeting languages.
Named accounts: Unlike Ethereum’s hex addresses (0x…), EOSIO has human-readable account names (up to 12 characters from [a-z1-5]). Accounts have a permission system: owner key (recovery), active key (daily use), and custom permission levels.
Multisig by design: The permission system supports threshold multi-signature requirements at the protocol level — no separate smart contract needed.
Sections of the Whitepaper
| Section | Content |
|---|---|
| 1. Background | Blockchain scalability goals |
| 2. Blockchain Applications Requirements | Requirements for dApp-hosting blockchains |
| 3. Consensus Algorithm | DPoS mechanics; producer election |
| 4. Accounts | Named accounts; permission levels; keys |
| 5. Communication | Async cross-contract communication; events |
| 6. Governance | On-chain protocol upgrades; dispute resolution (The Constitution) |
| 7. Scripts & Virtual Machine | WASM execution; contract sandbox |
| 8. Inter-Blockchain Communication | Light client proofs across EOSIO chains |
| 9. Conclusion | Theoretical throughput claims |
Reality Check
EOSIO’s design goals were ambitious, and the claimed “millions of TPS” never materialized. In production, EOS processed thousands of TPS but suffered from:
- RAM speculation: The launch was dominated by RAM bots, not applications
- BP centralization: The 21 BP system was quickly controlled by a small number of Chinese mining pools and block.one-affiliated entities
- Block.one’s inactivity: Despite the $4B raised, Block.one was fined $24M by the SEC in 2019 and deployed relatively little development capital back to EOS
- Governance failure: The “EOS Constitution” governance mechanism was never practically implemented
- EOSIO v2 and abandonment: Block.one ultimately ended support for the EOS network, transferring development to the EOS Network Foundation
EOSIO’s technical design (DPoS, resource model, WASM, named accounts) was genuinely influential and was adopted by several other blockchains (WAX, Telos, Ultra, Antelope).
Legacy
DPoS as a pattern became widely used. WAX (Worldwide Asset eXchange) used EOSIO and became the leading NFT blockchain by transaction count in 2021. The named account + permission system influenced subsequent UX-focused chains. Antelope (formerly Leap) continues EOSIO’s technical lineage.
Related Terms
Research
- Block.one. (2018). EOS.IO Technical White Paper v2. GitHub.
— Primary source. Section 9 (IBC design) and Section 3 (DPoS mechanics) are the most technically substantive.
- Larimer, D. (2014). BitShares. bitsharestalk.org.
— Larimer’s earlier DPoS design; EOS is the evolutionary successor.
- SEC. (2019). SEC Order: Block.one Registration Violations. sec.gov.
— Documents the $24M SEC settlement; relevant context for evaluating EOSIO’s development trajectory.