Should the senders be allowed to refund others deposits?

[andreivladbrg]

As per one of Rusty’s findings: https://cantina.xyz/code/99ae802b-f05c-4e36-a1d1-240d5146649c/findings/6

Since the deposit function is publicly callable by anyone, it means that anyone can act as the depositor for any stream. The issue arises when a depositor wants to fund a stream but also guarantee that the recipient will receive all the funds. Currently, this guarantee is not possible.

IMO we have three possible scenarios:

1. Accept the current implementation and warn other depositors that the funds can be taken by the sender via refund
2. Allow only the sender to call deposit
3. Introduce a new variable (non refundable balance - shortly nr_bal) that tracks the balance deposited by non-senders
   • the withdrawable amount then becomes: min(bal + nr_bal, td)

Between these, I would personally vote for either option 1 or 2.

wdyt? @sablier-labs/solidity @razgraf

[smol-ninja]

Not really a finding in my view (if we all agree, we should inform Rusty too), not even an informational.

• Accidental deposits into a stream are very unlikely. It requires calling a deposit function with a wrong stream Id. This is similar to accidental ERC20 transfers or withdrawals to incorrect addresses, none of which are reversible and are not considered an exploit but rather a user error.
• If UI becomes malicious, then there would be bigger issues.
• The advantages of public deposit for senders outweigh these "unlucky" accidents.
• Your first suggestion is solid: a warning in the UI when a user deposits into a stream they are not sender of.

Option (2) restricts the flexibility for senders to deposit from multiple addresses, and option (3) seems too complex given the nature of the issue.

Even in case of grants, if a DAO decides to steal depositors money, before that they would dump their token and rug their users :))

[PaulRBerg]

Fully agree.

[andreivladbrg]

Agree with you. Just wanted to make sure we are all on the same page.