Use ERC-6551 to address inefficiencies in asset lockup

[scorpion9979]

I have been exploring solutions to enhance a few potential areas of inefficiency within the protocol. Here are the two primary issues I've identified:

1. The locked underlying assets' opportunity cost due to the inability to earn yield on them.
2. The inability to leverage the voting capability of locked COMP-like governance assets.

In my research, I found that ERC-6551 could potentially provide a robust solution to these inefficiencies. In the existing model, when a new Sablier stream is created, the underlying assets for all streams of the same type are sequestered within a single lockup contract.

My proposal entails a shift in this approach: the stream NFTs could incorporate ERC-6551, binding each stream NFT to a uniquely tailored contract designed to hold the stream's assets and dictate the lockup and release procedures of those assets.

Here's how such logic could be applied to address the above-mentioned inefficiencies:

Yield Generation

1. The sender locks up the underlying into a custom NFT bound contract that initiates a constructor logic sequence which deposits the underlying into a yield-generating vault (such as by converting USDC into cUSDC), allowing the locked assets to generate income.
2. The NFT bound contract also includes logic to convert the yield assets back to their original underlying form whenever the stream's recipient unlocks assets from the stream.

COMP-like Governance Delegation

1. The sender locks up the underlying into a custom NFT bound contract, which initiates a constructor logic sequence. This calls the delegate function, which delegates the votes of all locked assets to some address.
2. The custom NFT bound contract could also have a mechanism to update the state of delegation whenever the stream's recipient unlocks assets from the stream.

Note: ERC-6551 is still a draft in the very early stages.

[PaulRBerg]

Thanks for your proposal, @scorpion9979. Voting is complicated, so before we dive into that, I would first like to understand how this model would work just for yield generation.

You say that the stream NFTs could "incorporate" ERC-6551, but what does that mean in practice? Then, you say that the sender "locks up the underlying into a custom NFT bound contract", but again, how would this work in practice?

I'm not quite sure where Sablier fits into your proposed design.

Are the typical Sablier create functions used?

Note: I'm not familiar with ERC-6551 and cannot give it a full read at the moment.

[scorpion9979]

Sorry for causing confusion, I should have probably prefaced by saying I'm exploring different ideas that could potentially yield value for future iterations of the protocol. What I am suggesting above is an alternative paradigm to the current Sablier v2 design and is completely incompatible with it. After posting this discussion here, I figured out a better place to have it would have been to post it as an organization discussion.

Let me start with a TLDR on ERC-6551: it's a system that enables the creation of contract wallets that are inherently bound to NFTs. The standard can work with any NFTs, including ones that predate the EIP itself (i.e., BAYC, WPUNKS, etc.) The standard would enable special use-cases such as being able to sell a wallet that contains a variety of assets of different types by only having to sell the NFT that is bound to it, as owning the bound NFT enables you to control the contract wallet bound to that NFT and gain access to the underlying assets within. I have personally found this particular article to provide the shortest explanation to the EIP: https://blog.reddio.com/erc-6551-explained.

Re: "You say that the stream NFTs could "incorporate" ERC-6551, but what does that mean in practice?"
As I mentioned above, it would be a different design and codebase than what currently exists in Sablier V2. In my proposed design, it would assume that each Sablier NFT would have its own unique contract wallet that is tied to, as described by the ERC-6551 standard. The contract wallet would contain the underlying assets to be streamed from the sender to the recipient, along with the special logic that is executed upon each deposit and withdrawal of that particular asset.

Re: "Then, you say that the sender "locks up the underlying into a custom NFT bound contract", but again, how would this work in practice?"
Creating a new stream would involve invoking the createAccount() function according to ERC-6551, which would create the contract wallet that would contain the assets to be streamed from sender to recipient. One of the inputs for createAccount() is the implementation address of the contract wallet to be created, which in this case would include the logic for handling the deposit and withdrawal of underlying assets.

Re: "Are the typical Sablier create functions used?"
In my proposed design, those functions still exist and serve the same purpose as they currently do, but my proposal would basically change the implementation of how streams are created as it locks the underlying assets being streamed into ERC-6551 contracts instead of having all that liquidity in one single lockup contract (for the same lockup type).

I must admit that while my design might be able to address the problem of how to utilize the inherent capabilities of different streamed ERC-20 assets, it definitely presents a few hurdles and challenges:

• Flashloans are much more challenging now, as the underlying assets to flash borrow is segregated into many different stream contracts.
• Each stream creation would involve a contract deployment a la ERC-6551, which could turn out to be gas expensive for the stream creator.
• Tracking the protocol TVL would also turn out to be very challenging, as previously it would be as simple as checking the token balances of a couple of lockup contracts on Etherscan.

[PaulRBerg]

Thanks for the detailed write-up. I now understand what you meant. Appreciate you for sharing ideas!

At the moment, we would prefer the protocol to have a monolith design whereby all streams and assets are locked up in the same contract. Gas costs, TVL, and user experience (both typical users and integrators) are the main reasons behind our rationale. Flash loans don't matter that much - in fact, we did not even inherit the SablierV2FlashLoan contract in the current V2 deployments.

I figured out a better place to have it would have been to post it as an organization discussion

Great idea. I went ahead and enabled organization-wide discussions. I will move this discussion there.

[zerosnacks]

I've also been thinking about ERC6551 in context to streaming payments but in a different context namely in the form of a "membership card" (that being the ERC6551).

In this context a user would mint an "uncharged" membership card (ERC6551) which they can then "charge" by adding a Sablier stream (ERC721) with certain parameters and certain conditions. If the stream runs out the membership card becomes "uncharged" again. Depending on the status the membership card could have a different visual appearance but more importantly enable the holder to do more when "charged" (get certain rights, able to access some sort of content, etc..). For content creators it is highly preferable to have a recurring income stream that they can rely on.

I haven't thought through all the edge cases but I think it would be very powerful to have a primitive like this.

[PaulRBerg]

Hey @zerosnacks, thanks for your suggestion. Two comments:

1. Wouldn't this feature be similar to Unlock Protocol?
2. TBH, I'm not sure Sablier is a good fit for a use case like this because Sablier is closed-ended, but card membership implies a long-term, ongoing commitment with no specific end time. That said, I can imagine certain cases where Sablier would work, such as annual memberships that terminate on a specific date.

Do you have a particular project in mind which would be interested in making an integration?

[zerosnacks]

Hi Paul,

Thanks for your reply!

1. It does seem like it, I'm not familiar with Unlock Protocol - I'll have a look!
2. This is in relation to a passion project that would involve a transferable NFT identity and memberships of some kind.

2. Sablier is closed-ended

Ah I see, I was under the impression that with Sablier you would be able to extend the stream whilst it was running.

In my research I did find someone who experimented with using Superfluid for streaming payments + ERC6551 (https://devfolio.co/projects/sba-b742) which got me wondering whether it would be possible with Sablier V2 as well.

[PaulRBerg]

We would love for you to make an integration with Sablier, but I also don't want to recommend unsuitable use cases.

with Sablier you would be able to extend the stream whilst it was running.

This is not possible at the moment but stay tuned for V3 :)

[PaulRBerg]

Received a request for this CC @sablier-labs/engineers