Security Overview

Tetu's development team makes every effort to ensure that smart contracts are safe and work as expected.


We are 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

Fully functional code are deployed 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


Tetu is audited by DeFiYield and PeckShield.

Central governance with GnosisSafe

Tetu team doesn't have 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 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 the fetching of all critical metrics.

Possible attack vectors and defense

Flash loan and Arbitrage

Currently, Tetu's smart contracts are not eligible for this kind of attack.

Our vaults have whitelist protection for deposit operations.

This makes the likelihood of any type of attack involving asset manipulation impossible.


Currently, Tetu's smart contracts are not eligible for this kind of attack.

In case we use untrusted external calls, OpenZappelin best practive protection will be implemented.

Arithmetic Over/Under Flows

All math operations use OpenZappelin library SafeMath.

Functions visibilities

All critical functions checked with unit testing for unavailability for use on non-governance addresses.

Race conditions / Front running

User's assets are not eligible for this kind of attack in our contracts.

However, reward selling, theoretically, can be target of front running from sandwich bots.

For this reason, we use secured RPC providers like

And wrap our calls to other contracts for improve the protection of smart contracts' actions against front running.

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 MultiSig wallet and any operations will be double-checked with Tetu 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 and static analyzers.

Last updated