Allowlist of Sablier "rescuers"

[PaulRBerg]

An offshoot of #110:

What if we implemented a simple allowlist of special accounts with permission to call withdraw on behalf of the recipient of any stream, transferring the funds to the recipient? The allowlist would be managed by a multisig.

Pros

• Foolproof for stuck users. We could potentially rescue the funds for the recipient in case the tokens are sent to an address which cannot interact with the Sablier V2 protocol (e.g. a CEX address or a contract) and the sender is not able to claim on behalf of the recipient (e.g. he is unresponsive or lost access to his crypto wallet.
• Convenience. We could offer this as a paid service to lazy users who were granted Sablier streams but who couldn't care less about learning how to set up MetaMask to claim from Sablier.
• Withdrawal automation: We could potentially offer automate withdrawals at scale, programmatically, in exchange for a subscription fee.

Cons

• If any of the rescuer wallet's private keys get leaked, they would be able to trigger withdrawals on behalf of any Sablier user.
• Though not in a custodian fashion, this would give Sablier a little bit of financial control over the protocol, which would mean another topic to consider from a legal perspective.

My Take

I personally think that the pros outweigh cons. The only real concern about this is the development cost.

[razgraf]

The real concern is the gravity of the power placed in the hands of the allowlist. Given too much power, someone will most likely abuse it. By their hand or forced by other parties.

Handing over access to basically all redeemable funds in any stream alive means that if a party gets a hold of one of the allowed addresses, that party can now redirect all funds into their own wallet. In a DAO reality, if someone puts up a vote that passes unseen, containing a rage-quit instruction, they can steal literally everything available for withdrawal. In a legal situation, if the signers for one of those wallets are pressured to activate the deadly option, the reality of things going so very wrong is no less than frightening.

Aside from trying to limit our access-control schema to the bare minimums (which is a security best practices), not providing too much power that can end up in a nuclear explosion is usually a good thing to do.

Implementing this global allowlist sacrifices the security of the many for the convenience of a few.

---

As you can see I'm pretty much against these global/public triggers. I'd be fine with implementing (at a slightly steeper development cost) a per-stream allow-list through a proxy "recipient".

While it doesn't really solve the foolproof 1st argument, one could transfer an existing stream to a proxy (one with logic) that grants their address full rights (as a transient owner) and our relayer withdrawal rights in order to account for argument 2 and 3.

[PaulRBerg]

You have misunderstood my idea. At no point have I suggested to give the allowlist the power to withdraw to their own accounts. The idea is to let an allowlist of rescuers to call the withdraw function on behalf of the recipients and transfer the funds to the recipient's address.

Can I kindly ask you revisit my proposal, and reconsider it in light of what it actually means? I still think it would be valuable.

[razgraf]

on behalf of the recipient of any stream, transferring the funds to the recipient

Sorry, this part made me jump to the conclusion that the allowed entity would have unlimited power over any stream and any redirection. I see now that you want the recipient to be the same address, not another address defined informally as "also the recipient" entity. This makes things a lot more manageable, thanks for clarifying it. You do have to understand the overreaction if you take into account what my initial understanding was haha.

I guess the proposal now makes a lot more sense. I'm yet to figure out edge-cases for this, as it is still giving a bit of a "god mode" power to a single set of wallets. Let me sleep on it, but I now tend to agree with the value in adding something like this.

As a side note, apart from this allowlist capability, do we want to have "pauser" permissions (or similar) for these new contracts?

[PaulRBerg]

It's fine.

There are no edge cases. All this proposal would do, in practice, is add a new modifier to the withdraw function called isRescuer or isAllowlisted or something along those lines. The existing behavior would remain unchanged.

The "god mode" power is only a concern from a legal perspective, i.e. that Sablier would have a bit of financial control over the transactions settled by the protocol.

do we want to have "pauser" permissions (or similar) for these new contracts?

NO.

[PaulRBerg]

@razgraf any new thoughts on this? In your latest comment above you said you wanted to sleep on this idea.

I have basically maintained my position - the only real concern is the development cost. The benefits are worth it.

[razgraf]

I'm in favor of doing this. I'd just reconsider #158 in light of this allow-list, which basically has the same benefits with the addition of more granular control over withdrawal events (for both community and integrators).

Question for the allow list: should we maintain a fully permissionless variant of stream? I'm thinking what if someone wants the stream to be fully locked, with no allow list in place. Do we code a flag for this (similar to the cancelability flag)?

[PaulRBerg]

#158 is in a completely different ballpark with this discussion.

The same benefit might be achieved (prevention of locked user funds), but the means by which we get there are anything but similar. By allowing the sender to claim on behalf of the recipient, we are providing a non-interventionist solution, which is trustless and scalable. With the allow-list, we would have to have a form somewhere on our website "Did your funds get locked in the protocol? Let us return them to you". And by the way - how would that sound from a legal perspective?

My vision for the rescuers is for them to be last-resort system, which we use only in certain circumstances in which nothing else works. It wouldn't be advertised anywhere on our website.

Should we maintain a fully permissionless variant of stream? I'm thinking what if someone wants the stream to be fully locked, with no allow list in place. Do we code a flag for this (similar to the cancelability flag)?

No, this would be overkill; communicating this functionality to the user would be very difficult. I am already of the opinion that Sablier V2 is complex enough.

[PaulRBerg]

Locking this conversation, as per the decision that @razgraf and I have made during our most recent in-person meeting.

In short, implementing the rescuers is not worth it when there are simpler alternatives for rescuing funds, such as #189.

[PaulRBerg]

I'm re-opening this discussion based on the latest conversation in #666.

Here's a sketch of the most recent proposal:

• We implement a relayer system that allows the admin to add and remove relayer accounts
• Relayers can perform automatic withdrawals for any stream (this is easy to implement with Gelato)
• Users can opt out of the automatic withdrawals by setting their associated flag to false in a global mapping disabledRelayers
• (Optional) The UI would let users specify if they want automatic withdrawals (although there's a risk of overstuffing the create stream form with too many options, so this is TBD)

While this system will not completely alleviate the NFTFI integration issue discussed in #666 (comment), the risk will be more negligible. The ability to withdraw from streams shifts from all senders to just a tiny set of relayers, which will be controlled by Sablier Labs (in the foreseeable future).

[PaulRBerg]

@andreivladbrg would appreciate your feedback here when you have a moment (not urgent!).

[andreivladbrg]

As time passes, I start liking the idea of relayer accounts more.

Although I have some questions regarding your proposal:

Relayers can perform automatic withdrawals for any stream (this is easy to implement with Gelato)

Who would pay for these transactions? There might be cases where users would "abuse" this system to reduce their costs.

Users can opt out of the automatic withdrawals by setting their associated flag to false in a global mapping disabledRelayers

Who is the user, per se, that would be able to set this flag? Is it the creator/sender/recipient? Can it be changed after the stream is created?

[PaulRBerg]

Thanks for your feedback! This is good food for thought for ~V2.2

Who would pay for these transactions?

Assuming you meant gas

Gas will be paid by the entity running the relayers, e.g. we. The end user (stream sender) would pay a subscription in exchange for us performing this service.

There might be cases where users would "abuse" this system to reduce their costs.

The rate of withdrawal would be deterministic and known in advance to all parties.

Who is the user, per se, that would be able to set this flag?

The recipient. But I am not much in favor of this feature.

[PaulRBerg]

It looks like Yearn's vesting contracts offer this feature via an open_claim function:

https://github.com/yearn/yearn-vesting-escrow/tree/d14eed16f5b131bc35c58df2b8b4a03427928ef1

[PaulRBerg]

Validation for this feature:

One idea / request would be to allow a user to enter an address and a claim frequency so make it easier to automate the collection of the streams. User responsible for maintaining ETH in their wallet otherwise auto claim fails until ETH is topped up.

From https://twitter.com/thecurious_gark/status/1631451577973104641

[maxdesalle]

Anecdotally, we have received several requests from users asking for the ability to allow stream creators to pay for the withdrawal gas fees of the stream recipients, essentially asking for the ability to withdraw on behalf of recipients. They can already do so to the recipient's address, though, so not sure it's worth it to implement this for addresses other than the recipient's address.

[PaulRBerg]

Closing as outdated since we have decided to make the withdraw function public:

#731