Merging all Lockups in one contract

[PaulRBerg]

Problem

As @maxdesalle pointed out on Slack, one of the things that holds back NFT adoption is the Balkanization of the NFT collections: different releases, different chains, and different Lockup flavors.

The same issue has recently arisen in a conversation with a user — they were unsure which distribution shape in the UI corresponded to which Lockup model.

Solution

Merge all Lockups in one contract with the goal of providing a superior user experience.

I imagine that the maximum contract size of ~24kB following prevents us from accomplishing this design.

But what if we lower the optimizer runs, and we subsume the LockupLinear logic in LockupDynamic, i.e. we let the LD logic to handle the linear streams?

RFC

cc @sablier-labs/engineers for feedback.

[maxdesalle]

This would indeed be a very significant improvement in terms of user experience, even though the liquidity would still remain fragmented across chains and different protocol version, to be honest.

With regards to security, isn't the current compartmentalization beneficial? If a vulnerability is found in LockupDynamic, our other contracts wouldn't be impacted by it, for example.

[PaulRBerg]

Good point about liquidity fragmentation. We would still need to fix that with a dedicated UI for NFT trading.

Security is orthogonal to this discussion. Since bugs are unknowable, it's perfectly possible for a bug to only affect that branch of the function that deals with non-linear LockupDynamic streams.

[maxdesalle]

Since bugs are unknowable, it's perfectly possible for a bug to only affect that branch of the function that deals with non-linear LockupDynamic streams.

One could also say that since bugs are unknowable, acting defensively by compartmentalizing contracts just in case that might help, is a more rational approach. You highlight that "it's perfectly possible for a bug to only affect that branch of the function that deals with non-linear LockupDynamic streams", but that could also very well not be the case AFAIK.

[PaulRBerg]

The clause after the comma doesn't follow from the premise.

If bugs are truly unknowable, there could be no bugs or many bugs either way: with or without compartmentalized contracts.

e.g. there could be a bug in the abstract SablierV2Lockup, in which case it wouldn't matter that the contracts are compartmentalized since all would be affected.

that could also very well not be the case AFAIK.

Indeed

[smol-ninja]

Great idea. I'd also love to see a singleton contract handling all types of lockup streams for the same reason you have mentioned above. So I decided to run some tests and see if its possible.

With optimizer_runs = 1, it seems to me that we can fit LL, LD and LT all into one contract. Its the SablierLockup contract that's the heaviest.

I started with simply copying all code from Lockup Linear and Lockup Tranched into Lockup Dynamic (with some changes to the functions name as the overlap) and here is the build size:

Contract	Size (B)	Margin (B)
SablierLockupDynamic	25,965	-1,389

This is the absolute worse case. I also ran the benchmark to check the gas usage. As an example, createWithTimestamps with 100 segments consumes 2,643,037 with 1 run compared to 2,639,574 with 1000 runs (a ~0.1% increase). withdraw consumes 28,638 compared to 27,485 (a ~2.4% increase when you add up 21,000 base gas).

Here are a few ideas to DRY'ify the code:

1. Store an identifier in Lockup.Stream struct: 0 means LL, 1 means LD and 2 means LT
2. Make returned struct of Timestamps shared. And return 0 for irrelevant values for example if LT does not have a cliff, return 0.
3. Use the identifier to DRY'ify the following function: getStream.
4. DRY'ify _create function Lockup.Stream storage stream settings repeat across the three. This is the one taking the maximum size. And if we DRY'ify it, we may be able to bring the size below 26k.

[PaulRBerg]

Thank you, great sleuthing.

The increase in execution gas costs is acceptable.

25,965 B

Can you confirm that this is the size when optimizer_runs = 1?

Store an identifier in Lockup.Stream struct:

Or an enum?

Make returned struct of Timestamps shared

hmm, that doesn't sound good to me. Each stream type has different assumptions so this may lead to confusions.

And return 0 for irrelevant values for example if LT does not have a cliff,

