Generic feature requests for Airstreams

[razgraf]

Claim value getter

A read-only method that returns the value a certain address is entitled to claim from the Airstream contract.

[razgraf]

Balances

Given we won't be able to compute and validate the total amount required by an Airstream contract (can't parse the merkle tree) we have to be quite careful with the balances.

One idea would be to rely on physical balances of the contract (not a virtual balance) for this deposit value. If there's not enough in the contract (maybe some error happened and the initial deposit was lower than needed) there's the added benefit of simply transferring more tokens to the contract.

[PaulRBerg]

I don't understand what the suggestion is. What do you mean by "rely on physical balances"? Do you want to block the airstream campaign deployment if the campaign is not funded already?

That should be doable in principle since we are using CREATE2, but it would impair the UX of using airstreams.

[razgraf]

Nope, the opposite actually. What I was proposing/observing here is the system we ended up going with - not requiring the actual erc20 balance to be set/exact before the campaign can start.

If the campaign is not funded, or fully funded, the claim will simply fail until there are enough funds to be transferred to the claimant. Solvency will be tracked directly by using balanceOf and not any other custom virtual balance variable.

[razgraf]

Cancel on first-withdraw

Context: https://twitter.com/razgraf/status/1686082342819913728

From slack:

Imagine projects creating Airstreams with exponential progressions (linear works too, but expo is way nicer). We then use the onStreamWithdrawn callback/hook to cancel the stream after the first claim. The more you stick with the project and use those tokens solely for voting power, the more you get in the end. The earlier rent-seekers exit, the less people you have dumping in the markets.

The implementation depends on who the sender is, see #155 for more details.

[razgraf]

I don't see why tho 🤔 We already have an onWithdraw callback implemented for the sender (of course, if they're using a proxy). So no 3rd party systems are required.

[razgraf]

Note: probably won't be possible with onStreamWithdrawn as that's called on the recipient not the sender.

[andreivladbrg]

Yes, it wouldn't be possible with onStreamWithdrawn because it is called only on the recipient. I personally have mixed feelings about this feature. Consider a scenario where a user has waited until the end of the stream but for accounting reasons, wants to withdraw only a portion of the withdrawable amount, or even worse, what if an accidental withdrawal happens?

less people you have dumping in the markets

If the dumpers are more incentivized to wait until the end, wouldn't that moment (the end of the stream) become more difficult to manage?

[razgraf]

It's all game theory, for customers that want to align incentives better. Also, airdrops are usually a one-time claim so I don't think multiple-taxable events are a thing - hence we don't really have to support them either (if this special flow of cancel-on-withdraw is chosen).

Regarding token dumping, not necessarily. It's true that the end (dates) of the streams would be a date of interest. But the extended period gives the asset/product enough time to cement an image and proper value proposition, much better than a normal drop would. Sellers would most likely want to get their tokens fast, while parties interested in the long-term growth of the project (or in increased ownership) would withdraw towards the tail end. This extra time can also be used to figure out other mechanisms for governance and growth such as staking or giving the token usage.

At any rate, if it's of interest to them, we should think about offering this as a feature for projects experimenting with novel incentive alignment systems.

[PaulRBerg]

There are two threads in this discussion:

1. Technical feedback
2. Business logic

Technical feedback

we could potentially use Gelato to automate this
I don't see why tho. We already have an onWithdraw callback implemented for the sender

As you pointed out, there is no withdraw hook for the sender.

But even if there had been a withdraw hook, I would have still preferred to use Gelato due to a couple of reasons:

1. More gas efficient, as cancellations could have been batched via cancelMultiple
2. Safer to rely on the standard V2 Core functions rather than some ad hoc hooks
3. The more integrations, the better for the business

Business logic

I have grown more skeptical of this idea in the meantime.

If the intention is not to let users claim early, then why stream the airdrop? Why not a traditional vesting contract that unlocks after N days/ years? Some users may accidentally claim in advance (because hey, streaming!) only to realize that they lost the rest of their airdrop. Policing users this way may cause relationships to fray, but this is precisely what airdrop creators want to avoid.

With this incentive model, it is not even clear that the word "airstream" is an accurate descriptor anymore.

As @andreivladbrg argued, there are non-dumping-related reasons for claiming early. I would add to his list tax reasons, e.g. wanting to claim 10-20% of the airdrop to pay your taxes in advance.

I would thus suggest to not work on this feature in the in the foreseeable feature (if ever).

airdrops are usually a one-time claim so I don't think multiple-taxable events are a thing - hence we don't really have to support them either

Given the streaming nature of Sablier we can't really predict much about tax implications, nor can we give any advice.

[PaulRBerg]

Requested by an Exactly airdrop holder:

It'd be great to be able to replace your 'S' logo (upper left corner) with the actual project, example: Exactly

Personal comment: this would be difficult to do because the SVG is 100% generated on-chain and it's the same NFT descriptor contract for everybody. It would also lead to high gas costs for users and expensive, frequent deployments for us.

[PaulRBerg]

Claim value getter

A read-only method that returns the value a certain address is entitled to claim from the Airstream contract.

I don't think this is possible because the user has to provide the airstream amount when they claim. @andreivladbrg, can you confirm?

[PaulRBerg]

I don't think you have read my comment in full, @andreivladbrg.

if claim reverts with the SablierV2AirstreamCampaign_InvalidProof error, then it means that the claim data is invalid.

The question is: would a bespoke verifyClaim function that returns a boolean be that much more useful for front-end apps?

I don't know. Maybe.

[andreivladbrg]

I did 😅.

The question is: would a bespoke verifyClaim function that returns a boolean be that much more useful for front-end apps?

Yeah, that's what it was all about.

[razgraf]

Yup, the point was to verify that all the parameters are correct. But it's not such a big deal, we can simply simulate (or check if the claim call reverts) we don't need a separate function. Just questioning if it could be useful in other non try/catch flows, maybe to integrators.

[PaulRBerg]

Let me sleep on this idea. It might be useful for third-party contracts that receive airstreams.

[PaulRBerg]

My suggestion: this is not worth doing now on the basis of YAGNI.

I'd like us to first test the waters with a simple implementation of airstreams. Then, if we have good traction with it, we can consider adding utility features like this verifyClaim helper function.

Not implementing this feature will also reduce audit costs.

[PaulRBerg]

Closing this discussion on the basis that all feature requests have been implemented or addressed. Feel free to re-open it if you have any new suggestions.

[PaulRBerg]

We have recently received feature requests for some of the ideas shared in this thread, which makes me realize that 'bundler' threads like that aggregate multiple ideas makes it difficult to (i) find them later on and (ii) organize them (open or closed?).

So I suggest opening a separate discussion for each future idea, @razgraf.

[razgraf]

Sure, sounds good!