EOSIO Architecture EOS centers on a delegated proof-of-stake concensus algorithm (



As of June, 2019, there were over 70 paid stand-by block producers in positions 22 through 71. 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.



EOSIO Infrastructure Highlights Open source blockchain, APIs, tools and libraries

Delegated proof-of-stake block production (no mining pool cartels)

Low-overhead Byzantine Fault Tolerant Finality

Optional high-overhead, low-latency BFT finality

Fast transaction confirmations (500 milliseconds) for responsive applications and good user experience

No user transaction fees (no gas)

Stakeholder governance

Smart contracts powered by WebAssembly, battle-tested and performant

Ricardian contracts enforceable through arbitration

User-friendly accounts

Powerful hierarchical role-based account permissions

Scheduled Recurring Transactions

Support for Biometric Hardware Secured Keys (Apple Secure Enclave)

Horizontal scaling via Inter-Blockchain Communication (IBC)

Side Chains



Sister Chains

Vertical scaling using parallel execution across CPU cores/threads

Virtual (paginated) resources for cost-efficient application operation using LiquidApps infrastructure

Flexible mainnet upgrades and patches

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 Chintai



Significantly boosting RAM scalability and lowering the cost of running EOSIO applications,





has also created an objective SWOT (Strengths, Weknesses, Opportunities, Threats) analysis.

has written a Side Chains Side chains would deliver significantly higher throughput within a given EOSIO main network. Side chains would 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 EOSIO 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 EOSIO block chain, a sort of virtual chain running at full speed. For example, a single v1.5.3 EOSIO main network operates at 3,996 transactions per second; a huge main network with 1,000 side chains would peak at 4 million transactions per second.

Sister Chains A sister chain is a fully discrete EOSIO main network that uses IBC to integrate with the EOS main network. Sister chains allow the entire EOSIO 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.

Private Networks A private network is a totally independent EOSIO 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 EOSIO main networks, some likely firewalled and not even reachable on the Internet. For example,

Inter-Blockchain Communication (IBC) EOSIO 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 EOSIO main network, and also integrates EOSIO 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 will horizontally scale the entire EOSIO 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 EOSIO software nearly doubled TPS performance (over 9,000 TPS) in testnet, throughput must increase by orders of magnitude to handle future resource demands.

When IBC? That question is ringing out in a chorus across the cryptoverse. For example,



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.



Because CPU resources have already been stressed in the present single-threaded EOS software by a wave of gaming and gambling applications,



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. Cross-Chain Communication







EOS centers on a delegated proof-of-stake concensus algorithm ( DPOS ) created by Dan Larimer. The stakeholder community has ultimate governance over blockchain production and community standards. The blockchain is operated by 21 primary block producers distributed, 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 June, 2019, there were over 70 paid stand-by block producers in positions 22 through 71. 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 Canada provides a helpful overview of the core of EOSIO consists of several system accounts that control various blockchain system contracts. Like any operating system, EOSIO 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 EOSIO 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 EOSIO applications, LiquidApps recently (January, 2019) introduced vRAM, a contract-layer implementation of virtual disk storage using IPFS technology. 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).Side chains would deliver significantly higher throughput within a given EOSIO main network. Side chains would 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 EOSIO 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 EOSIO block chain, a sort of virtual chain running at full speed. For example, a single v1.5.3 EOSIO main network operates at 3,996 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 EOSIO main network that uses IBC to integrate with the EOS main network. Sister chains allow the entire EOSIO 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 EOSIO 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 EOSIO 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 EOSIO main network tailored for its brokerage/escrow products and services.EOSIO 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 EOSIO main network, and also integrates EOSIO 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 EOSIO 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 EOSIO 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. EOSIO 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 EOSIO 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. LiquidLink represents a milestone in cross-chain communication between EOS and Ethereum:

EOS Token Lifecycle This is the token lifecycle in the EOS main network, where five primary actors interact with staked or liquid EOS, optional REX, DAPP and a myriad of air-dropped or air-grabbed tokens: Stakeholders

