Improving the EVM deployment experience

[andreivladbrg]

(This idea came prior to this discussion)

Beyond the information (ABIs, contract addresses, broadcasts, etc.) that this repo will provide, I think we could take this even further. What if we make this repo a central point for everything related to deployments across all protocols—including the deployment scripts themselves (which means we’d need to add a foundry.toml file).

We’d also be installing all protocol repos (lockup, flow, airdrops, etc.) here via package.json, so we can implement a unified DeployProtocol script to handle all contract deployments in one go. It doesn't mean we can't have individual scripts as well, i.e. DeployLockup or DeployLockupNFTDescriptor.
One potential problem is dealing with different deployment profiles—for example, lockup requires fewer optimizer_runs, while airdrops can use a much higher value. But we can handle this by:

• Easy option: re-introduce precompiles in the protocols repos
  • we could refactor the DeployOptimized testing utils to contain the bytecode directly instead of reading it from out-optimized
• Harder option: using different Foundry profiles as a pre-step before running the deployment script to generate the initcode.

If we add the precompiles here

foundry.toml

[profile.lockup]
src = "src/lockup"
optimizer_runs = 500
[profile.flow]
src = "src/flow"
optimizer_runs = 1000
[profile.airdrops]
src = "src/airdrops"
optimizer_runs = 100_000_000

script/Precompiles.sol

/// Import to generate the bytecode
import { LockupNFTDescriptor } from "@sablier/lockup/src/LockupNFTDescriptor.sol";
import { SablierBatchLockup } from "@sablier/lockup/src/SablierBatchLockup.sol";
import { SablierLockup } from "@sablier/lockup/src/SablierLockup.sol";

library Precompiles {
    function lockupInitcode() internal pure returns (bytes memory) {
        return hex'<bytecode>';
    }
    function nftDescriptorInitcode() internal pure returns (bytes memory) {
        return hex'<bytecode>';
    }
    function batchInitcode() internal pure returns (bytes memory) {
        return hex'<bytecode>';
    }
}

script/DeployProtocol.s.sol

// lockup example but can be extended to include all protocols
function run() public pure broadcast returns (address,address,address) {
    address nftDescriptor = _deploy(Precompiles.nftDescriptorInitcode(), "", salt);
    address lockup = _deploy(Precompiles.lockupInitcode(), abi.encode(initialAdmin(), nftDescriptor, maxCount), salt);
    address batch = _deploy(Precompiles.batchInitcode(), "", salt);

    // so on for all protocols contract

    return (lockup, batch, nftDescriptor);
}

function _deploy(
    bytes memory _initcode,
    bytes memory _args,
    bytes32 _salt
)
    private
    returns (address deployedContract)
{   
    // Check to avoid deploying empty contracts 
    require(_initcode.length > 0, "Deployer: initcode length is zero");
    bytes memory initcode = abi.encodePacked(_initcode, _args);

    assembly {
        deployedContract := create2(0, add(initcode, 32), mload(initcode), _salt)
    }
}

Main benefits of this approach:

• No need to manually go into each repo to deploy and then move all the broadcasts/ABIs/info to this one
• A single source of truth for deployments
• Scripts don’t need to be updated across all repos every time a change is made
• We can fetch previously used addresses like NFTDescriptor without storing them in the repo
• Only the mainnet endpoint needs to be configured there for fork testing, no need for all (lockup, airdrops, flow)

I really think centralizing everything here is the right call in terms of maintenance costs and ease of use (deploying a lot of contracts over the past year 😆). The idea is mainly inspired by how Uniswap handles it (they have a single repo for all contract deployments), v2/v3/v4/permit2 and so on, and their new v4-core doesn’t even contain any deployment scripts.

Questions