Or rather a value like type(uint40).max to avoid any potential confusion with the default value of zero. But again, I would rather not share the Timestamps structs.

[smol-ninja]

Can you confirm that this is the size when optimizer_runs = 1?

Yes and SablierLockupDynamic contract contains code from SablierLockupLinear and SablierLockupTranched when calculating this size.

Or an enum?

Sounds good.

hmm, that doesn't sound good to me. Each stream type has different assumptions so this may lead to confusions.

The only difference among Timestamps structs is that Lockup Linear has cliff whereas the remaining two only return start and end. So, if we return cliff in LD's and LT's timestamps as 0, do you think that can cause confusion? 0 means no cliff in the context of Lockup Linear.

If want to squeeze everything into one contract, it may be a good idea to use shared structs wherever possible to enable us to add new features to the protocol. We are still due some changes on the lockup such as #974 which will further increase the code size.

Should I add it to my task list to experiment with it sometimes this week to see if its possible? Then I can create a separate discussion for changes required for the singleton contract, if it works.

[PaulRBerg]

0 means no cliff in the context of Lockup Linear.

Oh, I forgot about this. In this case, it should be fine to share the structs.

We are still due some changes on the lockup such as #974 which will further increase the code size.

TBH, between this refactor and that feature, I'd rather discard the latter (if push comes to stove).

Should I add it to my task list to experiment with it sometimes this week to see if its possible?

Yes, please.

[andreivladbrg]

I am in the review process, and I am just confused why including the cliff in the (common) timestamps struct is the choice here?

I believe we should only include the start and end.

do you think that can cause confusion?

Yes, I believe it would really create confusion as people might believe that the concept of 'cliff' exists in LD and LT as well, which isn't true.

Regarding the point 'not including the cliff is incomplete' - yes, it is, but so is for segments.timestamps and tranches.timestamps.

So, I am against including the cliff in the struct. We should either remove it completely (similar to StreamLL, StreamLD, and StreamLT) or keep it but without the cliff variable to be consistent with the other two models.

[smol-ninja]

Given that Timestamps is only used in events and as a returned value in getTimestamps function, I am in favour of removing Timestamps and replacing it with two functions: getStartTime and getEndTime.

Agree with you that it can mislead users into thinking that cliff exists for LD and LT.

[andreivladbrg]

Thanks for opening this. I really like the idea. To make a comparison, I’ve listed some pros and cons (feel free to add or mention more, but my two cents is that the pros far outweigh the cons):

Pros:

1. Maintenance Cost
   • Add new features
   • Make refactors
   • Generalized tests
   • Docs related changes
2. Generalize the Contracts for Their Use Cases
   • One contract for Vesting - Lockup, applicable to all shapes
   • One contract for Payroll - Flow
3. Deployment Costs

Cons:

1. Less Gas Optimized
   • depending on how we can dry-fy it, but the optimizer runs could be much higher than 1 IMO
2. The security concern that @maxdesalle has mentioned
   • this is primarily due to the assumption that the dynamic model is more fragile
3. Maybe not as friendly for etherscan interactions?
   • the current version is still not that friendly due to struct as params

---

Thoughts on the actual implementation

First, I will list the key differences between models (they share a lot of common logic):

1. the extra information that each model store
   • LD --> Segments
   • LL --> Cliffs
   • LT --> Tranches
2. the calculation function for each model (depends on the storage from 1)
   • the most complicated part
3. the different param struct
   • achievable if we dry fy all models to segments (see below)
4. the unique getter functions (like getStream and getCliffTime)
   • easy to address

If the gas implications are not a concern, we could internally remove the concept of a "cliff" and achieve the same result in a dynamic setup using two segments. For a linear stream, we can achieve the same result with a single segment. Doing so would dry-fy the logic between linear and dynamic models. Comparing the benchmarks, the difference would be around ~40-50k gas in create function (it should be fine since is one time call function) and for withdraw no significant difference.

