$Super explained — The PaymentSplitter
By: Philipp Böcker
Tags: Cryptocurrency, Smart Contract, Scam, Binance Smart Chain, Payments Contract

Super is a scam. Do not invest.

In a previous story I introduced you to the contract code of $Super, a relatively new contract on the binance smart chain. Today i want to have a look at the PaymentSplitter contract within the super contract.

Recap

$Super is a relatively new contract on the binance smart chain. It was created 14th December 2021. A first introduction into $Super can be found here and here. Be aware, especially the second story has the typical crypto marketing speech (“hidden gem”, “game-changing”, successive questions, …), but I refer them nevertheless because you will not find $super like other defi projects in every other story.

So, you got first impressions, let us now go straight to the contract and have a look at the code. You can find the token here and the corresponding contract here. I will give a overview over the contract code in this story and will maybe dig deeper within a follow up story.

What does the PaymentSplitter do?

The PaymentSplitter is a contract which pays out the balance of the contract or token balance of the contract to defined payees depending on their internally managed shares.

Currently, the $Super token contracts is holder of 237.645459642783184903 BNB (At the moment $124,248.18 (@ $522.83/BNB), 30 December 2021).

At creation time 2 payees (payee zero and payee one) where defined. Each of them are holding 50 shares (total shares are 100). No payee received any payment yet. Payee zero is also the address of the distribution pool and its balance is 153.975 BNB ($80,296.40 (@ $521.49/BNB), 30 December 2021). Until a few days ago this adress received its BNB from the super contract itself. Now it receives it from the 2 contracts you approve within the super web application (Heroes tier and villians tier) to create nodes.

The values are stored in BNB (Not in $Super). So, the developers have made $204,927.18 ($80,296.40 + $124,630.78) within 2 weeks which is a nice revenue. I guess I should playing with the idea to create a similar contract by myself. By the way, there is also a futurUsePool (sic!) with around 42.14 BNB ($21,886.94 (@ $519.36/BNB), 30.12.2021).

Should the developers — if they are scammers — withdraw it?

Simple no. It is stored in BNB and therefore it does not depends on the value of the token itself. If they withdraw it, user could get anxious. Just doing nothing is the best options for scammers. Once super does not earn any money anymore, they can come and get it.

Should the developers — if they are not scammers — withdraw it?

Maybe. But they have to communicate. They need to explain to its users what this money is for and what are they planning to do with it. In my opinion they have to find a valid use case for $Super. At the moment it is just a stock market game with one stock and extra rules. With no valid use case and if the developers are not scammers themself it stays a scam for every user who is not net positive — for every new user or for a user who bought in high. Until then, the net positve users are stealing the new ones merciless (especially if they advertise it)

How does the PaymentSplitter work?

So, you know already the developers have made around $200,000 within a little bit more than 2 weeks. Just out of curiosity lets have finally a look at the contract.

The code of the PaymentSplitter is from OpenZeppelin Contracts v4.3.2

The contract PaymentSplitter extends from the contract Context, which just provides the basic functions _msgSender and _msgData to access msg.sender and msg.data indirectly.

On creation (which happened during the creation of the Super contract) it receives payees and its corresponding shares calls the private function _addPayee which adds the payee with its share to the contract.

There are a few public read functions to get information about the total shares and total released, about the payees, and to get the shares and the released of a specific account (payee) and the coin BNB or a specific token.

The central write function is release, which sends BNB or a any other token to the provided address, if it is a payee. This function is not protected by any modifier to protect it from a call which is not the payee itself or the owner. Anyone can execute it (But it gets payed to one of the payee, not to your own address). By the developers of OpenZeppelin it is marked as virtual, so it can (and in my opinion should) be overwritten to by the inheriting contract to protect it from misuse. I do not think that the payees wants that anyone can trigger the release of the contract balance or the tokens within the contract.

Next Time

Next time I will have a look at the $Super contract itself and the contract NODERewardManagement.

Until then,

all the best to you.

Philipp