Making withdraw public: Pros and cons

[PaulRBerg]

Context

There has been a lengthy discussion about the permissiveness of the withdraw function in Withdraw on behalf of.

I will attempt to summarize the dissenting views on the matter here, as objectively as I can, but as you guys know I tend to favor the position that we should make withdraw public.

Interpretation of Money Ownership

There are many ways one could interpret the moneyness of a Sablier stream, but the two ways that are relevant for this discussion are the following:

1. The money in a Sablier stream is not actually the recipient's until the recipient withdraws.
2. The money in a Sablier stream is actually the recipient's, even before any withdrawal is made.

I shall refer to the 1st interpretation as the "Conservative Interpretation", and to the 2nd as the "Dynamic Interpretation".

Crucially, this distinction is a psychological one. The technology is the same in both cases - it's just a question of how humans interpret it. If we're successful, this distinction might someday be statutory, in which case we will just follow the law. But we're not there yet.

The Interpretation Makes the Position

The Conservative Interpretation favors making the withdraw function private, while in light of the Dynamic Interpretation, making withdraw public makes a lot of sense.

Thus I think this is actually a debate about what interpretation we should favor internally.

Pros

Global Relayers

A public withdraw function would give us extreme optionality. We would be able to:

1. Withdraw money for stuck users, e.g. those who streamed money to CEX addresses.
2. Offer a great UX for withdrawal automation, e.g. withdrawing for users once per month, without asking users to sign a message or make a transaction. This could potentially be done in exchange for a fee, which would be yet another source of revenues for us.

Simpler Implementation

No need for any whitelisting mechanism. The pure withdraw function would be able to do everything.

Scalability

Assuming the Dynamic Interpretation ...

The year is 2025 and Sablier is completely integrated in most web3 wallets, including MetaMask.

MetaMask now tracks all of your Sablier streams and shows up the total balance access all streams. When you wish to make a transfer, MetaMask will check what is the actual balance of your EOA and, if it is not sufficient to cover the transfer costs, MetaMask will simply call withdraw on your behalf on as many streams as needed (or ask one of the many public Sablier relayers to do this), so that you can perform your token transfer.

Cons

Taxable Events

Assuming the Conservative Interpretation, anyone would be able to trigger a taxable event for any Sablier user.

Lack of Control

Again assuming the Conservative Interpretation, users wouldn't be in full control anymore. Some users might feel uncomfortable with the idea that random people on the Internet can move funds for them.

Riskier Implementation

All else being equal, a function which can be called by anyone is a more dangerous function than a function that can be called only by some users.

[PaulRBerg]

Above, I presented the debate objectively. Below, I will give a few subjective takes.

My Interpretation

We ought to remember that Sablier is a money streaming protocol, not a token vesting protocol. It just so happens that vesting a brilliant use case for streaming, but Sablier is first and foremost a money streaming protocol.

True money streaming means that with every second that passes, the money is actually yours. So the Dynamical Interpretation is the only charitable interpretation of money streaming.

I know that in practice, we don't deliver on that promise today. Users need to manually inspect each stream. We don't even show a total balance of all streams in the Sablier UI. But here we're concerned with V2 and the future direction of the project, so this is the right time to talk about a shift in perspective.

My Responses to Cons

Taxable Events

This is fair, and IMO the only relevant con. Though I think we should view it as a necessary cost for the pros, and we should also weigh in on how large this risk would realistically be. I posit that for the vast majority of streams, there would be zero interest in triggering a taxable event for the recipient (in order to grief them).

Also, there's no MEV.

Lack of Control

This an irrational fear. As long as the protocol is safe (an assumption which we make nonetheless), users shouldn't be concerned about this.

Riskier Implementation

All else being equal, this is true. But not all else will be equal - we will take greater care of the testing for this function, we will fuzz the caller addresses, and so forth. We're not in a hurry with the contracts deployment, so we have ample of time to test the protocol.

[andreivladbrg]

A solution that I thought of and I think that would please both camps would be to add a bool type variable in the Stream struct that will give free will to the users to decide wether they want or not to have a public withdraw function.

The only downside I could think of is that it adds complexity to the core, but maybe it's worth it.

[PaulRBerg]

