Audit+ Blue Paper (English)

EOS Audit+
Blue Paper
Providing an overall framework for security
analysis tooling and contract audit for
EOSIO-based applications.
Part I
2022

Acknowledgements
The EOS Network Foundation (ENF) would like to express our sincere gratitude to the principal
authors of the Audit+ Blue Paper.
Sentnl — Blockchain auditing firm specializing in penetration testing, wallet security audits, and
smart contract audits for EOSIO blockchains.
Slowmist — Blockchain security company offering solutions that include security audit, threat
intelligence (BTI), bug bounty, defense deployment, security consultancy, and other services
for EOSIO projects.

Table of Contents
Table of Contents��1
Abstract��3
Reading this document ��4
1.Current solutions that exist in the
community��5
1) Klevoya Inspect ��5
A) Description��5
B) Features��5
C) Benefits to EOSIO��6
D) Reference Material��6
2) Software development libraries. ��6
B) Features��7
2. Solutions that are demanded by
community��8
1) Software libraries for secure smart contract
development ��8
B) Reasoning��8
C) Who is demanding��8
2) Bug Bounties ��9
B) Reasoning��9
3) Contract upgrade authorization DAO ��9
B) Reasoning��10
C) Who is demanding��10
3. Equivalent work done in other
ecosystems ��11
1) Security Registry for dApps ��11
B) Features��12
C) Highlight issues to avoid��12
E) Reference Material��12
2) Open source Security tools ��12
B) Features��13
C) Issues to avoid ��13
E) Reference Material��13
3) Software libraries for secure smart contract
development ��14
B) Features��14
4) Common security pitfalls when writing smart contracts
��15
B) Features��15
5) Bug bounties ��16
B) Features��16
6) AML platform ��17
B) Features�� 18
C) Issues to avoid �� 18
D) Business opportunities that are from these
solutions�� 18
E) Reference Material�� 18
1
EOS Audit+ Blue Paper
EOS Audit+

4. A list of initiatives that could
improve the EOS ecosystem.��19
1. Open source security audit API and platform ��19
A) Problem��19
B) Objective��19
C) Benefits to EOSIO�� 20
D) Deliverables�� 20
E) Level of Effort��22
F) Minimum Viable Product��23
F) Minimum Viable Product+ ��24
G) Future Goals ��24
H) Reference Material��24
2. Contract upgrade authorization DAO ��25
A) Problem��25
D) Deliverables��27
F) Business opportunity��27
G) Minimum Viable Product�� 28
H) Reference Material�� 28
3. Create AML platform �� 28
A) Problem�� 28
B) Objective�� 28
4. Software libraries for secure smart contract
development ��31
A) Problem��31
5. Bug bounties ��33
A) Problem��33
C) Benefits to EOSIO�� 34
E) Level of Effort�� 34
G) Future Goals �� 36
6. Build automated security auditing tools. ��37
A) Problem��37
E) Level of Effort�� 38
F) Minimum Viable Product�� 38
7. List of common security pitfalls when writing EOSIO
smart contracts �� 39
A) Problem�� 39
G) Reference Material��41
5. A list of recommendations to the
foundation on the best course of
action.��42
smart contracts ��42
2. Software libraries for secure smart contract
development �� 43
3. Bug bounties �� 43
4. Open source security audit API and platform ��44
6. Appendix��45
2
EOS Audit+

Abstract
In this paper we provide our research and initiatives around improving the overall security of
EOSIO blockchains.
Our research shows that very few solutions exist in the EOSIO geared towards security.
The EOSIO core system is beautifully designed to allow for a security oriented approach,
but there is much work required to bring it up to the same standard of security that other
blockchains offer.
A key area that resides in this paper is knowledge. The self perpetuating knowledge with-
in developer communities which can only be achieved by giving them the right tools
and documentation.
The huge security knowledge of the hacker communities and their inquisitive nature that we
should harness to continuously secure EOSIO.
The knowledge of our userbase knowing that their interactions with EOSIO dApps are safe and
secure, which is possible to achieve due to EOSIO’s unique structure as long as we provide the
underlying services and APIs.
As mentioned, the overall core design of EOSIO allows for a security oriented approach, we
just need to focus on the basics and then go a step further, by harnessing some key EOSIO
elements that will help us stand out from other blockchains.
3
EOS Audit+

Reading this document
Based on the guidance provided the paper is divided as following:
1. Current Solutions. We start by describing what solutions are currently available in EOSIO.
2. Solutions demanded by the community: Followed by what solutions are demanded by the
community based on our research.
3. Existing solutions in other communities: We then provide some research around what
solutions exist in other communities that could also be leveraged in EOSIO.
4. Our initiatives: The penultimate section of the document relays all our initiatives to improve
overall EOSIO security.
5. The final part of the document lists 4 initiatives we feel are best suited as a starting point
that will form the security foundation to build upon.
6. Appendix is provided for those terms that might be unfamiliar for the reader.
4
EOS Audit+

1. Current solutions that exist in
the community
Although there are some solutions available in the EOSIO community, overall we feel that there
is a basic lack of foundational security oriented solutions.
Below we cover some of the solutions available that are mentionable and in active use.
1) Klevoya Inspect
A) Description
Klevoya inspect is a tool that allows developers to upload their compiled WASM code and have
it inspected for vulnerabilities based on unique patterns created by the Klevoya team. ¹
Inspect employs a technique called Static analysis. Static analysis is performed by reasoning
about a computer program’s source-code, or some intermediate representation, without actu-
ally executing it.¹
Under the hood, the uploaded WASM code and ABIs are uploaded into a proprietary interme-
diate representation that is loaded into a database. The patterns matcher is then run against
the entities in the database looking for known vulnerabilities. ²
The product is not open source and is a paid for service.
B) Features
Automated scanning of uploaded compiled WASM code.
Scanning engine that detects vulnerabilities in WASM code based on in house
designed patterns.
5
EOS Audit+

