feat(ev-deployer): part 3a - add live chain deployment via CREATE2

[randygrok]

Summary

Adds a deploy subcommand to ev-deployer for deploying AdminProxy and Permit2 contracts to a live chain via CREATE2 using the deterministic deployer factory.

Previously, ev-deployer could only generate genesis alloc JSON for pre-genesis deployment. This PR adds the ability to deploy the same contracts to an already-running chain, with deterministic addresses, state persistence, and idempotent resume.

Key changes

• Optional addresses in config — address is now Option<Address> in contract configs. Required for genesis mode (validated at runtime), ignored in deploy mode where CREATE2 determines the address.
• CREATE2 module — Computes deterministic addresses using Nick's factory (0x4e59b44847b379578588920ca78fbf26c0b4956c).
• Deploy state file — JSON state file tracks a random salt, the original config intent, and per-contract status (pending → deployed → verified). Immutability checks prevent config drift between runs.
• ChainDeployer trait — Abstracts on-chain operations (get_code, deploy_create2). LiveDeployer implements it with alloy provider + signer.
• Deploy pipeline — Orchestrates: connect → verify factory exists → deploy each contract → verify bytecodes on-chain. Fully idempotent (skips already-deployed contracts).

Usage

# Deploy to a live chain
ev-deployer deploy \
  --config deploy.toml \
  --rpc-url http://localhost:8545 \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  --state deploy-state.json \
  --addresses-out addresses.json

# RPC URL and private key can also be set via env vars
export EV_DEPLOYER_RPC_URL=http://localhost:8545
export EV_DEPLOYER_PRIVATE_KEY=0xac0974...
ev-deployer deploy --config deploy.toml --state deploy-state.json

The state file is created on first run and reused on subsequent runs for resumability. If a deploy is interrupted, re-running the same command picks up where it left off.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e328adfb-939e-43ce-900c-65cff26803c5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ev-deployer-part3a

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Claude finished @randygrok's task —— View job

---

PR Review: feat(ev-deployer): part 3a - add live chain deployment via CREATE2

I've completed a comprehensive review of this PR. This is a well-implemented feature that adds live chain deployment capabilities to the ev-deployer tool via CREATE2. Here are my findings:

✅ Overall Assessment

This is high-quality code that demonstrates strong engineering practices. The implementation is well-architected, thoroughly tested, and includes proper error handling and security considerations.

---

Code Quality & Architecture

🎯 Excellent Design Patterns

• Clean separation of concerns: The modular design with separate modules for create2, deployer, pipeline, and state is excellent
• Trait abstraction: The ChainDeployer trait properly abstracts on-chain operations, making testing and future extensions easy
• State management: The DeployState design with immutability checks and atomic file operations shows thoughtful design
• Configuration validation: Separate validation for genesis vs deploy modes is well-implemented

🔧 Implementation Highlights

• Idempotent deployment: The pipeline correctly handles resumability and skips already-deployed contracts
• Atomic state persistence: Using temp file + rename for state saves prevents corruption
• Proper error propagation: Consistent use of eyre::Result throughout
• Good documentation: Code is well-documented with clear comments

---

Security Review

✅ Security Strengths

1. Private key handling: Keys are properly parsed and contained within the LiveDeployer, not exposed in logs
2. Address validation: Zero address checks prevent common deployment mistakes
3. Immutability enforcement: Config drift protection prevents accidental changes between runs
4. Chain ID validation: Explicit chain ID matching prevents wrong-chain deployment
5. Bytecode verification: Post-deployment verification ensures contracts deployed correctly
6. Factory verification: Checks that deterministic deployer exists before attempting deployments

⚠️ Security Considerations

1. Private key in CLI: While standard practice, private keys via command line are visible in process lists. The environment variable option helps, but consider warning users about process visibility
2. No transaction gas limit: The TransactionRequest doesn't set gas limits, relying on provider defaults

---

Technical Implementation

✅ Strong Technical Decisions

• CREATE2 implementation: Correct implementation using Nick's deterministic deployer factory (0x4e59b44847b379578588920ca78fbf26c0b4956c)
• State machine: Clear progression through Pending → Deployed → Verified states
• Bytecode patching: Proper handling of immutable values in Permit2 bytecode (chain ID, domain separator)
• Error handling: Comprehensive error messages with context

🧪 Test Coverage

• 53 test functions across 10 modules - excellent coverage
• Mock implementations for testing the deployment pipeline without live chains
• Property-based testing for CREATE2 address computation
• Integration tests covering the full deployment flow
• Edge case handling (chain ID mismatches, missing deployer, etc.)

---

Performance & Efficiency

✅ Performance Considerations

1. Efficient bytecode operations: Uses static bytecode constants with runtime patching
2. Minimal RPC calls: Only fetches what's needed, implements proper caching via state file
3. Concurrent-ready: Uses async/await properly for potential future parallelization
4. Memory efficient: Streams bytecode operations rather than loading everything into memory

---

Minor Suggestions for Improvement

📝 Code Quality

1. Line 149 in pipeline.rs: Consider extracting the admin proxy deployment logic to match the permit2 pattern for consistency
2. Consider gas limit settings: Add optional gas limit configuration for transaction requests
3. State file versioning: Good forward-compatibility with version field, but consider migration strategies for future schema changes

🔍 Security Enhancements

1. Private key warning: Consider adding a warning about command-line private key visibility
2. Transaction fee estimation: Add gas price/fee estimation for better user experience

📚 Documentation

1. README updates: The README changes look good and provide clear usage examples
2. Consider adding troubleshooting section: Common issues like missing deterministic deployer

---

Specific Technical Notes

CREATE2 Implementation (src/deploy/create2.rs)

• ✅ Correct implementation of CREATE2 address computation
• ✅ Proper factory calldata format (salt || initcode)
• ✅ Good test coverage for different salts and initcode

State Management (src/deploy/state.rs)

• ✅ Excellent atomic file operations with temp file + rename
• ✅ Strong immutability checking prevents config drift
• ✅ Random salt generation for deployment uniqueness

Pipeline Orchestration (src/deploy/pipeline.rs)

• ✅ Well-structured deployment flow with clear progress reporting
• ✅ Proper verification of prerequisites (chain ID, deployer existence)
• ✅ Idempotent contract deployment with state tracking

---

Final Recommendation: ✅ APPROVE

This is a high-quality implementation that:

• ✅ Adds significant value with live chain deployment capabilities
• ✅ Follows security best practices with proper validation and verification
• ✅ Has comprehensive test coverage with 53 test functions
• ✅ Uses sound architectural patterns with proper abstraction and modularity
• ✅ Includes excellent error handling and user feedback
• ✅ Maintains backward compatibility while extending functionality

The code is production-ready and demonstrates excellent engineering practices. The minor suggestions above are optional improvements that don't block the merge.

---