When the blockchain launched in June, 2018, over 130 people had contributed to the open source-project hosted on GitHub, with over 7,500 commits to the repository.
The final pre-release, Dawn 4.2, was tagged on May 25th, 2018.
The first production release, EOSIO 1.0, was tagged on June 1st, 2018, featuring the bnet plugin which provided a
"beast" P2P protocol based on websockets using multi-threaded networking to achieve nearly 3,996 TPS.
The latest version is v1.7.2, which achieved 9,179 TPS
demonstrated during load testing in the
Future releases will increase throughput, vertically with extensive parallel processing, and horizontally with side-chains and IBC to deliver theoretical million+ TPS throughput.
Disrupting The Status Quo
EOS.IO is designed to disrupt existing centralized, large-scale enterprise technology.
It provides a scalable blockchain platform for a new generation of decentralized applications to disrupt current technology incumbents, including Facebook.
Besides generating $4 billion during a year-long ICO, Block.one announced several venture capital partnerships to help finance their ambitious plans.
July, 16th, 2018: Blockchain platform Block.one is close to announcing a new fundraising round, bringing in Peter Thiel and Chinese billionaire Jihan Wu’s Bitmain Technologies Ltd. as new investors.
June, 1st, 2018: Block.one, publisher of the ground-breaking EOSIO blockchain protocol, and SVK Crypto, an industry-leading, City of London-based investor in blockchain technologies, announced today that they have partnered to launch a new US$50 million fund to accelerate the growth and development of the EOSIO blockchain ecosystem.
April, 6th, 2018: Blockchain veterans Michael Cao and Winnie Liu formed a new US$200 million joint venture fund, EOS Global. EOS Global will make strategic investments in Asia-focused projects utilizing EOSIO, and is the fourth injection of capital through Block.one’s EOS VC initiative which now totals 600m USD.
March, 21st, 2018: FinLab AG, one of the first and largest company builders and investors focused on the FinTech sector in Europe, today announced the signing of a letter of intent regarding the formation and capitalization of a new $100 million (€81 million) fund managed by FinLab, that will make strategic US$100m investment throughout Europe in projects that utilize the EOSIO open-sourced blockchain software.
January, 23rd, 2018: Block.one, the developer behind the leading blockchain software EOSIO, and Galaxy Digital LP (“Galaxy Digital”), a full service, digital assets merchant bank, today announced the formation and capitalization of a joint venture that is focused on developing the EOSIO ecosystem and making strategic investments in projects that utilize EOSIO blockchain software. As part of the new relationship, Block.one and Galaxy Digital will deploy capital for future investments through the capitalization of a new US$325 million EOSIO Ecosystem Fund (the “Fund”).
January, 16th, 2018: Block.one today announced with TOMORROW BLOCKCHAIN OPPORTUNITIES (“TomorrowBC”) the creation of a US$50 million fund to exclusively invest in opportunities leveraging EOSIO software. This is the first announcement for Block.one’s EOS VC partnership program to stimulate EOSIO innovation. TomorrowBC aims to invest in trailblazing entrepreneurs and companies looking to shape our future utilizing new technologies, like the EOSIO blockchain open source software.
Block.one has partnered with leading technology hedge fund managers and venture capitalists:
EOS is based on a delegated proof-of-stake architecture (DPOS).
EOS stakeholders have ultimate governance over blockchain production and community standards.
The blockchain is operated by 21 primary block producers distributed throughout the world, chosen by ongoing community voting and rewarded daily using a 1% annual token inflation model.
Primary block producers are determined through a recurring vote tally every 126 seconds.
Stakeholder votes decay over time and need to be re-cast weekly to remain fully counted.
Block producers found to be in violation of community standards can be voted out of the top 21 active producer set.
There are any number of stand-by block producers, currently numbering over 500 registered producers in April, 2019.
Stand-by block producers that garner more than 0.5% of total stakeholder vote are also rewarded using a graduated scale.
As of April, 2019, there are 62 paid stand-by block producers in positions 22 through 84.
Dan Larimer's experience with prior DPOS blockchain projects has identified a "sweet spot" of 21 active block producers.
There are three fundamental design levers available for blockchain architects to choose from, but they can only pick two: security, performance or decentalization.
Security is mandatory, but all blockchains next face a trade-off between transaction performance and decentralization.
Greater decentralization provides higher trust but leads to propagation delays and longer transactions that result in unaceptable user experiences in most commercial applications.
EOS.IO ecosystem highlights:
Open source blockchain, APIs, tools and libraries
Delegated proof-of-stake block production (no mining or pool cartels)
Ricardian contracts enforceable through arbitration
Fast transactions (500 milliseconds) for responsive applications and good user experience
No user transaction fees (no gas)
Powerful account permissions
Horizontal scaling via Inter-Blockchain Communication (IBC)
Side Chains (in development)
Vertical scaling using parallel execution across multiple CPU cores/threads
Virtual (paginated) resources for cost-efficient, scalable applications using LiquidApps infrastructure
Flexible mainnet upgrades and patches without forking
Open-source development API using C++ with Web Assembly, battle-tested and performant
Airdrop and airgrab token distribution
Passive income generation through system layer token leasing using the Resource EXchange (REX)
Passive income generation via token leasing using the Chintai
Like any operating system, EOS.IO manages blockchain operations, including computing resources (CPU time, RAM storage and Newtork bandwidth), user accounts, authentication, smart contract execution and persistence using memory-mapped object/document database (MongoDB).
The use of memory-mapped persistence via MongoDB is a key design decision that enables high transaction throughput.
Sub-second performance is attainable because contracts (applications) use data/structures allocated in resident RAM.
In effect, users of distributed EOS.IO applications access data cached in memory for super-fast access-- not in slower secondary/drive array storage.
Significantly boosting RAM scalability and lowering the cost of running EOS.IO applications,
recently (January, 2019) introduced vRAM, a contract-layer implementation of virtual disk storage using
vRAM allows applications to swap inactive data out of scarce/costly physical RAM into slower secondary (SSD/disk) storage;
when users reconnect to the EOS main network, inactive data in vRAM is swapped back into physical RAM.
Ledger Capital has written a good overview.
EOS Germany has also created an objective SWOT (Strengths, Weknesses, Opportunities, Threats) analysis.
Aurora EOS has written a Medium article that provides a good overview of Inter-Blockchain Communication (IBC).
Once implemented, side chains will deliver significantly higher throughput within a given EOS.IO main network.
Side chains will likely be used to partition application load (CPU, bandwidth resources) on separate, dedicated hardware, with side chains focusing on various business sectors, including gaming, retail, social media, travel, real estate, etc.
Conceptually, an EOS.IO main network hosts multiple side chains using IBC to coordinate activity between them, periodically (approximately once per second) synchronizing summary transactions with the EOS main network.
Each side chain is a separate, tightly integrated EOS.IO block chain, a sort of virtual chain running at full speed.
For example, a single v1.5.3 EOS.IO main network operates at 4,000 transactions per second; a huge main network with 1,000 side chains would peak at 4 million transactions per second.
A sister chain is a fully discrete EOS.IO main network that uses IBC to integrate with the EOS main network.
Sister chains allow the entire EOS.IO ecosystem to horizontally scale in a massive way.
Even with repeated performance gains in each new release Block.one delivers, even with a thousand side chains running within a single, huge main network, it's unlikely to scale high enough to support thousands of applications, each having a large base of active users.
Sister chains will likely arise out of differences of opinion regarding chain governance.
Sister chains allow chain experimentation with various constiutional and other fundamental chain structures.
Besides scale and governance, sister chains are also needed to provide the EOS main network cover from regulation and other entanglements.
For example, the Worbli sister chain is designed to support financial institutions and applications, markets that require strict adherence to many complicated guidelines and regulations.
Worbli requires more flexibility to integrate tightly with the regulatory environment, including international banking standards.
A private network is a totally independent EOS.IO main network that does not integrate with the EOS main network.
A private main network uses IBC to integrate with its private side chains; for greater scale, IBC could also integrate horizontally with other private main networks.
Private chains will probably, ultimately outnumber all other chain types combined.
Corporations and other institutions will likely stand up private EOS.IO main networks, some likely firewalled and not even reachable on the Internet.
For example, Platio is a
Smart Banking Ecosystem
built entirely using a private EOS.IO main network tailored for its brokerage/escrow products and services.
Inter-Blockchain Communication (IBC)
EOS.IO has been designed from the start to support IBC for extremely high scalability.
Inter-Blockchain Communication (IBC) is lightweight client, probably managed by a system smart contract, that integrates transactions between multiple side chains running within a given EOS.IO main network, and also integrates EOS.IO sister chain transactions with the EOS main network.
IBC coordinates and confirms transaction existence, sequence and irreversibility confirmations between chains.
Fast (0.5 second) transactions within a 21 active node design greatly reduces latency between nodes, providing rapid irreversibility even across multiple side chains or main networks.
Each chain's light client would interact with IBC multisig accounts, sending each other transaction status confirmations (existence, irreversibility) to obtain proof that a transaction happened so further action (release the side-chain tokens, for example) can take place.
For example, a given user (account) running on the EOS main network sends EOS to an IBC multisig account destined for another account located on a sister or side chain.
Proof is sent to the sister/side chain confirming a transfer transaction actually happened, and eventually completed (irreversible).
The sister/side chain confirms proof was received and then releases tokens to the desitination user/account in the sister/side chain.
If the token release is successful, the sister/side chain sends confirmation; if the tokens could not be released, the main network is notified and returns the EOS back to the sending user's account.
For more, please review Dan Larimer's IBC Steemit article.
Consult Enabling Blockchain Innovations with Pegged Sidechains for a good paper on side chain design.
IBC will horizontally scale the entire EOS.IO ecosystem with theoretical million+ TPS throughput.
This protocol is essential to grow the ecosystem to the point where it supports numerous large-scale applications with millions of users.
New sister chains are appearing at a rate of one per month, and the growth rate is likely to rise.
Although Block.one is not actively implementing IBC right now (January, 2019), it's just a matter of time: IBC will eventually become an absolute necessity.
Even though the latest 1.6 EOS.IO software nearly doubled TPS performance (over 9,000 TPS) in testnet, throughput must increase by orders of magnitude to handle future resource demands.
That question is ringing out in a chorus across the cryptoverse.
For example, Lisk stakeholders have been waiting years for side chain support.
We all know how long BTC and ETH fan boys have been waiting to scale.
Block.one is focusing hard on its applications, not multi-threading or IBC at the system layer for true side chains.
The need-for-speed-to-market with applications is taking precedence over pushing vertical and horizontal scaling.
With $4 billion in cash, Block.one can afford to do both in parallel, but have chosen not to attempt it.
EOS.IO github commit history shows a huge drop-off in committers/commit activity after genesis in June, 2018.
Clearly, Block.one moved most of their software development velocity to other private code repositories, which one can easily surmise is the shift in focus to application development.
Moreover, since the June launch Block.one development staff/capacity has tripled--
based on bytemaster's past statements related to challenges ramping up new developers, and his recent public statements about having over 100 developers on the payroll now.
Despite this spike in developer capacity, the commit velocity for the EOS.IO repository continues to slow each month since launch.
Because CPU resources have already been stressed in the present single-threaded EOS software by a wave of gaming and gambling applications,
there are indications that B1 may deploy their upcoming applications on a new,
dedicated sister chain, following the path already taken by a few applications that have isolated themselves--
not on the EOS mainnet. If this is true, it really highlights the need to implement multi-threading and side-chain IBC sooner than later.
With this present course at Block.one, prepare for many single-threaded EOS 1.x sister-chains, too many to follow, along with many alternative IBC implementations.
These recent sister chains and their efforts to produce various forms of IBC can be viewed as a practical outcome of not having real side-chain IBC already in place.
Building these stop-gap measures could make matters worse, buying a little more time before needing side chains in the system layer.
Given side chain complexities there is no other entity willing/able to implement this critical software.
As of January, 2019, launching sister chains is the only approach available to scale.
EOS will grow despite its present architecture, but not as fast compared to an EOS ecosystem with many side chains scaling high on hundres of multi-core servers.
Regarding parallelism, Block.one is gradually implementing multi-threading in more core areas/
Side chain support introduces complexities that may require a port/migration of existing applications already built on the present v1 architecture.
Establishing a new account involves picking a 12-character account name, generating and assigning public/private keys, and purchasing a minimal amount of EOS to establish approximately 3KB of RAM storage.
Creating a new account isn't free, but the cost of entry is minimal, fluctuating with the RAM market price.
Establishing a new account usually requiress less than $1 USD.
For more information about account creation cost, please read this Medium article
by EOS New York.
Every new account requires specifying a unique public and private key pair.
There are several tools available to generate a unique public/private key pair.
Use Scatter to generate a public/private key pair during account creation.
Alternativley, use the latest version of Greymass when generating key pairs,
since Greymass provides safe offline (cold storage mode) key generation.
In the EOS.IO ecosystem, account ownership is determined/proven by knowing the private key, therefore:
It is CRITICAL to ALWAYS keep your private key PRIVATE and SECURE
Store your private key SECURELY using an encrypted disk, USB or some other form of cold storage, preferably saving two copies in two physically separate, secure locations
NEVER expose your private key
NEVER provide it to ANY website
NEVER reveal your private key to ANYONE, ANYWHERE, using ANY MEDIUM, AT ANY TIME
The only exception being when establishing/configuring a wallet for the new account
Be EXTREMELY careful when chosing a wallet; stick with established hardware or desktop wallets, including
EOS Voter (Greymass) and
There are several good tools available to create an account, including:
A Bit of History: ICO Account Registration Before Genesis
Block.one initiated their ICO on June 26, 2017.
The ICO ended nearly a year later on June 2, 2018 at 22:59:59 UTC, when tokens were frozen on the Ethereum blockchain during preparation for the EOS mainnet launch.
The ICO utilized an ERC20 token contract running in the Ethereum blockchain.
The ERC20 distribution totaled 900 million tokens over a 341-day offering, 2 million tokens every 23 hours, with Block.one reserving 10% of the distribution.
Besides directly participating in the ICO, tokens could also be purchased indirectly on several exchanges, including Kraken and Binance.
All Registered ERC20 tokens were converted to EOS tokens in a genesis snapshot taken during the launch.
During the ICO, Block.one recommended either of two Ethereum wallets to store EOS ERC20 tokens: MetaMask or MyEtherWallet (MEW).
Wallets were required to be registered with
eos.io prior to launch.
It's important to emphasize the wallet itself must be registered, not the individual ERC20 tokens stored therein.
The registration process using MetaMask is relatively straightforward.
However, people in the United States and China were restricted from participating in the ICO due to protective legal measures taken by Block.one to avoid EOS being considered a security by regulators,
complicating the registration process. Workarounds included using a virtual private network (VPN) product like CyberGhost during the eos.io registration process, selecting a VPN server located in Canada or another supported country to mask the browser location.
Alternatively, some exchanges (Binance,
and Kraken) announced registration support for customers who purchase and hold EOS ERC20 tokens.
After completing EOS registration of the Ethereum wallet, token holders could visit
EOS Authority to confirm whether the wallet is registered properly for the EOS genesis snapshot.
There is a recovery option after launch for those who do not register.
An EOS contract named eosio.unregd tracked unregistered ERC20 balances identified during the genesis snapshot at launch,
allowing owners of unregistered ERC20 tokens to prove ownership and claim their tokens.
Ethereum public addresses can be converted into EOS public addresses without registering.
Scatter announced support for converting ERC20 wallet private keys to EOS private keys within its wallet.
This ecosystem diagram focuses on the token lifecycle.
Requirements around account names and namespacing are presented in GitHub issue #3189.
Community benefit projects are migrating to a worker proposal system, tracked by issue #1005.
Acknowledgement to RiverKingfisher for providing many refinements:
EOS DApps require CPU cycles, network bandwidth and physical RAM to run.
CPU cycles and bandwidth are in relatively abundant supply at reasonable prices.
RAM is in relatively short supply and rather pricey.
Staking EOS tokens automatically reserves a proportional amount of CPU and bandwidth, since these resources are plentiful.
However, RAM is treated separately due its scarceness.
Automatically reserving RAM would unnecessarily lock up a limited resource, since most users don't need to reserve RAM.
Developers who want to run applications need RAM and must use it efficiently in their code.
To avoid hording and excessive speculation, RAM supply will be initially limited and gradually increased as more applications are released in the community.
RAM must be explicitly purchased with a 0.5% transaction fee, with the same fee applied whenever RAM is eventually sold/released.
Block Producer Selection Criteria
After careful consideration, Sonata Systems has established the following block producer (BP) selection criteria:
No mining pool affiliation
No exchange affiliation
No operation, ownership or investment in more than one block producer
No collusion or cartel-forming activities (vote buying, exclusive voting)
No production in unstable or authoritarian geopolitical locations
Favor broadly distributed production located around the globe
Favor independent, self-funded block producers
Favor transparently operated block producers
Favor bare metal block production architecture
Favor producers with 7x24 support
Favor block producers making significant technical contributions
Favor block producers performing significant community outreach
Favor founding producers who adopted EOS early and participated in its genesis
Favor production in jurisdictions that protect individual liberty and support free enterprise
A Bit of History: BP Structure/Compensation
EOS Dawn 4.0 (pre-release) established 21 active block producers and any number of standby producers.
In order to receive rewards, block producers must receive at least 0.5% of the total stakeholder vote.
Producers with vote tallies below this threshold receive nothing.
Each block producer claims their share of the per-vote reward once per day.
The top 21 active block producers earn a 0.25% per block reward on a pro-rata basis on the number of blocks each BP produces.
All active and standy block producers earn a .75% per-vote reward on a pro-rata basis on the total number votes received.
EOS uses delegated proof-of-stake (DPOS), so stakeholder diversity and voter participation is critical to avoid block production collusion that results in cartels which threaten ecosystem stability.
DPOS is a double-edged sword.
EOS stakeholders elect 21 active block producers.
Limiting production to 21 nodes brings many advantages, including a very low-latency platform for highly responsive DApps.
However, 21 is a temptingly small number of entities to corrupt, inherently susceptible to collusion.
Moreover, a quorum of 15 block producers in agreement results in complete control over blockchain operation.
For the ecosystem to thrive long-term, stakeholders must vote carefully and frequently to establish a widely distributed, independent set of block producers that are technically solid, ethically sound, with independent and transparent operations in stable, non-authoritarian jurisdictions.
Whales And Cartels
Avoid voting for whales.
Be especially wary of block producers closely associated with whales, with votes originating fromy a small number of very large whale accounts.
Avoid organizations that fund a cabal of block producers, including exchanges, mining pools and venture capital organizations.
Avoid producers that are also coin exchanges, including producers associated with (partial or full ownership) exchanges, including Eossey Hanbitco, EOS JRR (shared funding source with Binance) and Bitfinex.
Avoid producers backed by mining pool cartels, including Bitmain Antpool, Huobi Mining Pool, eos.fish (backed by F2Pool) and viaEOS.
INBlockchain is a whale actively funding a cartel of block producers, including EOS Mao Lao, OracleChain, EOS Gravity and eosONO.
Recommended Block Producers
A majority of the recommended block producers shown below use bare metal infrastructure to produce blocks.
Most cloud/hybrid producers listed here have plans to migrate into a bare metal environment.
It is important to vote for 30 quality block producers, not just a few.
Based on this analysis, please consider voting for the following block producers shown in no particular order.
Referendum voting is now live on the EOS mainnet.
The EOS Referendum contract was finally deployed on January 10th, 2019.
A quorum of active block producers (15) approved deployment of the referendum smart contract created by EOS Canada in the eosio.forum system account.
For more information please refer to the launch article on Medium.
A Bit of History
Keep in mind that Dan Larimer asserted at launch in June, 2018, that the initial, hastily produced constitution would likely be eventually replaced by a referendum contract.
Seven months later, the newly deployed EOS Referendum Contract begins to fulfill Larimer's prediction.
Two Categories: Poll and Binding Referendum
Realize that you will be voting mostly for non-binding polls and fewer binding referendums.
Binding referendums are normally preceeded by exploratory polling.
Creating a valid binding referendum requires major effort; a referendum must be clearly defined, feasible to implement and deployable onto the mainnet; code modifications must be provided and reviewed whenever EOS system and/or contract code changes are involved.
Approved referendums still require approval by 15 active block producers before it can be deployed onto the mainnet.
Practicle Voting Advice
Active, knowledgable voter participation is critical to ensure the EOS ecosystem flourishes
Carefully review each referendum prior to casting a vote; reach out for clarification whenever necessary
Referendums exist until they pass or expire after 120 days
Passage requires favorable votes from at least 15% (150 million) of all staked tokens, and yes-votes must exceed no-votes by at least 10% for 30 consecutive days
This is an intentionally high bar for passage, ensuring only solid proposals with sustained favorable concensus are accepted
Referendum vote tallies are updated every 10 minutes
Only staked EOS is voted (not liquid tokens)
Your vote is anonymous
Votes do not decay; you do not have to re-cast your vote unless you want to change your vote
You must keep your tokens staked until the referendum you voted has ended
Since the act of voting consumes account RAM (approximately 0.42 KB per vote), so consider purchasing more RAM (approximately 0.25 EOS) before voting for/against several referendums, especially if RAM utilization is high (90% or higher)
Your RAM vote-related resources will be released after the referendum has passed or expired
Voting Directly or By Proxy
Stakeholders can vote directly or rely on their chosen proxy to vote their stake.
It is important to note that direct stakehoder voting takes precedence over proxy voting.
For example, assuming you've chosen Sonata Systems Voter Proxy, if you agree with the proxy vote on all but one referendum, place one vote directly from your account on the single referendum you differ with the proxy on; your direct vote takes precedence.
Creating and Submitting Referendums
For detailed information on the referendum submittal process, please review the EOS BallotCraft Guide created by the BallotCraft Working Group.
the EOS BallotCraft Guide PDF.
Consider using Bloks when creating referendums; it relies on Scatter for transaction signatures.
Creating a referendum will consume a significant chunk of RAM, so consider purchasing more RAM (approximately 1 EOS) before creating a handful of new referendums.
Your RAM referendum-related resources will be released after the referendum passes or expires.
Should EOS tokens sent to eosio.ramfee and eosio.names accounts in the future be allocated to REX? (ID: rex4all)
Note: REX deploys when Block.one releases it, requiring 15 BPs to launch on mainnet; a referendum is not required to activate REX. The referendum is needed only to redirect collected name auction and RAM fees into REX.
Should EOS adopt the EOS Community Constitution (ECC) in place of the interim Constitution? (ID: ecc)
Should EOS adopt the EOS User Agreement (EUA) in place of the interim Constitution? (ID: eosuseragree)
Note: Lacks BP standards and regproducer enforcement, an important element for any responsible agreement to help avoid harmful BP cartels/collusion.
Should EOS establish a voluntary, non-inflationary, commons fund for EOS core development through a bidding system built on top of eosio.token smart contract? (ID: tokenauction)
Note: Medium article by referendum author, EOS New York YES
Reduce the annual rate of inflation to 1% (ID: inflation)
Delete Eos Core Arbitration Forum? (ID: decaf)
Should we burn accumulated un-used inflation (4%) in eosio.saving? (ID: burnsaving)
Deploying REX with system funds, including inflation (excluding BP rewards) (ID: rexwithinfla)
Reduce the number of BPs to 10 and paid SP to 5 (ID: geteos)
Should the voting weight be changed to 1 Token 1 Vote? (ID: 1token1vote)
Remove vote decay for proxy if proxy votes regularly (ID: proxydecay)
Spread out WPS tokens evenly to everyone. (ID: fundeveryone)
Inflation model update to 3% year inflation (ID: eosinflation)
Voting: An Essential Responsibility
Referendum and block producer voting is an ongoing, critical stakeholder responsibility.
Remember to re-evaluate and cast your block producer votes on a regular basis, since block producer voting strength begins to decay after one week.
Please consider using the Sonata Systems Voter Proxy if referendum research and block producer evaluation is too onerous.
EOS Titan provides a very helpful voting analysis tool that ranks BPs and reveals major stakeholder voting:
EOSeoul is monitoring the vote and the mainnet with EOStat, which includes a web voting portal:
Informed voting requires careful block producer reasearch and active ecosystem monitoring, a signifcant amount of ongoing work.
Alternatively, selecting and voting by proxy is comparitvely easy.
Instead of indiviually researching and selecting thirty block producers, stakeholders can research a handful of vote proxies, then choose and designate a single vote proxy account with their account to make subsequent voting quick and simple.
Considerable research is required to select a proxy that best matches individual stakeholder voting preferences.
For more information about proxy voting, refer to this Medium article by Blockgenic.
For an ongoing discussion about proxies, join the EOS Voter Proxies channel on Telegram.
To set a vote proxy in the Greymass wallet, simply press the "Set Voter Proxy" button and enter the proxy account name you want to use.
Thereafter, the proxy will be used whenever you decide to vote your staked EOS.
You can remove the vote proxy whenever you want to, if you decide to manually vote for block producers yourself.
Please remember to refresh your vote regularly, since voting strength decays rather rapidly; voting every week ensures zero decay.
The mainnet is now fully operational, launched on Sunday, June 10th, 2018 at 1300 UTC (9AM EST).
ERC20 tokens became non-transferable on Friday, June 1st, 2018 at 22:59:59 UTC when the ICO ended.
Exchanges began locking down EOS ERC20 token deposits and withdrawals two days before launch.
The window for wallet registration expired on June 2, 2018 22:59:59 UTC when tokens were frozen on the Ethereum blockchain.
The mainnet launch sequence began with a genesis snapshot of all registered ERC20 tokens less than an hour after the freeze on Saturday, June 2nd, 2018 at 10:00:00 AM UTC.
First, several block producers will generate and validate their seed-token genesis files and arrive at a concensus file to boot from.
This JSON file maps EOS wallets created during registration to associated Ethereum wallets storing ERC20 token balances.
Two block producer launch groups have formed using differing bootstrap approaches, which is to be expected when standing up such a large distributed platform.
One appointed block producer (chosen from 11 candidates) will seed the mainchain, with other block producers validating and subsequently meshing in.
Finally, after the mainnet is validated it will be opened up to stakeholders to begin the block producer voting process.
Before any blockchain can actually become fully operational, EOS core requires stakeholder approval representing at least 15% of the issued and outstanding EOS tokens.
More than one mainnet may arise during launch.
More than one chain may attain 15% voter endorsement, enabling the token snapshot and most functionality.
Eventual consolidation down to a single mainnet is the prevalent expectation, possibly during launch day or soon thereafter.
At some poiont, block.one will vote their 10% stake which should result in consensus on a single chain.
Thomas Cox has written about his launch expectations on Medium,
asserting it will be difficult for even two blockchains to garner 15% of the stakeholder vote.
It's reasonable to surmise there will be at most two competing chains on launch day.
Chances for one mainnet have improved given recent improvement in communication between the block producer bootstrapping camps.
As the flowchart above depicts (courtesey of EOS Tribe), Dan Larimer's third crypto-child is going through a launch gauntlet.
June 4th: Block producers have been working extremely hard for two days straight, many are pushing themselves beyond exhaustion.
The snapshot is good. Many block producer teams seem fully capable of standing up testnets rather quickly.
Efforts are centered on testing the blockchain itself and its numerous life cycles (un-staking tokens, voting, auctions, etc.), and also evaluating network security with attack/penetration testing.
Half a dozen or more tools/scripts are being utilized for this testing.
The work is time-consuming to perform and difficult to coordinate across a multitude of BP teams, with participants distributed around the world in numerous time zones, speaking various languages, etc.
There is still noticeable dissension with the usual political maneuvering when money/power is up for grabs, which doesn't help the velocity.
Essentially, Dan's software, the network infrastructure and each BP team are all being set through their paces.
June 6th: Block producer candidates have been testing the security infrastructure and blockchain functionality for 4 days.
A large group of BPs in China announced the start of an independent audit to review the entire project (network, server configuration and EOS.IO source code).
Two outside auditing firms were hired in China to perform the work:
SlowMist and Joinsec.
Several BPs in China originally requested 7 days for the audit, but soon lowered the request to 2 days with a status provided each day.
China obviously has considerable influence (with 500 million stakeholder tokens, according to EOS Silicon Valley) and several BPs there do not want to rush into a launch.
The earliest launch date appears at this point to be Friday, June 6th, unless testing/auditing identifies critical issues (identified as P0 or P1) that need to be fixed and then revalidated.
June 7th: Block producer candidates have been testing the security infrastructure and blockchain functionality for 5 days.
The 0100 UTC go/no-go meeting was extremely long, disorganized and therefore chaotic.
Lingering disagreements were the rule, including how to fund RAM for accounts at inception and the severity of a few other issues.
The ongoing independent audit in China had not produced any P0/P1 issue.
The first vote met the two-thirds + 1 requirement for a launch.
However, disorganization pervaded the meeting, especially over voting procedures, which resulted in a second round of go/no-go voting.
Prior to the second vote, Dan Larimer joined the meeting to discuss the issues, an upcoming 1.0.2 patch (bi-weekly recurring patch cadence) and to take questions; he clearly indicated there were no show-stopper issues, no P0/P1 issues.
According to Larimer, the highest unrecovarable risk is private key loss at inception, with most of that risk existing in external browser-based wallets and voting portals, not in the core chain itself.
Thereafter, a second round of voting resulted in less support for going live, not enough votes to meet the two-thirds + 1 threshold.
The aftermath was continued frustration for the majority of block producers who voted in favor of launching, along with increasing stakeholder dissaproval, especially given the zero-show stopper feedback provided by Dan Larimer, which a significant number of block producers in the minority chose to disregard by voting no.
June 8th: Block producer candidates have been testing the security infrastructure and blockchain functionality for 6 days.
Unlike prior meetings, this 0100 UTC go/no-go meeting was streamed live on YouTube.
Unlike the prior meeting on June 7th, this meeting was brief and appeared to be a formality with no discussion over recurring disagreements.
The single round of voting resulted in unanimous approval to launch.
An appointed block producer (ABP) is preparing the genesis snapshot and EOSIO 1.0.2 for launch.
On Saturday, June 9th at 1300 UTC, 10 additional seed nodes will begin to mesh with the ABP.
On Sunday, June 10th at 1300 UTC, the live chain will be announced and BP voting commences.
Thereafter, EOS becomes fully operational whenever the mainchain gathers 15% voter approval, a threshold that will likely be crossed rather quickly.
June 9th: The independent audit report was released in public form on June 9th, 2018:
The EOS mainnet went live on Sunday, June 10th, 2018 at 1300 UTC (9AM EST).
Voting commenced immediately with EOSphere,
EOS New York and EOS Authority tracking the vote tally.
EOS stakeholders voted past the 15% minimum threshold (150 million tokens, 15% of the total distribution) and unlocked the mainnet on Thursday, June 14th.
EOS Authority processed the genesis snapshot.
For those who were not able to register before the ERC20 freeze (3,301,220.3641 tokens), EOS LaoMao created a script and validated all of the unregistered EOS holders and their balances.
Block.one and several exchanges represent the top-10 accounts, holding nearly half the total distribution.
Besides the 10% stake held by EOS.IO, other top accounts are exchanges with token counts that represent an aggregation of many individual customer accounts.
The overall distribution is concentrated at the top: 90% of all tokens are held by 1.6% of the accounts.
Top 10 Holders: 20,675,047
Top 100 Holders: 646,595
Top 1,000 Holders: 42,941
Top 10,000 Holders: 3,312
Top 100,000 Holders (of 169,930 accounts): 55
Top 10 holds 496,735,539 Tokens or 49.67% of the total 1 billion ICO distribution
Top 100 holds 748,176,831 Tokens or 74.82% of the total tokens
Top 1,000 holds 858,120,383 Tokens or 85.81% of the total tokens
Remaining accounts (1,001 through 163,930) hold a total of 138,570,296 Tokens, 13.86% of the total distribution
Ignoring 10% Block.One Stake
Top 10 (excluding B1) holds 396,735,539 Tokens or 39.67% of the total tokens
Top 100 (excluding B1) holds 648,176,831 Tokens or 64.82% of the total tokens
Top 1000 (excluding B1) holds 758,120,383 Tokens or 75.81% of the total tokens
Remaining accounts (1,001 through 163,930) hold 138,570,296 or 13.86% of the total distribution
Block.One stake: 100,000,000 tokens (10%)
Top 2 through 1,000 holders have 758,120,383 tokens (75.81%)
Remaining 1,001 though 163,930 holders have 138,570,296 tokens (13.86%)
3,309,321 tokens remain unregistered (0.33%)
Grand Total: 1,000,000,000 EOS Tokens (100%)
Choosing The Right Wallet
Please exercise EXTREME caution when selecting a wallet for your EOS account.
To prove account ownership, you will be required to provide your private active account key during the initial wallet setup process.
WARNING: There have been several Trojan websites and phishing campaigns, fraudulent wallets designed to simply steal your private key and raid your account!
For a good overview of wallet options, please read this Medium article by EOSphere.
First, GreyMass offers a popular desktop wallet packed with many other features, endorsed by Dan Larimer:
Scatter is another essential desktop tool that provides transaction signature, identity and reputation services throughout the EOS ecosystem.
Dan Larimer recently announced a very secure hardware wallet for select Apple devices is being developed at Block.one:
Chintai has already integrated REX into its web application, announcing the alpha release to the Jungle Testnet, including several upcoming enhancements as well:
EOS Cafe Block has written an
excellent overview of this new EOS token rental market which allows stakeholders to earn passive income by delegating bandwith to others.
REX is part of EOS.IO v1.7.2,
a release which includes several performance improvements:
Several of the PRs [GitHub Pull Requests] in this release contribute to the overall goal of increasing the efficiency of the peer-to-peer networking layer and real-time transaction throughput.
Internal benchmarks show considerable increases in token-transfers-per-second as a result.
While this does not represent real-world usage, it does suggest that there will be noticeable improvements to transactions per second, reductions in the billable CPU time for transactions, and lower latency for block propagation.
Already available on the EOS Mainnet, Chintai is another token rental marketplace EOS stakeholders have at their disposal:
Besides basic account information, there is an ongoing need for additional RAM storage.
For example, the persistence of proposed referendums, including each and every vote placed for block producers, polls and referendums.
Note that referendum/voting related RAM resources are eventually released once the poll/referendum expires.
There is a 0.5% fee each time RAM is purchased or sold.
FeeXplorer also tracks RAM prices with a histogram:
RAM Allocation Proposals
During the July 2nd EOS EMLG Meeting,
Dan Larimer discussed various RAM allocation proposals to address increasing RAM costs driven by current RAM speculation.
One key take-away to help govern RAM pricing was the need to slowly introduce new RAM capacity over time instead of dumping large amounts suddenly.
Eyal Herzog published a subsequent analysis that
examined another proposal for a continuous 10% burn rate from the RAM contract to drive prices down.
Larimer has also published his thoughts on the present RAM market on Medium.
Greymass recently proposed the separation of RAM into two separate components: live storage (current) with read-write permission, and persistent, backed-up storage with only activation permission.
Proposal for Partitioned RAM with Tiered Quality-of-Service Costs
Similar to Greymass, this proposal further stratifies storage into four tiers instead of two, with side-chains having a declared storage quality-of-service level and associated relative cost.
Not all applications require sub-second transactions.
Some can work asynchronously and tolerate 2 or 3 second end-user response times.
Some applications are batch-oriented entirely and have long execution windows (minutes, not seconds).
Many applications fall somewhere in between.
EOS uses MongoDB, a memory-mapped file system document database that performs best when everything remains resident (cached) in memory.
MongoDB is flexible enough to support all of these applications.
Whenever RAM runs short as the number of applications and/or user activity grows, MongoDB can swap part of the "working set" of infrequently referenced documents out of memory into SSD/disk storage, which slows performance down noticeably whenever the data in these swapped-out blocks are referenced/needed again.
EOS itself and its RAM marketplace should be equally flexible and support various performance tiers with relative pricing.
RAM could be partitioned in terms of performance, with the highest prices determined by the Bancor marketplace in the top RAM partition that guarantees the contract/app will always remain resident in RAM, assuring fast transactions.
Another leased RAM partition would ensure 66% residency and 33% SSD storage for contracts/apps that don't require sub-second transactions, but response times in a 1-to-3 second window.
A third leased RAM partition would ensure 33% residency and 66% disk storage for contracts/apps that support asynchronous transactions lasting between 3 and 10 seconds.
A fourth partition would not ensure any RAM residency and use cheaper disk/array storage for contracts/apps that process information in the background in "batch" mode.
The lower three RAM partitions would use leasing to allow application developers more choices and lower costs for their particular application.
Note the thresholds/metrics in these tiers are hypothetical; actuals would be based on observed application performance testing/benchmarks.
Once side-chains are supported in EOS,
each side-chain could belong to a tiered service offering that supports a targeted RAM partition with a designated quality-of-service level.
Applications that require high-performance will stake a lot of tokens chains belonging to the top Bancor marketplace tier with 100% RAM residency.
Background/batch applications can be deployed on side-chains configured for the bottom performance tier using significantly fewer tokens.
Many applications will fall somewhere in the middle two tiers.
Side-chains offer the opportunity to stratify service offerings in terms of application performance, which is directly tied to RAM or the lack of residency therein.
Many developers may not be able to afford 30 or 50-MB in the open Bancor marketplace used by the first RAM tier.
Many of these developers won't require sub-second response times, some may need 100-MB or more, and others are dealing with a totally batched design with minutes or hours-long execution windows.
These application domains shouldn't have to pay a premium price for fast transactions when they aren't needed.
Developers will want several storage options priced according to performance characteristics.
EOS applications would be comprised of three main components: Ricardian Contract, Arbitration Specifications and Designated Side-Chain RAM Partitioning:
Partitioning like this seems almost inevitable if true mainstream adoption takes place, as the number and variety of applications and users increase.
CryptoGlobe has reported on the recent
that there are over 260 projects being built on EOS.IO.
As of January, 2019, the EOS ecosystem hosts a growing number of applications accross numerous sectors:
Four months earlier, MEET.ONE updated the growing EOS application landscape:
Six months earlier, soon after EOS launched, EOS Tribe documented
several decentralized applications building on EOS:
For application developers, EOS Authority has produced a video on how to create an EOS airdrop.
Aloha EOS created EOS Block Producer Reliability Tracker, a page that monitors block production performance metrics:
EOS Titans provide a page that summarizes block producer voting patterns:
EOS Nation hosts Block Producer bp.json Validator with endpoint, resource, API version error reports:
Visit the EOS Tracker producer page to determine block producer rankings and payouts:
EOS Titans has released a block producer ranking explorer:
EOS Beijing has created a block producer voting analysis tool:
Note how many of the top ranked producers have a handful of whales voting them into the payout zone.
Some BPs have just 3 or 4 whale accounts voting them into the active producer set.
However, whale support does not equate to block production competency.
Dawn 4.0 established 21 active block producers and any number of standby producers.
In order to receive rewards, block producers must receive at least 0.5% of the total stakeholder vote.
Producers with vote tallies below this threshold receive nothing.
Each block producer claims their share of the per-vote reward once per day.
For more, EOS Canada has provided a block production revenue analysis.
An important GitHub proposal was made recently to add support for
TypeScript software development, using
Binaryen for compilation to
Expanding access into the TypeScript marketplace will significantly increase the rate of new applications for the EOS community.
Less than a year after EOS Mainnet genesis, the initial constitution was replaced by the
EOS User Agreement
(EUA) on April 12th, 2019.
The EOS Authority System Upgrade
web page reports EUA approval by 15 of 21 active block producers, and subsequent EOS Mainnet update.
The EUA referendum
was approved by 99% of EOS stakeholders who participated in the voting process.
However, voter turnout was poor, with only 1.7% of stakeholders actually placing a vote, just 454 accounts from a pool of nearly 1 million accounts.
The initial constitution used a dispute resolution service, EOS Core Arbitration Forum (ECAF).
That organization no longer exists with the ratification of EUA.
ECAF and EOS governance in general has been hamstrung since inception; ultimately, ECAF proved to be controversial, ineffective and universally ignored by active block producers.
Arbitration in the system layer is a dead concept.
Future arbitration will likely be implemented via Ricardian agreements within the application/contract layer.
Arbitration organizations may eventually appear, some specializing in various sectors.
Application providers and users will likely choose from a menu of arbitration options.
Such arbitration would be independent and self-funded with fees collected from the claims process.
A Bit of Arbitration History
For a variety of reasons, on June 26th, 2018, Dan Larimer announced his desire to replace the initial constitution with a more narrowly focused referendum contract at the application level, including a reduction in arbitration scope.
Watch this BP meeting where arbitration is discussed with Dan Larimer.
Just 1.6% of EOS holders own 90% of the tokens. The token ownership, governance, and block producer selection are all compromised by the existence of massive
"whale" addresses that can push EOS in any direction they want without regard to the majority of token holders, developers, or even the overall health of the network.
Telos Whitepaper, July, 12th, 2018
An EOS sister chain, Worbli focuses on providing an EOS.IO platform for financial service and other corporate/commercial applications that require
with Interblockchain, Worbli is on the forefront of implementing an inter-blockchain communication solution.
Please read this Medium article for more information.
BOSCore is an EOS.IO sister chain with a focus on providing users and developers with easier, lower-cost access to blockchain services, a more friendly infrastructure that lowers entry friction for both users and developers.
The BOS Foundation will encourage application development by providing lower-cost token-based mortgage services for DApps in the BOS Network.
For more information, please review the White Paper.
Keeping Your Account Secure
NEVER divulge your private key unless the source asking for your private key is ABSOLUTELY trustworthy!
NEVER agree to sign/confirm transactions unless your are ABSOLUTELY sure what the transaction is about to perform!
When available, move into Ledger, Trezor or the new iOS hard wallet being developed by Block.one
Besides hard wallets, the Greymass desktop wallet is a good choice
Keep your EOS fully staked, providing a 3-day window to detect and react to unauthorized activity (unstaking)
IMMEDIATELY establish a different public/private key pair for your OWNER account permission: NEVER use the same public/private key pair for your ACTIVE permission
If you detect fraudulent account activity (usually an unstake or owner-permission change transaction), use Greymass or Scatter with your OWNER account permission to immediately change your ACTIVE permission public/private key pair, and then re-stake your tokens
Set up free account alerting at EOS Authority for instant notification of all account activity
Install a quality antivirus product (ESET, AVG or McAfee) to detect and block several dangerous phishing websites
Avoid using social media on any hardware that hosts your wallet or any other senstive information-- ALL chat rooms are dangerous-- so limit usage of dangerous applications to hand-held/pad devices containing zero sensitive information
Unless you are ABSOLUTELY sure, avoid clicking on any link-- especially links provided in chat rooms or email
ALWAYS confirm/verify the source before installing any application
Read this helpful guide on keeping your EOS account secure
If your account is hacked and you've lost control (usually, the hacker creates new ACTIVE and OWNER permissions using your stolen ACTIVE permission private key), IMMEDIATELY create an account at EOS Detective to track token transfer activity from your account, usually to one or more accounts at one or more exchanges
IMMEDIATELY contact the exchanges where the stolen funds were transferred to, notify them of the theft from your account, and request them to freeze the account(s) on their exchange containing your stolen tokens
Increase EOS.IO adoption by lowering entry friction
Clarify EOS.IO technology for both existing and prospective stakeholders
Maintain fresh EOS.IO content while the ecosystem rapidly expands
Produce objective content for reference purposes, minimizing editorial, opinionated material
Completely independent and totally focused on maintaining a strong EOS.IO ecosystem
Not sponsored by or colluding with any external entity
Do not accept compensation of any kind from any source related to EOS.IO
Performs empirical EOS.IO research, including testnet, mainnet, GitHub monitoring and active community participation
Maintains fully staked positions in EOS, Telos, Worbli, MEET.ONE and BOSCore main networks
In naval terms, this is Dan Larimer's third and latest crypto-vessel: H.M.S. EOS.
Larimer is putting the ship through its paces, a shakedown cruise to evaluate the mainnet and resolve issues before major applications begin rolling out.
Besides evaluating performance in the field, shakedowns also familiarize the crew (block producers, application developers and stakeholders) with ship operations.
We are witnessing an aggressive trial that relies on the abilities of Block.one and block producers to patch and enhance EOS.IO:
Expect bugs, quick performance gains, ongoing patches, security enhancements and hard wallets to appear near-term.
Thereafter, expect tools for improved stakeholder voting/participation in constitutional ammendments and proposals.
Expect referendum tools and a major constitutional overhaul with arbitration changes that limit or eliminate the ECAF arbitration process.
Expect the arrival of several new applications and faster user/account growth towards the end of the shakedown cruise.