C) Benefits to EOSIO
Although this feature is a paid for service and won’t guarantee to cover the same depth as a
manual security audit, static analysis fuzzing is a very powerful tool and will give developers a
unique opportunity to self diagnose and self resolve security issues, which ultimately over time
will make them better at writing smart contracts that are more secure.
D) Reference Material
• ¹https://klevoya.com/inspect/index.html
• ²https://klevoya.medium.com/?p=242400e10cdc
• ³https://www.fuzzingbook.org/html/ConcolicFuzzer.html#SMT-Solvers
2) Software development libraries.
A) Description
EOSIO provides an eosio.contracts warehouse, which contains bios, system, msig, wrap and
token contracts. Using the MIT License agreement, developers can use the code almost un-
limitedly, and they can also master the EOS mainnet by learning these contracts including the
governance parameters and economic models.¹
There are also some general use SDKs available in the community:
1. SX organization that has open sourced 9 DeFi-type smart contracts on Github, that con-
tain good quality coding standards and some of them have passed the security audit,
but it should be noted that these libraries do not indicate the copyright agreement to
be followed.²
2. Blockmatic, collected 112 community open source EOS smart contracts source code and
made the list public. The code contains game, DeFi, payment, DAO, stablecoins, and NFTs
, ICO and other types of contract examples and even projects that utilise Rust as a devel-
opment language, which allows us to see the developer's enthusiasm for development
on EOS.³
6
EOS Audit+

B) Features
At present, the community has a large list of open source coding examples, but the code that
has undergone security audits is relatively small, and the amount is much smaller than that of
Ethereum by several orders of magnitude. Most striking is that most of the code bases have
been suspended for maintenance.
Developers are one of the key roles in the development of blockchain. How to attract more de-
velopers to enter the EOSIO ecosystem is an important issue that the EOS community needs
to think about. By developing and sharing a high-quality open source code base, the difficulty
of development can be reduced, and developers with inexperience can quickly develop secure
smart contracts, thereby increasing the adoption of EOS.
• ¹https://github.com/EOSIO/eosio.contracts
• ²https://github.com/stableex
• ³https://github.com/blockmatic/eosio-contracts-list
7
EOS Audit+

2. Solutions that are demanded
by community
Based on our research and speaking to stakeholders within the EOSIO community, we have
listed some of the key parts that we feel are demanded by the community that would help im-
prove the overall security of the EOSIO ecosystem.
1) Software libraries for secure smart contract development
A) Description
Security hardened software development libraries (SDK) allow software developers to har-
ness battle tested contract templates and libraries to minimize risks when developing
smart contracts.
They are just like your standard SDKs, but included within them are pre-built examples of per-
forming certain actions that are built based on best security practices, so instead of having to
create your function that performs a certain action you can utilise existing ones that you know
have been tested for security issues.
B) Reasoning
Using such libraries will not only help minimize risk when creating smart contracts, as they help
developers use existing methods that have already been scrutinized from a security point of
view, but also allow you to include security testing within your unit testing.
If all developers in EOSIO start using the same list of SDKs that are constantly updated to
account for the latest security issues on EOSIO it helps to improve the overall security of smart
contracts as it prevents developers from making the mistakes that are easily avoidable.
C) Who is demanding
EOSIO software developers want to create more secure smart contracts but we lack the
overall tooling.
8
EOS Audit+

2) Bug Bounties
A) Description
Bug bounties are monetary rewards given to ethical hackers who successfully discover a vul-
nerability in an application or piece of software.
Widely adapted across all chains it plays a very important part in ensuring your blockchain
code is constantly scrutinised, especially if your code base constantly changes or has
multiple flavours.
B) Reasoning
Having a well run bug bounty programme will attract the best of the hacker community to im-
prove the overall security of EOSIO. The lack of such a programme is discouraging the hacker
community from investing time and effort to look into the EOSIO code base.
C) Who is demanding
Ethical hackers want to participate in EOSIO but will only invest the time and effort once we
define and start a well run Bug Bounty programme.
3) Contract upgrade authorization DAO
A) Description
In EOSIO smart contracts are deployed to an active account and usually developers have full
access to upgrade those smart contracts in the future . This creates a trust issue, because the
users of that smart contract inherently need to trust the owner of the account that he will do no
evil, regardless of the security audit status of the smart contract.
You can ofcourse remove the ability for anybody to update the smart contract which creates
trust between the users and the smart contract owners, however this prevents any future
9
EOS Audit+

updates to the smart contract which would be required if bugs or security vulnerability are
identified that require remedy.
So you are left in a position where you need some type of multi-signature scenario that can
facilitate trust between users and smart contract owners and allow the smart contract owner
the ability to make updates if and when required in a timely manner.
B) Reasoning
As previously mentioned we need a better way of managing contract authority to facilitate
more trust between users and smart contract owners, whilst also allowing smart contact own-
ers the ability to make updates to their software.
C) Who is demanding
The community and smart contract owners both require this type of functionality. dApp own-
ers want their user base to trust them but also have the flexibility to update their dApps as and
when required. Although it’s never possible to fully promise that a dApp the community is us-
ing is not at risk from being hacked or that the owners have good or bad intentions, providing
this additional layer of trust helps create more trust between the community and dApp owners.
10
EOS Audit+

3. Equivalent work done in
other ecosystems
Researching other blockchains we have provided a list of security related content and prod-
ucts that are generally always available on top blockchain protocols, the overall general theme
of how security is approached is very similar across all blockchains.
We also cover a fairly new idea that has started to take fruition on Ethereum, which we also
cover as one of our core initiatives later in the document.
1) Security Registry for dApps
A) Description
We found that in Ethereum a github REPO exists that is trying to list all the current smart con-
tracts, given their chain, address and the associated project they belong to.
It seems like a fairly new endeavour by ETH as looking at the REPO history it was started on
Sep 2021.¹
“The goal is to be able to provide information about an address when a user is interacting with
it, as well as tracking security contact information for known projects in the event that a vulner-
ability is found in a given contract address.”
The list of ETH EVM chains currently supported are:
1. Etherum Mainnet
2. Optimistic Ethereum
3. Binance Smart Chain
4. xDAI
5. Fuse
6. Polygon
7. Fantom Opera
8. Arbitrum
11
EOS Audit+