If we agree with the change above, to fix the gas problem, we can redefining what a segment is (further dry-fy the tranched contract as well). i.e. we could remove the exponent field from the struct and store the exponents separately (just for dynamic functionality), similar to how we currently handle cliffs (using a different mapping). This would allow us to use the same segment struct for all models, without facing the same gas implicacitions (mentioned above), and without having a lot of duplicated logic within the singletone contract.

POC code

[!NOTE]
There would be only two external create functions and one internal function, meaning we would have a single set of create params structs. Also, this implementation is not final; its purpose is to convey my idea.

struct Segment {
  uint128 amount;
  uint40 milestone;
}

struct Stream {
   // --snip--
   Segment[] segments;
}

// only storage we will have 
mapping(uint256 streamId => Stream) internal _streams; // containing the segments
mapping(uint256 streamId => UD2x18[] exponent) internal _exponents; // only for dynamic

function calculateStreamedAmount(uint256 streamId) internal returns (uint128) {
    if(isLinear(streamId)) {
        return streamedAmountInCurrentSegment(streamId);
    } else if (isDynamic(streamId)) {
        return sumElapsedSegmentAmounts(streamId) + streamedAmountInCurrentSegment(streamId);
    } else if (isTranched(streamId)) {
        return sumElapsedSegmentAmounts(streamId);
    }
}

/// the function will take into consideration the exponent only if it is a LD stream.
function streamedAmountInCurrentSegment(uint256 streamId) internal returns (uint128) {
    // -- snip --
    UD60x18 elapsedTime = ud(block.timestamp - start);
    UD60x18 elapsedTimePercentage = elapsedTime.div(end - start);
    
    if (isDynamic(streamId)) {
         SD59x18 elapsedTimePercentageSD = elapsedTimePercentage.intoSD59x18();
         SD59x18 exponent = _exponents[streamId][count].intoSD59x18();
         elapsedTimePercentage = elapsedTimePercentageSD.pow(exponent).intoUD60x18();
    }
    
    UD60x18 streamedAmount = elapsedTimePercentage.mul(segmentAmount);
    return streamedAmount.intoUint128();
}

Some invariants depending on the model:

• LL: _streams[linearStreamId].segments.length <= 2 && _exponents[linearStreamId].length == 0
• LD: _streams[dynamicStreamId].segments.length == _exponents[dynamicStreamId].length
• LT: _exponents[tranchedStreamId].length == 0

But to achieve this, we would need, as you, @smol-ninja and @PaulRBerg, pointed out, an additional enum to identify the type of model the stream is using.

Very curious about what you have to say @sablier-labs/solidity.

[smol-ninja]

Thanks for sharing your idea Andrei. I'd like to share a few thoughts that came to me while reading your proposal:

1. You mentioned that it would cost 40k-50k extra gas in using your approach to create linear streams. In benchmark, its mentioned that it costs 200,605 gas for 2 segments. So if we use 2 segments to create a cliff linear stream, wouldn't it cost 200,605? On the other hand, linear contract takes 129,276 gas to create a linear stream. That should be 70k increase in gas then.

2. This also means, sunsetting all the discussions that were started to optimise Lockup Linear contract to support various cliff unlock models such as Design Lockup Linear to support Cliff Linear vesting #903. Doesn't it also mean sunsetting Lockup Tranched model? Because it was always possible to use LD to create tranched streams but we decided to build a separate contract due to the gas efficiency reasons.

3. It might make it difficult for integrators to integrate the contract since it is not intuitive to provide segments to create a linear streams.

4. You mentioned that its not friendly to provide struct in create parameters. Using segments would make it worse.

5. For linear streams, shouldn't the exponent length be 1? An exponent of 1 is required to create a linear stream.

Its a good idea but its a big refactor. At the same time, it increases the gas cost.

---

Your second approach is what I tried to implement in #1069.

[andreivladbrg]

Thanks for the fast answer.