Block Producers

REX Borrowers

Distributed Applications (DApps)

LiquidApps DApp Service Providers (DSPs)



Requirements around



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. This is the token lifecycle in the EOS main network, where five primary actors interact with staked or liquid EOS, optional REX, DAPP and a myriad of air-dropped or air-grabbed tokens: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. There are also previous Version 1.0 Version 1.1 , and Version 1.2 diagrams.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.

Sunday, June 10th, 2018 The mainnet is now fully operational, 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



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.







As the flowchart above depicts (courtesey of



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 EOSIO source code). Two outside auditing firms were hired in China to perform the work:



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



June 9th : The independent audit report was released in public form on June 9th, 2018:





Security Plan

BP Securit Audit

P2P Vulnerability (Fixed)

Slowmist ETH Vulnerability

The EOS mainnet went

Voting commenced immediately with Aloha EOS,

EOS stakeholders voted past the 15% minimum threshold (150 million tokens, 15% of the total distribution) and unlocked the mainnet on Thursday, June 14th. 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.: 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.: 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 EOSIO 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.: 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.: 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.: 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.

1 Billion Tokens Distributed Block.one, whales (mining pools) and coin exchanges dominate the 90% of all tokens are held by 1.6% of the accounts . A majority of the distribution is owned by token holders located in China. A small number of whale accounts, many of them exchanges, are presently controlling block production. Block production collusion (vote buying and swapping) is growing.

Available tokens: 996,690,678

Total accounts: 163,930

Average tokens per account: 6,079

Accounts holding > 10 million: 17

Accounts holding > 2 million: 41

Accounts holding > 500,000: 120

Accounts holding > 100,000: 485

Accounts holding > 10,000: 4,054

Accounts holding > 1,000: 25,800

Accounts holding > 500: 38,868

Accounts holding < 100: 77,623 Average Tokens Held 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 Distribution Summary 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%) Current Vote Distribution Here is the current vote distribution as of May, 2019: Number of Voters: 56,609 accounts

Total EOS Voted: 300,155,586 EOS

Average EOS per Vote: 5,302 EOS

Largest single account that voted: bigbigaccoun (12,333,203 EOS)

Total EOS Voted by Proxies: 199,978,704 EOS

Number of Voters using a Proxy: 16,642 accounts

Number of Voting Proxies: 784 accounts

BPs with largest single vote: big.one (5 more) (12,333,203 EOS)

Average number of BPs per vote: 13.4681

BP with highest number of voters: eosauthority (30,386 accounts)

BP with most EOS votes: eoslaomaocom (138,917,103 EOS)

Number of accounts that voted for just 1 BP (exclusive votes): 10,621 accounts

BP with highest number of exclusive votes: eoshuobipool (1,124 accounts)

BP with the highest exclusive vote size: eossv12eossv (4,297,365 EOS) Available tokens: 996,690,678Total accounts: 163,930Average tokens per account: 6,079Accounts holding > 10 million: 17Accounts holding > 2 million: 41Accounts holding > 500,000: 120Accounts holding > 100,000: 485Accounts holding > 10,000: 4,054Accounts holding > 1,000: 25,800Accounts holding > 500: 38,868Accounts holding < 100: 77,623Top 10 Holders: 20,675,047Top 100 Holders: 646,595Top 1,000 Holders: 42,941Top 10,000 Holders: 3,312Top 100,000 Holders (of 169,930 accounts): 55Top 10 holds 496,735,539 Tokens or 49.67% of the total 1 billion ICO distributionTop 100 holds 748,176,831 Tokens or 74.82% of the total tokensTop 1,000 holds 858,120,383 Tokens or 85.81% of the total tokensRemaining accounts (1,001 through 163,930) hold a total of 138,570,296 Tokens, 13.86% of the total distributionTop 10 (excluding B1) holds 396,735,539 Tokens or 39.67% of the total tokensTop 100 (excluding B1) holds 648,176,831 Tokens or 64.82% of the total tokensTop 1000 (excluding B1) holds 758,120,383 Tokens or 75.81% of the total tokensRemaining accounts (1,001 through 163,930) hold 138,570,296 or 13.86% of the total distributionBlock.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%)Here is the current vote distribution as of May, 2019: Pre and Post-Genesis Account Recovery



