[FEATURE] EV Deployer #119
Description
Is your feature request related to a problem? Please describe.
Deploying smart contracts in EV REF (Hyperlane, custom contracts, protocol infrastructure) is a manual, error-prone process. Each deployment requires direct interaction with deployment scripts, environment-specific configuration, and careful coordination of contract addresses across multiple chains or environments. There is no unified tool that handles this end to end.
When a new chain or environment needs to be stood up, operators must piece together scripts, manage private keys, track deployed addresses, and verify configurations by hand. This slows down iteration, increases the risk of misconfiguration, and makes reproducibility difficult.
Describe the solution you'd like
Build EV Deployer, a CLI tool for deploying and upgrading smart contracts within the EV REF ecosystem. The tool should be modeled after [OP Deployer](https://docs.optimism.io/chain-operators/tools/op-deployer/overview) from Optimism.
Core requirements:
- Declarative configuration. Operators define the desired deployment state in a config file (YAML or TOML). EV Deployer reads it and executes only the contract calls needed to reach that state. This removes the need to understand the deployment sequence or manage intermediate steps.
- Hyperlane and smart contract support. The tool should handle deploying Hyperlane core contracts (Mailbox, ISM, IGP, etc.) as well as any custom smart contracts defined in EV REF. It should be extensible enough to add new contract types without rewriting deployment logic.
- Portable, standalone binary. Distribute EV Deployer as a single binary with no external dependencies. It should work in local dev environments, CI/CD pipelines, and production deployment workflows without extra setup.
- Upgrade support. Beyond initial deployment, the tool should support upgrading existing contracts to new implementations. Config diffs should drive the upgrade path.
- Address management. Track and output all deployed contract addresses in a structured format (JSON or similar). This state file should be reusable across subsequent deployments and by other tooling.
- Safe defaults, with escape hatches. Optimize the happy path for standard EV REF deployments. Expose lower-level primitives for operators who need non-standard configurations.
Describe alternatives you've considered
- Manual deployment scripts. This is the current approach. It works but does not scale. Each new environment requires duplicating and editing scripts, which leads to drift between environments and frequent human error.
- Hardhat/Foundry deploy plugins. These tools handle individual contract deployments well but lack the declarative, state-driven model needed for managing full protocol stacks. They also do not natively support multi-chain orchestration or upgrade workflows out of the box.
- Forking OP Deployer directly. OP Deployer is purpose-built for the OP Stack. Its contract interfaces and deployment assumptions are tied to Optimism's architecture. Forking it would require stripping out OP-specific logic and rebuilding the contract interaction layer for EV REF, which is roughly the same effort as building a new tool inspired by its design.
Additional context
- OP Deployer reference: https://docs.optimism.io/chain-operators/tools/op-deployer/overview
- OP Deployer is considered production-ready and has been used in several mainnet deployments. Its declarative model and portable binary distribution are the two design choices most worth carrying over.
- Initial scope should focus on Hyperlane core contracts and a small set of EV REF smart contracts. Broader contract coverage can be added incrementally.
- The config schema should be versioned from day one to support future changes without breaking existing deployment files.