Security Overview
We make all possible efforts for keeping our smart contract secure and safe.

Tests

We using Hardhat framework with typescript configuration.
Test framework - Mocha.
All test code has strict typification with typechain that dramatically reduces possible mistakes.
Over 200 tests for the base functionality and over 600 tests for strategy implementations.

Static analyzers

All code checked with solhint and slither

Test environment on Rinkeby

We have fully functional deployed code on Rinkeby test net.
Every business logic was tested on deployed contract with additional tests.
You can always try the last version contracts/UI on https://staging.tetu.io/

Audit

We have been audited with DeFiYield.App
Detailed information you can find here

Central governance with GnosisSafe

We don't have any access to users' funds.
All critical contracts that keep users' funds have 48 hours Timelock.
Any actions that can change critical contracts state under the control of MultiSig wallet 3/4.

Contract monitoring

We use https://tenderly.co/ for monitoring any unusual activity

Strict checking external platforms contracts

Each strategy development includes not only implementing base functionality but analyze the farmable platform and fetching all critical metrics.

Possible attack vectors and defense

Flash loan / Arbitrage

Currently, we are not eligible for this kind of attack.
However, we have whitelist protection for deposit operations for our Vaults.
It makes impossible any kind of attack with assets manipulations.

Re-Entrancy

Currently, we are not eligible for this kind of attack.
If we will use untrusted external calls we will implement OpenZappelin best practice protection.

Arithmetic Over/Under Flows

All math operations use OpenZappelin library SafeMath

Functions visibilities

All critical functions checked with unit test their unavailability to usage from non-governance address.

Race conditions / Front running

User's assets are not eligible for this kind of attack in our contracts.
However, reward selling, theoretically, can be frontrunning with the sandwich bot.
For this reason, we will use secured RPC providers like https://taichi.network/
And wrap our calls to other contracts for hiding execute actions.

Denial Of Service (DOS)

Currently, we are not eligible for this kind of attack.
We don't use any loops with external changeable arrays.
External calls have no way to provide DoS for our contracts.
Any new integrations will be checked for this kind of behavior.
Any ownership changes in our contracts have unit tests and can't lose control unexpectedly.
Our contracts are under the control of MuliSig wallet and any operations will be double-checked with our team.

Floating Points and Numerical Precision

Any calculations triple-checked with different numbers and have 100% test coverage

Timestamp Dependence

We do not have any calculations that are possible to get additional money with logic based on block timestamp.

Other Possible Contract Weakness

Other possible attack vectors are too rare, out of date, or obviously covered with unit tests / static analyzers.
Last modified 2mo ago