For those who were able to register but have lost their EOS genesis keys,



Block.one, whales (mining pools) and coin exchanges dominate the top accounts , holding nearly half the total distribution. Besides the 10% stake held by Block.one, exchanges dominate with huge token counts represented by hot/cold wallets and an aggregation of many individual customer accounts. The overall distribution is concentrated at the top:. A majority of the distribution is owned by token holders located in China. A small number of whale accounts, many of them exchanges, are presently controlling block production. Block production collusion (vote buying and swapping) is growing. EOS Authority processed the genesis snapshot . At the end of the ICO, over 3 million ERC20 tokens were not able to register before the freeze. 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.For those who were able to register but have lost their EOS genesis keys, EOS Authority provides an excellent account recovery tool

Passive Income With REX Release of the much anticipated



Based on the



Extensive testing took place over the past several months, led by











There are several other tools available with good REX support, including Bloks.io, eosflare.io and the EOSVoter wallet:















REX is part of Release of the much anticipated EOS Resource EXchange (REX) took place on May 2nd, 2019. REX is a system-level EOSIO contract that provides stakeholders with a resource market to lease unused CPU and NET resources for passive interest income; early tracking indicates an approximate 1% APR rate of return. REX provides application developers with very low-cost resource leasing; purchasing a 30-day lease of 2,500 EOS tokens presently costs just 1 EOS, greatly lowering entry friction and ongoing operation costs for application providers.Based on the Bancor algorithm , stakeholders cannot loose their original investment. Interest is earned as borrowers lease CPU and NET resources from REX; name auction fees are collected daily, with fees from REX leasing and RAM trades accruing real-time. For the same reason stakeholders are encouraged to stake their EOS, leased REX tokens should also be staked; a 4-day unstaking period is required to obtain liquidity before staked REX can move.Extensive testing took place over the past several months, led by EOS Authority with its newly released REX user interface:There are several other tools available with good REX support, including Bloks.io, eosflare.io and the EOSVoter wallet:REX is part of EOSIO v1.7.3 , 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. Passive Income Using Chintai Available on the EOS Mainnet for several months prior to REX,







For more information about Chintai, please read the

You can also review the

Passive Income From Airdrop/Airgrab Tokens Visit







Available on the EOS Mainnet for several months prior to REX, Chintai is another token rental marketplace EOS stakeholders have at their disposal that includes REX integration:For more information about Chintai, please read the launch article written by EOS42 You can also review the whitepaper Visit EOS Dividends to track tokens that pay passive dividends.

Account Namespace Auction By default, EOSIO requires a 12-character account name when creating an account. However, shorter vanity account names can be purchased through a namespace auction process.

and



Use







The



By default, EOSIO requires a 12-character account name when creating an account. However, shorter vanity account names can be purchased through a namespace auction process. EOS Canada and EOSPark have authored good overviews of the account name bidding process.Use EOS Authority to bid on account names:The EOS Toolkit by GenerEOS is also available to bid on account names:

Purchasing RAM 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.











The







MarketstackD has released their











RAM Allocation Proposals During the 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 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



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. 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. EOS Toolkit by GenerEOS supports RAM trading:The Greymass Wallet also supports RAM trading:MarketstackD has released their RAM Buying Calculator EOS New York built EOS Resource Planner to track current RAM pricing and utilization: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.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.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.

Analyzing Block Producer Performance































EOS Titan also provides a







Visit the















