Frequently Asked Questions

  • Audits

      What is the process of an audit?

      After the client contacts HashEx, the company reviews the code and estimates the price. Then the audit is conducted and a preliminary report is formed. After that, the report is returned to the team and they review it and fix the issues. The final step is the final audit report that is published on HashEx social media.

      What types of contracts does HashEx audit?

      HashEx audits contracts of any difficulty: Contracts for the token Standards ERC20, ERC721, ERC1155 Aside from tokens, HashEx audits smart contracts for DAOs, staking, NFTs, DApps, DEXs, Farms (MasterChefs and others), Lending, marketplaces, auctions, games, bridges.

      What languages does HashEx audit?

      HashEx performs audits for Solidity and Rust languages. Requests for other audits can be discussed by contacting our team.

      What blockchains does HashEx work with?

      HashEx audits contracts for most blockchains that use Solidity and/or Rust languages: Ethereum, BSC, Solana, Avalanche, xDai, Near, Aurora, Terra.

      Does a passed audit mean that the project is safe?

      A finalized audit, unfortunately, does not guarantee project’s safety. Before investing it’s good to recheck the existing issues and vulnerabilities, presented in the audit report. It also helps if the project’s lp is locked, and the project’s team is known publicly or has passed a KYC by a tire one security company.

      How to read a HashEx audit report?

      HashEx report consists of several blocks: aside from disclaimer, HashEx reviews submitted contracts, outlining the main issues in each contract. Auditors state the issue and present a short description with the potential danger of said issue. Note that there is a table of contents, in this case, audited contracts. It’s important to make sure that all the contracts have indeed been audited and that a client didn’t add new ones that haven’t been reviewed.

      What separates a HashEx audit from any other one?

      HashEx team has a rich background in DeFi security. The company itself has over 4 years of experience in DeFi security and has performed over 500 audits. Our team of auditors has a vast library of known issues and thanks to manual reviews, they have the ability to find even minor errors. The reviews are performed first by an automated tool, then by two separate teams. This process is aimed at eliminating the possibility of missed vulnerabilities.
  • Development

      What types of contracts does HashEx develop?

      HashEx works with the most well-known types of smart contracts, primarily on Solidity and Rust languages. For inquiries on development in other languages, please contact the team. Among successfully developed contracts there are fungible token contracts, NFT contracts, DAOs and Farms, Staking and Vesting contracts, and many others.

      What is the development process?

      After the client approaches HashEx, we develop a vision of what the contract has to represent. We determine the type and language, the goals, and specific details. Then we develop the contract and test it. After that step, the client receives the finished product.

      What else does HashEx Develop?

      Aside from smart contracts, HashEx specialists develop simple and sophisticated dApp solutions, that include smart contracts as well as front-end and back-end.
  • Testing

      How does HashEx test smart contracts?

      As a part of the development process, HashEx always writes unit tests aiming to achieve 100% coverage. While developing back-end and front-end of a DApp, HashEx developers employ special automated testing scripts and manual testing by an experienced team. HashEx also provides fuzzing services upon request.

      What testing tools does HashEx use?

      HashEx tests smart contracts using several tools. Mostly, the developer team uses Hardhat, within which they apply a stack of ethers.js, waffle, and mocha. If further issues present themselves, and additional testing is required, other tools may be involved. If it’s imperative to test a contract, considering the real network data, the team does so using a mainnet fork. For Fuzzing HashEx testers use Echidna.