B) Features
1. Listing your project: In order to list your project you complete a form listing your project de-
tails which include, Name, Github address, Contact email (incase of security issues), chain
and contract address.
2. Emergency contact: An emergency security contact email is required when listing your
project with the idea that if a serious breach is identified with your contract, there is a way
for the community to notify you.
3. Automated security contact tracking: To allow smart contracts to automatically register
their security contact details upon creation, a specific format has been adopted to allow
developers to provide this information as code comments.
C) Highlight issues to avoid
Current solution seems to be a very manual process adding a lot of unnecessary steps, which
could be more automated using EOSIO.
E) Reference Material
• ¹https://github.com/ethereum-lists/contracts
2) Open source Security tools
A) Description
Open source security tools are a very easy way for developers to self-assess the overall secu-
rity of their smart contracts. Although not very common these tools do exist and they especial-
ly exist within the top tier protocols, we are actively trying to compete with. These tools pro-
mote self diagnosis and develop the knowledge of the developer community around common
security pitfalls to avoid. ¹
12
EOS Audit+

B) Features
The common and nice to have features that are present in these tools are:
• Identifies the error, the type of error, it’s severity and where it occurs in the source code.
• Easily integrates into continuous integration and SDKs.
• APIs are available to allow developers to write custom analyses.
• Execution is very fast.
• Code is mostly open source and maintained by the security and developer community.
C) Issues to avoid
Avoid developing these tools in obscure languages and keeping the source code closed. Most
of these tools are open source and developed in a programming language that is well suited
for such analysis like Python, however there are some examples like Solana, where the only
tool available is closed source which limits community involvement and stifles the growth of
the tool.
• ¹https://github.com/crytic/slither
• ¹https://github.com/ConsenSys/mythril
• ¹Soteria (Solana) -
https://medium.com/coinmonks/soteria-a-vulnerability-scanner-for-solana-smart-con-
tracts-cc202cf17c99
13
EOS Audit+

3) Software libraries for secure smart contract development
A) Description
These software development libraries focussed around security are used to guide the devel-
opment of smart contracts, reduce the difficulty of development, and improve code quality
and security.
They are just like your standard SDK but come with added features that help guide developers
in writing code that is more secure.
It is usually led by the official development, or developed by a well-known project party.
Development libraries are usually examples of applications, such as token, NFT, lending, swap,
governance, etc. Some provide functions commonly used in contract development, such as
the safemath library that provides functions for arithmetic calculations that prevent overflow.
B) Features
These secure development libraries have excellent code quality, which is specifically
manifested in:
• Each type of application has a complete function realization;
• Simple and modular code;
• Function and variable naming methods with clear meaning and consistent style;
• Variable and function function annotation description;
• Comprehensive unit testing;
• Support general package management tools, such as npm, cargo;
• After a more comprehensive security audit;
C) Issues to avoid
One-time outsourcing development should be avoided, the development library should be
continuously updated for security, and technical support should be provided to the community
as much as possible.
14
EOS Audit+

• https://github.com/OpenZeppelin/openzeppelin-contracts
• https://github.com/open-web3-stack/open-runtime-module-library
• https://github.com/solana-labs/solana-program-library
4) Common security pitfalls when writing smart contracts
A) Description
Common security pitfalls are in-depth and up-to-date documents that list the past security
mistakes made by developers in a particular blockchain. These documents are created to help
future developers from repeating the same mistakes. ¹
Think of them as a list of rules to follow. Follow these basic rules and your smart contract will
generally be secure from hackers,
B) Features
List of common security pitfalls which include a description of the type of attack, some exam-
ple source code showing where the mistakes occur, what vulnerabilities these mistakes could
lead to and preventative techniques to allow developers to not repeat the same mistakes in
their own code.²
At times real world examples of prior mistakes where hackers manage to exploit a specific
piece of code are also provided to help further educate the developer on the dangers.³
C) Issues to avoid
During our research we noticed some of this type of documentation being very dispersed and
not properly updated. We should avoid having this information dispersed over too many plac-
es and ideally this type of information should remain on a Git type system and all references
should point back to the same location.
15
EOS Audit+

• https://medium.com/coinmonks/soteria-a-vulnerability-scanner-for-solana-smart-con-
tracts-cc202cf17c99
• ¹https://blog.neodyme.io/posts/solana_common_pitfalls
• ²https://consensys.github.io/smart-contract-best-practices/known_attacks/
• ³https://github.com/sigp/solidity-security-blog
5) Bug bounties
A) Description
Most top blockchains either run their own Bug bounty programme¹ or run via external platforms
that facilitate bug bounties like hackerone², bugcrowd³ and Immunefi4.
A bug bounty program is a deal offered by many websites, organizations and software de-
velopers by which individuals can receive recognition and compensation for reporting bugs,
especially those pertaining to security exploits and vulnerabilities.
B) Features
• Well defined vulnerability classification and severity scope with associated bounties.
• Well defined rules around what constitutes a bug.
• Well defined procedures to submit bugs.
• Leaderboards showing the top hackers for a particular bug bounty.
• Good communication and fare payouts.
• Good communication around sharing vulnerabilities to all other EOSIO chain and the pub-
lic announcement of such vulnerabilities.
16
EOS Audit+

C) Issues to avoid
Like ETH, EOSIO has become multichain so in the event of vulnerability a standardised way to
communicate to all other chains needs to be in place, as such once the vulnerability is made
public hackers could not leverage this to attack any other EOSIO chain.
We need to avoid making vulnerabilities publicly known before all chains have had the chance
to assess the newly distributed security patch and upgrade.Therefore a well thought out meth-
od of communicating EOSIO security issues to key people is an important requirement.
• ¹https://ethereum.org/en/eth2/get-involved/bug-bounty/
• ²https://hackerone.com/cardano-foundation?type=team
• ³https://bugcrowd.com/vulnerability-rating-taxonomy
• 4https://immunefi.com
6) AML platform
A) Description
EOS is a DAO system, many of its decisions rely on the analysis of information on the chain,
such as whether to freeze a hacker account suspected of attacking smart contracts. At this
time, a data platform is needed to analyze these behaviors. Establishing an AML platform
can ensure that we have enough means to track the flow of funds after a hacking incident.
The well-known Ethereum block explorer Etherscan has established such a platform. When
a hacking incident is disclosed, the platform helps to identify the attacking account and that
is marked as the exploiter, and relevant parties such as exchanges can query the platform to
ensure sending and receiving from and to this account is blocked.
17
EOS Audit+

