Comment on page

Internal Security

Closed testing – internal audit

We make the inner team of testers and auditors inspect the quality of work code as purely as possible to make sure that there are no backdoors.

High requirements for the team professionalism

We engage only reputable teams of developers with relevant work experience.

Peer Review

We invite DeFi, cryptography and blockchain professionals and experts, to review the changes being made. Each update must be reviewed by an independent expert to exclude design errors.

Closed user testing of new functions

Any user can be a member of an independent group of testers and be the first to get access to tested, new project features. All the identified malfunctions will be fairly paid from the Bug Bounty Fund.
The Bug Bounty Fund is used to reward a team of testers and independent hackers for identified vulnerabilities, errors in code mechanics and inefficiencies, program code errors of one of the project's modules.
We offer from 10 USD in $8F for a detected typo in the text on the site, up to 1,000,000 USD in $8F for critical errors threatening the project's existence.

Open Source orientation

We are for top transparency of our project, including our code transparency. We use proven Open Source developments and also actively share our innovations on Open Source sites for public independent audit and testing, copying and distribution of high-quality ideas and code.

No migration code

We choose secure DeFi! Funds for staking and farming will always belong to you. We have no migration code: no one will be able to withdraw funds from the account except the user.

Timelock for changing

All the changes related to a smart contract go through a 72 hours timelock before entry into effect. Timelock countdown begins after the code has already passed an internal audit, external auditor's check, and has been tested together with the test team. Only after that, at the last stage the update code becomes open for public verification. Within the 72 hours timelock anyone will have the opportunity to verify the safety and reliability of the code and timely report potential problems to us and the community.

Saving the code changes history in a smart contract

Code change history is an important tool for understanding what changes took place and why. This end-to-end supervision by internal audit team, third party expertise and audit, and ordinary users ensures an efficacy of future changes to the code and absence of hidden bugs.

Protection from DDoS attacks

Protection against this type of attack is a part of the basic security toolkit of any respected project. 8.Finance is not an exception. We provide protection against any high-frequency requests to our servers and gateways.

Fire drill documentation including records of tests

Access to the project protocol for urgent changes (without timelock) is performed through the MultiSig signature of the project owner. Access is monitored by the DefiSafety auditor.
DefiSafety monthly conducts “fire drills” and creates a protocol access request to capture the response time of owners accessing the protocol via the MultiSig signature. The drill recording and test results are available for public.
Such a check is necessary to publicly confirm the availability of access to the protocol and the readiness of the team to make operational changes to the protocol in case critical vulnerabilities are identified, to solve which require urgent actions.

Uptime online monitoring of the site state

We perform a continuous 24/7 quality control of the site and promptly solve all the arising problems. Monitoring is done by reputable independent provider, uptimerobot. The monitoring status is public. It can always be found on the home page of the site and on the uptimerobot site via the link here.

Stress testing before launch and after each update

Stress testing is an important element of guaranteeing platform no-failure operation. We perform stress testing after deploying each new update to identify the bottleneck and take the necessary measures to address the scaling issue. Cryptocurrency projects are able to obtain a huge user base within days. Under these conditions, it is important to understand the bandwidth of all the sites, gateways, and the blockchain itself to form a bandwidth reserve in advance and evenly distribute the load.

Formal verification test of tokenomics model

It is a mathematical testing of the tokenomics model for fault tolerance and work efficiency. Before the project launch, we performed such a check with several competent experts:

Full test suite (launch is scheduled for the second phase of the project development)

Our test group develops and updates a set of test behavior models to solve the problems of testing the correct operation of the platform and its individual elements. The test suite includes detailed instructions or targets for each set of test cases and information about the system configuration to be used during testing. Assemblage of tests is open for public use and verification by anyone.

Scripts and instructions for test launch by user

The project team creates a separate instruction for a fresh user on step-by-step testing of the platform and its individual elements using the test suite at home.