Audits from Trail of Bits give organizations ways to fix their current issues and provide them with a roadmap to prevent the same security problems from occurring in the future. However, product teams don’t always implement the recommendations. This may be due to a lack of resources, a lack of institutional motivation, or several other internal reasons. Even when action is taken, progress can be difficult to measure.

We now have a way organizations can measure that progress. The Rekt Test provides a framework for an informed conversation that, if moderated by experts, can allow an organization to get a fuller picture of the risk presented by a blockchain project. Modeled after the The Joel Test, an organization should try to answer ‘Yes’ for as many of the below questions as possible before going public with a new blockchain venture. The more an organization can answer ‘Yes’ to these questions, the more stable its security foundation should be.

The Rekt Test

  1. Have you documented all actors, their roles, and their privileges?
  2. Does your key management system require multiple humans and physical steps?
  3. Do you have a written and tested incident response plan?
  4. Have all employees undergone positive identification and background checks?
  5. Does someone on your team have security defined in their role?
  6. Does access to production systems require hardware security keys?
  7. Do you use the best automated tools for discovering security issues in your code?
  8. Have you defined key invariants for your system and do you test them on every commit?
  9. Have you received an external audit and do you run a vulnerability disclosure or bug bounty program?
  10. Have you documented all the external services, contracts, and oracles you rely on?
  11. Have you documented the best ways to attack your own system?
  12. Have you considered and mitigated avenues for abusing users of your system?


1. Do you have all actors, their roles, and privileges documented?

It’s crucial to understand who is operating in your environment — users, developers, miners, validators, and other stakeholders — and the breakdown of their unique responsibilities, tasks, permissions and other duties that may be performed. This should be documented in a clear and concise manner, so an organization can easily identify when a security incident is happening.

2. Do you employ a multi-factor human and physical key management system?

The keys to your wallets are always going to have a target on them. For protection, we recommend implementing a two-factor authentication system for users, using both physical and digital backups, and applying a multi-signature system for transactions.

For multi-signatures, we suggest a consensus requirement for a sensitive action, like spending funds out of a wallet. This is to mitigate the risks of any singular party’s judgment overruling others, any singular party’s mistake causing a failure, and any singular credential compromise causing a failure.

3. Do you have a written and tested incident response plan?

While security in the blockchain space is different from traditional enterprises, an incident response plan is a proven practice that will enable your organization to be resilient in the face of a security incident. The plan should include steps to identify, contain, and remediate the incident, through both automated and manual procedures. An organization should have all team members familiar with the plan, including both internal and external communication channels. This plan should be regularly tested to ensure that it is up-to-date and effective, especially given how quick the blockchain security world can change. As an example of what this traditionally looks like, Carnegie Mellon University has posted their plan online.

4. Do you perform identity verification and background checks on all employees?

This is where your human resource officers can help with your security posture. While organizations should be conducting the standard checks — criminal background, employment history, credit check, reference check — a social media background check can unearth behavior that could be problematic from a security perspective. A little OSINT could go a long way.

5. Do you have a team member that has security defined in their role?

Answering “yes” to this isn’t as simple as hiring a CISO. (Although that’s better than nothing!) Whether it’s developing something new or updating something that already exists, security cannot be a side gig on someone’s job responsibilities. There needs to be a dedicated person in the organization that can take the lead on making sure a product or service is as secure as possible. This person should also be deeply involved in getting an organization to “yes” on other questions in this list, particularly incident response plans and using the best tools currently on the market.

6. Do you require hardware security keys for production systems?

Let’s not mince words: if your internal credentials are leaked or stolen, the fallout will be harsh. Using SMS codes for two-factor authentication is not good enough for the credentials guarding your code. There are several different options that support a wide range of authentication protocols, which will make your business-critical code repositories highly secure and resilient to breach attempts. YubiKey and Google Titan are two good choices for hardware keys.

7. Do you use the best automated tools for discovering security issues in your code?

If organizations are going to be constantly testing their security, they are going to need tools that can keep up with the industry’s best practices. Trail of Bits has a wide suite of tools and documentation that will allow you to stay current in your security posture:

  • Echidna, a smart contract fuzzer
  • Slither, a static analyzer for solidity
  • Circomspect, a static analyzer and linter for the Circom programming language
  • Amarna, a static analyzer and linter for the Cairo programming language
  • Building Secure Contracts, guidelines and best practices to write secure smart contracts
  • ZKDocs, comprehensive, detailed, and interactive documentation on zero-knowledge proof systems and related primitives.

An organization will be unable to stay current in their security posture if they don’t have tools that can find the biggest security issues in the industry. While we want you to use our tools, any tools that work within your products and services is better than using traditional software security tools that aren’t suited for the blockchain.

8. Do you define key invariants for your system and test them on every commit?
For those unfamiliar, an invariant is a condition or value that remains unchanged throughout a program’s execution. It is used to ensure that the program behaves as expected and that the results are consistent. As you develop new features, your organization should be testing to see if the new code plays nice with these invariants. These could be tied to things like cryptographic hash functions, consensus mechanisms, transaction validation, transaction privacy or other network security functions. By continually testing, you are constantly given the opportunity to find issues in your system before an attacker does.

9. Do you undergo external audits and maintain a vulnerability disclosure or bug bounty program?

Getting an external audit will positively compound your security posture, both internally and externally. An audit will allow experts with a fresh perspective to search for and fix vulnerabilities that an internal security practice may not be aware of or have the expertise to uncover. Whether the audit falls on the actual smart contract or the components supporting the contract, it will also provide assurances to the public that your organization is taking the necessary steps to independently verify that your security is as good as it can possibly be.

A vulnerability disclosure or bug bounty program is an additional way to enhance your security posture. Leading blockchain and web3 companies have set these programs up as a way to tap into the public’s security expertise and address potential issues before they become a problem. Some examples are:

By leveraging the public’s security expertise, organizations can save money on security testing and bug fixes. The fallout from a security incident could be exponentially higher than the payouts attached with the most-critical bugs found in these programs.

10. Do you keep documentation of all the external services, contracts, and oracles you rely on?

An organization can have the best security procedures integrated into their own development and still be the victim of a destructive security incident. The blockchain industry has seen this repeatedly:

Documenting your full exposure to external parties should be part of your incident response plan, including a point-of-contact for your security team to reach out to in case of an incident.

11. Do you document the best ways to attack your own system?

The best method to figuring out an answer to this question is by constructing a threat model for your organization. With a threat model, an organization can gain a visual for its entire environment that provides assurance on where the weak points are. A threat model can also be a force multiplier: The information gleaned from the model can then be used to build and/or refine your incident response plan. It can also be used as a litmus test against your development and feature implementation choices for months or years at a time.

12. Do you identify and address potential avenues for users who abuse your system?

Your security posture should have some built-in checks that operate under the assumption that at some point, someone is going to try to meddle with your system. While your organization may differ from your peers in the way it implement its security, the following list is a good starting point in proper user behavior:

  • Implement a KYC process to ensure user identity
  • Consider a reputation system to track user behavior
  • Establish escrow accounts to ensure funds are held securely in the event of a security incident
  • Monitor relevant chains for suspicious activity and shut down users in the event of bad behavior

These are not the only actions that can determine your project’s security posture. Given how fast the blockchain industry changes, today’s best practices may be worthless six months later. Additionally, answering ‘Yes’ to these questions doesn’t mean you will completely avoid a security incident. However, it’s extremely important to set internal benchmarks that can grant you resiliency in the face of changes in the blockchain security space or an attempt to attack your products and services. Answering the above questions will empower blockchain organizations to steer clear of the worst label in the industry: getting rekt.