As of June, 2018, over 130 people have 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.6.0, 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 the 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).
A concensus of EOS stakholders with governance rights endorse a blockchain constitution that establishes community standards, including an arbitration process when disputes arise.
The blockchain is supported 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.
Votes decay over time and need to be re-cast weekly to remain fully counted.
Block producers found to be in violation of the constitution can be voted out of the active producer set.
There can be any number of stand-by block producers, currently numbering over 400 registered producers in October, 2018.
Stand-by block producers that garner more than 0.5% of total stakeholder vote are also rewarded using a graduated scale.
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, but blockchain architects 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 many commercial applications.
The EOS.IO infrastructure includes:
Delegated proof-of-stake block production (no mining or pool cartels)
Like any operating system, EOS.IO provides and manages blockchain resources, including 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 allows for very fast EOS transactions.
Sub-second performance is attainable because the data/structures allocated in EOS (including the contracts/apps running therein) are actually held resident in RAM.
In effect, data is cached in memory for super-fast access-- not in slower SSD storage or even slower hard 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) by business sector, 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.
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 multiple half-baked (slow), pseudo IBC implementations.
These recent sister chains and their efforts to produce a crude/slow form of IBC can be viewed as a practical outcome of not having real side-chain IBC in place.
Unfortunately, building these stop-gap measures makes matters worse, buying a little more time while allowing B1 to delay even further the real work of adding side chains and IBC in the system layer.
Given its complexities and the present low EOS token price, there is no other entity willing/able to implement this critical software.
As of January, 2019, launching multiple sister chains is the only crude approach available to scale.
History is repeating with another series of cloned/forked blockchains named after various metals like eosGold, eosSilver, eosBronze...eosZinc.
Regardless, EOS will grow despite the presently hamstrung architecture, but not as fast compared to an EOS ecosystem with fewer sister chains and a lot more side chains scaling high on a multi-threaded core.
Regarding parallelism, whenever Block.one finally begins to implement multi-threading and side chains, will that require a major port/migration of the growing stack of existing applications being built on this single-threaded v1 architecture?
Will Block.one have to rewrite their applications whenever they eventually decide to implement IBC?
Usually, applications written for a platform and API designed to run in a single-threaded architecture are significantly different than the same application written for a highly parallel, distributed platform.
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 bare metal block production architecture
Favor transparently operated block producers
Favor producers with 7x24 support
Favor block producers making significant technical contributions
Favor block producers performing significant community outreach
Favor founding producers that adopted EOS early and participated in its genesis
Favor production in jurisdictions that protect individual liberty and support free enterprise
The top 21 active block producers will earn a 0.25% per block reward on a pro-rata basis to the number of blocks each one produces.
All block producers (active + standby) will also earn a .75% per vote reward on a pro-rata basis to the total number of votes they receive.
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, having votes made by a small number of very large accounts.
Avoid organizations that fund a cabal of block producers, exchanges, mining pools and venture funding organizations.
Avoid producers that are also coin exchanges, including producers associated (partial or full ownership) with 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)
YES Note: REX will be deployed once Block.one releases it, requiring 15 BPs to agree on its deployment. A referendum is not required to activate REX. The referendum is needed only to redirect collected name auction and RAM fees into REX.
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)
Let's get the exchange to develop a voting tool (ID: kiliman)
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 (every 2 to 4 weeks), since voting strength decays rather rapidly.
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:
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.
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.
Dispute resolution and the EOS Core Arbitration Forum (ECAF) are in their infancy.
As EOS New York stated, arbitration and governance processes/tools are work in-progress.
Initially, ECAF is the only hamstrung option available and it will evolve over time:
Once referendum voting is in place ECAF may even be replaced entirely.
More arbitration options in the contract layer are likely, not necessarily in the system layer.
Just as an appointed block producer was chosen to bootstrap the blockchain, arbitrators involved in ECAF have been similarly appointed.
EOS did not launch with a full suite of community tools; it will take time to stand everything up.
ECAF is just the initial/default arbitration service.
Additional arbitration organizations will appear, some specializing in various sectors, and stakeholders will be able to choose from a menu of arbitration options.
Arbitration services/choices are established within contracts.
Arbitration will be independent and self-funded with fees collected from the claims process.
Future community arbitration enhancements will allow stakeholders to discuss arbitration cases, nominate and vote for arbitrators.
Watch this BP meeting where arbitration is discussed with Dan Larimer.
For a variety of reasons, on June 26th, 2018, Dan Larimer announced his desire to replace the present constitution with a more narrowly focused referendum contract at the application level, including a reduction in arbitration scope.
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.
NEVER divulge private keys unless the source is ABSOLUTELY trustworthy!
When available, move into Ledger, Trezor or the new iOS hard wallet being developed by Block.one
Until hard wallets are available, stick with the Greymass wallet and Scatter for transaction signing
Use a different public/private key pair for your OWNER account permission, not the same public/private key pair for your ACTIVE permission
Keep EOS staked which provides a 3-day window to detect and react to unauthorized activity
Use a quality antivirus product (ESET, AVG or McAfee) to detect and block several dangerous phishing websites
Avoid using social media-- chat rooms are dangerous-- or limit usage to your phone or pad
Read this helpful guide to keeping your EOS account secure
Set up account alerting at EOS Authority for instant notification of account activity
Help increase EOS.IO adoption by lowering entry friction
Help clarify EOS.IO mysteries and reduce its complexities for both existing and prospective stakeholders
Maintain fresh EOS.IO content while the ecosystem rapidly expands
Keep site content objective for reference purposes, minimizing editorial, opinionated material-- except for our BP evaluation/selection proxy and referendum voting record
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 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 affect/limit the current ECAF arbitration process.
Expect the arrival of several new applications and faster user/account growth towards the end of the shakedown cruise.
Expect the arrival of new sister chains based on EOS, including Worbli and Telos.
Major blockchain performance enhancements for higher scale will likely appear after the cuise ends.
This maiden voyage is a high-risk, high-reward strategy in preparation for upcoming applications, higher loads and community tools.
Timing is critical to foster developer adoption and establish a strong foundation of new blockchain applications.
Put your life vest on (secure your private keys) and prepare for heavy seas.
Participate fully and do your best to bolster the EOS.IO ecosystem!