Update on the SYRUP Incident
Following the emergency decision to remove support for SYRUP on PancakeSwap, it came to light that an unexpectedly large number of users had bought and sold SYRUP and were negatively affected.
This is going to be a long and frank article, but there’s a lot to say.
What happened?
An exploit in the interaction between the MasterChef contract and the SyrupBar contract was abused by bad actors. Previously when CAKE was staked, an equal amount of SYRUP tokens would be minted. Once the CAKE was unstaked and withdrawn, the SYRUP tokens would be burned. The specific exploit here was that if a user used the emergencyWithdraw function in the MasterChef contract to withdraw their staked CAKE, the corresponding SYRUP tokens would not be burnt as intended. This allowed bad actors to repeatedly mint more SYRUP tokens with their CAKE tokens. This was an oversight on our part that we did not consider when writing the logic for the SyrupBar contract.
By having an amount of SYRUP tokens in circulation much greater than allowed, this meant that the bad actors were receiving a higher portion of Syrup Pool rewards than people that abided by the rules. We needed to fix this fast.
Does PancakeSwap blame the users?
No.
The chefs accept the blame for the issue with the code.
We do not and cannot place any blame for the issue on users who bought or sold SYRUP in good faith.
We also understand our users’ frustration and are sincerely sorry for any losses that the emergency decision to remove support for SYRUP may have caused.
A request: if there is evidence of core team members trying to hide the exploit, misinform users, or accuse them, we invite you to reach out on Telegram and we will investigate.
Why didn’t you warn users not to trade SYRUP?
We did.
When we realised that some users were using SYRUP in ways other than intended or anticipated, we decided to add warnings instead of fully removing it from the exchange. (See below for the reasons for this decision.)
Warnings include, but are not limited to:
- Warnings on the exchange interface have been on the exchange since this git commit was merged 29 days ago
- Warnings (and countless memes) in the Telegram community, since this community guide was posted or earlier
- Warnings in the docs
But those warnings didn’t say we COULDN’T trade SYRUP!
While the warnings and memes in the community were extremely direct, the most important warnings were those in the UI.
With hindsight, instead of “please be careful”, we could have used much stronger language to scare users away.
We’ve learned a valuable lesson about UX writing and will be much more direct when writing warning messages, if needed, in future.
But those warnings didn’t say we could lose money due to the flaw in the contract!
Right. That’s because we didn’t know about the issue with the contract when we wrote them, so we couldn’t warn against it.
So why didn’t you just remove SYRUP from the default exchange list?
This decision was actually made to protect those users who had already mistakenly traded it.
Internal chat logs from October 8th reveal the chefs’ initial thought process:
- [08.10.20 12:05] We should not let users swap it
- [08.10.20 12:07] a lot of them already have
- [08.10.20 12:07] will probably just result in more questions from users on why they can’t find it etc.
- [08.10.20 12:08] if it’s completely removed now those who made the mistake are stranded
We expected that adding warnings would be enough to deter people.
We expected those who had traded SYRUP would see these warnings, realise they’d done something risky and unintended, and reverse their actions.
We also didn’t anticipate the issue in the contract.
We were wrong on all three counts.
Wasn’t the contract audited?
Yes, the contract was audited.
But when we contacted CertiK to inform them of the exploit, they explained that, since the function that led to the exploit was the emergencyWithdraw function, and as that function was part of the original SushiSwap contract, it wasn’t picked up in the audit.
Why wasn’t the exploit picked up in the audit?
The contract audit from CertiK only included the “delta” meaning anything that was added to the original SushiSwap contract. CertiK also pointed out that the first case of the exploit being used was 24 days ago.
In addition to the audit, we also joined CertiK’s Security Oracle Program and “CertiKShield” program with high hopes to make PancakeSwap users and their funds as safe as possible. As part of the CertiKShield program, we paid for 12 months of membership, which was originally due to be announced the day the exploit was found.
Unfortunately, as CertiKShield protects against crypto theft as a result of situations like the theft of a private key, as well as inaccessible tokens like frozen contracts, etc, we were unable to execute a claim.
Why did you ignore people who brought this exploit to your attention?
When we heard about it, we started investigating.
When we found the problem, we acted in a way that would best protect the majority of PCS users.
If we didn’t respond to some comments about it in the chat directly, please don’t take this to mean we were ignoring the issue.
Why was discontinuing SYRUP the chosen solution?
The chefs debated several different solutions. However, as malicious actors exploited it with increasing speed, we had to decide and act FAST. We chose the solution that was the fastest and least disruptive to the greatest majority of our users.
Here are a couple of other solutions that we considered at the time:
- Redeploy new MasterChef and SyrupBar smart contracts with updates that would fix the exploit.
This solution would require all CAKE farm contracts and all SYRUP Pool contracts to be updated to use a new set of smart contracts. This would mean that all liquidity providers would need to migrate their LP tokens to new farms, and that all CAKE holders also would need to unstake their CAKE using SYRUP-old, and re-stake it to issue SYRUP-new.
This would have caused a great deal of disruption to all PancakeSwap users. We also could not execute this solution until 6 hours later due to the time-lock. - Add a new logic when staking CAKE to check that the amount of SYRUP owned by each address corresponded to the correct amount of CAKE owned.
This solution would have likely fixed the exploit going forward, but it would not have solved the fact that there were an additional 10–20M SYRUP tokens on the market. These additional tokens would have continued to be circulating and able to be staked in SYRUP Pools, diluting the rewards of everyone else.
What about the community proposals asking for compensation?
We greatly appreciate the community’s use of the voting platform to share their thoughts on how we should proceed.
As you know, community proposals are not binding decisions, and represent instead the sentiment of the community. For example, while this community vote received support from many voters, unspecific language such as “A 1:3 rate or something similar could work” and “will have to be whitelisted somehow” show that it’s intended to demonstrate a general sentiment instead of being a full and thorough proposal for specific actions the team should take. And that’s OK — that’s a very valid way to use community proposals.
More details on the votes about compensation below.
What about the core vote regarding compensation?
In the coming days we will be updating the governance portal to be powered by CAKE instead of SYRUP. Once this is done, we will post a vote for CAKE holders to decide possible compensation.
Why should CAKE holders decide, not SYRUP holders??
- There is now an excess number of SYRUP in circulation, so its reliability as a governance token has been entirely compromised.
- During the period that users who purchased SYRUP were able to accumulate rewards, CAKE holders that observed the intended use case of the CAKE/SYRUP system held more risk for less rewards.
What will happen to my SYRUP now, and what can I do with it?
We don’t have any plans to bring back any sort of support for SYRUP at all.
We do not recommend you do anything with it, and will not give suggestions.
Note that:
- SYRUP will not have any value as a governance token
- SYRUP is still needed to unstake CAKE from the old SYRUP-based pools. If you’re still staked in one, you will need to unstake first.
Conclusion
Lastly, we would just like to say a sincere thank you to everyone who has, and continues to support both PancakeSwap and our team throughout this troubling week — including the critics. PancakeSwap is just over a month old, and with your help, we’ve been able to hit some incredible milestones, like being the #1 AMM on Binance Smart Chain and hitting over $250M USD in TVL at one point.
For now, we’ll be getting back to work, ready to deliver the next items on our to-do list.
Stack’em!
The PancakeSwap Team 🐰
