Technical Overview

An overview of DeFunds contracts and mechanics

Architecture

The main contracts of the platform are:

Addresses of these contracts are available on this page. DeFunds platform uses USDT as a base currency, here are addresses for supported networks:

Another important component of the system is the trigger server, that is hosted by DeFunds and is authorized to make certain operations. Let's examine each component separately.

Upgrader

Most of core DeFunds contracts are implementing the Proxy pattern, specifically inheriting from UUPSUpgradable and OwnableUpgradeable. The Upgrader contract is the only contract, that is able to upgrade the set of DeFunds contracts. The Upgrader itself is not upgradable. Thus the platform logic can be updated in a single transaction with guaranteed delay. Investors will be notified in advance in case of contract updates, and will be able to withdraw their funds in case of unwanted changes.

Currently these contracts are upgradable through Upgrader:

  • Trade

  • Feeder

  • Interaction

  • Fees

  • DripOperator

  • FundFactory

  • Registry

Registry

The Registry contract stores all contract addresses, that are used along the platform. This contract is upgradable only through Upgrader.

Trade

Trade - is the core contract in the DeFunds platform. Every fund has its own instance of Trade contract with the separate address - it is usually deployed through BeaconProxy. Only manager and trigger server are authorized to execute methods related to trading, but both of them are not able to withdraw assets from Trade contract. Withdrawing assets from Trade contract is not available for anyone, except Interaction and Feeder contracts - they need to cover expenses during report.

Every Trade instance stores settings and permissions of the fund, like allowed tokens and services. Manager is authorized to trigger the settings update, but it also goes through guaranteed delay and users notification. These settings are storing in a form of bit mask, where every bit means:

  • For tokens - whether the token with the index of the bit is enabled or not

  • For services - whether the service with the index of the bit is enabled or not (the order is: 0x, GMX, AAVE)

TradeParamsUpdater

Only this contract is authorized to update Trade contract settings, like allowed tokens or services.

FundFactory

The FundFactory is used for creating funds through the main newFund method. Usually it is called by manager through the client. Everyone is able to create a new fund through FundFactory. Once newFund is called, the new Trade instance is created using BeaconProxy, as well as ERC20 instance for the fund known as ITKN is also deployed in the same transaction.

Interaction

Interaction contract is the main entry point of the platform. Investors use this contract to make deposit or withdrawal request, as well as to receive aggregated fund properties through pendingTvl getter. It also handles logic related to opened/closed funds.

DripOperator

The DripOperator contract handles the report flow. It handles logic, related to big reports, that can't be processed with a single transaction. It contains the only one method drip, that needs to be called N times, until it returns true, which means that report for the fund is successfully done, and there are no unprocessed operations, like deposits or withdrawals, remained for this fund.

Only trigger server is authorized to call the drip method. The TVL parameter is calculated off-chain, using data from external services contracts, and prices from the coinmarketcap.

Feeder

The Feeder contract is used to distribute money during report. It handles the core functions, such as:

Fees

The Fees contract accumulates all fees and contains methods to calculate them. Manager of fund is authorized to access the Fees contract to withdraw the accumulated fee. For more details about the kinds of fees, you can read here. The funds held in the contract are strictly divided into fund managers' assets and the service fee. Only the fund manager has the right to withdraw their profits, just as only DeFunds has access to withdraw the accumulated service fee.

ITKN

It is a regular ERC20 token, that have 1 to 1 relation with funds, which means that every fund has its own instance of ITKN. Owning this token means ownership of shares in the fund.

Whitelist

The Whitelist is used to store the global whitelist of the platform. Only DeFunds is authorized to edit the content of the whitelist. It is possible to add or remove tokens from the Whitelist. Adding token to the list does not mean supporting token by all existing funds - it requires a separate change from manager and a delay, before the change is applied. Every token has its unique index.

Last updated