• If we plan to add Solana deployments as well, things could get messy. In that case, we might want to reconsider the repo name—something like evm-deployments—and keep Solana-related broadcasts in the solsal repo, as I initially suggested. (we won't have to deal with multichains there, so it makes sense to keep there).
• We could also consider moving the multichain-deployer logic into this repo. That way, we could repurpose the current repo into something else—maybe a multi-scripts repo—and use it for scripts like this one.

---

@sablier-labs/evm RFF — I tried to keep my message concise here, but I highly recommend checking out Uniswap's repo. Not necessarily to do a deep dive, but just to get a general sense of how they’re structuring things and what patterns they're following.

[smol-ninja]

I think this a great idea. Advantages are very clear to me.

re-introduce precompiles in the protocols repos

We should not rely on precompiles for deployments. Using precompiles assume that the same foundry configurations would work across all the chains, which is not true. For example, Linea requires a different value for optimizer runs. Therefore, a more robust approach would be to have build settings specified in this repo. This would allow us to have a good control over multichain deployments.

we plan to add Solana deployments as well

We should keep Solana deployments in a separate repo and once that repo is matured enough, then we should look into merging the two together. This would be the most convenient way to unify all Sablier related deployments. There will be many unknowns in the Solana deployment process which we are not aware of at the moment and having it in a separate repo will make it agile without having to worry about following this repo's structure.

multichain-deployer

Same argument as Solana deployment. I would suggest to have multichain-deployer as a separate repo until we reach a point where its easier to merge the two together. One step at a time!

PS: I haven't had a look at Uniswap's repo yet but its on my to read list.

[andreivladbrg]

I think this a great idea. Advantages are very clear to me.

Thanks

For example, Linea requires a different value for optimizer runs

good point.

Therefore, a more robust approach would be to have build settings specified in this repo. This would allow us to have a good control over multichain deployments.

The problem with that is you won’t be able to deploy all protocols in a single script, which is why I went with the precompiles version:

// just for demonstrative purpose, there are more contracts
function run() public return (SablierLockup lockup, SablierFlow flow, SablierMerkleFactory factory) {
      // requires 500 op_runs
      lockup = new SablierLockup();
      // requires 1000 op_runs
     flow =  new SablierFlow();
      // requires 100M op_runs
     factory =  new SablierMerkleFactory();
}

We wouldn’t be able to just run forge script script/DeployProtocol.s.sol and deploy everything— we’d have to deploy the protocols in separate steps.
I don’t have a better solution at the moment, but we can think about it later.

---

We should keep Solana deployments in a separate repo and once that repo is matured enough, then we should look into merging the two together.

Agree. My opinion is that we shouldn’t include them at all, since we’ll have Solidity deployment scripts — separation of concerns.

. I would suggest to have multichain-deployer as a separate repo until we reach a point where its easier to merge the two together. One step at a time!

I’m not talking about when to do it, but that we should do it — I still believe (unlike the solana deployments) it’s the right call to move it

[smol-ninja]

The problem with that is you won’t be able to deploy all protocols in a single script, which is why I went with the precompiles version:

Can we not use a bash script to run it with a single command (ofc internally there would be 3 deployment scripts but I don't see an issue with that)?

I’m not talking about when to do it, but that we should do it

Are you suggesting to move it now? I didn't get your intention there. There is always a when, its now or later :))

[andreivladbrg]

Can we not use a bash script to run it with a single command (ofc internally there would be 3 deployment scripts but I don't see an issue with that)?

We already have multichain-deployer — adding a bash script would unnecessarily overcomplicate things. We can think of solutions later.

Are you suggesting to move it now? I didn't get your intention there. There is always a when, its now or later :))

There are two questions: 1. Should we move it here? 2. Should we do it now or later?
My question was the first one, but you answered the second in your initial reply.

My answers: 1. Yes 2. Later

[smol-ninja]

We already have multichain-deployer — adding a bash script would unnecessarily overcomplicate things. We can think of solutions later.

Then technically, we are already deploying all protocols with a single command. I think using a single command matters more than how many scripts it uses under the hood.

My answers: 1. Yes 2. Later

Agree with your answers.