Info

Dreamy Pug
Author

Source on GitHub

https://github.com/Vasylll/apportion-ton-smc

Smart Contract Address

kQBS8IaEVSpQa31xmm8YrPcPWiu6eEou5Xa21lnAgR0cedrH

Testing and Issues

You can test this entry and submit issues during the testing period of the Blockchain Contest, Stage 2 contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.

Voting

2

Comments

Dreamy Pug Dec 24, 2019 at 10:26
Smart contract aims to handle group expenses.

For instance you are going for a trip with your friends, all expenses are supposed to be shared between you all.

You (smc owner) initialize a smart contract and record in your friends (add smc members) by adding their address and public keys.
Now, any member can send his expense signed with his own public key to the smc. Once smc owner approves expense, smc recalculates who should pay whom and how much.
Member can ask smc about his own balance (credit/debt).
To pay off a debt member should send certain amount of grams to the smc, it will redirect your payment to the member with the biggest credit and recalculates all members balances.
It is also possible to withdraw member credit manually if smc has enough grams on the balance.
You have not added any comments yet...
by rating

Issues

Clever Turkey Feb 11, 2020 at 02:22
We found some issues in your contract.
Critical:
- In withdraw function `msg` can be loaded from input message. `amount` doesn't have to be equal to amount set in `msg`, so funds can be easily stolen by any member.
Minor:
- In approve_expense external message is accepted before valid_until is checked, effectively allowing to drain contract balance if the check fails.
- creditor_lookup is very inefficient and is called for all members.
Dreamy Pug Feb 11, 2020 at 23:53
Thanks a lot for the feedback!
- with regards to `critical` issue found, I also noticed it but it was too late to change the code. I mean, I didn't want to change anything after the deadline to avoid disqualification. I should have just delete the an option to withdraw by external message.

- with regards to `minor #1` issue, it's very low chance to drain funds this way, because if we are inside of `approve_expense`, then multiple validations has passed already (msg time validation at line 272, signature at line 289, expense id has found line 146). But yes, still possible to drain funds if unapproved expense has expired and mentioned validation has passed. It's definitely better to move `accept_message` after expiry validation.

- `creditor_lookup` should be optimized for sure, the simplest in my mind is to keep members list in a sorted order, so that `creditor_lookup` will just pick the first one from the list.
Nobody added any issues yet...