Why create a contract specifically for compounding?

The reason for creating a contract that has only one function is security. SInce our solution relies on our internal off-chain service that constructs calldata for such protocols as 1inch, OpenOcean, FireBird and others. To change protocol we need only to modify destination address and calldata.

But from a security perspective, making a raw call to an external contract with calldata from off-chain service is not really safe.

This is why we have opted for this architecture.

• Security by design: The system's architecture is crafted to minimize potential risks associated with the reliance on an off-chain service for generating transaction data. This design choice acknowledges the possibility of security threats but contains their impact.

• Risk containment: In the event that the off-chain service is compromised, the system's exposure to risk is limited to the rewards from the most recent compounding cycle. This means that in case of a security breach, only the rewards awaiting reinvestment could be affected, protecting the principal and the broader system.

• Resilient structure: The architecture also addresses a specific vulnerability related to smart contracts, particularly the risk of a contract being destroyed through an exploit involving the `SELFDESTRUCT` opcode. The system is set up so that if the Compounder contract were to be compromised in this way, it could be quickly redeployed with no significant adverse effects. This ability to rapidly restore the contract ensures that the system can maintain its operations and safeguard users' assets even in the face of potential attacks.

Overall, the system's architecture is strategically designed to enhance security and ensure robustness by limiting potential losses to a single cycle's rewards and enabling the quick recovery of key components in case of an attack.