Note how many of the top ranked producers have a handful of whales voting them into the payout zone. Many whales are exchanges. Exchanges are voting for themselves and other exchanges. Whales are moving up using public and private vote-buying arrangements. Whales with just a handfull of huge accounts provide enough stake to vote them into the active producer set. Unfortunately, whale support does not equate to block production competency, good community support or DApp productivity.



The top 21 active block producers run and control the blockchain, receiving the highest block production inflation rewards. In order to be rewarded, block producers must receive at least 0.5% of the total stakeholder vote. Each block producer claims their share of the per-vote reward once per day. The next 70 standby producers (approximately) receive smaller reward amounts. Producers with vote tallies below this threshold receive nothing. There can be any number of standby producers.



For more, Aloha EOS created EOS Block Producer Reliability Tracker, a page that monitors block production performance metrics: EOS Authority provide a page that summarizes block producer voting patterns: EOS Nation hosts Block Producer bp.json Validator with endpoint, resource, API version error reports: EOS Titans has released a block producer rank and voting explorer:EOS Titan also provides a heatmap that tracks BP and proxy proposal voting history:Visit the EOS Tracker producer page to determine block producer rankings and payouts: 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. Many whales are exchanges. Exchanges are voting for themselves and other exchanges. Whales are moving up using public and private vote-buying arrangements. Whales with just a handfull of huge accounts provide enough stake to vote them into the active producer set. Unfortunately, whale support does not equate to block production competency, good community support or DApp productivity.The top 21 active block producers run and control the blockchain, receiving the highest block production inflation rewards. In order to be rewarded, block producers must receive at least 0.5% of the total stakeholder vote. Each block producer claims their share of the per-vote reward once per day. The next 70 standby producers (approximately) receive smaller reward amounts. Producers with vote tallies below this threshold receive nothing. There can be any number of standby producers.For more, EOS Canada has provided a block production revenue analysis.

EDNA gives you control over your own DNA, provides secure storage and unlocks its true market value.



EDNA uses state-of-the-art DNA testing and advanced cryptography to obtain and secure your genetic data.



Unlike other DNA providers, EDNA members own their DNA . You decide whether to grant genetic researchers access to your genetic information, and you are compensated accordingly. You can opt to lease your EDNA tokens to other members and earn dividend income, helping more people particpate in the genetic ecosystem.



You can optionally share a percentage of your profits to fight human-trafficking and illegal wildlife poaching, helping recover stolen children and protect endangered wildlife while advancing genetic science.

Obtaining EDNA Tokens Purchasing EDNA tokens currently requires an

The following exchanges trade EDNA tokens using your EOS account: Newdex is a popular exchange for trading several EOSIO tokens, including EDNA

DEXEOS also trades EDNA with lower volume compared to Newdex EDNA Token Teleporation EDNA supports token teleportation between EOS, WORBLI and TELOS main networks.



IMPORTANT: To fully participate in EDNA token economics you must move (teleport) your EDNA tokens to the



Your authorization (signature) is required when teleporting EDNA tokens between EOS, TELOS and WORBLI main networks. Install and configure one of the following tools to perform the needed authentication and signature operations if you haven't already done so: Anchor desktop wallet by Greymass

Scatter is another option Follow the steps below to move EDNA tokens from EOS to WORBLI.



NOTE:



First, log into your EOS account using the







Next, click on the "Tables + Actions" menu item:







Enter "ednazztokens" in the "Contract Name" field and then press the "Get Contract" button:







Click on the "Actions" menu item:







Click on the "teleport" button:



Enter your EOS account name in the "from" field

Enter the number of EDNA tokens being teleported from EOS to WORBLI in the "quantity" field; the quantity enetered MUST have 4 digits of precision to the right of the decimal place, MUST be followed by a space and MUST end with the token name "EDNA", for example: 100.0000 EDNA

Entering content in the "memo" field is optional

Enter 3 in the "target_chain" to send EDNA tokens to the WORBLI main network

Enter your WORBLI acount name in the "address_to" field; this is the WORBLI destination account where your ENDA tokens will be placed