You mentioned that it would cost 40k-50k extra gas in using your approach to create linear streams. In benchmark, its mentioned that it costs 200,605 gas for 2 segments. So if we use 2 segments to create a cliff linear stream, wouldn't it cost 200,605? On the other hand, linear contract takes 129,276 gas to create a linear stream. That should be 70k increase in gas then.

I was doing these comparisons: createWithTimestampsLL with cliff set vs. createWithTimestampsLD with 2 segments (both no broker set), which is: $180015 - 137629 = 42386$.

What you're comparing is the 200,602 gas cost for createWithDurations (2 segments) (Broker fee set) with a 129,276 gas cost for createWithDurations (Broker fee set) (cliff not set). We need to compare it to createWithDurations (Broker fee set) (cliff set), which would result in a 137,629 gas cost, leading to a difference of $200602 - 137629 = 62973$, which indeed is a bigger difference compared to the "createWithTimestamps" functions, but not quite a 70k increase as you mentioned.

This also means, sunsetting all the discussions that were started to optimise Lockup Linear contract to support various cliff unlock models such as #903.

I'm afraid yes, it would indeed contradict this new optimization for the unlock linear and cliff shapes.

Doesn't it also mean sunsetting Lockup Tranched model? Because it was always possible to use LD to create tranched streams but we decided to build a separate contract due to the gas efficiency reasons.

No, it won't be, since the new segment is going to have only 2 fields (amount, milestone), which means the tranche will remain the same in terms of gas (the exponent is outside of the segments).

It might make it difficult for integrators to integrate the contract since it is not intuitive to provide segments to create a linear streams. You mentioned that its not friendly to provide struct in create parameters. Using segments would make it worse

Yes, you are correct. This is why I have listed this in the "Cons" category.

For linear streams, shouldn't the exponent length be 1? An exponent of 1 is required to create a linear stream.

No, it shouldn't need an exponent at all. My proposal is to "redefine" a segment, as stated above: removing the exponent from the struct.

Its a good idea but its a big refactor.

Indeed, it is a big one. That's why I mentioned not to release it in the 1.3.0 version.

At the same time, it increases the gas cost.

My two cents: for a simple linear shape, it won't be that affected, but for others, it will. Also, I want to mention that the above calculations (42,386 and 62,973) won't be accurate for my proposal, as removing the exponent would most likely decrease the costs, though a significant difference would still remain.

---

This discussion makes me think of a dilemma we are facing at Sablier at the moment. What should we prioritize more: optimized code (in terms of gas efficiency) or maintainable code? (Inspired by the Ethereum trilemma). At first, I leaned more toward optimization, as I’ve made multiple optimization PRs in the past. However, now that we are planning to release more products related to “streaming/payments", and as we are iterating on more versions each year (which means we are more feature-oriented), I believe we should prioritize maintainable code to have the ability to react quickly and deliver efficiently.
(Also, multi chain implementation should be taken into consideration - more languages that require the "same" implementation of the protocol)
Since we have agreed on package tethering, I believe this change aligns well with this approach.

Of course, this discussion exists on a spectrum; I am not suggesting we take an extreme position on either side. I am simply talking about how far we should deviate from the center of this “dilemma” and towards which direction. This can be a longer discussion, which we can address in another place.

Some extra notes

Maintainable Code	Optimized Code (Gas Efficiency)
Easier to iterate and scale over time	Can be complex to maintain long-term
Faster feature delivery and easier collaboration	May result in slower feature delivery
Higher gas consumption	More cost-effective in gas consumption

[smol-ninja]

Great reply. A few questions that I could not comprehend:

1. Why would separating LL, LD and LT logic (a.k.a. optimized code in the above context) result in slower feature delivery and increased complexity? Most of the shared logic is in the abstract contract. Each lockup logic primarily contains _create and calculateStreamedAmount. So, I do not agree that separating them provides more complexity and higher maintenance compared to using segments to represent all of them.