B) Features
The tagging platform should have enough data to ensure the accuracy of account tagging,
and have sufficient participation in the ecosystem to be able to deal with new events in a
timely manner.
C) Issues to avoid
There are few account marks, inaccurate marks, and slow response to community incidents.
D) Business opportunities that are from these solutions
It may be possible to provide some paid blockchain analysis services.
• Etherscan Label Word Cloud: https://etherscan.io/labelcloud
• https://eosdetective.io/network
18
EOS Audit+

4. A list of initiatives that could
improve the EOS ecosystem
Based on all the current solutions that exist in the community, what’s demanded by the com-
munity and what we see that exist in other blockchain protocols we have come up with a list of
initiatives that will help EOSIO get ahead in terms of security.
There is some work required to get us to the same level as other blockchains, but once
our baseline is established EOSIO’s unique design will allow us to move a step above
other blockchains.
1. Open source security audit API and platform
A) Problem
Currently no service exists where the community can verify that the current smart contracts
code they are interacting with has been audited and deemed as secure, nor is there a central-
ised location for auditors to publish their audit findings and associated information.
B) Objective
Establish a contract source code verification platform3 and an audit information disclosure
platform1 which will make it easy for the community to verify the security of the smart con-
tract they are interacting with. Community includes users, other applications like wallets
and exchanges.
Working group Audit+, Wallet+, Core+
Target Audience Exchanges, Community, Other dApp
Initiative Type Development, Design
MVP Proposed Yes
MVP Cost $95,500
19
EOS Audit+

1. Exchanges can verify security of smart contracts by verifying the onchain hash matches
the hash of last audit performed.
2. Wallets can integrate with API using well maintained standards to provide a stamp of ap-
proval against smart contracts used during interactions.
3. Users can easily verify security of applications via wallets and or by visiting the proposed
frontend which would make it easy to view any application, it’s associated smart contracts
and the status of the audits.
D) Deliverables
1. On chain contract to push new audits: Allow security auditors to push new completed au-
dits to chain either via foundation or via MSIG. Each audit should contain:
a. Account address where the contract is loaded.
b. SHA256 hash of compiled WASM that audit was performed on.
c. Code repo URL.
d. Date of audit.
e. Auditor name.
f. Auditor email address.
g. Link to certificate if applicable.
h. Link to report if public.
i. Result: passed or failed.
2. ABI standard to automatically track new smart contacts: To automatically register new
smart contracts, developers should list basic info for their contract in their ABI. (Could pos-
sibly use ___comment : field)4 Information required:
a. Security contact information for your project upon deployment.
b. Project Name
c. Code Repo link
20
EOS Audit+

3. API standard: Create a API standard that is listed and maintained on Github.5
5API JSON Example:
{
account: compcontract,
auditStatus: 0, // 0=not audited,1=auditing, 2=audited
timestamp: timestamp of latest audit,
org: {
company_name: dApp company,
website: https://www.company.io,
email: info@company.io,
code_repo: {
code_location: CODE URL
},
social: {
steemit: ,
twitter: company01,
facebook: ,
github: company01,
keybase: company01,
telegram: company01
}
},
audits: [{
timestamp: timestamp of audit,
organisation: {
name: Sentnl,
country: GB,
website: https://www.sentnl.io,
email: charles@sentnl.io,
},
name: name of smart contract,
hash: sha256,
report: link to report,
certificate: link to certificate,
result: passed
},
timestamp: timestamp of audit,
organisation: {
name: Slowmist,
country: CH,
website: https://www.slowmistio,
email: charles@slowmist.io,
},
name: name of smart contract,
hash: sha256,
report: link to report,
certificate: link to certificate,
result: passed
},
]
}
21
EOS Audit+

4. Frontend: Web frontend + Mobile friendly platform for community showing list of dApps
and auditing information as described by the API standard.
E) Level of Effort
The initiative comprises 3 separate working parts, the on-chain data, the API and the frontend
that lists all of the published smart contracts.
• Prerequisites Additional Research:
• Pushing of audit information to chain needs to be controlled by a MSIG, to ensure the
information provided by auditors can be verified before pushing to chain. To provide
a working MVP this is not required, however we suggest a working group researching
this subject.
• Research and define an API standard.
• Research and define an ABI standard.
• Research the legal implications around presenting this information to the community
should be investigated. If applications are presented as safe by API consumers and
those applications are compromised what does that legally mean for API consumers.
Very important to note that even with multiple audits a contract can never be deemed
completely safe, so there is always a risk that users will lose money.
• Estimated Hours: 1280 hours
• Estimated costs: $95,500
• Expertise Required:
• Smart contract Developer - 280 hrs @ $100 per hour ($28000)
• Frontend Designer - 350 hrs @ $75 per hour ($26250)
• Fullstack Developer - 350 hrs @ $75 per hour ($26250)
• Project Manager - 300 hrs @ $50 per hour ($15000)
22
EOS Audit+

