EOS Aridrop gone wrong: SEVEN
se7ens.io is running a promotion campaign where the users can claim 10000 SEVEN tokens via a Scatter extension. They decided to run an “airgrab”, so that the users claim the tokens and pay for RAM from their accounts. Alright guys, you saved $10000, but…
But it went totally wrong, in many different aspects:
- The smart contract of
xxxsevensxxxis an extension of a standard
eosio.tokencontract. They added a new method, “signup”, which takes the desired amount of SEVEN tokens, and just gives the tokens to the user, without leaving any action trace. So, the tokens appear magically on your account, without
- Also they forgot to verify the amount (why is there the amount at all?) in their
signupmethod, so I managed to claim 1 billion of their tokens.
- After I published the above post on Reddit, they silently cut my balance to 100000 tokens and called it a bug bounty. I didn’t even receive any transaction in my history, and the tokens have magically disappeared. So, the team assigns themselves a freedom to modify user balances at will. I wonder how they plan to be listed on an exchange with such treatment of their assets.
How a proper airdrop should be done
- Copy the standard
eosio.tokencontract and only modify it if really necessary. The only thing that the standard contract is missing, is freezing the tokens if you want to prohibit the transfers until a specific date. In other cases, just take the compiled WASM code of the standard contract and upload it to your token account.
- Assign permissions to execute
issuemethods to your treasury account.
- Make the token contract immutable: set the owner and active permissions to
eosioaccount and remove your public keys.
- Test everything in a testnet before applying in live network.
- Transfer the whole amount of airdrop tokens to a separate account dedicated to the airdrop, and distribute them from there.
If you really need to save on RAM, there are some good examples of airgrab contracts on Github, but such thing needs a thorough audit and testing before going live. The rest of the above recommendations applies: the contract needs to be immutable, and most of the funds should be controlled by a highly secure treasury account.