2. Why would using segments to create any lockup be easier to iterate with and result into faster feature delivery? It depends on which feature needs to be implemented. Adding protocol fee on withdraw will have same efforts in any structure. It would be easier to add an unlock cliff feature to Lockup linear in the current model compared to the proposed model.

3. If each stream costs 63k more gas which is ~$2.34 (@12 Gwei / gas), then with 10,000 streams, it will cost $23,400 more in gas to users overall. Does it justify the maintenance cost reduction you are mentioning?

4. Another point you may have missed is that it would also increase the gas cost for airdrop claiming which at the time of claim can be very significant due to surge in gas prices. A 40k increase would be noticeable in that case.

---

Do you have any estimation on what would be the contract size? I am guessing it would be near the singleton contract demonstrated below but a bit better i.e. 500-1000 gas less than max.

---

During this discussion, I think we have missed an important point: the OP states that separating out the contracts lead to fragmentation of NFTs. IMO combining three lockups into one should not come with a cost of increasing gas cost for users.

[andreivladbrg]

slower feature delivery and increased complexity?

as said in my initial comment 1. different storage layouts 2. different calculation functions 3. unique param structs for each create function

So, I do not agree that separating them provides more complexity and higher maintenance compared to using segments to represent all of them

complexity maybe not, but maintenance yes as per 3 points above

Why would using segments to create any lockup be easier to iterate with and result into faster feature delivery?

i will answer with a diagram

graph TD
    subgraph LD
        LL["LL"]
        LT["LT"]
    end

Loading

you can achieve both LL and LT in a LD setup and having only on model thats suits all shapes would allow to make faster deliveries

Adding protocol fee on withdraw will have same efforts in any structure. It would be easier to add an unlock cliff feature to Lockup linear in the current model compared to the proposed model

i am not sure i understand this point

If each stream costs 63k more gas which is ~$2.34

it won't be 63k as said in my previous message, i can't say an exact number now but it would less. your calculation is probably for mainnet, right? on most L2s we are talking about less than $0.05 (5 cents)

Another point you may have missed is that it would also increase the gas cost for airdrop claiming which at the time of claim can be very significant due to surge in gas prices. A 40k increase would be noticeable in that case

that's the same point, gas increase, which i agree, it is not a good thing

---

Do you have any estimation on what would be the contract size? I am guessing it would be near the singleton contract demonstrated below but a bit better i.e. 500-1000 gas less than max.

no i don't, i am just brainstorming the core idea here, and if we decide on it, we can further implement it and benchmark it

the OP states that separating out the contracts lead to fragmentation of NFTs.

yes, a contract to rule them all (shapes)
(LOTR reference , in case you miss it 😂)

IMO combining three lockups into one should not come with a cost of increasing gas cost for users.

yes that would be ideal if we won't have an increase of gas cost

[smol-ninja]

Great sounds good, Andrei. I'd also appreciate if you can give your opinion my comment below and then we can review all the ideas. I think the solution below is really good, has minimal Cons but all the Pros we are looking for in this discussion.

[smol-ninja]

I finally got it. And moved LL, LD and LT into one contract without changing the lockup designs. You can review the changes in #1069.

The singleton contract has a size of 23,853 Bytes with 1000 runs (yes thats 1000 runs), and that is 723 B less than maximum. The major changes that contributed to bytecode reduction are follows:

1. Removing _calculateStreamedAmountForOneSegment
2. Changing visibility of Helper functions to public. Making them public deploys Helpers as a separate contract which otherwise was a part of the parent contract's bytecode.
3. Moving calculateStreamedAmountForSegments to Helpers.
4. DRY'ifying create functions withdraw affecting the logic.

Pros:

1. A single contract with much lower bytecode. This enables us to add new features in the future.
2. LL, LD and LT retain their internal designs.
3. Only minor impact in the gas cost. The only gas cost increase is same as calling a public function vs an internal function.
4. One NFT to rule them all.

Cons:

1. Public functions in Helpers.
2. Change in create APIs.
3. Had to remove getStreams but can bring it back. However, can we check if its being used by users? its job can still be achieved through a set of other functions. cc @razgraf

