Sigma Prime Audit

Overview

Tracer DAO has recently wrapped up an audit with Sigma Prime on the Tracer Perpetual Pools smart contracts.

Below is Mycelium's analysis of the audit, and responses to any issues raised. For the full audit completed by Sigma Prime, see here. The Perpetual Pools codebase is now fully open-sourced and can be found here.

Protocol security – the safety of users' funds primarily – is our biggest priority. As such we want to provide some insight into the audit results, as well as giving the community a more candid insight into perpetual pools.

There were a total of 12 issues raised, with 1 critical, 1 medium, 2 lows and 8 informational issues. The team has already actioned all of the above-mentioned issues in the form of fixes or mitigation strategies and is excited to be bringing Tracer Perpetual Pools to market.

The following is a summary of all issues, their severity, and the corresponding fix if applicable.

TCR-01 Denial-of-Service Attack on Leveraged Pool via Multiple Commits

Severity: Critical

Status: Mitigated

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/147

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/162

This issue has been raised as a critical by the Sigma Prime team because if abused, it has the potential to deadlock a pool and prevent users from interacting with the protocol.

While the team was aware of this issue, finding a suitable mitigation strategy proved difficult. Ultimately we ended up opting for the simple approach of having a minimum commit size and maximum commit queue size. This allows us to compute the cost of attack for each and every pool.

The current mitigation strategy for this issue is to introduce the following two parameters to the Tracer Pools

• minimumCommitSize : The minimum size measured in settlement tokens, that a user must commit to mint or burn
• maximumCommitQueueLength : The maximum number of commits that may be pending for any given period.

The combination of the above two parameters can be fine tuned to increase the economic cost of performing a denial of service attack. It should also be noted that gas fees are a factor in this equation since each individual commit a user makes will cost them gas.

These parameters will be fine tuned by the developer multisig initially, and then once the protocol has been operating smoothly, this responsibility will be passed on to the DAO.

While fine tuning these parameters, consideration must be made of the gas block limit and computational ArbGas limit (when operating on Arbitrum).

The team has also removed the uncommit functionality, meaning that for users to perform an attack they must actually commit funds to the protocol and mint pool tokens, hence providing liquidity themselves.

TCR-02 User Can Reset earliestCommitUnexecuted State Variable

Severity: Medium

Status: Fixed

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/140.

This issue was raised as a medium due to the fact that a user could manipulate the earliestCommitUnexecuted state variable, given they had enough commits in a particular order. This issue did not have the potential to steal user funds or cause issues with minting and burning and has been patched in the following PR https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/140.

TCR-03 Invalid string to bytes16 Conversion

Severity: Low

Status: Fixed

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/151

TCR-04 Divide Before Multiply

Severity: Low

Status: Fixed

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/161

TCR-05 Ownable Oracle Allowed in ChainlinkOracleWrapper

Severity: Informational

Status: Acknowledged

Fix: N/A

The Mycelium team acknowledges that this issue is currently present. However, due to the security model of the V1 launch, it is not being patched and is instead considered part of our current model. Deploying trustless oracles is a difficult problem to solve. While the protocol utilises Chainlink oracles, we still need to ensure that these oracles can easily be updated should Chainlink feeds change.

Each Chainlink Oracle Wrapper will be deployed by the developer multisig, with control handed over to the DAO after the initial launch period. By having each oracle wrapper controlled by either the multisig or the DAO means that in order for the mentioned exploit to be executed, the DAO or multisig would have to be malicious and initiate a proposal to change the oracle being used.

Proposals take 2 days to warm up when sent via the DAO and as such any user in a pool that experiences this attack from the DAO will be able to get notified and exit the pool.

TCR-06 Unnecessary Multiplication by fixedPoint

Severity: Informational

Status: Fixed

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/160

This issue was raised as an informational. Primarily due to the fact that it did not cause any problems within the protocol. This is due to how the power leverage formula works to compute the amount of funds to move between each side of the pool. It is based on a ratio, and as both the numerator and denominator were being multiplied, the ratio was still consistent. It did however add unnecessary gas usage to the protocol, and this has been fixed.

The community will be updated as soon as the team moves away from the multisig ownership model to complete DAO ownership.

TCR-07 Potential MEV Attack When Users Commit

Severity: Informational

Status: Mitigated

Fix: N/A

This threat still exists in the current model. While the team feels this attack is quite unlikely, it is possible for a malicious actor to use a MEV service such as flashbots and bribe a miner to manipulate the block timestamp to ensure they are the last user entering the pool.

To mitigate against this, the front running interval is being set to 5 minutes for each pool deployed. This prevents users from performing this exploit on last minute price updates, as nobody can enter any later than 5 minutes before a price update. The team believes this alone is enough to almost entirely remove any MEV that can be gained using a similar attack to that mentioned in the audit report.

TCR-08 onlyGov Role Can Withdraw Users’ Fund

Severity: Informational

Status: Mitigated

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/144.

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/141

This issue was raised as an informational. This issue is acknowledged by the team and still exists in the codebase. As mentioned in TCR-05 this issue is mitigated by having the onlyGov role initially be a dev multisig, and then the Tracer DAO. Once control is transferred to the DAO, any action it takes must propagate through the proposal system, meaning users would have two days to act before any of the raised issues could be exploited.

We have also introduced an explicit pause and withdraw function that allows the onlyGov to more explicitly drain user funds. This has been introduced as a safety measure to the protocol, to allow pools to be paused if need be, and to allow user funds to be returned should an exploit occur. The changes that introduce this pause and withdraw functionality can be found in the following two PRs:

Withdraw Functionality: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/144

Pause Functionality: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/141

TCR-09 Known Issues

Severity: Informational

Status: Fixed / Mitigated

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/156.

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/154.

This raised 4 separate issues that were known to the team. They were:

• multistep governance transfer;
• view function for keeper rewards;
• keeper gas price usage; and
• new keeper propagation.

Multistep Governance Transfers

This issue has been addressed in the following PR https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/156

View Function for Keeper Rewards

While a function does exist that allows keepers to compute their tip amount (see PoolKeeper.keeperReward), it is difficult to extract this out into a simple view function for any keeper to call. This is due to the fact that there are a number of factors that go into computing the final reward. It is recommended that keepers use this function along with their own data to estimate the reward for each call. This is however outside of the protocol scope.

Keeper Gas Price Usage

This issue has been addressed in the following PR https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/154. Once more reliable gas price oracles exist, the team will be looking to migrate over to a more dynamic solution.

New Keeper Propagation

This issue has not been addressed. For the initial release, the dev multisig and Tracer DAO will be responsible for deploying markets. Any updates that need to happen to the Keeper Contract will be batch propagated by the party performing the upgrade. This keeps this functionality out of the core protocol.

TCR-10 Test Coverage Improvements

Severity: Informational

Status: Acknowledged

Fix: N/A

The test suite is actively being improved by the team. The tests produced by Sigma Prime are also being integrated into the Perpetual Pools test suite.

TCR-11 Gas Optimisations

Severity: Informational

Status: Fixed

Fix: https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/157.

All gas optimisations have been implemented.

TCR-12 Miscellaneous Tracer Contract Issues

Severity: Informational

Status: Fixed

Fix:

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/158

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/147

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/162

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/147

https://github.com/mycelium-ethereum/perpetual-pools-contracts/pull/162

All miscellaneous fixes have been implemented.