Withdraw on behalf of

[PaulRBerg]

In an offline discussion, @razgraf made the suggestion to implement a "withdraw on behalf of" functionality, which would enable third-party relayers to pay the gas costs for withdrawing for end-users.

My only reservation is that it would take quite some time to implement this, and we already have a long list of more urgent matters to tackle. Multiple new functions and one big mapping would be needed to add support for withdrawing on behalf of other users.

That said, there are two alternative implementations that would achieve the same goal, albeit they would involve different assumptions:

1. What if we let anyone call the withdraw function? Obviously the concern with this is that anyone would be able to trigger taxable events for other people.
2. In a similar vein to Should we rename the "linearStreams" to just "streams" in the "SablierV2Linear" contract? #1, what if we add a new boolean property in the Stream struct that by default is set to false but users can set to true which would allow anyone to call the withdraw function?

[razgraf]

There is a 3rd option of having a special allowance system, similar to the management of the funders.

I'll bring yet another reason for which this functionality is very important. For our custom vault/routers/erc4626 and even as per the example given in #41 we will have the possibility of hiding certain actions from the user. Example: they'll be able to stream native tokens while we do the wrapping on create and the unwrapping on withdraw. In order to be able to do that, the user won't call the withdraw method of the sablier contract but the withdraw/claim method of the vault, which will perform the withdrawal on their behalf, unwrap the token and send it to the user in the end.

[razgraf]

Hmm I was thinking more like:

1. User allows vault to spend asset and wAsset
2. Stream gets created - user calls vault method create which takes asset, wraps into wAsset and calls sablier.create()
3. Stream happens
4. User wants to withdraw - user calls vault method withdraw [the following happen in the same transaction]
   4.1. Vault calls sablier.withdrawOnBehalfTo() - it withdraws wAsset and transfers it to itself (I agree this introduces a new method and a strong attack vector)
   4.2. Vault has the wAsset so it proceeds to unwrap it into asset
   4.3. Vault sends the asset to user

LE: Actually if user allows vault to spend wAsset, we might not even need the onBehalfTo variant

I also like the idea of the vault being the recipient. Even better we could think of some case where streaming vault tokens or special-logic tokens is only done through a proxy/user.

I guess we need to have a session brainstorming just these vault use-cases to make sure we do it right.

[PaulRBerg]

Re point no. 1 - native assets like ETH don't have any allowance mechanism.

Re other points - this is a different feature proposal. I thought we were discussing withdraw on behalf OF, not withdraw on behalf TO. We can discuss this idea as well, but again, we have to weigh it in compared to the other more urgent (and necessary) tasks on our plate.

LE: Actually if user allows vault to spend wAsset, we might not even need the onBehalfTo variant

We would still need it, due to the reasons given in my first comment.

I also like the idea of the vault being the recipient.

Yes but it's not practical. Senders would have to be aware of this and ask recipients to create some specialized proxy/ vault. Very cumbersome.

I guess we need to have a session brainstorming just these vault use-cases to make sure we do it right.

Yup.

[razgraf]

Re point no. 1 - I attempted to solve the wrap/unwrap use-case globally, be it for ETH/WETH or DAI/CDAI, the latter being a type of wrapping as well. Hence the allowance.

[PaulRBerg]

Yes, for DAI/ CDAI there would have to be a wrapping step, but you cannot use the same implementation for ETH/ WETH. I mean, you could, by adding if statements, but I don't see why we would do that when we can just have different periphery contracts for native assets vs yield-bearing assets.

[razgraf]

Well that's exactly what we should do, split it in 2 different periphery! But the logic remains more or less the same (except allowances and payable methods).

[razgraf]

As asked I'll share my thoughts on a public withdraw function.

Pro

• Anyone can trigger a withdrawal, thus being able to subsidize gas costs
• Lower gas costs due to the lack of caller checks

Con

• Anyone could trigger a tax event for the recipient by calling withdraw
• The freedom of choice is out of the hands of the recipient - we would break the principle of least privilege

---

I still think we would benefit from creating an access control scheme where the user can nominate some entities that handle withdrawal on their behalf. The natural question is if we should implement this privilege manager for:

1. withdraw direct to recipient - onlyRecipient, onlySender(?), onlyAuthorized
2. withdrawTo redirect funds to any address - onlyRecipient, onlySender(?), onlyAuthorized

Pro

• Only authorized actors can trigger a tax event
• Withdrawals could be safely automated and redirected (imagine a relayer doing DCAs on your behalf)
• Withdrawals could be combined (zaps) with other transactions maybe even without the need for a proxy contract

Con

• Increases complexity and gas costs

[PaulRBerg]

I assume that what you meant here by the access control scheme is a design whereby the user would allow a third-party to withdraw on their behalf for any stream? That'd be interesting, for sure!

[razgraf]

Another argument against a public withdraw method is the complexity it brings to integrations.
Imagine a collateralization protocol, using a wrapper contract for our NFT streams. As someone randomly calls withdraw, now the balances are split between

1. what's still locked (and available) in the stream itself
2. what's now assigned as balance to the wrapper contract (the recipient at the time of withdrawal) - tokens that if not careful could be locked

[PaulRBerg]

@razgraf what it means for a user to "be in charge" is contingent upon how a user interprets the "moneyness" of their Sablier streams.

[maxdesalle]

It's not even about taxes @PaulRBerg, it's just that I wouldn't want a random stranger being able to withdraw funds from Sablier to my wallet without my approval, just like I wouldn't want a random stranger being able to transfer funds between two bank accounts in my control.

Yes, the money stays mine, but it's still an invasion of personal boundaries.

[maxdesalle]

Worth noting that a lot of recipients in Sablier are people who are really not technical when it comes to crypto. It's usually the stream creators who are technical (company founder), streaming to recipients who are sometimes technical, but sometimes not (company employees).

If someone where to call the withdraw function on their behalf, without them knowing, chances are high non-technical recipients would believe they are hacked.

[PaulRBerg]

@maxdesalle The year is 2025 and Sablier is completely integrated in MetaMask, in the sense that MetaMask tracks all of your streams and shows up your total balance across all of your streams. Suppose then that you want to make a transfer - if the actual balance in your EOA is not sufficient, MetaMask would simply call withdraw on as many streams as needed, so you can then perform your transfer.

The only reason you know that "a random stranger" can perform an action is a matter of web3 wallets UX - that is, how they display your balance with respect to Sablier (hint: they don't do it at all today).

I will expound on this point in another discussion because it became difficult to track all the arguments that have been made in this comment thread.

[PaulRBerg]

If someone where to call the withdraw function on their behalf, without them knowing, chances are high non-technical recipients would believe they are hacked.

Why would a hacker pay you? If they wanted to hack you, they would have taken money from you.

[PaulRBerg]

This proposal has been morphed into #155. Locking.