@andreivladbrg I'd appreciate if you can review this. I think this is a very good approach since there is not much change to the current design of the lockups. And we should move in this direction. It has all the Pros that you mentioned above without any of those Cons.

tagging @sablier-labs/solidity

[andreivladbrg]

I just got partially through the version you wrote, and it looks like this might be the approach we should take if we want to keep all families (LD/LL/LT) in the same contract. If we decide to include this in 1.3.0, I’d like to make several refactors/DRY it up compared to the version in the PR (I know you mentioned that this version is for demonstration purposes) but we can furthur discuss privately.

Had to remove getStreams but can bring it back

we can have getStreamLD getStreamLL and getStreamLT

---

The apple of discord here is that we would need the public libraries (deployed separately) to achieve this: 23,853 bytes with 1,000 runs.

cc @PaulRBerg I can’t remember why we moved away from this approach. I remember making a similar change back in 2022, but I can’t find exactly where. Do you remember which were the reasons?

[PaulRBerg]

we can have getStreamLD getStreamLL and getStreamLT

Or getStreamDynamic, getStreamLinear, and getStreamTranched

The apple of discord here

I wouldn't classify this as a discord

I can’t remember why we moved away from this approach

Nope, I don't remember unfortunately, but I don't think it matters now given the explanations provided in the OP.

[andreivladbrg]

I wouldn't classify this as a discord

My wording wasn’t the best. Let’s put it this way: the "game changer" in this equation is the public libraries.

Nope, I don't remember unfortunately, but I don't think it matters now given the explanations provided in the OP.

At the time, I took inspiration from Aave and introduced the Errors and Validation library. I also tried to fit as much logic as possible into a public library to achieve gas optimization. (Whether it matters or not, do you remember this?)

[smol-ninja]

Very exciting to do this. Happy to see all of us on the same page now.

Regarding getStreamDynamic, getStreamLinear, and getStreamTranched, why do we include them? It would require declaring separate structs as returned values. And, as @razgraf mentioned that they don't use it in the UI and the same result can be achieved by using other view functions.

So we can stay lean without impacting DX. The only thing it impacts is the number of RPC calls that one would have to make in order to fetch all values in their code. But imo RPC calls are cheaper than 1000 B. By saving 1000 B, it gives us rooms to make changes in the future.

[PaulRBerg]

OK sounds good, we can forgo those getters.

[PaulRBerg]

To avoid re-reading everything, can you say if reading @smol-ninja's last message would be sufficient to have all the context I need on this?

[smol-ninja]

Yes but also this and this (see some extra notes there) where @andreivladbrg proposed using segments to construct both LL and LT streams instead of having separate (current) LL and LT implementations.

[PaulRBerg]

I favor @smol-ninja's proposal.

@andreivladbrg thank you for your feedback.

For the sake of simplicity, I suggest keeping the LL, LT, and LD stream models as separate concepts. Without this separation, we would introduce a major refactor in both the UI code and the subgraphs. In the latter, special logic would be required for differentiating linear streams from other non-linear ones.

This discussion makes me think of a dilemma we are facing at Sablier at the moment. What should we prioritize more: optimized code (in terms of gas efficiency) or maintainable code?

This is a false dichotomy.

Merging the Lockups into one contract doesn't make the code more or less maintainable.

[PaulRBerg]

Also, I don't agree with getting rid of LL and LT. We should keep them separate for gas optimization purposes.

[andreivladbrg]

The statement 'this is a false dichotomy' wasn't unexplained. The statement that followed it was the explanation.

no, my point was that you said "doesn't make the code more or less maintainable" and this wasn't explained why
sorry for not being precise enough

We already have all these differences

yes, that's correct, and my whole point is to remove them and rely on a new structure orientated to the new segment proposed

Putting them into one contract won't increase the maintenance cost long-term.

anytime we add a new feature that touches all components or refactor existing code, we will need to add or modify more code

It will just introduce a development cost in the short term