@razgraf I guess that after the recent conversation we had with Andrew (as per #150), the possibility of making the withdraw function public is completely out of question now, isn't it?

[razgraf]

Yes, I believe so. We anticipated this in our conversations early on but hearing it from a user (and integrator) makes it clearer.

---

To keep an open mind: for those looking to enable public withdrawals later down the line we can provide some tooling to make it "opt-in" by using some sort of proxy (anyone can call withdraw through the proxy). This makes it so we keep sensitive features opt-in rather than enabled by default.

[PaulRBerg]

Locking this discussion since it's clear that we won't make the withdraw function public.

For the same reason that no DeFi protocols allows any third-party to claim tokens on your behalf (e.g. yield farms don't allow this).

[PaulRBerg]

Unlocking this because I just saw in LlamaPay's README that their withdraw function is public:

Ability to trigger withdraws for someone else (for people that don't use metamask)

[PaulRBerg]

I also don't think it's a productive thing for us to do what (1) we think regulators may or may not do

Of course it is. Until legislators (this is not about regulations, it's a question of how smart contract balances are viewed under statutory law) provide clarity on this, we have to take a stance on what it is likely that they are going to do. And my point is - hey, it's not so obvious that some money that is rightfully yours and can be extracted any time (I mean, we are promoting ourselves as a streaming protocol) but is sitting in a smart contract should not be taxed.

those actions could harm our users in the meantime

By saying this you are implicitly assuming that legislators will choose to not consider smart contract balances as legally owned by an EOA. Which it's an educated guess and it's likely that legislators will end up doing this, and so users would be harmed only if they withdraw, but you have to follow this chain of reasoning to arrive at this conclusion.

Here's my rationale for why money that is effectively "owed" to you by a smart contract (whether streamed, airdropped, or whatever) should not be considered legally yours and thus not be taxable (putting my legislator hat on):

1. Mental overhead. It's just unfeasible to expect everyone to monitor all the smart contracts in existence, and on top of that understand the API of the said smart contracts so well that the user can know how much money they are owed by the smart contracts. What about unverified contracts? And also, what about statefulness and mempool txs that might impact your eligibility to withdraw?
2. Practical accounting purposes. It's impractical to pay taxes every second (this might change with Sablier V3 tho, with stream composability).

Other projects doing X is a good argument but not without having a clear idea why they did it doesn't help a ton.

Good point. We should find out why they did it, and how often this public withdraw functionality is needed.

[razgraf]

The dynamic aspect of "anyone can press this button at any time" is not harmful just tax-wise. I'm trying to not have a strong case on this for now. But the act itself. It's simply a trigger which made public, would be far out of the control of our streamers. Tax is one point. Integrations is another. Imagine the mental gymnastics of your personal accounting with the following scenario:

"Ok so my funds are in a stream contract, where I manually withdraw to get a hold of them ... I'll do this 2 times a week ... but wait what are these 2 TXs from an address I don't know (sender) and can't google (idk, DAO, relayer etc.) and who clicked withdraw from me ..."

Regarding your regulator-pov rationale, I agree, although this feels like it should be in another more political discussion, not necessarily related to our withdraw function. At the moment, the reality is:

1. I think there's more social/mental complexity in a public scenario vs a slightly more private one
2. When given the choice, I'll always consider reducing an access control schema
3. If we were to consider what other ecosystem participants have told us about how they handle taxable events, we'd just follow common practices (simply accepting something can be considered endorsing it, but still..)

[PaulRBerg]

Fair points, and agree with most of what you said, with a few exceptions.

"an address I don't know"

You definitely know the Sablier contract address if you are calling it twice per week.

It doesn't matter who paid the gas for a withdrawal. In fact, it's a good thing for your PnL if someone else pays for gas.

although this feels like it should be in another more political discussion

I don't think this should be moved in a separate polemic, because it's about the withdraw functionality in particular.

When given the choice, I'll always consider reducing an access control schema

This a priori stance that doesn't hold water under scrutiny. Would you also like to add an access control schema in the create functions, so that we ban some users? You have the "choice" of adding access control there, too.

My suggestion is to discuss each feature/ proposal on a case-by-case basis, and limit the a priori baggage.

[razgraf]

You definitely know the Sablier contract address if you are calling it twice per week.

I was referring to the address of the random person that calls that Sablier contract and withdraws money on your behalf. You don't know their address. And paying for gas is again, a small inconvenient (you could ask the sender to do that) vs. the panic for an untrained user when things are happening to their stream without them being aware.

I don't think this should be moved in a separate polemic

Ok. One is an economic consideration, the other a UX consideration. Anyway, ok to keep it here for now.

This a priori stance that doesn't hold water under scrutiny

Strawman. Of course access control isn't a one-size-fits-all. But the contract (and its create function) is a public utility (there shouldn't be any massive guardians standing in front of it). Meanwhile, the stream is a semi-private party-to-party matter. It's based on a social agreement where everyone should be able to keep tabs on who can do what. Access control works as a mental model for these type of situations.

[PaulRBerg]

Who cares about what is the address who paid the gas for a tx? This is why gas relayers exist - to offload this step for users.

the panic for an untrained user

I still do not understand what this panic is based upon, besides the tax point which we have discussed above at length.

Strawman

No, not a strawman. You made a general statement that was clearly not confined to the scope of the withdraw function.

Of course access control isn't a one-size-fits-all.

This I agree with. But this is not what you indicated in the previous post, and why my critique of it wasn't a strawman.

Perhaps your intention was to not make a general statement, but this doesn't invalidate my criticism, which I still think it's fair, because it revealed your intended point (in the end).

the stream is a semi-private party-to-party matter

Again, I agree.

[PaulRBerg]

Here's another argument in favor of making the withdraw function public instead of implementing the rescuers idea.

From a regulatory perspective, it would make Sablier seem much less of a financial product, and more of an autonomous protocol.

[razgraf]

I agree.

[razgraf]

@PaulRBerg could you maybe ask some past-users or even developers close to the matter like Micah what they think about this? I'm still pretty much against this (cons of a public method outweigh the pros for me). @maxdesalle expressed his opinion. I'd love to hear @andreivladbrg and @gavriliumircea pitch in too. But hearing some extra opinions shouldn't hurt. That is if you have anyone in mind that could provide a clear argument pro/against.

[PaulRBerg]

Yeah, talking to users is always the best medicine to mediate polemics like this.

If @andreivladbrg and @gavriliumircea pitch in, it would be helpful if they read the whole discussion, not just the first post or someone's comments in particular. There's a great deal of nuance here.

[maxdesalle]

Agree @razgraf, the cons outweigh the pros by a lot IMO. The risks of making the withdrawal function public are just way too high for it to be worth it.

[PaulRBerg]

@maxdesalle could you provide a summary of the risks?

[maxdesalle]

@PaulRBerg I'm just thinking about a situation where a random person would trigger a massive tax event for a large user of ours by calling the withdrawal function for them, that would be really really bad.

And if the withdrawal function is public, it's a matter of when, not if.

[PaulRBerg]

As we discussed above, whether a claim is a "tax event" depends upon the interpretation of legal ownership of smart contract balance. By making the statement you have just made, you are implicitly assuming that money not claimed yet is not legally yours.

Now, I agree that that it's a fair interpretation, and the most likely one on the horizon. My point is to make your implicit (or rather, our) assumptions explicit, so we have a better understanding of the topic at hand.

While I have landed on not making the withdraw function public, I still think it's a productive exercise to keep challenging that decision, especially since we get hints that our competition has taken a different approach (for reasons we don't know yet).

Finally, I don't think that this would be a question of "when", rather than "if". There are a bajillion smart contracts deployed on Ethereum - nobody will give a damn about a Sablier stream if they cannot extract the value of it (there's also no MEV). The only plausible scenario I can think of is a user who knows the identity of another Sablier user intentionally claiming a withdrawal on their behalf .. but this is quite far-fetched, and the said user wouldn't have any incentive to pay the gas for withdrawing from any other stream besides that targeted user's stream.

[PaulRBerg]

Locking. We've beaten this topic to death.

I think that we have landed on a soft agreement that it feels somewhat unnatural to leave the protocol callable by anyone.

[PaulRBerg]

Evidence on Discord that people want the withdraw function to be public:

Hey guys, I just tested Sablier and I really like it! I have a question :
It seems it is not possible to call the withdraw function with another wallet than the sender or the recipient. It would be really cool if any other wallet could call this function, and I don't think there are any additional security concerns, what do you think ?

[PaulRBerg]

Some more feedback from the same user:

our treasury sends a payment to one of our workers that is still not very familiar with cryptocurrencies, thus uses a centralised exchange. It makes him unable to activate the withdraw function, and its quite cumbersome for us to activate the withdraw function with the treasury wallet due to the security features we put in place.

If anyone could call the withdraw function, it would let any employee, when they have the time, activate withdraw with an easy to unlock hot wallet.

To me it seemed there is no problem to let the withdraw function callable by anyone, as they would just pay the gas for you.

I was also thinking this could enable automatic payments, by letting people use Gelato for example to automate the withdraw call, or an automation incentive such as pancake swap had at one point for their autocompounder, where the one that calls the withdraw functions of others gets rewarded with a small amount of tokens that costs more than the gas he pays.

I would like to ask you to reconsider this feature @razgraf @maxdesalle because the arguments put forward by this user make complete sense to me, and I am again in favor of making the withdraw function public.

As I've said multiple times above, the advantages outweigh the disadvantages.

[PaulRBerg]

There are a million ways in which someone can trigger a taxable event for someone else in crypto, and I don't see how Sablier would make any significant difference (at the margin) if the withdraw function were publicly callable.

Whereas I see a great many benefits in making this function public.

[maxdesalle]

There are a million ways in which someone can trigger a taxable event for someone else in crypto

Very good point. Changed my mind about this, agree!

[PaulRBerg]

Thanks, Max.

Piling two more arguments in favor of public withdraw:

1. Traditional airdrops are typically claimable by anyone.
2. Account abstraction-enabled relayers cannot claim on behalf of the account owner (sure, the user can approve the account owner, but TBH that is a faff)

[razgraf]

I (subjectively) still do not like this proposal due to the following:

• public withdrawals make NFT integrations harder (having to deal with 2 parties who can trigger withdrawals i.e. the sender and the recipient seems vastly easier than having anyone able to trigger an action)
• public withdrawals may prevent safe NFT lending (imagine someone front-running an NFT deposit and calling withdraw on it just to lower its valuation)
• I still disagree that "lack of control" is an irrational fear. You've hinted at protocol safety when using this argument. I don't think it's about protocol safety, but rather ownership of one's funds - I'd like to know who can move my funds around (even if they still end up in my wallets)
• Traditional airdrops are a one-time claim, streams are more frequent and longer dated so I can't say I see much similarity between them

Good point on the tax event.

Regarding the user's pain point: would still be solvable by a whitelisted (protocol level or stream level) set of NFT operators. This, without scaling the set of addresses with permission to withdraw to "anyone". On the other hand, they make a good point when they say "as they would just pay the gas for you".

---

I (objectively) am fine with the idea if you still want to implement it, due to advantages clearly still existing and not being invalidated. But I'd urge you to consider a couple more ideas before choosing the protocol-level public withdrawal route:

• popularizing the idea of NFT operators that can withdraw on your behalf
• introducing a flag (similar to transferable / cancelable) which can be set upon stream creation (by the sender) or toggled any time afterwards (by the recipient) that would manage public withdrawals on a given stream

[PaulRBerg]

Created an issue:

#731

[PaulRBerg]

While I created that issue on the basis that we've landed on an agreement here, could you please confirm this, @razgraf?

[razgraf]

We are in a soft agreement, yes (although as stated, I still do not believe a completely public withdraw is the best choice).

[PaulRBerg]

Then we are not in agreement. And that's fine, but we need to continue the debate in this case.

I still do not believe a completely public withdraw is the best choice

Could you please refute my latest arguments, or accept mine and discard yours?

[razgraf]

Could you please refute my latest arguments, or accept mine and discard yours?

I'll try to go over points still unclear to me. You can point to the ones I've missed afterwards.

For the same reason that no DeFi protocols allows any third-party to claim tokens on your behalf (e.g. yield farms don't allow this).

Here, outside of Llamapay, why was this point discarded?

We should find out why they did it, and how often this public withdraw functionality is needed.

Your brought Llamapay as an example of someone enabling public withdrawals. Are we now sure the feature is being used, are there metrics to back up the need for a fully-public withdraw function? (Talking about fully, not partially e.g. sender + relayer, as the former exists and can be analyzed, while the latter not so much - maybe in similar implementations like NFT Operators or gelato-managed contracts, idk).

it feels somewhat unnatural to leave the protocol callable by anyone

You mention here that it feels "unnatural". Has your opinion changed on the topic?
While you may have thought of something else, it does resonate with the "fear" we've been talking about later in the conversation. I did explain it in this post and I believe your comment was that it's invalid due to the "interpretations" made in the OP. To continue...

there should be no qualitative difference between funds in Sablier

I agree with this statement, but the time horizon and related initiatives I believe are crucial to making this point valid now, vs. for/after v3. For example: isn't it too early to march on the "dynamic interpretation" without proper tooling? Shouldn't we first provide e.g. a wallet or a portfolio interface that teaches the user about cross-managed assets (streams + static tokens) and then makes it easier for them to aggregate these assets (e.g. through public withdrawals)? What I'm questioning here is the timing: is v2.2. the best place to enable this?

True, but NFT integrations are already challenging

Here you've used an argument against "public withdrawals make NFT integrations harder" by opening up another conversation, not by invalidating the point. If integrations are challenging, isn't good for us to make them less challenging? Would public withdrawals be less challenging than sender-only ones? How about public vs. whitelist? How about them vs. the toggle idea?

To note here, by making them public we do provide one good thing to the integrator, which is clear expectations: they 100% need to handle withdrawals instead of simply leaving them out of the picture due to a sense of safety around the fact that only clear, whitelisted entities can enable them. Knowing the unknowns is an advantage.

High development cost (frontend-wise)
High coordination cost
We have other priorities

Would you mind adding some arguments (or reminding me) as to why the toggle/whitelist is a bad idea? I feel like the point wasn't refuted but just left out due to a very generic cost analysis. For one, I'd feel ok leaving things as they are for v2.2. and dedicating some time to find a better solution for v2.3 if we can find one. But of course, if you can explain why the toggle / managed-withdrawals idea is bad (steelman it), I'm ok discarding it.

Quite the opposite, it leads to a lot of faff; end users would need to manually enable it, understand how the system works

True. Bet then it's a feature that could also be pre-configured by the sender and streamlined by the app. We make it clearer for the user, while making it safer (parameters are more constrained) for the integrators.

Here's another user begging us to withdraw on their behalf

This is also a case for whitelisted withdrawers, not necessarily for public ones.

Could you please refute my latest arguments, or accept mine and discard yours?

I'm sorry if I missed any of the open ones, so if you can point to them I'll try to offer my input on those too.

---

As a conclusion, I'm not looking to beat up a dead horse by not agreeing to an outcome.
I do see the value in having public withdrawals, but at a non-negligible cost of risk, lack of some control and harder-to-predict behavior. I'm ok flagging these as minor, but I still feel the need to express my concern regarding them or at least question if there are any better alternatives.

After answering these outstanding points, if there aren't any that resonate, feel free to include this public-withdrawal function in the roadmap and mark the conversation as an agreement. After re-reading the entire thread, I can see that including it is supported by enough valid and objective arguments to make it feasible.

[PaulRBerg]

Here's another user begging us to withdraw on their behalf:

[andreivladbrg]

after reading this discussion, an idea came to mind - that it's against and problematic to this proposal - if we are going to implement this (or at least something integrating a lending protocol), and if there's a bad actor who wants to manipulate the market or exploit the lending protocol, wouldn't giving them access to withdraw on behalf of the users (presumably a large volume) from the lending protocol be an attack vector for that protocol – and implicitly for us too?

[PaulRBerg]

wouldn't giving them access to withdraw on behalf of the users ... from the lending protocol be an attack vector for that protocol – and implicitly for us too?

No. A good lending protocol has to be able to withstand full user withdrawals. The APY would go to zero (for lenders) but there wouldn't be any security incident.

Also, have you heard about this thing called flash loans? 😁

Anyone can withdraw everything from Aave.

[andreivladbrg]

have you heard about this thing called flash loans

completely different scenario, as the liquidity doesn't exit the protocol at the end of the transaction, access to withdrawing in a recurrent way(continuously over time/transactions) is definitely something that needs more research

[PaulRBerg]

No, not different from the perspective of the EVM unless there's some block number delta checks (which most protocols don't have).

Can you put your finger on what exactly is the security vulnerability here?

if not, there isn't anything.

[andreivladbrg]

not different from the perspective of the EVM unless there's some block number delta checks

that is simply not true, the apy is calculated on block.timestamp, when flash loaning on the same tx (same block.timestamp) the apy is not effected as the funds are transferred back

Can you put your finger on what exactly is the security vulnerability here?

as mentioned in my initial statement: offering a platform for price/apy manipulation(by withdrawing a large volume of assets) is a problem (maybe a legal one) - definitely it is not our intention in doing so but allowing this to happen thorough our "rules" we have in our contracts it is problematic if unwanted events happen - we want to be caution

[PaulRBerg]

that is simply not true

Let's discuss this on a call or in person.

offering a platform for price/apy manipulation(by withdrawing a large volume of assets) is a problem (maybe a legal one)

What users do with the Sablier smart contracts is never our legal problem - they are permissionless scripts that are not in anyone's control.

it is problematic if unwanted events happen

You keep saying it is problematic, but you're not putting your finger on what the problem is. That the APY can go down is a reality of how lending protocols work. These protocols should be impervious to who can make the withdrawal.

Can you please explain, in very specific terms and with a numerical example, what the risk is?

[PaulRBerg]

More (indirect) empirical support:

[PaulRBerg]

Micah's feedback on making the withdraw function publicly callable.

Beautifully argued!

[smol-ninja]

Should I close this issue since withdraw is now publicly callable going forward?

[PaulRBerg]

Yes, closing now.