F) Minimum Viable Product
It’s worth noting that the MVP proposed here is based on a very small set of smart contracts, in
order for this to be used in production we first need to establish a reliable method to retrieve all
smart contract ABI’s from chain and all current audits.
1. Create API standard: (Fullstack Developer - 20 hrs)
a. Create github Repo
b. Define a API standard in JSON format.5
2. Create ABI standard: (Smart contract Developer - 20 hrs)
a. Define ABI standard for developers to follow to provide project information.
3. Create a test contracts using ABI format and publish to chain: (Smart contract Developer -
25 hrs)
a. Create 3 dummy smart contracts using ABI standard and publish to chain.
4. Create chain Audit table and publish some test data:(Smart contract Developer - 25 hrs)
a. Create an account and on-chain table where auditors can publish results.
b. Work with Security engineers to publish some audit results.
5. Develop API: (Fullstack Developer - 50 hrs)
a. Setup DB and define DB layout.
b. Setup API backend.
c. Create API routes.
6. Write function to pull data from hyperion for MVP (Fullstack Developer - 100 hrs)
a. Write function to pull ABI details from hyperion for dummy contracts including their
associated dummy audits and post to DB.
7. Develop and Design Frontend: (Frontend Designer - 250 hrs,(Fullstack Developer -
100 hrs)
a. Setup minimal working frontend that retrieves data from API.
b. Show smart contracts and all available API data.
8. Create Docker: ((Fullstack Developer - 50 hrs)
a. Dockerize the frontend, backend and DB instances for easy deployment and testing
23
EOS Audit+

F) Minimum Viable Product+
Will contain all the MPV parts of Minimum Viable Product, but also include a necessary step to
move this product into production.
1. History Solution:
a. a Solution to pull together the contract deltas of completed security audits contract
and smart contracts ABI’s that can be saved to the DB.
b. The solution needs to be able to stop and start where the process last stopped to en-
sure no contract ABIs are missed.
G) Future Goals
1. Auditors of EOSIO contracts should be incentivised to provide this type of information and
smart contract developers should also be requesting this as part of contract, so as such
some education and or marketing around this iniative might be required.
2. Method to repopulate/sync API database with what’s listed on-chain within the Audit smart
contract table and contract ABIs, incase of DB loss using History solutions.
H) Reference Material
• 1Certik has a list of all their audits completed - https://www.certik.com
• 2https://github.com/ethereum-lists/contracts
• 3https://sourcify.dev
• 4https://developers.eos.io/welcome/v2.1/smart-contract-guides/understanding-ABI-files
• 5https://github.com/eosrio/bp-info-standard
24
EOS Audit+

2. Contract upgrade authorization DAO
A) Problem
As we all know EOS contracts can be deployed on ordinary EOS accounts, and the owner by
default has all the permissions to change the contract as he pleases. This creates a trust issue
between the smart contract owner and the users of the product. How do the users know the
owner won’t suddenly change the contract to an untested and un-audited version or at worst
take all the funds locked in the contract. We need to identify a way to create this trust whilst
also allowing developers the option to upgrade their contracts.
We require some sort of multi-signature DAO to manage the upgrade permissions of
smart contracts.
B) Objective
Establish one or multiple contract authority management DAOs, which is responsible for han-
dling EOS contract upgrades:
Establish a DAO smart contract to manage owner and active key permissions of
dApp accounts.
We don’t necessarily think there should be a single entity handling this, this type of service
should be a business and the same way auditing companies gain the trust of developers over
time by doing thorough audits, these types of business should overtime gain trust based on
their handling of smart contract verification and upgrades.
Due to the account of stakeholders involved in this initiative more research is required around
this subject but an example of how such a system could work is listed below.
Working group Audit+
Target Audience EOSIO community
Initiative Type Development, Design, Research
25
EOS Audit+

DAO Example:
DAO XYZ provides smart contract upgrade facilities. The DAO consists of 5 x top21 BPs, a
security auditor and a well known EOSIO twitter user.
Jolly Defi joins EOS mainnet and decides to use the services of DAO XYZ, they install their
initial contract that was audited by another external security auditor and once running on chain,
update their owner and active keys to a 6/8 MSIG.
MSIG setup
1. Top21 BP
2. Top21 BP
3. Top21 BP
4. Top21 BP
5. Top21 BP
6. Security Auditor
7. EOSIO twitter user
8. Jolly Defi
DAO XYZ company monitors on chain activity and notices Jolly Defi has added them as MSIG
and sends DAO XYZ the necessary information:
a. Contract details - contract, code warehouse, compiler version and link to
security audit.
b. Client details. - Application website, code warehouse, linkedin profile if available etc..
DAO XYZ, checks the hash of the security audit matches the contact loaded on chain and if
everything checks out, adds Jolly Defi to their list of approved applications.
Any user now using Jolly Defi, can first visit DAO XYZ and verify that Jolly Defi is indeed man-
aged by DAO XYZ and everything checks out. In an ideal world, you would incorporate this into
block explorers.
3 Months later and Jolly Defi would like to upgrade their contract to increase performance.
They would then send over all the relevant information to DAO XYZ for re-verification and initi-
ate a MSIG to upgrade the contract.
26
EOS Audit+

Once DAO XYZ have performed their checks, they sign and execute the MSIG and the new
contract is uploaded to chain.
Through a standardized method, the multi-signature of smart contracts has become a cus-
tomary method, which reduces the threshold for developers to use multi-signature and im-
proves EOS users' trust in smart contracts.
D) Deliverables
Establish a DAO MSIG protocol that the EOSIO stakeholders agree on, which any DAO looking
to provide this type of service can follow to setup their business.
E) Level of Effort
• Estimated hours: 400 hours
• Researcher - 400 hrs @ $100 per hour ($40,000)
1. Research this topic further and establish a DAO protocol for this type of service.
(Researcher - 350 hrs)
a. Research the topic with EOSIO stakeholders over multiple chains.
2. Create DAO MSIG protocol documentation. (Researcher - 50 hrs)
F) Business opportunity
This should be a paid for service and providers should compete with one another.
In future DAO can expand to add a rating system to dApps, to include additional checks like:
The contract provide ricardian contracts to determine the responsibility
Is the contract open source and verifiable/auditable by the community.
27
EOS Audit+

