Allow senders to undo the streaming to rescue tokens in case of recipients losing access to their wallet

[PaulRBerg]

Problem

Fallibility is a fact of life, and there's nothing we can do to prevent recipients from losing their wallets. Mistakes will still be made even in a world powered by Account Abstraction wallets with social recovery features.

Note — this discussion refers exclusively to cases when users lose access to their wallets. Cases of wallet hackers are out-of-scope.

A recent user (Derive) has recently inquired about this possibility on Telegram:

Solution

• New boolean isRescuable (nomenclature due to be settled later) in the stream struct that allows senders to specify if they want to be able to undo the streaming.
  • This boolean setting would be hidden underneath an Advanced section (similar to the optional public withdraw feature), and by default, it would be set to false.
• New function rescue that can only be called by the stream sender to undo all streaming and rescue all tokens
  • To simplify the first implementation/API, we could consider allowing this function to only be called once, and have it refund all available tokens back to the sender, and automatically settle the stream.

Nota Bene

Introducing this feature would make Sablier less trustless for recipients as they would have to trust the sender to not undo the streaming. Historically, we have argued that this is bad because it makes Sablier as a whole less permissionless. However, I would now like to argue against that view:

• The vast majority of users won't click on Advanced, so most streams will remain non-rescuable.
• Only sophisticated users who consider this possibility will use this.
• Even when isRescuable is set to false (the default), recipients still need to place a high trust on the sender — e.g., they can abandon the project
• At any rate, Sablier Labs will still have zero governing power over the streamed assets. So, from a legal perspective, we're as well-covered as ever.
• Over the years, we have received many feature requests for this. We should listen to users!
• Our competitors Streamflow and Hedgey offer this feature.
• And again, fallibility is a fact. Errors will be made, and this feature will make error correction possible.

Feedback

cc @sablier-labs/everybody for feedback

@maxdesalle maybe you can remember any requests for this received over the years?

[maxdesalle]

No. No. No. Applying every single non-existant veto rights I have against this.

Recipients need to be able to trust and have the peace of mind that when they receive funds in Sablier, those are safe and owned by them. If we start meddling with that and make some streams "safe" where the asset cannot be rescued, and others "unsafe" where they can, that trust and peace of mind is broken. Bad luck for the senders. They made a mistake, that's how it is. There's no way to "rescue" a token transfer on the blockchain either, people are already accustomed to that.

[andreivladbrg]

Same here, personally I am against this feature.

They made a mistake, that's how it is. There's no way to "rescue" a token transfer on the blockchain either, people are already accustomed to that.

completely resonate with this

also, as an analogy from real-world scenarios: it’s like an employee going to the employer's bank to recover money that the employer lost because they got scammed.

[smol-ninja]

A very interesting proposal, I must say. If I only focus on the problem of "rescuing tokens in case of loss of wallet private key," I have another solution:

There are wallets managed by email ID, such as Phantom (yes, it supports EVM as well), and then there are also wallets such as Coinbase, which are managed by biometric. IRainbow also has a pretty solid backup option. And I suppose the majority of the users, for this discussion, are rookies, and they do whatever the wallets ask them to do, i.e., back up on iCloud.

I can bet that in 2025, more popular wallets like Metamask, Rainbow, and Gnosis Safe will start having features to create wallets using email IDs or supporting passkeys. I haven't dig much but I think there are more wallets that support passkeys these days.

 The vast majority of users won't click on Advanced, so most streams will remain non-rescuable

It means that this is a concern only for a handful of senders. These senders can recommend their users to use wallets like Phantom or educate them about backups. We can also support Phantom in the UI for such users.

My take on the proposal is that I think this feature is analogous to cancelable with the addition of now retrieving streamed funds as well. As most streams are cancelable, with this feature enabled, more and more senders will start making streams as rescuable, as a backup, and if it gets misused just once, it will put Sablier reputation at stake.

[andreivladbrg]

good points ser

[razgraf]

I echo @maxdesalle's view and stemming from @andreivladbrg's note, it makes me think this could make the system even more dangerous.

It makes large sender wallets a larger target for hacks since all streams can be taken back.

I know, they could've already been targeted maybe due to cancel, but now cancel/non-cancelable doesn't even mean much if everything not-withdrawn can be taken back. Larger pot.

IMO, Sablier should remain neutral here and err on the side of hard rules established onchain. Adding too many levers to pull sends us in centralized territory. The sender-recipient relationship at least becomes too loose, the "trustlessness" aspect fades away.

I'm all for serving the user, but in this particular case, it doesn't do us a favor.

---

Since I believe this "rescuing" is something the recipient should opt-in rather then something decided by the sender, there's a ton of ways to make this happen outside Sablier itself. Similar to @smol-ninja's proposed usage of "smarter wallets" we could recommend them to use things like 1/2 Safe(s), where the NFT (non-transferable) lands in a Safe controlled by both sender and recipient.

In a private conversation earlier you mentioned it's bad UX, but it's good enough for people looking for this extra layer of caution, as well as good enough for us to continue our work while maintaining our "neutral" stance towards the sender-recipient relationship.

It's bad UX, which if we get enough users asking about it, we can then focus on improving.

---

Derive asked for a pre-emptive measure, which can be solved by something like the suggestion above this, today. I relate to their need: maybe the recipient is hacked, or maybe they're a bad actor (investor, employee leaving the company) and they need to terminate the vesting schedule etc. But these are edge-cases and solving them as proposed in the OP would affect all-streams and all-users and I'm not sure it would do that in a good way.

[PaulRBerg]

Because both the sender or the recipient can be malicious.

[smol-ninja]

How are we biased towards recipients?

When it comes to a stream, if the sender is malicious, the inability to recover the streamed amount favours the recipient. If the recipient is malicious, the sender's ability to reclaim the unstreamed amount works in their favour. This appears to be favouring both the parties and hence maintaining a neutral position.

However, if the sender were allowed to recover everything (streamed + unstreamed), it seems we would shift significantly toward favouring the sender.

[maxdesalle]

In any case, neutrality, just like fairness, doesn't matter. What matters is creating a good product, and as noted here, the token rescue feature would break the trust and peace of mind users have in our product.

[razgraf]

Worth noting that in case a recipient is malicious, they'd probably withdraw everything they can so for this case in particular, the sender would be able to recover only the unstreamed amount. Which makes recover act like a toggle-back for non-cancelability .. which again is a problem of optics as non-cancelability doesn't mean much any more.

[maxdesalle]

Worth noting that in case a recipient is malicious, they'd probably withdraw everything they can so for this case in particular, the sender would be able to recover only the unstreamed amount. Which makes recover act like a toggle-back for non-cancelability .. which again is a problem of optics as non-cancelability doesn't mean much any more.

Precisely, very well said @razgraf.