Ever since the early days of Ethereum, Ponzi Scheme smart contracts have been showing up in the news constantly. They have been showcased not only because of the ethical questions raised by pyramid schemes (sometimes called “social experiments”), but also because they tend to cause a lot more damage than the average smart contract out there.

The explosive mix of memes, “GET RICH QUICK!” and copy + paste of code led to a lot of controversy, hacks and ETH stolen. This ecosystem is so rich from a security perspective that it could be used as a case study on how carelessness can affect the quality of code.

The early days

The following contracts laid the foundation for today's meme factories.

The King of the Ether Throne contract is to this day used as an example on how a send() to a contract can revert due to a fallback function spending too much gas, or be forcibly reverted by the receiving contract, resulting in a contract that is forever frozen in state. It was frozen in early 2016, making “Sir Wobblle” the eternal King, because his wallet consumed more than the 2300 gas available (link).

The Rubixi was also one of the earliest, launched in the beginning of 2016. The code was copied from a previous Ponzi contract, but the deployer forgot to rename the constructor function that remained named “DynamicPyramid”. This function set the msg.sender as owner, so any address could claim ownership of the contract, and then drain the fees it charged. After the vulnerability was found, users actually made a ranking of addresses that got the most fees:

From solidity 0.4.23 the constructor syntax changed, and this would have mitigated the error above.

In March 2016, the Governmental scheme came to life. The contract had a payout function that iterated over all users calculating the amount to be paid. Soon after it was deployed, 1100 ETH got stuck in it, because the aforementioned function's gas requirements exceeded the block gas limit.

In 2017, A groundbreaking academic experiment by Dr. Jochen Hoenicke evolved the concept to what still is today’s standard. In his study for the first time he tokenized the so called investments, and created the scheme in which newcomers paid fees for all current users. The catch is that the value of the token increases as more tokens are sold, incentivizing withdrawals over time Hoenicke created a proof of concept in the Ropsten testnet, and also included the contract’s known bugs, including a public function to drain the whole ETH. Soon after someone else published the contract to the mainnet, and it had a bug that was abused days after (as described by Hoenicke himself in his webpage), leading to at least 2000ETH being stolen (link).

A paper solely on Ponzi Schemes and overall impact in Ethereum was published by Bartoletti et al (2017) and it outlined several aspects of the ecosystem, including security (link). The conclusions were somewhat alarming, with around 10% of the smart contracts in Ethereum being Ponzi Schemes, holding a considerable amount of ETH in them.

Recent History

Ponzi schemes have evolved, having survived the growing pains of the ecosystem (a lot more pain than in other ecosystems, I must say). The contracts have evolved in complexity and (coincidentally or not) have also been exploited several times.

Although the nature of the contracts is of course still arguable (the ethics of Ponzi schemes is beyond the scope of this article), users seem to actually trust the fact that they are implemented in smart contracts and the fact that the schemes promise no human intervention.

source: powh3d reddit thread, powh3d being the 3rd version of the Proof of Weak Hands, history outlined below.

They also have implemented new functionality that boosts popularity of the schemes, the main one being masternodes, that allow influencers to bring other users and take a cut of their profit, leading to a flow of articles encouraging the use of such schemes (link, link, link, link).

Free shipping available

The most prominent case (or cases) in recent memory is PoWHCoin and its spinoffs. Their implementations of the original Ponzi coin were hacked one after another, generating press both over the comic side of it (link) and of course from the security community.

Summing up, Proof of Weak Hands (original website: link) is a smart contract that incentivizes users to “invest” and hold their tokens (and ETH in the smart contract) with the expectation that more “investors will come into play” and that the tokens will be sold later on at a higher value. It also included the masternode concept previously mentioned.

Their smart contracts were hacked one after another resulting in the theft of funds (link) and in a contract’s funds frozen (link). Interestingly, the funds frozen in Shadowfork’s contract were actually recovered, using the same vulnerability from PoWHCoin (We could not find any info on whether they were returned to users).

