Andre Cronje’s Solidly Launch Not As Smooth As Expected

Table of Contents

• A Battle For Control Between Top Protocols
• The Solidex Issue
• Solidex’s Disclosure Of The Incident
• Possible Fix?

There was considerable drama at Andre Cronje’s new AMM launch, Solidly, with significant confusion at launch, leaving users frustrated. The issue began with a power tussle between Solidex and 0xDAO.

A Battle For Control Between Top Protocols

Alexcutler.eth outlined the issue at launch in a Twitter thread where he explained what led to the problems. While announcing Solidly, Andre Cronje distributed ownership to top Fantom protocols based on their total locked value (TVL). This led to a struggle between two teams on Fantom, SolidexFantom, and 0xDAO. 0xDAO eventually gained the upper hand over Solidex, but there was a problem.

With the launch getting closer, the 0xDAO team went silent, and just before Solidly was supposed to go live, the team announced that they were not ready and offered no timeline regarding their readiness. This obviously switched everyone’s focus to Solidex, but there seemed to be an issue here as well.

The Solidex Issue

With emissions beginning, users noticed that top pools on Solidex were not producing any rewards, with liquidity providers providing liquidity but receiving nothing in return. Solidex eventually took to Twitter, highlighting that a problem had been detected with Solidex that led to problems cropping up during voting for the first round of SOLID emissions. It assured users that their funds were safe.

Solidex’s Disclosure Of The Incident

Solidex published a full disclosure describing the incident and the problem that occurred. The report stated that an issue. When transactions were finalized beyond the voting deadline, the votes were reset to their default state. Solidly voting takes place at 00:00:00 UTC on Thursday of every week. However, in reality, voting takes effect individually for each gauge upon the first acting in a pool after the deadline lapses. This leaves a window at the beginning of the week where no voting occurs.

The issue was discovered when the transaction was finalized just after the deadline, leading to the Solidex votes to reset to default, which led to the certain pools receiving all the voting power.

Possible Fix?

Because the smart contracts on Solidly and Solidex are immutable and non-upgradable, at the moment, there is no way to apply a fix. However, there is a way to mitigate the issue as long as submitVotes() is not called after 00:00:00 UTC. One way of preventing the problem from recurring is ensuring that SubmitVotes() is called before 00:00:00 UTC, eliminating the possibility of the votes being set to the default state. The Solidex team is currently researching possible deterrents to mitigate the problem.

Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.