Feature request for optional public withdrawals

[PaulRBerg]

Problem

I've recently demo-ed Sablier on a business call with Contango. I told them about our public withdrawal feature and why we have implemented it, and they said that they would like to be able to disable it for their streams.

The rationale was to eliminate the risk of 'accounting griefing' for their investors; i.e., someone intentionally claiming small amounts to clutter the transaction history for their investor accounts.

Solution

Add a new boolean in the stream struct that specifies if withdrawals are publicly available or not.

Feedback

My take on this is not to rush, and wait for more user requests before making any move.

1. There's no incentive for perfroming these public withdrawals. The only actors somewhat incentivized to do it are malicious competitors/enemies, but there are better ways to cause harm than through accounting griefing.
2. The size of the Lockup contract is a concern.

cc @sablier-labs/solidity and @razgraf and @maxdesalle for feedback

[maxdesalle]

Don't really have an opinion on how needed this is, and am generally in favor keeping the protococol minimal etc., but in any case this griefing "attack" is an expensive one given the attacker needs to pay gas fees. In worst cases it would cause minor discomfort for a specific user, but it's not the end of the world either.

[andreivladbrg]

I am in favor of this proposal (and have been since the beginning back in 2022 😆).

Re the added complexity, it’s just one boolean in the struct, and we could handle it in this function, which would make things smoother.

[smol-ninja]

I am not in favour of this feature but I’d also like to see more user requests before we move forward with implementing it. My rationale is below:

• I agree with Max that a "griefing attack" is unlikely due to the gas cost, which leaves "zero" incentive for anyone. Public withdrawals are only useful for users managing multiple streams across multiple addresses, and they want to withdraw from all of them without needing to switch between wallets or grant transfer approvals. And someone can only accidentally withdraw on an unknown stream.

• So, if griefing attacks are not incentivised, even though a small feature, it may be redundant or only useful to an Infinitesimal set of users, let's say.

If we make a decision to implement it, then:

• Senders should not have the ability to enable or disable this feature. Since it directly impacts recipients, they should be the ones deciding whether public withdrawals are enabled or disabled for their streams. This would mean managing a mapping for recipients (address => bool), which would apply globally to all their streams.

• Would it also need to be applied to the claim? The same "accounting griefing" argument applies there as well.

[andreivladbrg]

I’d also like to see more user requests before we move forward with implementing it.

I agree with this.

Senders should not have the ability to enable or disable this feature. Since it directly impacts recipients, they should be the ones deciding whether public withdrawals are enabled or disabled for their streams. This would mean managing a mapping for recipients (address => bool), which would apply globally to all their streams.

We don’t need a new mapping. IMO this should be a stream-based variable (one stream may have public withdrawal enabled, while another may not - salary (public) vs shares vesting (not public)). The easiest and most effective approach would be as follows:

// Add a Lockup.CreateWithTimestamps boolean input parameter to the `create` functions 
// (the sender and recipient may have discussed this prior to creation).
// In case things change in the meantime, we will provide a function for the recipient:
function togglePublicWithdrawal(uint256 streamId) public {
     if (msg.sender != _ownerOf[streamId]) revert();
     _streams[streamId].isWithdrawPublic = !_streams[streamId].isWithdrawPublic;
}

In this way, we achieve the greatest flexibility while keeping it as minimal as possible.

[smol-ninja]

In this way, we achieve the greatest flexibility while keeping it as minimal as possible

Yes but at the expense of paying tx cost for every stream ID to toggle this value. IMO the most optimum solution would be:

1. Allow recipient to set a global preference <----- so that if a user prefers to have public withdraw on all streams, he wont have to do it manually for a new stream created for him.
2. Allow recipient to override it for a particular stream <----- for reason you mentioned above

Similar to fee logic in merkle factory.

[andreivladbrg]

paying tx cost for every stream ID to toggle this value

Indeed, it would be more gas-efficient to toggle this for a high number of streams, but it is more flexible (salary vs vesting mentioned above), and we have batch function to make it easier.

Allow recipient to set a global preference <----- so that if a user prefers to have public withdraw on all streams, he wont have to do it manually for a new stream created for him.

As mentioned in the comment above, I don’t think he needs to do so. If he has this preference, he can always discuss it with the stream creator beforehand to make it public.

The problem with this approach, is that I believe it would significantly increase the size.

[smol-ninja]

but it is more flexible, and we have batch function to make it easier. It would significantly increase the size.

Then, we can also allow public withdrawals by default and use togglePublicWithdrawal to disable it—this would also not cause the size problem. I really think that public withdrawals are very useful for users (I myself use it a lot, and I don't want senders to make a decision on the default value for me).

he can always discuss it with the stream creator beforehand to make it public

This can not be practically possible given that a sender can have millions of recipients. Take the example of campaigns, I don't think campaign creators take inputs from recipients on the configurations, they just do it and announce. This two way conversaion, however, is possible in payroll.

So with salary use case, users may prefer to have non-public withdrawals (and also that its very likely to use only one address to accept payments), but for airdrop campaigns and vesting, it's typical for a user to control more than one address.

So, what if we introduce this feature in Flow only and see what senders and recipients prefer more?

[PaulRBerg]

Thanks guys, great feedback.

I agree that gas costs make griefing attacks (almost) pointless.

Interesting point about allowing recipients to decide if they want public withdrawals. However, this sort of defeats the purpose mentioned in the OP.

• It increases the cognitive load for recipients — whether a blockchain function is publicly callable or not is a rather technical detail, which many users may not understand
• It doesn't allow senders to make decisions on behalf of recipients (which is what Contango wanted) — though, as you said @smol-ninja, this is both a pro and a con, since experienced users like you would prefer to make this decision on their own

Would it also need to be applied to the claim?

No. That's a one-time claim, and it's an airdrop, and it's more difficult to generate the leaf data.

even though a small feature, it may be redundant or only useful to an Infinitesimal set of users, let's say.

Indeed.

[PaulRBerg]

Will keep this open for a while to see if we receive additional feature requests for this.