The core EOSIO code has never received a thorough third-party code audit that has been published and information about any internal code audits performed by Block One are unavailable. And yet, this is a core protocol that EOS, WAX, Telos, Ultra, FIO, UX, Proton and other blockchains are built upon representing billions of dollars in market capitalization and total value locked into these economic platforms. There have been several security exploits discovered and patched by the Block One EOSIO development team engaged with a focused group of leading EOSIO developers, of which I had been included. The EOSIO bug bounty was ended years ago meaning that no independent entities have any strong incentive to research new releases looking for vulnerabilities.
The ENF-commissioned AUDIT+ Blue Paper offers a number of good ideas about how to better secure EOISO code in the future, and yet, it missed the most crucial one: to perform a full third-party audit of the EOSIO core code to ensure no vulnerabilities exist to be exploited. This is a crucial, high priority need as those involved in the ENF EOSIO+ process set off to assume control of the future of this protocol for the benefit of all chains and users.
My interest in facilitating a full audit of the EOSIO code grew from three experiences I’ve had working with the Telos blockchain, where I am a leader of the Telos Core Developers team. When applying for listing on exchanges, it’s common to have to fill out a long questionnaire about the chain particulars. These typically ask for a code audit. This request was generally aimed at ERC-20 tokens, not Layer-1 blockchains like Telos, but the fact was, we could not produce these and appealed to exchanges that already had listed EOS that the core protocol was the same. However, this first opened my eyes to the fact that there was no audit available and I started wondering if this was because none had ever been performed.
When Telos searched for the most appropriate way to audit our EVM code, given that it would not be immediately open-sourced, we opted to hire Sentnl, which we felt was the best-in-class auditor in part because they had pioneered the “fuzzing” process which had discovered roughly ten EOSIO vulnerabilities in a short period of time when the Block One bug bounty program still existed. In the process of auditing the Telos EVM code, Sentinl provided the Telos team with a wealth of important advice for us to implement to improve that project. One inescapable fact of software development is that no large codebase is totally without vulnerabilities unless thoroughly tested and audited. An illustration of this is that Sentnl’s fuzzing techniques discovered a vulnerability in the most-used Go Ethereum (geth) implementation necessitating a high priority patch in August of 2021. This code had doubtless been reviewed dozens of times without discovering this potential exploit. That is just the nature of software development.
When Block One officially ceased its development of EOSIO core software, my concerns about the overall security of the code grew. While I have been an outspoken critic of Block One’s practices towards the EOSIO community for over three years now (often misinterpreted as concerns about other chains), I still realized that I had been counting on Block One to preserve the security of the EOSIO code that so many chains rely on. And yet, now it was clear that there was absolutely no reasonable basis for this assumption. Is EOSIO code secure? Who can say for sure? Block One may know but they haven’t shared any specific information about audits. In the absence thereof, the only responsible action is to assume that the code is NOT secure and undertake a top quality audit of the existing code. I have now stepped into a role with other leaders across EOSIO chains where I feel a responsibility to provide a better answer for this question than those before me offered. I think it is crucial to demonstrate the high level of security of EOSIO code.
As an individual highly associated with the Telos blockchain, and prior to any involvement I had with the ENF EOSIO+ working group, I decided to explore personally hiring Sentnl to perform a full audit of Telos/EOSIO core code because I frankly knew that I had absolutely no reasonable response to a question about whether our code had been fully audited by a premiere outside auditor, should any vulnerabilities eventually be exploited resulting in token-holder losses. I am not a fiduciary for the Telos chain or any other and yet, I always aim to act in its best interest wherever I may have influence to do so, and in the best interest of all EOSIO chains because many Telos community members are also engaged in other EOSIO chains as well. Therefore, I created a general specification for a full code audit from Sentnl and approached other, better funded parties about sharing the cost with me. This coincided with the time when I engaged with the ENF EOSIO+ workgroup and learned that the Audit+ Bluepaper was underway and would be published in the near future. With the Blue Paper coming out soon, I delayed my plans to initiate an audit with the hope that this would be included in its recommendations. Upon reading it, however, I was surprised that what I believed to be the most foundational task–to ensure a clean and secure starting point for future code development–had been omitted as a proposed task.
I propose that the Audit+ Blue Paper be amended to include and prioritize the performance of a full audit of the version of EOSIO code to be first released. I would further propose that incremental audits of new code release be incorporated into whatever release strategy the EOSIO+ group ultimately adopts. While there are many who could perform such an audit, I would put forward Sentnl, as they were the group that I was willing to engage when I was contemplating spending my own funds to do this. I have already begun the process with them and received an initial scope of work proposal. I will also share the information about additional, outside funding groups that have expressed interest in contributing to the funding of an audit. The cost of such an audit will be $70,000-$110,000 USD depending on which code repositories will be included. Future incremental audits would be at a reduced rate. There are several benefits to such an audit. First, auditing would provide clear evidence that the codebase is secure. In the current world of blockchain protocols, a current, comprehensive audit from an auditor that has proven its methods many times over would be an early, clear signal that from this point forward, EOSIO is not going to replicate the bad habits of Block One, but support regular, open code auditing to place a priority on security for all EOSIO chains, users, developers and investors.
Please consider adding this important step to the recommendations of the ENF Audit+ Blue Paper.