EthTrust Community Group

What is EthTrust?

The EthTrust specification describes all known security vulnerabilities that can appear in Smart Contracts written in Solidity for the Ethereum blockchain. It is designed from an auditor's perspective - what should you check for?

The current Editor's Draft follows the publication of version 3 in May 2025, and is expected to be the basis for a version 4, to be released "when it's ready".

Why not "critical", "moderate", etc?

The EthTrust spec does not assign a priority for vulnerabilities. The primary reason is that this is very context-dependent: What might be a critical problem in one project, because it is central to the entire operation, could be a minor concern in another, because it is very hard to exploit and can only impact relatively unimportant information.

Instead EthTrust divides requirements roughly according to the kind of checking necessary to find them:

Level [S]: These are requirements that can be detected by "static analysis" - relatively simple software could test these reliably, or a person can find them with only a basic level of solidity knowledge.
Level [M]: These require some understanding of Ethereum and Solidity to interpret and correctly identify reliably.
Level [Q]: A substantial amount of good judgement is necessary to identify and assess these requirements. As well as basic vulnerabilities this level covers quality issues that can impact medium and long-term security.
Good Practices - "level" [GP]: This is what it claims. Good Practices, that if done right can improve security, sometimes significantly. These are not sorted into the normal Levels structure because they are not strictly vulnerabilities, but it is also important to understand that it is possible to do these badly, and that doing these things badly can provide a false sense of security or even actively reduce the level of security.

How do we work?

WORK IN PROGRESS. This is still being sorted, but based on years of experience there is a plan that continues the spirit of the last 5 years of development.

The specification draft is in this GitHub repository, and the base working model is:

Raise and discuss issues: Describe something that needs to be addressed - a vulnerability the spec doesn't identify, an explanation that is insufficient or doesn't make sense, something that would make it easier to understand or implement...; The optimal way to do this is through the Issues in this repository.
Propose a solution: Typically, this means a change to the specification, or some associated documentation.; The ideal way to do this is a Pull Request, but it can also be done in the issue discussion, or however else you can communicate it to the group.
Agree on a solution: The group tries to reach "lazy rough" consensus. This means that there are no strong objections, and there is real support, at least far more than for alternatives proposed.; The mechanics of decision-making include discussion at meetings as well as in the repository. Ultimately, it depends on the chair accurately guaging the consensus of the participants.

Where did it come from

The EthTrust project began as an effort to show that Smart contracts had been audited, a goal similar to ERC-7512. (There is a website at ethtrust.org that appears to be a link to assorted gambling sites, but maintains some of the 2019 content). Although code was written, the project did not take off, and was eventually handed to EEA to see if they could lead it to success.

The EEA pivoted from the need to identify audited contracts to the need for a basic auditing standard. Thus the EthTrust specification was developed, covering code written in Solidity - the vast majority of Smart Contracts on the Ethereum blockchain.

The project developed the work of the Smart Contract Registry (long outdated but available at swcregistry.io). As the EEA spec began taking shape in 2020 that project stopped being maintained by its developers. Everything in SWC was eventually covered by EthTrust, as were the entire collection of Solidity Compiler bugs, otherwise most easily found in a Javascript file and series of blog posts maintained by the developers of the Solidity compiler. Over time, various other sources of vulnerabilities were scoured, along with the experience of a broad range of expert contributors.

The EEA had stopped maintaining the specification by the release of version 3, in May 2025. Beginning in April 2026, the EthTrust Community Group was created to maintain the specification through an open public process.

Who has worked on it?

The published versions of the specification each attempt to thank all the individuals who contributed to that specific version:

Among the companies and organisations that have participated in or actively supported the work are:

Abbaccio
Banco Santander
DTCC
CertiK
ChainSecurity
Coinspect
Consensys Software Inc.
Consensys Diligence
Creed
Cube3.ai
Enterprise Ethereum Alliance
EY
Fly You Fools
Hacken
JP Morgan
Kauz Security Services GmbH
LACChain
Max Planck Institute for Security and Privacy
Microsoft
NVISO
Olympix.ai
OpenZeppelin
Quantstamp
Runtime Verification
SAE
SigmaPrime
Splunk
Trail of Bits
TMIO

Please note that having participated or supported in the past does not necessarily imply an organization's support for the current project or state of the specification.

How can I help?

The EthTrust Community Group is set up as a W3C Community Group. Anyone can join, by getting a W3C Account (free, but you have to agree to the conditions).

There are many ways to help:

Review the specification, make comments ("looks good to me" is helpful feedback, just as raising an issue is).
Implementing requirements in tools or workflows helps understand whether they are appropriately designed and explained. We will attempt to list known implementation, and particularly welcome feedback on what made it easy or difficult, that we can use to improve the specification.
Developing Tests that others can use to check their implementations, understand the specification, or benchmark their evaluation of specific points, can all help improve how consistently different people apply the specification. We will attempt to list known tests and examples, whether they are primarily developed for machines or for people.
Explaining, Translating, Mentioning the specification in contexts where the group has little presence is generally helpful.