G) Minimum Viable Product
Set up a DAO, responsible for contract source code verification and contract
upgrade approval.
None
3. Create AML platform
A) Problem
As a new technology platform, blockchain has the characteristics of openness and anonymity.
At the same time, there are a large number of valuable assets circulating on the blockchain,
making it one of the main targets of hacker attacks. According to the records of SlowMist
Hacked, 547 hacking incidents known to date have caused losses of $20,779,621,384, of
which 120 EOS attacks have resulted in the theft of a large number of EOS assets. After
hackers steal funds, they often transfer them to exchanges to sell or exchange them for oth-
er assets. However, exchanges cannot obtain information on related attacks in time and fail
to prevent hackers from trading, resulting in exchanges becoming accomplices of hackers'
money laundering. In fact, it is not just an exchange. In the EOS ecosystem, wallets, browsers,
and dApps may all need to evaluate malicious behaviors and transaction risks on the chain
to reduce malicious behaviors and avoid becoming accomplices of money laundering, while
complying with international anti-corruption activities. Regulations on money laundering and
counter-terrorism financing.
Because EOS has a high TPS, historical transaction records need to take up extremely large
storage space, and one of the core technologies of the AML system is to analyze historical
transactions, so the establishment of such a system requires investment in higher-cost hard-
ware equipment. This also hinders the development of the AML system.
B) Objective
Establish an EOS-oriented anti-money laundering system, collect data from various data
sources (including all content from the dark web to hundreds of exchanges around the world,
28
EOS Audit+

and intelligence provided by the EOS community) for cleaning and integration, and combining
artificial intelligence technology from this Accurate data is extracted from the huge data col-
lection, the account is marked with identity characteristics, and the transfer of assets is moni-
tored in real time. The user or partner can check whether the account or transaction contains
malicious behavior through the interface.
1. Provide data support for EOS governance to reduce malicious behaviors on the chain,
such as helping the project party that has been hacked to recover funds;
2. It can help the EOS exchange or wallet to monitor the transfer of funds and freeze illegal
funds in a timely manner;
3. Provide a basis for law enforcement for regulatory agencies, analyze money laundering be-
havior, and promote EOS to move toward compliance;
D) Deliverables
1. A website with a visual chart showing the path of asset transfer;
The user enters the account number in the search box on the front end to view the asset trans-
fer status in a chart.
2. API interface for querying account tags;
API JSON format example:
{
lable: eos project exploit,
transactions: [
0x123456789...,
0x123456789...,
0x123456789...,
],
accounts: [
eoshacker...,
eoshacker...,
]
}
29
EOS Audit+

E) Level of Effort
• Prerequisites:
• The project party needs to have certain blockchain intelligence data;
• Need to quickly download EOS historical node data;
• Required expertise:
• Frontend Designer - 240 hrs @ $75 per hour ($18,000)
• Full stack engineer - 480 hrs @ $100 per hour ($48,000)
• Algorithm engineer - 480 hrs @ $100 per hour ($48,000)
1. Transaction data processing (full stack engineer - 240 hrs)
a. Build EOS full history node
b. Record all transfer information to a relational database
2. Information collection and processing (full stack engineer - 240 hrs)
a. Collect relevant accounts in the history of hacker attacks;
b. Collect as many identifiable accounts as possible such as dApp and
exchange accounts;
3. Develop account association algorithm (algorithm engineer - 480 hrs)
a. Sort the associated accounts and funding relationships of the target accounts
b. Create data query interface
4. Design web UI (front-end designer - 240 hours)
a. Display account mark information
30
EOS Audit+

G) Future Goals
1. 1The AML project party should continuously improve the accuracy of malicious behavior
identification and improve the reliability and usability of the system;
2. EOS wallets, browsers, transactions and other platforms should be encouraged to use the
AML system to reduce malicious behaviors on the chain;
• Etherscan Label Word Cloud: https://etherscan.io/labelcloud
• SlowMist AML: https://aml.slowmist.com/
• Chain Analysis: https://www.chainalysis.com/
4. Software libraries for secure smart contract development
A) Problem
With DeFi protocols now managing billions of dollars in assets, the blockchain community can
no longer overlook security when building smart contracts. The risk of attack is too high. While
audits and secure operations are key to diminishing risks of security vulnerabilities, they aren't
enough. There is a fundamental component missing from developing and launching secure
smart contract systems: Integrating security within the development
B) Objective
Hire experienced developers, develop some commonly used smart contract templates, and
open them to developers in the community.
Target Audience Developers
Initiative Type Development, Documentation
31
EOS Audit+

Even inexperienced developers can develop secure smart contracts by using or learning de-
velopment examples, thereby reducing hacker attacks.
D) Deliverables
Create development templates and open source the code of 6 popular business implementa-
tions and pass the security audit of at least 2 well-known security companies.
E) Level of Effort
• Prerequisites:
• Investigate the implementation of smart contracts in other blockchain ecosystems.
• Estimated costs: $170,000:
• Smart Contract Engineer - 1000hrs @ $100 per hour ($100000)
• Smart Contract Security engineer - 350hrs @ $200 per hour ($70000)
1. Create development templates for common application types. ( Smart Contract Engineer -
1000hrs )
a. Swap Protocol contract
b. Oracle Protocol contract
c. NFT Standard contract
d. Flashloan Protocol contract
e. Stable coin Protocol contract
f. Lending Protocol contract
2. Perform security audits on contracts
a. Two independent audits should be completed on all development templates. (Smart
Contract Security engineer - 350 hrs)
32
EOS Audit+

G) Future Goals
• Create more development templates to keep up with a growing ecosystem.
• https://github.com/OpenZeppelin/openzeppelin-contracts
• https://github.com/open-web3-stack/open-runtime-module-library
• https://github.com/solana-labs/solana-program-library
5. Bug bounties
A) Problem
Currently in EOSIO there lacks a well defined bug bounty program to attract the hacker com-
munity on investing time to analyse the EOSIO code base.
Pretty much all top end blockchains have bug bounties and they remain quite competitive in
terms of compensation to ensure they attract the best of the hacker communities.¹
B) Objective
Setup a managed and well defined Bug Bounty programme with attractive rewards to attract
the best talent within the hacker community. The programme should be well defined and man-
aged so you not only attract the best talent but also retain them for the long term.
We also require a method of communicating high vulnerability bugs to all EOSIO based chains
to ensure timely updates before bugs are made public. ²
Target Audience Hacker community
33
EOS Audit+

