refactor: update repo for the new iteration

[andreivladbrg]

Closes #42

Changes

feat: add airdrops dir
feat: add linear curves creator
feat: add tranched curves creator
refactor: restructure lockup dir
refactor: update lockup to singleton version
refactor: use latest deployments addresses
build: install staging version in for all repos
test: update the block number forked
test: add tests for linear and tranched curves creators

[andreivladbrg]

@smol-ninja I’ve marked the PR as ready for review.

One thing that wasn’t mentioned in the OP is the need to move the dynamic shapes from (CurvesCreator) to linear and to tranched.

[smol-ninja]

Great work on the PR. Some feedback below. I have also added a commit with some changes on comments. There were some linting warnings so the changes to the solhint config are to disable them.

[andreivladbrg]

I see that many comments are about the names used in lockup linear curves. My intention was to keep the existing terminology from the docs, but it seems that it’s not working well.

IMO we shouldn't explicitly include “linear” in the shape names (except for the default one), as all shapes are within the “lockup linear” model, which is implicit enough. Therefore, I propose the following new names, based on what distinguishes them from the default linear shape.

Scenario	Shape Name	Cliff Time	Start Amount	Cliff Amount
1	Linear	❌	❌	❌
3	Cliff Unlock	✅	❌	✅
3	Initial Unlock	❌	✅	❌
4	Initial Cliff Unlock	✅	✅	✅
5	Constant Cliff	✅	❌	❌
6	Initial Unlock Constant Cliff	✅	✅	❌

(still not sure about shape 6 because it is too long)

Plot graphs

Scenario 5

Scenario 6

lmk what you think

[smol-ninja]

as all shapes are within the “lockup linear” model

Its implicit to us but may not be for someone who is reading the examples. The expliciteness in names can help them understand that the stream is still Linear with start and cliff unlocks. All the functions under Linear examples create a Linear stream with different configurations.

was to keep the existing terminology from the docs

In the docs, it looks good because of the different levels of heading. Cliff is under Linear categories so it is very clear.

Your proposal is good for docs because we have a level 2 heading called Linear and then level 3 headings called cliff unlock, initial unlock etc. but imo we can have function names suffixed with Linear in examples.

Think of it this way.

function createStream_CliffLinear is made of cliff which is level 3 heading in docs and Linear which is level 2 heading.

[andreivladbrg]

Its implicit to us but may not be for someone who is reading the examples The expliciteness in names can help them understand that the stream is still Linear with start and cliff unlocks.

In the docs, it looks good because of the different levels of heading. Cliff is under Linear categories so it is very clear.

ser, the contract name is LockupLinearCurvesCreator. if it is clear on the docs, it is clear here as well IMO

Your proposal is good for docs because we have a level 2 heading called Linear and then level 3 headings called cliff unlock, initial unlock etc. but imo we can have function names suffixed with Linear in examples.

here the level 1 heading is the contract name

so, i still think the list from above (without including the Linear word) is a good one

[smol-ninja]

Fair points. Lets go it your way.

[smol-ninja]

Just a note that Batch examples do not contain reference to unlock amounts in case of batch LL. So they are being passed as 0.

[smol-ninja]

Approving this since we are ready to merge it tomorrow. Repeating my previous note ICYMI:

Batch examples do not contain reference to unlock amounts in case of batch LL. So they are being passed as 0.

[andreivladbrg]

just pushed a new commit adding the unlock amounts in the batchLL example dc85aa6

we should sync this merge with the docs PR