Trail of Bits (ToB) completed a 3 day security review of the Eclipseum smart contract from 10/13/2020–10/15/2020. The ToB findings can be seen in the PDF summary, or in the issues opened on the Eclipseum Github. ToB opened 4 issues which are addressed in this article. This article uses Eclipseum specific terminology that assumes the reader has already read the Introducing Eclipseum article.
Issue #1: Fee Incorrectly Applied
This issue can be found on Github here.
In the Buy DAI function, a 0.3% fee is paid by the user. The amount of DAI the user receives from the transaction is calculated using the constant product market maker equation, and then 0.3% is subtracted from that value. Then, the function transfers approximately half of that transaction fee to the ECL liquidity pool. ToB points out in this issue that the amount transferred to the ECL pool is not exactly half.
The user effectively pays the transaction fee in DAI, but the value transferred to the ECL pool must be in the form of ETH. So the price exchange rate between the two assets must be used to convert the DAI quantity to an ETH quantity. The exact quantity could be calculated using the final DAI/ETH price as defined by the quantity of ETH and DAI in the DAI liquidity pool. However, the DAI/ETH price used is based on the price that the user receives. Calculating the exact quantity of half the transaction fee in ETH is a more gas intensive calculation than the calculation implemented in the contract. The numerical difference between the two calculations is negligible, and the current calculation is kept in the final contract code due to gas savings.
Issue #2: Economics Divergence on Soft Sell ECL Allows User to Drain Funds
This issue can be found on Github here.
In this issue, ToB correctly points out the fact there are certain situations in which users can profitably arbitrage using the Buy ECL function and the Soft Sell ECL function repeatedly. In the Github issue, ToB included code for a Truffle unit test that simulates these conditions after the contract is initially deployed. This test has been recreated and displayed in Simulation 1 shown in the two figures below.
This profitable arbitrage opportunity emerges in situations in which the Soft Sell ECL Price in ETH is greater than the ECL Price in ETH. This opportunity will exist when Eclipseum is initially deployed, when the ECL Liquidity Ratio is very large, resulting in an ECL Price Ratio greater than one.
To avoid this arbitrage opportunity, the deployer of the contract simply needs to make a series of Buy ECL transactions to reduce the ECL Liquidity Ratio, thereby decreasing the ECL Price Ratio below one, and leaving Eclipseum in a stable state in which the arbitrage opportunity does not exist. An example of this is depicted in Simulation 2 shown in the figures below.
It is important to emphasize that once the ECL Price Ratio has been decreased below one, the Eclipseum game theory creates a strong tendency for the ECL Price Ratio to stay below one. Details on this game theory are explored in the Introducing Eclipseum article.
Issue #3: Code Quality Recommendations
In this issue, ToB points out two code quality recommendations which can be found in the Github issue here.
The first recommendation is to add indexing to the user addresses in the five transaction events. This enables searching through Eclipseum transactions by user account address.
The second recommendation is to change two assert statements into require statements. These assert statements were evaluating the success or failure of a DAI token transfer. This change does not affect functionality of the smart contract, as both require and assert statements result in the function reverting when they evaluate to false. However, the Solidity convention is that asserts should be used only on invariants that indicate a bug in the contract code when they evaluate to false.
Both of these recommendations by ToB were incorporated into the Eclipseum contract source code in commit 9a612f3.
Issue #4: Economics Uncertainty
This issue can be found on Github here.
In this issue, ToB points out that while Eclipseum transaction functions utilize the constant product automated market maker (CPAMM) equation, Eclipseum breaks the underlying constant since ECL tokens are minted in every Buy ECL transaction, and burned in every Sell ECL, and Soft Sell ECL transaction. ToB expresses concern that this may cause unexpected price behavior and that simulations showing the economic impact should be created. Simulations 3 and 4 are shown below comparing how the Eclipseum algorithm differs from a traditional CPAMM algorithm.
Simulation 3 demonstrates how buying ECL from the ECL liquidity pool differs from buying arbitrary token ABC from a standard CPAMM liquidity pool that does not mint or burn tokens. Both the ECL liquidity pool and the ABC liquidity pool implement a 0.3% transaction fee. The simulation includes 100 token buys of 0.01 ETH in each separate liquidity pool.
It can be seen from Figures 5 and 6 that the ECL Price in ETH increases less than the ABC Price in ETH, and the ECL Circulating Supply increases more than the ABC Circulating Supply. In this way, the ECL Pool finishes the simulation with far more available liquidity relative to the ECL Circulating Supply than the ABC Pool has relative to the ABC Circulating Supply.
Simulation 4 compares selling ECL tokens to the ECL liquidity pool to selling ABC tokens to the ABC liquidity pool. The sell orders are split up into 100 separate transactions of equal size, such that after the last transaction the circulating supply of both tokens is zero.
This simulation demonstrates how the ECL Price in ETH of the ECL liquidity pool is more resilient to large selloffs than a standard CPAMM liquidity pool. There are three main mechanisms that enable this which are outlined below.
- ECL tokens are burned from the ECL liquidity pool in each Sell ECL transaction, which dampens price decreases, whereas the standard CPAMM liquidity pool does not burn tokens.
- The ECL liquidity pool maintains an ECL Liquidity Ratio greater than 1/6, which provides more liquidity to ECL sellers, and results in less price decrease when tokens are sold.
- The ECL liquidity pool also offers the Soft Sell ECL function as an alternative for ECL sellers. It can be seen in Figure 8 when ECL sellers transition from using the Sell ECL function to using the Soft Sell ECL function, this is the point in the chart where the ECL Price in ETH stops decreasing.
Simulations 3 and 4 should show that the ECL liquidity pool offers advantages over standard CPAMM liquidity pools in decreased downside price volatility and increased liquidity. These advantages do come with a tradeoff, as some price upside potential is sacrificed as a result.
Conclusion
To conclude, ToB found some good recommendations that have been incorporated into the contract. Eclipseum implements a lot of new game theory and economic algorithms that are still experimental, so naturally ToB expressed caution when reviewing the contract. As always, no one can guarantee with 100% certainty the security of any smart contract, and all users should use Eclipseum at their own risk.
