I am currently writing a paper/article on tokenization, in the beginning of which I introduce smart contracts. To this end, I present the following contract as an example:
pragma solidity ^0.6.0;
contract SplitPot {
address payable[] beneficiaries = [
0x498898b3F52DAba1bB304a4b4D2EA31a111484B1,
0xAcb19c763EB67ea757Efd8Cd8b6ecceb28F1284B,
0xD5d3f3650C4DdE7B8034671129443A596Ce8ed57
];
receive() external payable {
uint individualAmount = msg.value / beneficiaries.length;
for (uint i = 0; i < beneficiaries.length; i++) {
beneficiaries[i].transfer(individualAmount);
}
}
}
Obviously, the purpose of the contract is to evenly distribute all Ether sent to it among the three beneficiaries (all of which are testnet accounts I created). It works on testnet.
For this specific purpose, i.e., explaining what smart contracts are, I believe this is a very good contract:
- It is very short and easy to understand.
- It does something that is usually facilitated by a trusted third party -- which is now obsolete.
I also know this is a very bad contract, as it has severe shortcomings. For example: What if a transaction fails? Afaik, the beneficiaries have no way of recovering their share of Ether, and the contract doesn't re-attempt to send it to them. Also: I don't know whether the contract would execute correctly on mainnet, too.
I want to inform my readers that this is, in fact, a flawed contract, and I want to let them know what specifically can go wrong. As I just started learning about Ethereum, I'd be very thankful if you helped me identifying these flaws -- especially with regards to gas economics and coding style.
The paper/article will be licensed CC BY-SA 4.0, so I am not asking for help on commercial work!
receive
cannot be re-entered (for example, by requiring that a boolean state variable is false at the beginning of the function, then setting it to true, then setting it back to false at the end of the function).function
beforereceive() external payable
, but I guess that's just a typo of yours.