Yesterday evening I (Ameen) was informed that the SpankBank has a critical vulnerability. Stakers can splitStake and overwrite other existing stakers, permanently freezing their staked SPANK. All staked SPANK is currently safe because the splitStake function can’t be called by any staker until the next period (you can’t splitStake after you have checked in for a period, and staking automatically checks you in). We have closed the deployed SpankBank, fixed the bug, and redeployed. If you have already staked, you can immediately withdraw, and re-stake if you choose.
We’ve updated the SpankBank Explorer UI and added a “Withdraw stake from previous contract” button that only shows up if we recognize your account as a staker in the buggy SpankBank. As of right now, you can immediately withdraw your SPANK from the old SpankBank. Funds are safu.
Once your withdrawal transaction confirms, the “Withdraw stake…” button will disappear and be replaced with the familiar “Stake your SPANK”, which will allow you to re-stake on the new SpankBank contract (with the same account if you want). We apologize for the inconvenience.
In our tests we check for overwriting the delegateKey of another staker, but failed to check for overwriting the main staker address. This is an excruciatingly stupid mistake. As the author of this code and the tests, I take full responsibility for the error. It was also my decision to forego an audit, which would have likely found the bug.
We may have been overconfident, but we weren’t reckless. We designed a big red button to push in case of emergencies like this one, and we’ve already fixed the problem and moved on. We also knew going in that the upside of attacking the system was low, and so the incentivizes for a rational gray-hat hacker who discovers a critical exploit favor sharing it with us, which is exactly what happened. Having a community of engaged developers who can help us make our systems more robust is invaluable at this stage, and one discerning hacker has earned a $5,000 ETH bounty.
Aside from the period 0 start time, which was reset when we redeployed the SpankBank contract, all other operational parameters of the SpankBank will remain the same.
We don’t think there are any more bugs (which is the type of thing that you’re right about once, but can be wrong about several times), but if we’re wrong we’ll pay out the bounty, fix it immediately and move on. It’s also helpful to remember that this bug presented us the opportunity to test voting to close the SpankBank, so now we all know what to expect when we decide to upgrade, or in case of another critical bug.
As a final note, I’d like to remind everyone in the community that we are pioneers exploring a new paradigm of economic coordination. We’re going to encounter obstacles and make mistakes. As a community, we need to be pragmatic and alert, ready to quickly maneuver to overcome any challenges, learning and growing stronger from each experience.
For context, here are a few of the obstacles SpankChain has made it through:
1. July 2017—Within 24 hours of Suicide Girls passing on us as a launch partner because they thought our name was too outlandish, we met Janice Griffith who joined as a cofounder and became our primary adult industry liaison.
2. Nov 2017—We designed our ICO to be too fair and didn’t offer buyers any bonus for committing early. As a result, our first day saw only $700K ETH in deposits and with 24 hours to go on the last day of the two-week auction we still only had $2M ETH deposited. The minimum was $5M. This was stressful, but rationally we knew that all the money would come at the very end, and true enough, with 8 hours to go we reached the minimum of $5M and by the auction close we had collected $6.5M.
3. April 2018—We were (perhaps foolishly) hoping to copy Gnosis’s work on the two-token model but they decided to de-prioritize it. We adapted and built the SpankBank ourselves.
4. September 2018—This.
In BOOTY we trust.