Original content from ShadowPyramid

It then started generating a wave of clones that are hard to track (link, link). All spinoffs are built with the same level of humor, and bold statements about security:

Audited?

The present version is https://powh.io/, currently holding over 4.5k ETH, or approximately 2.5 Million USD (june/2018) (link).

The EthPyramid also seems to be very prominent, having rebranded to https://ethphoenix.io/. It currently holds 132 ETH / 91k USD. The team goal was to create a vulnerability free Ponzi contract, and up to now they have succeeded.

We know not everyone had a good laugh

Also an honorable mention to PonziCoin.co. It was cloned from a Ponzi contract created back in 2014. After getting some attention, the dev pulled the plug on what he called “The world’s first legitimate Ponzi scheme”. (link , link).

We’ll now analyse some of the spinoffs, and also try to find other versions of possibly interesting (from a security perspective) schemes.

Keep in mind that we are not auditing the contracts, we’ll just take a quick look at them to find possible issues. Do not consider the contracts free from bugs not disclosed here. If ever in doubt about the legitimacy of these schemes, please reread this preface twice. We also did not review any of the Dapps not mentioned below.

Here we go

As expected, most of the schemes created today are clones of the ethPyramid or PoWH. The ethPyramid clones are usually an exact copy of the original, including the name (search for ethPyramid in Etherscan returns over 10 results). The PoWH crowd actually changes bits and pieces of code, and some of them still do not care about uint overflows. They often leave humorous comments in the source code, as we can see in a couple of snippets below:

Now let's check unrelated schemes:

PonziICO was last used around 50 days ago, currently holds a little over 3 Eth, the first thing that caught my attention was the fact that the fees are significantly higher than usual, at 50%:

There is an unbounded for loop in the code (see governamental case in the preface). An unbounded loop could result in the function reaching the block gas limit if the investor number becomes too large, and therefore causing a denial of service until gas limits rise. At least it only runs every time someone invests or reinvests, so users will still be able to withdraw their funds if that happens:

These contracts are very similar, Ethstick looks like an evolution of Piggibank. All ETH transfers in the contracts are unchecked sends, such as shown below:

In the case above, a revert , require or a transfer in place of send would be advised. If the send fails the function returns, but the funds remain in the smart contract. In other places in the contract the same problem is present.

Two problems with the code above, the returning value of send is not checked, and if it reverts the user’s balance is still changed, so the user will lose the amount permanently. Also note that state is modified only after the send , possibly making the contract vulnerable to reentrancy (the fallback function of a smart contract could call the withdraw function over and over until the gas limit is reached).

The random number calculated on chain (taking block.number ’s keccak hash as input) could be easily guessed by another contract calling the function, because they would be processed in the same block, using the same block.number as a parameter.

Another unbounded for , lesson not learned from Governmental. Although the payout starts at payout index, if too many due payouts accumulate the block gas limit could be reached (the payout function is quite gas heavy, writing several state variables).

A ponzi game, where the user pays for land but could also find treasure chests that payout. It was “self destructed” by the owner, draining the 1.047 ether that were stored in it. Could not find reference if this was due to legitimate reasons, the frontend is still up and running.

In this game, the token price starts at 1 ETH, and increases 20% per token bought. Taken from the website:

Although the above is stated, the creator of the contract can drain its balance, as follows:

As in the example above, the owner could selfdestruct and get all funds from the contract:

Although advertised as completely trustless, users had to trust the contract owner:

Conclusion

As seen above, careless coding can become a disaster. For most of the cases above, a good review, a good testing coverage and an audit could’ve prevented the worst issues. It’s no wonder why the developers of those contracts did not identify themselves (other than using nicknames in the minority of cases). When coding a smart contract, care is never enough. Patching roles is impossible, the only way to get it right is having as many reviews as possible, a strong test coverage and independent audits.