Issues with using stream NFTs as collateral for lending

[PaulRBerg]

Problems

I've had yet another productive call with NFTFI - we dived deep into the difficulties of accepting stream NFTs as collateral.

Broadly speaking, there are three problems:

1. Bidding dynamics. During the bidding window (which can be up to 7 days), the stream parties may withdraw assets from the stream, and so the collateral value may end up lower than what had originally been estimated by the lender.
2. Cancelability. If the stream is canceled during the bidding window or once the NFT borrow has been materialized, the lender will get REKT if the collateral value had been assumed to include the unstreamed funds.
3. After the bid is accepted, the NFT is transferred to an escrow contract, which may or may not be able to handle ERC-20 deposits. See more details in Consider scraping off the ability of the sender to withdraw on behalf of the recipient #666.

Solutions

This is a hairy problem for which the solution is necessarily multi-faceted. Here's what we discussed on the phone:

1. Create a "locked" NFT contract, which would wrap the vanilla Sablier NFTs. This wrapper would have an immutable expiration when the NFT becomes unlocked, and there would be a locker address with permission to unlock the NFT earlier than expiration.
2. Add a new locker address in the Stream structs that locks the stream NFT when its value is non-zero. NFTfi doesn't like this solution because they would need to build a custom implementation for Sablier, i.e., query the Stream structs.
3. Separate the NFT contracts into cancelable and non-cancelable (see Separate NFT contracts for cancelable and non-cancelable streams #659)

Broadly speaking, what NFTfi requires (and any other NFT lending platform, presumably) is a way to disable withdrawals during the bidding process.

[PaulRBerg]

A paraphrase of the feedback provided by Jorge from Unlockd on a Telegram voice note:

• Unlockd deploys a fork of a 2-of-2 Safe multisig for each user
• The user holds one signature, Unlockd protocol holds the other
• This means that Unlockd has the ability to whitelist and blacklist arbitrary interactions with the Safe
• For instance: during the NFT bidding and the lending process, Unlockd could disable withdrawals by the stream recipient
• Sender withdrawals are still possible, but this is not an issue for Unlocks because the ERC-20 tokens will eventually be available to be claimed by the recipient

Therefore, it looks like none of the issues in the OP apply to Unlockd.

[PaulRBerg]

Feedback from NFTfi:

• This mechanism will require users to lock the NFT in the safe before they can receive bids. This ha s a couple of implications, mainly that they are then not able to list on multiple lending platforms to find the best rates.
• We are deploying a similar safe based solution, however, blocking "arbitrary actions" still requires us to block the right actions for your design. This would mean additional work for every lending platform that want's to support Sablier NFTs. In contrast having a standard locking wrapper from Sablier means all protocols could use the NFT without doing custom work.
  So in summary: We could also support a similar solution, but it limits composability as each lending platform would need to do work here. It also creates a slightly worse user experience for borrowers by locking them into a specific platform when looking for a loan.

I guess the decision for you guys is this: How important is composability across NFT financial products to you. (not just lending, other infrastructure like options protocols etc would face similar issues)

If it's very important then I would lean towards having a standard way provided by Sablier to ensure the asset remains immutable during the bidding process. If it's less important for you then I think you could get away with pushing some of the work onto the NFT finance infrastructure

[maxdesalle]

Feedback and info from Unlockd:

• They are storing the NFT in a Safe wallet with three signatures, one from the user, one from the liquidator (contract?), one from Unlockd, and only one signature is needed to transact the funds.
• They are still working on figuring out the bidding process and finding the right risk framework for the integration
• They can read our SVG and they use Alchemy for the API.

[PaulRBerg]

@smol-ninja I'd be interested to hear your feedback on the Locked NFT idea

[smol-ninja]

@PaulRBerg

I like the idea of a locked NFT because it enables composability across NFT finance for Sablier streams. But I also think that it should not require any custom integration. Newer and better protocols keep coming up to replace old protocols so if we think in the long term, the locked NFT should behave as any other PFP NFT. If I understand the motivation correctly, it is to allow Sablier recipients to borrow against their future income.

Add a new locker address in the Stream structs that locks the stream NFT when its value is non-zero

This solution requires lending platforms to have custom integration. I would say even if we manage to convince a handful of companies to have a custom integration, it limits the ability of other platforms to support us.

Separate the NFT contracts into cancelable and non-cancelable

An interesting design but it still limits which NFT can be lent and which cannot. We should aim for something that can apply to all Sablier users.

Create a "locked" NFT contract, which would wrap the vanilla Sablier NFTs. This wrapper would have an immutable expiration when the NFT becomes unlocked, and there would be a locker address with permission to unlock the NFT earlier than expiration.

This is a good solution but I don't understand why we need expiration. I like the locking/wrapping approach where anybody can wrap their stream. So here is a slight modification to that:

• When a user wraps his Sablier stream, the wrapper contract becomes the new owner (aka recipient) of the stream. Now, if a sender cancels or initiates withdrawal from the stream, the amount will get transferred to the wrapper contract which can handle ERC20. These assets are still a part of the wrapped NFT so it does not impact estimated collateral value. This solves the first and third problem problem.

• Unwrapping will transfer Sablier NFT as well as assets to the wrapped NFT owner. It also transfers assets that wrapped NFT has received because of early cancellation or withdrawal by the sender.

• During the bid, if the user unwraps the NFT, it will not rekt bidders because accepting a bid requires smart contract interaction and this is not possible anymore (burnt wrapped NFT).

Now speaking of problem 2

The lender will get REKT if the collateral value has been assumed to include the unstreamed funds.

Naturally, a non-cancelable NFT will receive higher bids compared to a cancelable NFT. With this design, we are atleast allowing the market estimate the collateral value of NFT items. For example, if a sender has a high reputation / lower cancelation rate, lenders may be more comfortable to loan a higher amount for that NFT. I'd expect bids to be in the range [Streamed Amount, Expected Payout) for cancelable.

NFT Oracles

NFTfi, unlockd and other lending platforms use Oracle services such as Upshot and NFTbank which can provide risk-adjusted predictions for wrapped NFTs based on the cancelability of the stream. It might also be in our interest to talk to these companies and help them understand how they can value wrapped NFTs. Once these Oracle start to provide a valuation to wrapped NFTs, problem 2 will become redundant.

Let me know what you think about this and feel free to correct me if I have misinterpreted something here.

[razgraf]

Nice analysis! I, too, am of the same opinion - providing a standard wrapper is both easier for projects to integrate with and more scalable.

1. Easier integration

   Custom wrappers abstract the logic away from Sablier NFTs and make them more "standard". We've talked about them since the start of V2 (either in discussions or in person) when we've had some difficulties assessing how protocols will handle the old "cancel-and-withdraw-to-recipient" behavior (Delay re-routing funds upon a stream getting canceled #150 - which was implemented in the end in refactor: do not withdraw recipient assets on cancel #422). Same applies (as you preempted) to the sender-triggered-withdraw / public-withdraw Making withdraw public: Pros and cons #110.

2. More scalable

   Custom wrappers mean we could, in theory, create multiple types of wrappers as "collections". Think of all the transferable/non-transferable cancelable/non-cancelable combinations. For protocols that can't support very complex logic (see Separate NFT contracts for cancelable and non-cancelable streams #659), we could even create multiple collections (represented by these wrappers) that they whitelist instead of the Sablier NFT itself.

[PaulRBerg]

Good stuff, @smol-ninja.

it should not require any custom integration

Indeed.

If I understand the motivation correctly, it is to allow Sablier recipients to borrow against their future income.

Yes.

This is a good solution but I don't understand why we need expiration

My contemplated design included a locker user who would have joint control over the wrapped NFT. The idea with expiration was for you to not be at the mercy of the lending platform to unlock your NFT.

But your design is simpler and better.

I like the locking/wrapping approach where anybody can wrap their stream

"anybody" = stream owner, or literally anybody, i.e., make the function publicly callable?

I don't see how the latter makes sense.

An interesting design but it still limits which NFT can be lent and which cannot. We should aim for something that can apply to all Sablier users.

Cancelable streams cannot be lent in practice anyway (due to financial risk issues). More on this below.

During the bid, if the user unwraps the NFT, it will not rekt bidders because accepting a bid requires smart contract interaction and this is not possible anymore (burnt wrapped NFT)

hmm. Could you explain again, please, @smol-ninja?

Are you saying that by burning the NFT, the bids would be automatically called off?

Naturally, a non-cancelable NFT will receive higher bids compared to a cancelable NFT. With this design, we are atleast allowing the market estimate the collateral value of NFT items

I agree with this from first principles but, in practice, platforms like NFTfi have said that they will not accept cancelable streams at all. The risk is prohibitively high.

The only way I can see them working is through credit delegation, i.e., binding on-chain addresses to real-world identities and social connections. But that's a different topic altogether.

NFTfi, unlockd and other lending platforms use Oracle services such as Upshot and NFTbank which can provide risk-adjusted predictions for wrapped NFTs based on the cancelability of the stream. It might also be in our interest to talk to these companies and help them understand how they can value wrapped NFTs

Interesting! Related discussion: sablier-labs/v2-periphery#182

---

On top of what @razgraf has said:

3. Easier cross-release management; the NFT wrapper could accept stream NFTs coming from multiple releases (V2.0, V2.1, etc.) as long as they adhere to some interface file.

[smol-ninja]

Thank you for your comments @PaulRBerg and @razgraf.

"anybody" = stream owner, or literally anybody, i.e., make the function publicly callable?

Sorry about that confusion. I should have said stream owner. By "anybody can wrap their stream", I meant anybody who owns a stream can wrap his stream.

Cancelable streams cannot be lent in practice anyway (due to financial risk issues).

By financial risk issues, are you referring to the fact that upon cancellation, there is a refund to the sender?

smol-ninja: During the bid, if the user unwraps the NFT, it will not rekt bidders because accepting a bid requires smart contract interaction and this is not possible anymore (burnt wrapped NFT)
PaulRBerg: Could you explain again

There are two steps by which a loan is created (at least on NFTfi):

1. NFT owner approves NFTfi to transfer his NFT. And then the bidding begins.
2. Only after the NFT owner has accepted an offer, NFTfi moves the NFT from his address to the NFTfi contract and the loan is created.

Now let's say during bidding, the user decides to unwrap the NFT. Unwrapping means burning the Wrapped 721 token and transferring out the stream NFT from the wrapper contract. Now since NFTfi can no longer move wrapped NFT to its contract, the loan can never become active. In such cases, it even stops showing up those loans in the UI. So essentially it does not rekt bidders.

Are you saying that by burning the NFT, the bids would be automatically called off?
Yes exactly.

I agree with this from first principles but, in practice, platforms like NFTfi have said that they will not accept cancelable streams at all. The risk is prohibitively high.

OK. I agree with their concern. They don't want any changes in the inherent value of the wrapped NFT that has been added as collateral. Cancelling the NFT issues a refund to the sender and changes that.

Easier cross-release management; the NFT wrapper could accept stream NFTs coming from multiple releases

Makes sense.

[PaulRBerg]

Sorry about that confusion. I should have said stream owner. By "anybody can wrap their stream", I meant anybody who owns a stream can wrap his stream.

No worries, thanks for confirming.

are you referring to the fact that upon cancellation, there is a refund to the sender?

Yes.

Now since NFTfi can no longer move wrapped NFT to its contract, the loan can never become active

oook, I am getting it now! Thanks.

Basically, the recipient cannot withdraw-and-accept-bid anymore because that requires unwrapping and that effectively requires burning the NFT, which destroys the bid.

They don't want any changes in the inherent value of the wrapped NFT that has been added as collateral. Cancelling the NFT issues a refund to the sender and changes that.

Yep

[smol-ninja]

Basically, the recipient cannot withdraw-and-accept-bid anymore because that requires unwrapping and that effectively requires burning the NFT, which destroys the bid

Yes.

[PaulRBerg]

There's apparently an ERC implementing a lockable extension of ERC-721:

https://eips.ethereum.org/EIPS/eip-7066