To factory or not to factory the airstreams

[PaulRBerg]

Problem Situation

The current design on the feat/airstreams branch involves an AirstreamsFactory contract that deploys a bespoke Airstreams contract for every airstream creator. But now I realize that we don't necessarily have to design the airstreams like this. We could instead have a monolith contract where all airstream campaigns are bundled together; there would be an Airstream struct and an airstreams mapping.

Comparison

Factory	Monolith
❌ High gas cost (to deploy the contract)	✅ Low gas cost
✅ Flexible design for users who need to customize the implementation (e.g., for upgradeability)	❌ Rigid design
✅ Relatively lower development cost	❌ High development cost: state access modifiers, special functions for transferring the admin
❌ Indexing and accounting are difficult	✅ Indexing and accounting are easy
❌ Leaving TVL on the table	✅ TVL boost
✅ No psychological deterrent for users	❌ Psychological deterrent for users (deposit assets into a pooled contract)

My Thoughts

In an ideal world, we would build both the factory and the monolith. In the UI, we would default to using the latter. Elsewhere, we would mention the possibility of creating bespoke Airstreams deployments (to cater to users who prefer to deploy custom contracts).

However, we have limited resources (time and money for audits), so our first MVP should contain only one design. But I can't decide which is better because the pros/ cons analysis doesn't tilt the balance in any particular direction.

WDYT, @razgraf, @andreivladbrg?

[razgraf]

Personally, I'd still go with the Factory pattern. My main reason is that It separates concerns: mentally (your last point) and technically too - no "filter by asset and campaign" needed, no state mixed between campaigns.

Airstreams feel like a more independent feature, rather than a centralized protocol architecture like the one we use for the core.

At the same time, I've no great technical argument for why a monolith wouldn't work. That's why I'm stuck at the architectural/cognitive POV at the moment.

Would you mind explaining more about the Accounting and TVL points? Not sure I understand why accounting would be more difficult, or why we'd lose TVL. Agree on the indexing (tracking one instance vs. multiple), although it feels like a minor point.

[PaulRBerg]

Thanks for the quick feedback.

Re separation of concerns: I was getting at the same idea with the 2nd row in my table, i.e., "Rigid design"

Re accounting - our integrators would now have to track N contracts rather than just one or two. Imagine Coinshift integrating airstreams for the sender view.

Re TVL - a minor point, yes, but it's the same issue that we would need to make frequent updates to the DeFiLlama adapters, etc.

[razgraf]

Hmm, manual updates wouldn't be so frequent as the Factory acts like a "registry". Implementing a Factory tracker (e.g. in the subgraphs) is actually a bit simpler than having separate instances, as the Factory acts like an entry point into a system.

An interesting thing to brainstorm on is what happens when we'll have multiple factories, but I guess the same arguments apply - we just need to move the root of the system another level above the factories.

At any rate, I've integrated both systems (factory and monolith) in systems like subgraphs and both are doable.

[PaulRBerg]

Implementing a Factory tracker (e.g. in the subgraphs) is actually a bit simpler than having separate instances

I'm sorry, I don't understand this point. Can you restate it, please?

Having separate instances (deployed via a Factory) entails implementing a Factory tracker.

what happens when we'll have multiple factorie

this is something that we can think about later, after we decide whether we use a factory or a monolith.

I've integrated both systems (factory and monolith) in systems like subgraphs and both are doable.

Glad to hear.

This discussion is one of those hairy decisions that has pros and cons on either side.

[razgraf]

Having separate instances (deployed via a Factory) entails implementing a Factory tracker.

Was comparing separate instances without a factory (harder) vs. instances configured by a factory (easier).

--

Another point with factory > monolith is data access at the contract level. Each getter, setter or event emit will have to include an extra entity id - which is the internal identifier for our Airstream campaign mapping. Getting to a stream's asset would probably look like campaigns[cid].streams[sid].asset instead of streams[sid].asset.

[PaulRBerg]

separate instances without a factory (harder)

I see, but this is not what I was talking about. By "monolith", I meant a parent contract that would contain all airstream campaigns within it.

Nonetheless, it is pretty much impossible to avoid having to track multiple, unconnected instances in the long term, for the simple reason that we will end up deploying multiple factories (i.e. in V2.x and V2.y).

Each getter, setter or event emit will have to include an extra entity id

fair point

[andreivladbrg]

IMO the factory pattern is the better choice here, primarily due to the notable difference in complexity between the systems. A system with greater complexity tends to be more prone to errors.

Regarding the cons of the factory, as @razgraf also mention, TVL and Accounting are minor points, and the gas one, yes it is cheaper from the sender point of view, but in the perspective of the recipient it would be more expensive due to a more complex mapping for the eligibility checking, plus the campaign checkings:

    mapping(uint256 airstreamId => mapping(uint256 => uint256)) private _claimedBitMap;
    enum CampaignType{
    LockupLinear;
    LockupDynamic;
    }
    
    function claim(Params params) public{
    // ...
    CampaignType campaignType = getCampaignType(airstreamId);
    if( campaignType == CampaignType.LockupLinear){
          lockupLinear.createWithDurations(createParams);
    } else if (campaignType == CampaignType.LockupDynamic){
          lockupDynamic.createWithDeltas(createParams);
    }

Probably there would be more checks required which I can't think of without actually starting to implement. Yes, the gas difference between the claim functions may not seem significant at first (around a few thousand), it's important to remember that airdrops are targeted to large audience (tens of thousands of recipients), meaning that the cumulative gas used for a campaign(at the end of it), viewed from both sender and recipient perspectives, may not show a substantial difference after all.

Factory pattern here is more "elegant" 😁.

[PaulRBerg]

Fair points @andreivladbrg, agree with everything you said except for the campaign type checking which is unrelated to this discussion.