Replies: 10 comments 11 replies
-
Toggling transferability may present additional complications. One another example is in the context of staking. Consider the following scenario:
My thoughtsMuch like the case with cancelability, where it is not wise to permit a stream to become cancelable after it has been set as non-cancelable, allowing a stream to become non-transferable after it has been made transferable could lead to a suboptimal experience for recipients. When a stream is set as non-cancelable, it gives confidence in the recipients that the stream will remain as such. Similarly, when a stream is made transferable, it introduces new utilities for the stream, some of which we comprehend, and others that we may not fully understand at present. If the sender were to revert the stream to non-transferable, it could give rise to unforeseen issues. |
Beta Was this translation helpful? Give feedback.
-
This whole feature sounds like a very niche thing, honestly. While I don't fully understand why a sender would want to make a Stream non-transferable (to me, it sounds like the recipient should be able to decide what happens with the Stream; if the sender isn't satisfied with a transfer, they can always cancel the Stream, after all), if we do implement the toggling of transferability, I suggest we do this similar to how the toggling of cancelability is already implemented. More specifically, I suggest that the Streams start off as non-transferable - and, once the sender flips the toggle, become transferable indefinitely. |
Beta Was this translation helpful? Give feedback.
-
Not completely sure about the 3rd one (could you give some specific examples, please?), but taking the option to do the first 2 from the Stream recipient sounds in contrast to the open market ideology that crypto has been built upon. If you're streaming me some value, it's my right to do whatever I want with this value, even if this means selling it for less than it's worth (either in your eyes, as the sender - or in general). Otherwise, it'd smell like CBDCs. 👃🤢 |
Beta Was this translation helpful? Give feedback.
-
I'm really curious about the specific reasons for why some companies might not want to have the Streams they create be transferable.
Absolutely! And in the case of the cancelable Streams, their intrinsic value is, generally, equal to the value of the streamed part. So, if I'm allowed to withdraw the streamed assets and do whatever I want with them, why am I not allowed to, say, use the Stream as collateral to borrow some crypto based on its intrinsic value (that has already been streamed and is, therefore, mine)? |
Beta Was this translation helpful? Give feedback.
-
Thank you for the insights, @smol-ninja! 🙌
Honestly, this sounds shady to me, as if they're trying to play tricks with their investors/token holders. If you don't want the market to value your token yet, don't launch it yet - do this at a point when you're satisfied with the valuation your project deserves 🤷♂️ This reminds me of the MetaWar project/token on BSC which has distributed its token to hundreds of thousands of addresses, but has limited their ability to transfer the tokens. They went as far as to require you to pay (out of pocket) to "unlock" your airdrop (which was both hillarious & outrageous). Of course, the price of their token has been steadily increasing, alongside their MCap, but this has been achieved by only a small fraction of the total supply being transferrable, while they have, likely, been using the "unlock money" they have been charging their token holders to buy up more of their token.
Ehm... Why would anyone lend you anything based on your Stream NFT in a trustless manner, without requiring you to transfer the NFT someplace specific (which would be impossible if the NFT is non-transferrable)? 🤔 |
Beta Was this translation helpful? Give feedback.
-
That's because MetaWar was, indeed, a scam 😆
So, how could this be done if the Stream NFT is not transferable? 🥲 re: why make Stream NFTs non-transferable, in general?Let's look at this from a different perspective. Imagine I have had some tokens streamed, and want to sell them. Even if I cannot transfer the NFT to some smart contract or EOA, I can still withdraw the streamed assets - and perform the sale. In other words, I can access the whole intrinsic value (represented by the streamed assets) of my Stream NFT, and use it as I please. Given this, how would a company I've invested in (and am receiving streamed tokens from) benefit from me not being able to transfer the Stream NFT, if I can access its internal value, anyways? |
Beta Was this translation helpful? Give feedback.
-
I did have a look at the references. Back when you had shared them 🙃 If I had to summarize traditional vesting in one sentence, it'd probably, be that it is a way to reward the loyalty of an employee in the form of company stock (with a quantity known in advance), unlocked in batches over the years that the employee works at the company. Moving to web3, the unlocked value can only be withdrawn once it's been streamed - and from this point on, I don't see a big difference (to the Stream Sender, that is) between the Recipient withdrawing the streamed value and transfering it to some third party - and the third party withdrawing the value on behalf of the Recipientdirectly. As long as the Recipient does their job (whatever you're streaming them the value for), you keep streaming the value - and whatever value has been streamed is out of the Sender's control. If the Sender happens to disapprove the third party that the Stream NFT has been transferred to, they can always stop the "unstreamed" value from being streamed to that party, by canceling the Stream. Unless the Stream is non-cancellable, of course 🙂 Having said all this, I admit that it's possible for a certain clause (that I'm unaware of) to exist in the legal contracts associated with traditional/DeFi vesting, that renders my arguments above useless. If that's the case, there's nothing we can do besides adapting to the legal limitation. |
Beta Was this translation helpful? Give feedback.
-
Yes, naturally.
Now, we're getting somewhere! As I've said in my previous comment, if the non-transferability (or smth else that, in turn, makes it impossible) is stipulated in the legal contract underlying a Stream, then, this whole argument fades away. In that case, it becomes irrelevant what we/I might think about Stream transferability: we either implement it (and potentially onboard the respective Streamers) - or don't (and definitely lose them, as they won't bother trying to bend the laws they're working by).
Yep. Or they might wait for the unstreamed tokens to be streamed - and sell them afterwards. Both of these cases sound the same to me, as the end result is the same: the third party/competitor will only be able to access the unstreamed tokens once they're fully streamed: either by the original recipient withdrawing the tokens and transfering them to the third party - or by the third party withdrawing them directly, after the Stream NFT has been transfered to them. |
Beta Was this translation helpful? Give feedback.
-
Kind of. The argument involving the non-transferability of the assets/Stream NFT stipulated directly in the vesting legal contract still sounds more convincing/unarming to me, though. |
Beta Was this translation helpful? Give feedback.
-
Closing due to inactivity and soft agreement that the potential benefits are not worth the complications. |
Beta Was this translation helpful? Give feedback.
-
Idea
The idea is to add a new function that allows the sender to toggle the transferability of a stream.
This feature came up recently during a discussion with a potential integration partner, Smart Token Labs:
My Thoughts
Unlike cancelability, it makes sense for transferability to be something that senders can toggle on and off during the lifetime of the stream. From the recipient's perspective, a "non-cancelable" stream that can be made cancelable again is not really non-cancelable. However, a non-transferable stream that can be made transferable may be appealing to the recipient. While the reverse (transferable → non-transferable) is not true, the transferability dimension does not affect the core distribution of assets, so disabling transferability should not be a dealbreaker.
Cons
Besides implementation cost, there's another significant con.
This feature would throw yet another wrench in the developer experience of making an NFT integration with Sablier. Imagine the following scenario:
Thus, it seems like transferability would break NFT lending, and the only way to fix the resulting mess would be to implement a locked NFT wrapper. The problem is that the spec for that is not currently settled.
I suggest we do more brainstorming on this feature before assuming any particular course of action. Cc @sablier-labs/everybody.
Beta Was this translation helpful? Give feedback.
All reactions