Press the "Submit Transaction" button



Finally, click on the "Account" toolbar item and verify the teleportation transaction appears in your account's "Transactions" history:







Notes: Due to EOS main network congestion, although the submitted teleportation transaction will finalize in three minutes, several hours will likely transpire before your tokens actually arrive in your WORBLI account

Given recent CPU congestion in the EOS main network, teleportation from your EOS account requires enough available CPU resources to perform the token transfer transaction

Use the contact information below for support if your tokens haven't arrived in your WORBLI account after waiting 8 hours EDNA Customer Support Email EDNA Support

Visit EDNA Telegram Channel

Call +1 (715) 602-9200 for phone support Purchasing EDNA tokens currently requires an EOS mainnet account The following exchanges trade EDNA tokens using your EOS account:EDNA supports token teleportation between EOS, WORBLI and TELOS main networks.: To fully participate in EDNA token economics you must move (teleport) your EDNA tokens to the WORBLI main network. Before teleporting your EDNA tokens to WORBLI, you must establish a free WORBLI account if you haven't already done so.Your authorization (signature) is required when teleporting EDNA tokens between EOS, TELOS and WORBLI main networks. Install and configure one of the following tools to perform the needed authentication and signature operations if you haven't already done so:Follow the steps below to move EDNA tokens from EOS to WORBLI. Brave browser is recommended for teleportation.First, log into your EOS account using the Bloks.io explorer with Anchor or Scatter, then click on the "More" toolbar item:Next, click on the "Tables + Actions" menu item:Enter "ednazztokens" in the "Contract Name" field and then press the "Get Contract" button:Click on the "Actions" menu item:Click on the "teleport" button:Finally, click on the "Account" toolbar item and verify the teleportation transaction appears in your account's "Transactions" history:Notes:



is an EOSIO 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 BOSCore is an EOSIO 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



is an EOSIO sister chain designed to expand EOS ecosystem resources and reduce DApp operating costs.

For more information, please review the MEET.ONE is an EOSIO sister chain designed to expand EOS ecosystem resources and reduce DApp operating costs.For more information, please review the White Paper

Securing Your Account NEVER divulge your private key unless the source asking for your private key is ABSOLUTELY trustworthy!





divulge your private key unless the source asking for your private key is trustworthy! NEVER agree to sign/confirm transactions unless your are ABSOLUTELY sure what the transaction is about to perform!





agree to sign/confirm transactions unless your are sure what the transaction is about to perform! 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





establish a different public/private key pair for your OWNER account permission: 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









Use a hard wallet like the Ledger Nano, Metro, or, when available, the new iOS wallet being developed by Block.one





Keep most of your stake in hard/cold storage using a separate, infrequently used account





Use a separate account containing a much smaller stake for daily activity





Besides hard wallets, the Greymass desktop wallet is a good choice





Another option is to use Scatter Desktop for transaction signing





Keep your EOS fully staked, providing a 3-day window to detect and react to unauthorized activity (unstaking)





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





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





sure, avoid clicking on any link-- especially links provided in chat rooms or email ALWAYS confirm/verify the source before installing any application





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





Our Goals Help increase EOSIO adoption by lowering entry friction

Monitor, measure and report EOSIO ecosystem health

Clarify EOSIO complexity for both existing and prospective stakeholders

Maintain current EOSIO content as the ecosystem expands

Produce objective EOSIO content for reference purposes Disclosure Statement We are completely independent and totally focused on maintaining a strong EOSIO ecosystem

We are not sponsored by or colluding with any external entity

We do not accept compensation of any kind from any source related to EOSIO

We perform empirical EOSIO research, including testnet, mainnet, GitHub monitoring and active community participation

We have stake in EOS, WAX, Telos, WORBLI, BOSCore and MEET.ONE main networks

BT We also have stake in DAPP, CHEX, EDNA, EMT and other tools/applications that operate on these main networks

We are not financial or legal advisors

We do not provide financial or legal advice in any form