The Delphi crowdsale FairAuction contract has been finalized, and participants began individually withdrawing their DEL tokens a few hours ago. Unfortunately, there is a small problem with the version of the contract that was deployed, which has resulted in unintended balance distribution errors. The good news is that this is ultimately a harmless problem, with a simple fix which we are in the process of implementing now. Because some withdrawals have already been made, to ensure that all tokens are apportioned properly to users as originally intended, it will require us to deploy a new DEL token contract. We greatly appreciate the community’s patience and understanding as we get this done.

What Happened?

The contract’s finalize function was successfully called, which takes a “snapshot” of the total reward tokens (in this case DEL tokens) available to the contract for distribution. After this is done, the contract is marked as “finalized” and token withdrawals can begin.

Some users began claiming their tokens almost immediately, and were able to do so without issues. However, since there is nothing to prevent the finalize function from being called again after this has begun, a second token “snapshot” can be taken, overwriting the balance result of the first (tokenSupply) with the new value (which is smaller now that some tokens have been claimed by their new owners). This means that subsequent claim and withdrawal amounts are calculated with a reduced tokenSupply figure, ultimately resulting in fewer DEL tokens being sent to those users than are deserved.

What’s The Fix?

In terms of code, the fix is trivial and surgical.

Basically, in plain English: only allow the contract to be finalized once. This totally prevents any balance confusions or miscalculations from occurring.

As is so often the case, subtle issues like this can escape detection even in instances where multiple independent auditors are involved in the code review process (in open source in general and especially in our case, this can even include the world at large). Everyone in the Ethereum community understands by now that smart contracts are dangerously unforgiving in some ways, mistakes can occur, and the important issue is how those mistakes are dealt with once they do occur.

The FairAuction contract has been updated to include the fix, and as of commit 143dc91d53814249f8319d74534b6c0edb5cd134 will only allow finalize to be called a single time, so any future deployments of such an auction (or a modified version thereof) will behave as originally intended and described.

With no way to “call back” the DEL tokens already erroneously distributed, and with the understanding that zero economic activity has taken place with these DEL tokens yet, we can simply issue a new version of the DEL token contract and manually distribute these tokens according to the contribution results from the original FairAuction. This will be done in a totally transparent manner, and everyone will be able to review the final distribution of the new token contract and individually verify that it is correct.



It is worth noting that because our team was already manually distributing a significant portion of the original DEL tokens (for the Referral/Bounty portion), the intervention necessary in this case does not introduce any new trust vectors into the process. In other words, absolutely no harm is done in any respect. It also serves to highlight one of the biggest benefits of non-consensus-dependent frameworks like Pythia, where individual deployments’ bugs have a very limited scope in terms of damage potential.

An Opportunity

Although it is unfortunate that a contract balance confusion occurred at all, we are happy to have such an early opportunity to prove our commitment to solving problems as they arise. In this case, the fix is an easy one, and the biggest thing that needs to be done now is push it out and communicate properly. As long as everyone is aware of how things are moving forward, and the community is all on the same page, then this was a complete non-event, and won’t slow us down in any way. To this end, we will be updating all of our documentation, including our FairAuction walkthrough on Medium, to reflect this new information (and the new relevant token contract address), with the revision information clearly noted. We will be reaching out to all block explorers and token trackers to ensure that the correct contract address is distinguished as such. Bug bounty details will be forthcoming shortly.

Again, we infinitely appreciate the community’s patience on this as we get it completely sorted out. It is not something we had hoped to be doing today, but we are absolutely resolving this right now, and we thank you for bearing with us here.