Having a well managed bug bounty platform ensures EOSIO can attract the best hackers to
constantly evaluate the EOSIO codebase. This ensures an overall safer and more secure co-
decase which not only protects the EOSIO blockchains themselves but also the smart con-
tracts running on top of it. There is also an element of marketing attached to this service when
EOSIO vulnerabilities found by hackers affect other software using the included libraries. ³
D) Deliverables
3. Well defined bug bounty.
a. Well defined vulnerability classification and severity scope with associated bounties.
b. Well defined rules around what constitutes a bug.
c. Well defined procedures on how to submit bugs.
d. Well defined communication methodology to ensure timely communication between
Foundation and hacker/security community.
4. Bug Bounty Frontend.
a. Web frontend + Mobile friendly platform for hacker/security community showcas-
ing the EOSIO bug bounties available, leaderboards, bounty definitions and how to
submit bugs.
5. Method to communicate high vulnerability bugs.
a. Research with other EOSIO chains on how best to manage high vulnerability bugs.
E) Level of Effort
The effort to bring this to life, will consist of a very well defined bug bounty with an attractive
website and UX. You want to make submitting bugs easy for the security community. Another
important aspect that will require further research is how to communicate high vulnerability
bugs to all other EOSIO chains.
• Prerequisites:
• Foundation and other EOSIO chains will need to decide on bug bounty levels and
associated bounty. Including the severity attached to each level. Since this initiative
applies to all chains, the cost of running this service should be shared.
34
EOS Audit+

• The bug bounty site will also require a dedicated core development team of EOSIO
to evaluate incoming reports and decide bug bounty levels and co-ordinate security
upgrades if required.
• The core EOSIO developers will need to be in agreement to manage the bug
bounty programme.
• Bug Bounty Funding:
• In Addition to the MVP product, any bugs found by the security community will have
compensation attached. There is no easy way to predict a budget for the compensa-
tion that will be paid out.
• Estimated Hours: 260 hours
• Estimated costs: $16,625 + Bug Bounty Funding
• Fullstack Developer - 105hrs @ $75 per hour ($7875)
• Project Manager - 5 hrs @ $50 per hour ($250)
• Content Writer - 50 hrs @ $15 per hour ($750)
• Smart Contract Security engineer 20 hrs @ $200 per hour ($4000)
• Frontend Designer - 50 hrs @ $75 per hour ($3750)
1. Design Frontend (Frontend Designer - 50 hours)
a. Design frontend UX
2. Define Bug bounty (Content writer - 50 hours, Smart Contract Security engineer 20 hours)
a. Define bug bounty levels and the associated bounty, including an example of what
constitutes a bug in each level.
b. Define severity attached to each level.
3. Method to communicate high vulnerability bugs ( Project Manager - 5 hours )
a. Setup meeting with other EOSIO chains to start researching methods to manage high
vulnerability EOSIO bugs.
35
EOS Audit+

4. Develop Frontend (Fullstack Developer - 75 hours)
a. Create a single Page listing all information related to the bug bounty.
b. Create a leaderboard page listing the top bug bounty hunters.
5. Docker: (Fullstack Developer - 20 hours)
a. Dockerize the frontend for easy deployment and testing.
6. Submitting bugs form (Fullstack Developer - 10 hours)
a. Simple Google form to submit bugs.
G) Future Goals
• Expand the bug bounty programme to allow any dApp on EOSIO to create their own mini
bug bounty. This will further encourage security researchers to actively feed back on
discovered vulnerabilities.
• ¹https://ethereum.org/en/eth2/get-involved/bug-bounty/#rules
• https://guidovranken.com/notable-vulnerabilities-found-in-high-profile-software/
• ²https://twitter.com/etherchain_org/status/1431256423489495045?s=20
• ³https://www.telos.net/news/telos-evm-uncovers-ethereum-vulnerability
36
EOS Audit+

6. Build automated security auditing tools.
A) Problem
Currently in the EOSIO community there are no freely available tools to allow developers to as-
sess the basic security of their smart contracts. Some tooling does exist but are neither open
source nor free of charge.1
B) Objective
What we propose is to create an open source tool that is actively maintained that allows any-
one to run the tool against an open source smart contract written for EOSIO and be provided
with a report on how the contract fairs against current well known vulnerabilities.2 | 3
The tool should be free of charge, easy to install and quick to provide results.
The results provided should be clear and references provided that help the developer under-
stand how to resolve these issues. Ideally this should be linked back to another initiative: List
of common security pitfalls when writing EOSIO smart contracts. This will ensure a common
knowledge base to prevent documentation becoming to disperse.
Having such tooling available promotes self diagnosis and develops the knowledge of the
developer community around common security pitfalls to avoid. In the long term this cre-
ates a self perpetuating advancement around EOSIO security amongst the developer and
security communities.
37
EOS Audit+

D) Deliverables
7. Automated security auditing tool.
a. Build a security auditing tool in python that is modular to allow for easy contribution.
b. Tool should provide reporting and reference knowledgebase of how to resolve issues.
c. Tool should be easy to install and the installation process documented.
d. Tool should analyse smart contract and identify areas where contract is exploitable
based upon commonly known vulnerabilities.
E) Level of Effort
The level of effort involved here is considerably higher than the other initiatives, as it will re-
quire some pre-planning on how best to approach this tool.
• Prerequisites:
• Further research should be done on how best to create a base tool that is modular to
allow for external contributions and continued development.
• Ideally the initiative called List of common security pitfalls when writing EOSIO smart
contracts, should be completed prior to attempting this project.
• Estimated Hours: ~1550 hours
• Python Developer - 1050 hrs @ $50 per hour ($52500)
1. Automated security auditing tool. (Python Developer - 1000 hrs, Smart Contract Security
engineer 500 hrs)
a. Build a basic security auditing tool in python.
b. Tool should be modular to allow external contributions to add additional
security checks.
38
EOS Audit+

c. Installation instructions should be easy to follow.
d. Tool should be setup on Git.
2. Reporting. (Python Developer - 50 hrs)
a. Tool should provide basic reporting and include links that reference the list of common
security pitfalls.
• ¹https://klevoya.com/inspect/index.html
• 2https://github.com/crytic/slither
• 3https://github.com/ConsenSys/mythril
smart contracts
A) Problem
When writing smart contracts, the most common security pitfalls are the easiest to avoid with
adequate access to a shared knowledge base. There is no real documentation that exists on
these types of mistakes.
This is a very common feature in other major blockchains and we feel a must
have requirement.¹
Initiative Type Documentation
39
EOS Audit+

