Delay re-routing funds upon a stream getting canceled

[razgraf]

Context

We recently discussed with a user looking to integrate the Sablier v2 NFTs into their lending protocol. They presented us with some valuable feedback on the lifecycle of the token and how to possibly improve its DX.

Assumption

In the current design, the discussion revolved around burning the token (#129) as soon as the stream reaches an end state.

New perspective (technical)

To support our Sablier v2 NFT, their protocol would implement a special wrapper (a wNFS if you may, as in "wrapped non fungible stream"). The fact that canceling is a hard-to-predict action (sender may choose when [if stream is cancelable]) would force the integrator to code special logic to host not only an ERC721 but ERC20s too, inside the wrapper. This is because, upon cancelation, the owner of the token would have to expect funds being sent into their balance. The owner/recipient here would be the wrapper itself, hence the need for custom logic.

Proposed solution

The proposed solution consisted of creating a new end state that comes into play after the stream gets canceled. Instead of burning the NFT, the cancel action would move the idle/non-streamed funds back to the sender, while the ones that haven't been redeemed yet would remain in the custody of the NFT itself. This would actually make withdraw the only case when, upon asking to redeem 100% of the available funds would cause the stream to move into an end state and possibly be burned.

New perspective (economical)

Although we are not financial advisors and tax is subjective to our user's own research and jurisdiction, in a borrowing context, leaving the funds locked into the NFT could prove beneficial for its owner. As borrowing is usually not a taxable event, the user could choose to leave their funds idle in the token contract (delaying the final withdrawal) and borrow against it even though the stream itself may have stopped a long time ago.

TL;DR;

• Token should not be burned on cancel
• Token could be burned only on the final withdraw (no more value inside)
• In the context of integrations, any other action that's not in the full control of the recipient should be considered with extra care
• Keeping the NFT alive (for as long as it can theoretically hold value) maybe prove to be tax advantageous

[PaulRBerg]

This is great feedback. Never a bad idea to talk to users some more.

Trade-offs, Trade-offs Everywhere

As a general preface to my response, I wish to remark that it is not possible to build a protocol that serves all needs. As we've discussed elsewhere, all streams are not created equal.

Feedback

would force the integrator to code special logic to host not only an ERC721 but ERC20s too

I'm afraid that they would have to do this anyway, because the withdraw function allows the sender of a stream to withdraw on behalf of the recipient:

• withdraw
• isAuthorizedForStream

The proposed solution consisted of creating a new end state that comes into play after the stream gets canceled

I am against this.

1. This wouldn't tend to the problem, not at all, as per my explanation above that the sender can still trigger withdrawals.
2. The withdraw point is critical, but if we never mind it, a new end state in the cancelation flow would add yet another branching structure in the logic of the contract. We would have to reconsider renaming this repo to something like sablier/v2-contracts, because this wouldn't be just a simple, basic core any more.

Instead of burning the NFT

The burning of the NFT is rather orthogonal to the discussion regarding the end state of the stream. We could very well let the NFT live forever.

the cancel action would move the idle/non-streamed funds back to the sender

So what if later on we discuss with another user who says that, also due to tax or accounting reasons, they would prefer the protocol not to auto-send the funds to the sender on cancelation?

A smarter way to tend to this would be to only claim the funds for the caller - if the caller is the sender, claim for the sender, but not for the recipient, and vice-versa. But this would add a great deal of complexity for little benefit and at any rate as per my explanation above this is not a proper solution.

Although we are not financial advisors

This is another reason why we shouldn't make decisions about what counts as a taxable event or not.

Additionally, as I have explained this at length in #110, it may well be the case that in future, closed-ended Sablier streams will be considered income even before claiming.

Framing the Solution Differently

Rather than regulating the rules of the game ourselves (and adding undue complexity in the core), we should let developers "react" to stream interactions, i.e. to cancelations and withdrawals. See the discussion I opened about this here:

#157

Side Note about FSMs

Might it be helpful to flesh out a finite-state machine with the xState Vizualizer so that we are all aligned on the flow of funds in Sablier V2 (that is, us and the Astaria team)?

I don't think that handling ERC-20s would be such a difficult task for the wNFS contract. If they are serious about this integration, we might offer to give a hand and help them implement the handler. We might even consider offering this a smart contract SDK or something.

[razgraf]

Opened a Q&A in #158 about the withdraw permission we're giving a sender.

So what if later on we discuss with another user

Well, our job is to provide a kick-ass experience through our contracts, so talking to devs and weighing every suggestion is of the essence. At this moment we have only one feedback to work with.

Please do consider that the Proposed Solution above was my interpretation of the issue at hand. The latter should be treated independently of my suggestion.

Might it be helpful to flesh out a finite-state machine

I love the FSM idea.

[PaulRBerg]

provide a kick-ass experience through our contracts

Trade-offs. You cannot provide a kick-ass experience to everyone.

The latter should be treated independently of my suggestion.

What is the "latter" that you referred to here?

[razgraf]

"the issue at hand"

[PaulRBerg]

I am still very much against this, especially after my recent proposal in #164 to enable recipient hooks.

@razgraf can we consider this conversation closed and lock it?

[razgraf]

We can lock it sure. While hooks don't solve the problem, they at least provide better UX for integrators.

The tax problem remains, although one may engineer their system such that the recipient simply doesn't withdraw (not realizing the profit). And if they want the funds to remain safely locked in the stream NFT, they could ask the sender to "disable cancelability" towards the end, such that the recipient has full control over the instance of the NFT stream.

[razgraf]

P.S. I'm actually writing these ideas (combination of stream features) with the intention of turning them into recipes at some point. Meaning, "how-to(s)" for common use-cases our integrators may stumble upon.

[PaulRBerg]

Indeed the solution may be to just never withdraw, but even if a withdrawal is made, the funds are technically in the lending protocol, not in the user's wallet. So an argument could be made that the funds have not been realized yet.

Also good point with non-cancelable streams - I think there will be quite a few of those so at least this category will be shielded from the tax problem.

Re recipes - sounds like a great idea for an article series.

[razgraf]

This functionality ended up being implemented in #422 as a security practice.