Decide if the airstream sender should be the Airstream admin

[PaulRBerg]

Airstream contracts will inherit from Adminable, and there comes the question of who the stream sender should be when claiming airstreams?

It can be either the Airstream contract itself or the administrator's address.

The massive benefit of setting the admin as the stream sender would be that we wouldn't have to implement cancel and cancelMultiple in the Airstream contract. The typical cancellation flow would apply.

The only con I can think of is that this might interfere the accounting logic since the nominal sender would be different from the real sender (the Airstreams contract). However, this should be a negligible issue - many airstreams will likely be non-cancelable, and in any case the sender and the funder are different entities in V2 Core:

https://github.com/sablier-labs/v2-core/blob/fcbc567aea6362c1f102eb19732badeb4899dec5/src/interfaces/ISablierV2LockupLinear.sol#L28-L38

[razgraf]

I like the idea of having the Airstream contract be the sender.

• It would make the system self contained
• It simplifies the logic of funds "traveling" through multiple accounts, which allows airdrop funds to only be tracked through the Airstream contract (as opposed to balances in the contract and in the sender's wallet). Meaning token entries in the sender's wallet would only be done as a result of a manual clawback.

However, I do see how this would lower the burden of having to implement extra methods.

Informational note: regarding the accounting flow, the proxy is also going to create special "hoops". Not that this is any different from how the other contracts work at the moment. I assume, at least at the app level, we'll ask the sender to first create a proxy. Through it they'll deploy an Airstream campaign with the factory. Then, the cancelation transfers become:

Flows
Sender = Airstream	Lockup -> Airstream
Sender = User	Lockup -> Proxy -> Proxy Owner

Begs a separate question for our design: do we rely on sender proxies for this at all?

[razgraf]

Thank you for the reply. I think you're right. Technically, having the Sender and the Airstream entities separate would decrease complexity, therefore we could have a faster go-to-market sprint.

The self-contained idea - was thinking that for the sender, an "Airstream" contract could act as a facade, such that they wouldn't have interact much with the endpoint contracts (lockup linear, dynamic).

The accounting (mental) complexity remains: for a DAO, we'd probably suggest they use a dedicated wallet when creating and funding the airstream contract, not their main treasury. If for some reason people start canceling their streams (or they as senders have to, in multiple batches due to gas restrictions with createMultiple), they'd have an unwanted wave of entries in their treasury wallet.

Side note: Would be worth writing a guide for "best practices" with airstreams once we have it ready.

--

TL;DR; Let's try with Sender = Owner, not Airstream approach and see what users/auditors suggest as well. @andreivladbrg @gavriliumircea any thoughts on the above?

[gavriliumircea]

I do understand both your points., but right now it seems to me that we would benefit more from making the sender the admin.

[PaulRBerg]

Thanks!

that they wouldn't have interact much with the endpoint contracts (lockup linear, dynamic).

They will be familiar with LockupLinear/ LockupDynamic.

1. All of their users will need to interact with those contracts
2. It is likely that the campaign creators themselves will have some airstreams to claim and later withdraw from Sablier

I can also envision some airstream creators that build customized UIs for withdrawing from Sablier.

we'd probably suggest they use a dedicated wallet when creating and funding the airstream contract, not their main treasury.

I wouldn't go that far now. The next steps are (i) building the system, (ii) auditing it, and (iii) presenting it to users. Only after the 3rd step can we validate accounting best practices.

they'd have an unwanted wave of entries in their treasury wallet.

This is always possible on the blockchain - Sablier does not alter the status quo in any significant way.

Would be worth writing a guide for "best practices" with airstreams once we have it ready

Later on, yes. This would go on docs.sablier.com.

Let's try with Sender = Owner, not Airstream approach

Sounds good

[andreivladbrg]

I see that you've reached an agreement on sender = admin. I also thought this approach to be the better one, I don't have anything to add at the moment.

[PaulRBerg]

cheers @andreivladbrg.