Some examples of this are available in EOSIO:
https://github.com/slowmist/eos-smart-contract-security-best-practices/blob/master/
README_EN.md
https://cc32d9.medium.com/eosio-contract-security-cookbook-20210527-69797efe9c96
B) Objective
An actively maintained list of common security pitfalls that developers can refer to when writ-
ing smart contracts. ²
The benefits to this type of documentation is giving developers the re-assurance when devel-
oping their smart contracts that they are thinking of the latest threats on EOSIO.
D) Deliverables
1. List of common security pitfalls when writing EOSIO smart contracts.
E) Level of Effort
The initiative is to provide a document or wiki that can be actively maintained with version
tracking that lists the most common security pitfalls when writing EOSIO smart contracts.
• Prerequisites:
• n/a
• Estimated Hours: ~455 hours
• Estimated cost: $54000
• Content Writer - 200 hrs @ $15 per hour ($3000)
40
EOS Audit+

1. Common security pitfalls: ( Smart Contract Security engineer - 250 hrs, Content Writer-
150 hours )
a. Create a list of 10 known common security pitfalls that include:
I. Description of the type of attack.
II. Example source code where the mistake has been made.
III. Vulnerabilities that this could lead to
IV. Any real life examples if available.
2. Created on a distributed version control system like GIT. ( Smart Contract Security engi-
neer - 5 hrs, Content Writer- 50 hours )
a. Setup Git Repo for version control
b. Setup Gitbook to act as Wiki.
G) Reference Material
¹https://blog.neodyme.io/posts/solana_common_pitfalls
²https://github.com/sigp/solidity-security-blog
https://cc32d9.medium.com/eosio-contract-security-cookbook-20210527-69797efe9c96
https://github.com/slowmist/eos-smart-contract-security-best-practices/blob/master/
README_EN.md
41
EOS Audit+

5. A list of recommendations to
the foundation on the best course
of action.
The 4 initiatives proposed here are based on all our research around not only what EOSIO
requires, but also what is demanded by other communities in the blockchain space.
Recommendations 1-3 form the base requirement that any new blockchain tries to adapt to
promote a healthy foundation to build upon from a security point of view.
Recommendation number 4 is a relatively new proposal we have seen made in Ethereum. It
would be very advantageous for EOSIO to adapt this type of approach. EOSIO core technology
has several distinct advantages making it easier to adapt this type of solution. Albeit a large
undertaking and will require multiple stakeholders across all working groups to decide on the
best approach it will have a profound effect on the underlying trust of the system.
smart contracts
Justification:
This is a very easy win and a good start to help steer the developer community into creating
robust and secure smart contracts. It also acts as a base for future tooling such as the auto-
mated security toolset.
Cost Projection:
MVP cost:
• Cost: $22500 for the initial MVP.
Ongoing costs:
• Cost: $22500 per year to ensure the list is kept up to date.
42
EOS Audit+

There will be ongoing costs to ensure the list is continued to be updated. Some of the work
will come from the developer community since the list will be open source, but the Foundation
should get dedicated contractors once or twice a year to ensure the list is updated.
2. Software libraries for secure smart contract development
Justification:
This is an essential part of the developer community and similar to the common security pit-
falls list initiative , this also helps foster best practice around writing secure smart contracts.
Cost Projection:
MVP cost:
• Cost: $152,500 for the initial MVP.
Ongoing costs:
• Cost: $50,000 per year to ensure the tooling is kept up to date.
Ideally the tools are kept up to date by the developer community, but the Foundation should
get dedicated contractors once or twice a year to ensure the tools are kept up to date with the
latest security issues.
3. Bug bounties
Justification:
To ensure the underlying EOSIO core software is robust from a security perspective we need
to attract the external security community to continuously test EOSIO codebase.
Cost Projection:
MVP cost:
43
EOS Audit+

Ongoing costs:
• Cost: unknown
The management of the bug bounties will require agreement from the core EOSIO developers
which is a separate discussion between B1 and the Foundation and as such we cannot provide
a cost projection for the ongoing maintenance of the platform.
Addition the management there is also the cost of compensating for the security bugs found
which again cannot be predicted, hence the costs here are left as unknown.
4. Open source security audit API and platform
Justification:
Builds a robust security platform that almost no blockchains has, which would put EOSIO on
the forefront of giving users some peace of mind when interacting with EOSIO dApps.
Cost Projection:
MVP cost:
Ongoing costs:
• Cost: $50,000 per year to ensure the platforms are kept up to date
After the platform is build the bulk of the work will be done, but the different platforms and
standards should be updated to stay aligned with the requirements of the EOSIO ecosystem.
44
EOS Audit+

6. Appendix
Application Binary Interface (ABI): an interface between two program modules of a smart con-
tract. Application Programming Interface
(API): a software intermediary allowing programs to communicate with one another.
Bug Bounty: A bug bounty program is a deal offered by many websites, organizations and soft-
ware developers by which individuals can receive recognition and compensation for reporting
bugs, especially those pertaining to security exploits and vulnerabilities.
DAO: A decentralized autonomous organization (DAO), sometimes called a decentralized au-
tonomous corporation (DAC),[a] is an organization represented by rules encoded as a comput-
er program that is transparent, controlled by the organization members and not influenced by
a central government
dAppS: Decentralized applications (dApps) are digital applications or programs that exist and
run on EOSIO blockchains.
DeFi: Decentralized Financed based applications.
Fuzzing: Fuzzing or fuzz testing is an automated software testing technique that involves
providing invalid, unexpected, or random data as inputs to a dApp or computer program. The
dApp or program is then monitored for exceptions such as crashes, failing built-in code asser-
tions, or potential memory leaks.
Software development kit (SDK): is a collection of software development tools in one installa-
ble package that facilitates the development of programmes.
WebAssembly (WASM): a portable binary code format for efficient operation of
web applications.
45
EOS Audit+

Audit+ Blue Paper (English)

Recommended

Recommended

More Related Content

Similar to Audit+ Blue Paper (English)

Similar to Audit+ Blue Paper (English) (20)

More from ZackGall1

More from ZackGall1 (6)

Recently uploaded

Recently uploaded (20)

Audit+ Blue Paper (English)