How does DeFiHelper work? A Detailed Explanation
DeFiHelper (DFH) is an advanced assistant for managing DeFi portfolios of any size.
Our core product functions include auto-staking and no-code automation. DFH also provides a comprehensive overview of the entire portfolio across chains, separates volatile tokens from stablecoins, monitors impermanent losses, and reports on sudden changes in profitability. Users will also soon be able to find ready-made, highly profitable investment strategies on the DFH marketplace or create their own and earn a percentage of the profits received from the users who apply them.
In this article, we will give a detailed explanation on the DeFiHelper architecture and how it works.
The protocol consists of two distinct layers.
The first basic layer is the DFH governance token, the governance system and the voting process. This layer is powered by the Ethereum network.
The second layer is automation at the level of each individual blockchain. The protocol works with the Ethereum, Binance Smart Chain, Polygon, Avalanche, Waves and and more blockchains will be connected in the near future.
Why did we choose this architecture? At the design stage, we formulated several basic requirements:
- Security: the service must not have access to the user’s private keys, and hacking any of the system’s separate components should not jeopardize clients’ funds.
- Flexibility: the user can withdraw their funds at any time or perform actions manually, and the service should not be limited to certain contracts. The system must be universal and flexible in terms of connecting new protocols.
- Development speed: the protocol receives its commissions for automated actions it performs, and new protocols need to be quickly integrated into the DFH ecosystem.
The result is a service consisting of several subsystems, each with their own functions. Let us analyze each subsystem separately.
- Balance: this is a contract with information about users’ overall portfolio balance in the system. The protocol’s commission and the cost of blockchain transactions are debited from the balance.
- Treasury: this is a treasury of the protocol. Withdrawing funds from the Treasury is possible only through a general vote of DFH token holders.
- Budget: the technical contract for automatic replenishment of consumer balances (see below).
- Storage: a storage of basic parameters and protocol’s addresses.
- Store: a contract for batch purchases of assets. For example, a batch of notifications.
- Automation: a blockchain contract for automated execution of a set of actions on a specific blockchain.
Next are the off-chain components:
- Backend: all the business logic is concentrated here.
- Inspector: a service for calculating the actual commission.
- Consumer: a service for conducting transactions.
- Staking-oracle: an oracle that makes the decision to restake assets
DeFiHelper algorithm: Step-by-step
Let’s examine how DFH works using a specific example. Imagine a user wants to apply the auto-staking algorithm to one of their contracts.
1. To complete any transaction in the blockchain, users need to pay the blockchain commission. The first thing a user needs to do is top up their wallet balance in DeFiHelper. If the user plans to use the protocols on the Ethereum network, they need to credit Ethereum. If staking is done in the protocols on Avalanche, users need to top up their balances with AVAX tokens. The blockchain commission and DFH commission are debited from the balance. The unspent balance can be withdrawn at any time.
2. Next, the user needs to select the contract that they want to automate. DFH will offer the user the option to deploy an individual contract and to transfer LP tokens to this contract. These tokens will be restaked in the future. Please note that the contract itself explicitly states which functions can be called by the owner of the contract — the user — and which ones can be called by the service — the Consumer. Thanks to this function, DFH can charge the rewards from and add the deposit back to the contract, but DFH cannot collect the bulk of the deposit. This function can only be executed by the author of the contract.
3. The automation process.
Any script consists of conditions and actions. To proceed to actions, the script must check and pass all the conditions for its execution. If at least one of the conditions is not met, it will be impossible to proceed to the next stage. The complexity of the conditions is limited only by the author’s imagination. Users can opt to use terms based on gas prices, the time of day, or the deviation of the gas price from the normal average.
Effective restaking is the most appealing condition. The data on the user’s current earnings, profitability and the number of staked tokens, as well as the cost of the transaction are transferred to a special service called a staking-oracle. The oracle issues a “yes” or “no” result. Based on the answer, DFH either restakes the assets or waits for the next cycle. If all the conditions are met, the service performs a blockchain transaction or sends a notification. Multiple actions can be combined.
4. If the algorithm decides that it is time to act, the system sends the transaction through 1 out of N of our Consumers. The more Consumers there are, the more transactions the system can send at the same time. Consumers can only be wallets added to the Balance contract by voting. When conducting a transaction, the maximum transaction amount and the protocol commission that can be debited from the client are recorded in the Balance contract. This protects DFH from a situation of insufficient funds on the user’s balance to complete the transaction. The service pays for the transaction from its own funds, which are located in the Consumer’s balance, and writes off the received funds to the protocol’s income once a day. The Budget contract supplies the funds for Consumers’ wallets.
5. After the successful completion of the transaction, the Inspector comes into play and specifies the actual value of the transaction and records it in the Balance. Once a day, all executed transactions are calculated and transferred to the Treasury of the protocol. These funds are the earnings of the protocol and are distributed from time to time among token holders.
Thus, the DFH architecture allows transactions to be conducted in the blockchain automatically, instead of by the user manually, while simultaneously keeping their funds secure. If the Inspector’s or Consumer’s private keys are compromised, only the current balance of these wallets will be affected, but users’ funds will remain safe and sound. The most that cybercriminals can do is write off funds to the Treasury. From there, the funds are withdrawn only via voting of DFH token holders.
If you have any further questions, please feel free to ask them in our Discord or Telegram chat.