Separate NFT contracts for cancelable and non-cancelable streams

[PaulRBerg]

Problem

I've had a call with NFTFI.com, and they shared some feedback:

1. They can't accept cancelable streams as collateral
2. The fact that cancelable and non-cancelable streams are bundled under the same umbrella is problematic

NFTFI has a whitelisting mechanism that works on a per-collection basis. But since our NFT collection includes both cancelable and non-cancelable streams, this complicates the integration. They will need to add bespoke checks for the cancelability of streams.

Solution

Deploying separate NFT contracts for cancelable and non-cancelable streams would be the solution.

However, given the significant development cost, I am not yet convinced that we should do this.

More brainstorming is needed before arriving at a definite conclusion.

[PaulRBerg]

More feedback from NFTFI (the context is our NFT stream loan demo);

NFTfi will de-whitelist the contract address - to ensure that no other Sablier v2 loans are initiated. This is because we do not want any cancellable streams to be listed

They will have to whitelist and then immediately blacklist our contract, because of the cancelability issue.

[maxdesalle]

Do you know if this is also a problem for other NFT integrators, like DeFrag, or Astaria?

[PaulRBerg]

Not yet but my bet is that it is.

[maxdesalle]

Got it! This might be worth exploring, in that case, as if it's just a problem for one problem, I'm not sure it's worth the engineering time, but if it's a problem for all NFT integrators, then it's obviously definitely worth it.

[PaulRBerg]

I will double-check with Astaria and DeFrag.

However, we can pretty much reason from first principles that this ability of the sender to cancel can pose problems for the NFT lending use case.

[razgraf]

Did you mean "withdraw" or "cancel" here? Sender withdrawals are a separate issue right (a.k.a. #666)?

[PaulRBerg]

Good catch - I meant "cancel".

[andreivladbrg]

They can't accept cancelable streams as collateral

That's totally understandable.

But since our NFT collection includes both cancelable and non-cancelable streams, this complicates the integration. They will need to add bespoke checks for the cancelability of streams.

There will only be one additional check: calling isCancelable.

Deploying separate NFT contracts for cancelable and non-cancelable streams would be the solution.

This could solve the issue, but I am not convinced either that it's worth doing, given:

• The development costs.
• The need to track twice as many contracts, which would significantly increase the time spent managing them.

[PaulRBerg]

There will only be one additional check: calling isCancelable.

sure, but immutable contracts cannot perform this check. NFTFI is handling this problem by manually de-listing the Sablier contracts.

I am not convinced either that it's worth doing

I have actually become more open to this redesign.

The development costs wouldn't be that high, and at any rate what matters most is that this is something that users want.

In terms of address management - that is right. It would be an additional hurdle on our part.

[razgraf]

Unfortunately, our usage of NFTs is more technical then that of usual "PFP" collections so these kind of integration hurdles were bound to happen. While I can sympathize with this incompatibility between our systems, I don't think we should split functionality into separate contracts to accommodate this single scenario.

It comes back to our discussion around flash-loan flavored deployments creating too many choices for integrators (therefore unwanted complexity) - aside from our own management costs, as you discussed already.

Regarding other NFT markets such as Astaria, we should ask but it looks like they allow custom strategies with (1) unique validators based on specific token Ids not just collections and maybe (2) custom validator strategies a.k.a. there may be a way to register a SablierV2Validator in their router.

With DeFrag, it looks like they use price oracles to figure out the value of an asset, so we could just engineer a "Sablier Oracle" that values cancelable streams less (e.g. value streamed but not-withdrawn) or "0".

[PaulRBerg]

I don't think the comparison with the flash loan situation is accurate (or useful).

1. Flash loans were a deterrent
2. Separating cancelable and non-cancelable streams would be a boon

In fact, more than a boon. A necessity, because NFTFI cannot keep our NFT contract whitelisted as long as non-cancelable streams are present in the same collection.

On the integrations:

• It's good that Astaria manages NFTs by token ids.
• But regarding DeFrag, I don't see the relevance of their price oracle for this discussion. What matters is their listing process - do they list by token ids, or NFT contract?

As a side note: if you are worried about increasing complexity on the stream id front, I don't think that that criticism is valid given that we we will face that problem anyway (when we deploy V2.1).

[PaulRBerg]

That said, I agree that we shouldn't rush with this decision. Happy to wait a little bit to get further clarity from NFTFI and other NFT platforms.

[razgraf]

comparison with the flash loan situation

Setting aside the particularities (flash loans being more sensitive than transferability), from the POV of having X contracts vs X * 2 contracts, it is similar, isn't it? For me it's useful, as it creates yet another decision integrators have to make. Also, I'm sure I made this very same point during our FL debates but I cannot find it in a discussion so it must have been in Slack.

relevance of their price oracle

IMO a price oracle offers an entry point for custom price handling (e.g. market conditions, as well as flags such as cancelability, transferability etc.). If, of course, it relies on the tokenId as an input (this is a strong assumption, so I'm happy to withdraw this point for now).

do they list by token ids, or NFT contract

I don't know, we could ask.

if you are worried about increasing complexity on the stream id front

Not worried about that really, as for creating streams we'd always point to V2.latest, while for reading/managing streams we'd support all.

[PaulRBerg]

from the POV of having X contracts vs X * 2 contracts, it is similar, isn't it?

Yes

as it creates yet another decision integrators have to make

This is a good point, but it's a separate one from the flash loans comparison, which I continue to argue is not helpful.

[PaulRBerg]

Should we close this?

@sablier-labs/solidity

[smol-ninja]

Yeah. Hooks FTW.