correct, development cost is a subset of maintenance cost. i would argue that it is not only a short-term cost, but also a long-term one

Also, I don't agree with getting rid of LL and LT. We should keep them separate for gas optimization purposes.

that's another thing, as said above, it is a cost we pay for optimization (development cost) and it seems we agree

[PaulRBerg]

Development cost is not a subset of maintenance cost.

• Development cost = one-time thing
• Maintenance cost = recurring thing

we will need to add or modify more code

Once

but also a long-term one

Neither Shub nor I see why it will increase the maintenance cost long-term. Could you please explain why you think this?

[andreivladbrg]

we will need to add or modify more code
once

it is not once, because i am not talking specifically about this change, but about every new feature we add or a new refactor we make in the future, from above:

However, now that we are planning to release more products related to “streaming/payments", and as we are iterating on more versions each year (which means we are more feature-oriented), I believe we should prioritize maintainable code to have the ability to react quickly and deliver efficiently.
(Also, multi chain implementation should be taken into consideration - more languages that require the "same" implementation of the protocol)

having a model that suits them all would create a cascade effect, leading to faster delivery

Neither Shub nor I see why it will increase the maintenance cost long-term. Could you please explain why you think this?

we have multiple components we need to take into consideration always when add a new thing/modify current version

function createLD(Params memory params, UniqueParamsLD memory unique) external;
function createLL(Params memory params, UniqueParamsLL memory unique) external;
function createLT(Params memory params, UniqueParamsLT memory unique) external;
function calculateStreamedAmountLD(uint256 streamId) public returns (uint256);
function calculateStreamedAmountLL(uint256 streamId) public returns (uint256);
function calculateStreamedAmountLT(uint256 streamId) public returns (uint256);

vs for the gas optimization:

function create(Params memory params) external;
function calculateStreamedAmount(uint256 streamId) public returns (uint256);

[PaulRBerg]

Having a single model (LD) for all streams falls outside the original focus of this discussion. Here, we are proposing merging the separate contracts. Whereas you are proposing an even bigger leap — and the maintenance cost does not factor into the original scope.

Feel free to open a separate discussion about this point.

about every new feature we add or a new refactor we make in the future

This argument applies to the current design (with separate contracts) so again, not relevant for this discussion. Feel free to open a separate one.

[razgraf]

One small caveat with this merger (and I preface this by saying I haven't yet analyzed it in detail yet) is that it may break some assumptions in the client apps / services.

We've been able to work our way back from a contract address or an alias to a stream type until now. 0xA was LL, while 0xB was LD. Given we'll now house everything in one array, and one LL at id 4 may be followed by an LD at id 5 in the same 0xC contract

... it may require us to pipe (for example) two requests rather than a single one (since we have to now find out the type first).

One simple example is a multicall. We either run:

• (1) getType and (2) multicall to get-body-parts ... or
• ask for (1) get-body-parts and run both getSegments and getTranches inside, with the understanding that one will be useless

[andreivladbrg]

Couldn't we just have three mappings?

what you mean? the storage?

there would be a lot of duplicated logic and there might be size problems

---

we can have the getStreamLL getStreamLD getStreamLT getters (with different return structs) but as talked here, we abandoned the idea

so my solution was to have only one function, without adding different structs for each model

[PaulRBerg]

Right

(Yeah, I meant storage)

[razgraf]

would it be useful to add a getStream function

It could be useful, yes. For this particular case, it makes sense to use the getters, just didn't notice the need before. So my reply here won't be true any more.

[smol-ninja]

with the function above you will have all informations in one call, but you will need to decode it based on the lockupModel

@andreivladbrg won't they still have to make two calls?

1. First call to getType
2. Second call to getStream
3. Use value of first call to understand which decode structure to use for the returned value of the second call?

[andreivladbrg]

@andreivladbrg won't they still have to make two calls?

no, the function would return both: (lockupModel, data);

[andreivladbrg]

closing as everything got merged on staging