datahaven/contracts/script/deploy/DeployLive.s.sol

267 lines
11 KiB
Solidity
Raw Permalink Normal View History

feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.27;
import {DeployBase, ServiceManagerInitParams} from "./DeployBase.s.sol";
import {DataHavenServiceManager} from "../../src/DataHavenServiceManager.sol";
// Snowbridge imports for function signatures
import {BeefyClient} from "snowbridge/src/BeefyClient.sol";
import {AgentExecutor} from "snowbridge/src/AgentExecutor.sol";
import {IGatewayV2} from "snowbridge/src/v2/IGateway.sol";
// Logging import
import {Logging} from "../utils/Logging.sol";
// EigenLayer core contract imports for type casting
import {AllocationManager} from "eigenlayer-contracts/src/contracts/core/AllocationManager.sol";
import {AVSDirectory} from "eigenlayer-contracts/src/contracts/core/AVSDirectory.sol";
import {DelegationManager} from "eigenlayer-contracts/src/contracts/core/DelegationManager.sol";
import {RewardsCoordinator} from "eigenlayer-contracts/src/contracts/core/RewardsCoordinator.sol";
import {StrategyManager} from "eigenlayer-contracts/src/contracts/core/StrategyManager.sol";
fix: Resolve Foundry build errors and apply code formatting (#241) ## Summary Fixes the CI build failure in the `task-ts-build` workflow caused by Foundry v1.4.2's Solar linter not being able to resolve Snowbridge's context-specific import remappings. ## Problem The Snowbridge submodule uses context-specific remappings (prefixed with `:`) for its dependencies: - `lib/snowbridge/contracts/:openzeppelin/` → OpenZeppelin contracts - `lib/snowbridge/contracts/:prb/math/` → PRB Math library Foundry v1.4.2's Solar linter doesn't understand these context-specific remappings and fails with errors like: ``` error: file openzeppelin/utils/cryptography/MerkleProof.sol not found error: file prb/math/src/UD60x18.sol not found ``` ## Solution Added global remappings that the linter can understand: ```toml "openzeppelin/=lib/snowbridge/contracts/lib/openzeppelin-contracts/contracts/", "prb/math/=lib/snowbridge/contracts/lib/prb-math/", ``` ### Why This Works - The linter can now resolve `openzeppelin/` and `prb/math/` imports globally - These global remappings take **lower precedence** than context-specific ones during compilation - The compiler still uses the context-specific remappings (with `:`) when compiling Snowbridge contracts - The linter uses the global remappings when checking all files ## Changes ### Commit 1: Add global remappings - `contracts/foundry.toml`: Added 2 global remapping entries ### Commit 2: Apply forge fmt - Applied automatic formatting via `forge fmt` to ensure code style consistency - Multi-line formatting for long import statements and function signatures - No functional changes - purely formatting updates ## Testing ✅ Local build succeeds with `forge build` ✅ No Snowbridge import resolution errors ✅ `forge fmt --check` passes with no formatting issues ✅ Only linting notes/warnings remain (not errors) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude <noreply@anthropic.com>
2025-10-20 08:20:59 +00:00
import {
PermissionController
} from "eigenlayer-contracts/src/contracts/permissions/PermissionController.sol";
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
// OpenZeppelin imports for proxy creation
import {ProxyAdmin} from "@openzeppelin/contracts/proxy/transparent/ProxyAdmin.sol";
fix: Resolve Foundry build errors and apply code formatting (#241) ## Summary Fixes the CI build failure in the `task-ts-build` workflow caused by Foundry v1.4.2's Solar linter not being able to resolve Snowbridge's context-specific import remappings. ## Problem The Snowbridge submodule uses context-specific remappings (prefixed with `:`) for its dependencies: - `lib/snowbridge/contracts/:openzeppelin/` → OpenZeppelin contracts - `lib/snowbridge/contracts/:prb/math/` → PRB Math library Foundry v1.4.2's Solar linter doesn't understand these context-specific remappings and fails with errors like: ``` error: file openzeppelin/utils/cryptography/MerkleProof.sol not found error: file prb/math/src/UD60x18.sol not found ``` ## Solution Added global remappings that the linter can understand: ```toml "openzeppelin/=lib/snowbridge/contracts/lib/openzeppelin-contracts/contracts/", "prb/math/=lib/snowbridge/contracts/lib/prb-math/", ``` ### Why This Works - The linter can now resolve `openzeppelin/` and `prb/math/` imports globally - These global remappings take **lower precedence** than context-specific ones during compilation - The compiler still uses the context-specific remappings (with `:`) when compiling Snowbridge contracts - The linter uses the global remappings when checking all files ## Changes ### Commit 1: Add global remappings - `contracts/foundry.toml`: Added 2 global remapping entries ### Commit 2: Apply forge fmt - Applied automatic formatting via `forge fmt` to ensure code style consistency - Multi-line formatting for long import statements and function signatures - No functional changes - purely formatting updates ## Testing ✅ Local build succeeds with `forge build` ✅ No Snowbridge import resolution errors ✅ `forge fmt --check` passes with no formatting issues ✅ Only linting notes/warnings remain (not errors) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude <noreply@anthropic.com>
2025-10-20 08:20:59 +00:00
import {
TransparentUpgradeableProxy
} from "@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol";
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
/**
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
* @title DeployLive
* @notice Deployment script for live networks (hoodi testnet, ethereum mainnet)
* @dev References existing EigenLayer contracts on the target chain
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
*/
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
contract DeployLive is DeployBase {
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
string public networkName;
function run() public {
// Network detection and validation
networkName = vm.envString("NETWORK");
require(
bytes(networkName).length > 0,
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
"NETWORK environment variable required for live deployment"
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
);
_validateNetwork(networkName);
totalSteps = 4;
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
address avsOwnerEnv = vm.envOr("AVS_OWNER_ADDRESS", address(0));
require(
avsOwnerEnv != address(0),
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
"AVS_OWNER_ADDRESS env variable required for live deployments"
);
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
_executeSharedDeployment();
}
// Implementation of abstract functions from DeployBase
function _getNetworkName() internal view override returns (string memory) {
return networkName;
}
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
function _getDeploymentMode() internal view override returns (string memory) {
return string.concat("LIVE_", networkName);
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
}
function _setupEigenLayerContracts(
EigenLayerConfig memory config
) internal override returns (ProxyAdmin) {
Logging.logHeader("REFERENCING EXISTING EIGENLAYER CONTRACTS");
Logging.logSection(
string.concat("Referencing Existing EigenLayer Contracts on ", _getDeploymentMode())
);
// Reference existing EigenLayer contracts using addresses from config
delegation = DelegationManager(config.delegationManager);
strategyManager = StrategyManager(config.strategyManager);
avsDirectory = AVSDirectory(config.avsDirectory);
rewardsCoordinator = RewardsCoordinator(config.rewardsCoordinator);
allocationManager = AllocationManager(config.allocationManager);
permissionController = PermissionController(config.permissionController);
// Validate that contracts exist at the specified addresses
_validateContractExists(address(delegation), "DelegationManager");
_validateContractExists(address(strategyManager), "StrategyManager");
_validateContractExists(address(avsDirectory), "AVSDirectory");
_validateContractExists(address(rewardsCoordinator), "RewardsCoordinator");
_validateContractExists(address(allocationManager), "AllocationManager");
_validateContractExists(address(permissionController), "PermissionController");
Logging.logContractDeployed("DelegationManager (existing)", address(delegation));
Logging.logContractDeployed("StrategyManager (existing)", address(strategyManager));
Logging.logContractDeployed("AVSDirectory (existing)", address(avsDirectory));
Logging.logContractDeployed("RewardsCoordinator (existing)", address(rewardsCoordinator));
Logging.logContractDeployed("AllocationManager (existing)", address(allocationManager));
Logging.logContractDeployed(
"PermissionController (existing)", address(permissionController)
);
Logging.logStep("All EigenLayer contracts referenced successfully");
Logging.logFooter();
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
// Live deployments create their own ProxyAdmin (no existing one from EigenLayer deployment)
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
return ProxyAdmin(address(0)); // Will be created in _createServiceManagerProxy
}
function _createServiceManagerProxy(
DataHavenServiceManager implementation,
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
ProxyAdmin, // Ignored for live deployment
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
ServiceManagerInitParams memory params
) internal override returns (DataHavenServiceManager) {
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
// Live deployment creates its own ProxyAdmin for the service manager
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
vm.broadcast(_deployerPrivateKey);
ProxyAdmin proxyAdmin = new ProxyAdmin();
Logging.logContractDeployed("ProxyAdmin", address(proxyAdmin));
vm.broadcast(_deployerPrivateKey);
bytes memory initData = abi.encodeWithSelector(
refactor(contracts): Harden DataHavenServiceManager with input validation and code cleanup (#395) ## Summary - Add zero address validation across all functions that accept address parameters to prevent misconfiguration - Fix race condition in `buildNewValidatorSetMessage()` that could cause reverts during validator deregistration - Refactor contract for improved readability and reduced code duplication - Update AVS metadata URL to point to the correct hosted JSON file ## Changes ### Security & Validation - Add `ZeroAddress` error and validate all address inputs in `initialize`, `setRewardsInitiator`, `setSnowbridgeGateway`, `addValidatorToAllowlist`, `registerOperator`, and `updateSolochainAddressForValidator` - Fix race condition: filter out zero solochain addresses in `buildNewValidatorSetMessage()` to prevent reverts when a validator is mid-deregistration ### Refactoring - Replace verbose `if/revert` patterns with `require` statements for consistency - Inline single-use internal functions (`_createDataHavenOperatorSets`, `_setRewardsInitiator`) - Consolidate duplicate error types into single `ZeroAddress` error - Rename `initialise` → `initialize` to maintain consistency with the transparent upgradability pattern - Optimize validator set message encoding by removing redundant wrapper function ### Observability - Add `SolochainAddressUpdated` event for tracking validator address changes ### Cleanup - Remove unused remappings from `foundry.toml` - Fix typo in metadata description --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2026-01-20 10:32:32 +00:00
DataHavenServiceManager.initialize.selector,
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
params.avsOwner,
params.rewardsInitiator,
feat: implement weighted top-32 validator selection (#443) ## Overview Implements deterministic weighted-stake-based validator selection in `DataHavenServiceManager`, building on the era-targeting submitter model from PR #433. Previously, `buildNewValidatorSetMessage()` forwarded all registered operators in arbitrary membership order with no stake-based ranking, meaning high-stake operators could be displaced by lower-stake ones when downstream caps applied. This PR fixes that by computing a weighted stake score per operator and selecting the top-32 candidates before bridging the set to DataHaven. Spec: `specs/validator-set-selection/validator-set-selection.md` ## Contract Changes (`DataHavenServiceManager.sol`) **New state:** - `MAX_ACTIVE_VALIDATORS = 32` — cap on the outbound validator set - `mapping(IStrategy => uint96) public strategiesAndMultipliers` — per-strategy weight used in the selection formula **Updated `buildNewValidatorSetMessage()`:** 1. Fetches allocated stake for all operators × strategies from `AllocationManager` 2. Computes `weightedStake(op) = Σ(allocatedStake[op][j] × multiplier[j])` across all strategies 3. Filters operators with no solochain address mapping or zero weighted stake 4. Runs a partial selection sort to pick the top `min(candidateCount, 32)` by descending weighted stake; ties broken by lower operator address (deterministic) 5. Reverts with `EmptyValidatorSet()` if no eligible candidates remain **Admin API changes:** - `addStrategiesToValidatorsSupportedStrategies()` signature changed from `IStrategy[]` to `IRewardsCoordinatorTypes.StrategyAndMultiplier[]` — strategy and multiplier are stored atomically in one call, eliminating the risk of a strategy being registered without a multiplier - New `setStrategiesAndMultipliers(StrategyAndMultiplier[])` — updates multiplier weights for existing strategies without touching the EigenLayer strategy set - New `getStrategiesAndMultipliers()` — returns all strategies with their current multipliers - `removeStrategiesFromValidatorsSupportedStrategies()` now cleans up multiplier entries on removal **New error / event:** - `EmptyValidatorSet()` — reverts when no eligible candidates exist - `StrategiesAndMultipliersSet(StrategyAndMultiplier[])` — emitted on add or update of multipliers ## Tests (`ValidatorSetSelection.t.sol`) New 552-line Foundry test suite covering all cases from the spec: | Case | |------| | `addStrategies` stores multiplier atomically | | `removeStrategies` deletes multiplier | | `setStrategiesAndMultipliers` updates without touching the strategy set | | `getStrategiesAndMultipliers` returns correct pairs | | Weighted stake computed correctly across multiple strategies | | Operators with zero weighted stake are excluded | | Unset multiplier treated as 0 | | Top-32 selection when candidate count > 32 | | All candidates included when count < 32 | | Tie-breaking by lower operator address | | `EmptyValidatorSet` revert when no eligible operators | ## Deploy Scripts - **`DeployBase.s.sol`**: Sets a default multiplier of `1` for all configured validator strategies after AVS registration via `setStrategiesAndMultipliers` - **New `AllocateOperatorStake.s.sol`**: Forge script that allocates full magnitude (`1e18`) to the validator operator set for a given operator. Must be run at least one block after `SignUpValidator` to respect EigenLayer's allocation configuration delay. ## E2E Framework - **`validators.ts` — `registerOperator()`**: Extended to deposit tokens into each deployed strategy and allocate full magnitude to the DataHaven operator set after registration. Previously operators registered without staking, producing zero weighted stake and getting filtered out by the new selection logic. - **`setup-validators.ts`**: Added a stake allocation pass after the registration loop, invoking `AllocateOperatorStake.s.sol` per validator. - **`validator-set-update.test.ts`**: Added debug logging for transaction receipts and the `OutboundMessageAccepted` / `ExternalValidatorsSet` events. - **`generated.ts`**: Regenerated contract bindings to include new functions, events, and the `EmptyValidatorSet` error. ## ⚠️ Breaking Changes ⚠️ - `addStrategiesToValidatorsSupportedStrategies(IStrategy[])` → `addStrategiesToValidatorsSupportedStrategies(StrategyAndMultiplier[])`: callers must supply multipliers alongside strategies. - Operators with zero weighted stake are no longer included in the bridged validator set. ## Rollout Notes 1. PR #433 (era-targeting + submitter role) must be deployed first 2. Deploy this `ServiceManager` upgrade 3. Confirm `strategiesAndMultipliers` is set for all active strategies (default multiplier `1` applied automatically by `DeployBase`) 4. Deploy the runtime cap-enforcement changes (spec section 10.2) 5. Submitter daemon requires no changes — continues submitting `targetEra = ActiveEra + 1`
2026-02-24 08:23:57 +00:00
params.validatorsStrategiesAndMultipliers,
feat: automated validator set submission with era targeting (#433) ## Era-targeted validator set submission with dedicated submitter role > **Note:** This PR includes a detailed specification at [`specs/validator-set-submission/validator-set-submission.md`](https://github.com/datahaven-xyz/datahaven/blob/feat/validator-set-submitter/specs/validator-set-submission/validator-set-submission.md) that covers the design rationale, submission lifecycle, era-targeting rules, and failure modes. Reading the spec first will make the contract, pallet, and daemon changes easier to follow. ### Summary - Introduce a dedicated `validatorSetSubmitter` role on `DataHavenServiceManager`, separating validator set submission authority from the contract owner - Replace the unscoped `sendNewValidatorSet` with `sendNewValidatorSetForEra`, which encodes a `targetEra` into the Snowbridge message payload - Add server-side era validation in the `external-validators` pallet to reject stale, duplicate, or out-of-range submissions - Add a long-running TypeScript daemon that watches session changes and automatically submits each era's validator set at the right time ### Contract changes (`contracts/`) - **New `validatorSetSubmitter` storage slot** — set during `initialize` and rotatable via `setValidatorSetSubmitter` (owner-only). The storage gap is decremented accordingly. - **`sendNewValidatorSet` → `sendNewValidatorSetForEra`** — accepts a `uint64 targetEra` parameter and is restricted to `onlyValidatorSetSubmitter` instead of `onlyOwner`. - **`buildNewValidatorSetMessageForEra`** — the `NewValidatorSetPayload.externalIndex` is now caller-supplied instead of hardcoded to `0`. - **New events** — `ValidatorSetSubmitterUpdated`, `ValidatorSetMessageSubmitted`. - **New error** — `OnlyValidatorSetSubmitter`. - **New test suite** — `ValidatorSetSubmitter.t.sol` covering submitter set/rotate, access control, era encoding, and legacy function removal. ### Pallet changes (`operator/`) - **`validate_target_era`** in `external-validators` — enforces `activeEra < targetEra <= activeEra + 1` and `targetEra > ExternalIndex` (dedup guard). - **New errors** — `TargetEraTooOld`, `TargetEraTooNew`, `DuplicateOrStaleTargetEra`. - **Tests** — five new test cases for era boundary conditions (next-era acceptance, old-era rejection, too-new rejection, duplicate rejection, genesis behavior). Existing `era_hooks_with_external_index` test updated to use valid target eras. - **Runtime test fixes** — `external_index: 0` → `1` in mainnet/stagenet/testnet EigenLayer message processor tests to satisfy the new validation. ### Validator set submitter daemon (`test/tools/validator-set-submitter/`) - Event-driven service that subscribes to finalized `Session.CurrentIndex` via Polkadot-API `watchValue`. - Submits once per era during the last session, targeting `ActiveEra + 1`. - Tracks submitted eras to avoid duplicates; skips if `ExternalIndex` already covers the target. - Startup self-checks: Ethereum connectivity, DataHaven connectivity, on-chain submitter authorization. - Supports `--dry-run` mode and YAML configuration. - Graceful shutdown on `SIGINT`/`SIGTERM`. ### Test & tooling updates - **E2E test** (`validator-set-update.test.ts`) — calls `sendNewValidatorSetForEra` with a computed `targetEra` and filters the substrate event by `external_index`. - **`update-validator-set.ts` script** — accepts `--target-era` flag; defaults to era 1 for fresh networks. - **CLI launch** — wires validator set update as an interactive step after relayer launch. - **`package.json`** — new `submitter` and `submitter:dry-run` scripts. - Regenerated contract bindings, PAPI metadata, state-diff, and storage layout snapshots. ### Test plan - [x] `forge test` — passes, including new `ValidatorSetSubmitter.t.sol` - [x] `cargo test` — passes, including new era-validation tests in `external-validators` - [x] `bun test:e2e` — validator-set-update suite passes with era-targeted flow - [x] Manual: run submitter daemon against local network (`bun submitter`), verify it submits once per era at the correct session ## ⚠️ Breaking Changes ⚠️ - **`sendNewValidatorSet` removed** — replaced by `sendNewValidatorSetForEra(uint64 targetEra, ...)`. Callers must now supply a `targetEra` parameter. - **Access control changed** — validator set submission is now restricted to the `validatorSetSubmitter` role instead of the contract `owner`. The submitter address is set during `initialize` and rotatable via `setValidatorSetSubmitter` (owner-only). - **`external-validators` pallet now validates `targetEra`** — messages with a stale, duplicate, or out-of-range `external_index` are rejected on-chain. Existing integrations sending `external_index: 0` will fail validation. --------- Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-20 09:31:44 +00:00
params.gateway,
params.validatorSetSubmitter
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
);
TransparentUpgradeableProxy proxy =
new TransparentUpgradeableProxy(address(implementation), address(proxyAdmin), initData);
return DataHavenServiceManager(address(proxy));
}
function _outputDeployedAddresses(
BeefyClient beefyClient,
AgentExecutor agentExecutor,
IGatewayV2 gateway,
DataHavenServiceManager serviceManager,
DataHavenServiceManager serviceManagerImplementation,
address rewardsAgent
) internal override {
Logging.logHeader("DEPLOYMENT SUMMARY");
Logging.logSection("Snowbridge Contracts + Rewards Agent");
Logging.logContractDeployed("BeefyClient", address(beefyClient));
Logging.logContractDeployed("AgentExecutor", address(agentExecutor));
Logging.logContractDeployed("Gateway", address(gateway));
Logging.logContractDeployed("RewardsAgent", rewardsAgent);
Logging.logSection("DataHaven Contracts");
Logging.logContractDeployed("ServiceManager", address(serviceManager));
Logging.logSection(
string.concat("EigenLayer Core Contracts (Existing on ", _getDeploymentMode(), ")")
);
Logging.logContractDeployed("DelegationManager", address(delegation));
Logging.logContractDeployed("StrategyManager", address(strategyManager));
Logging.logContractDeployed("AVSDirectory", address(avsDirectory));
Logging.logContractDeployed("RewardsCoordinator", address(rewardsCoordinator));
Logging.logContractDeployed("AllocationManager", address(allocationManager));
Logging.logContractDeployed("PermissionController", address(permissionController));
Logging.logFooter();
// Write to deployment file for future reference
string memory network = _getNetworkName();
string memory deploymentPath =
string.concat(vm.projectRoot(), "/deployments/", network, ".json");
// Create directory if it doesn't exist
vm.createDir(string.concat(vm.projectRoot(), "/deployments"), true);
// Create JSON with deployed addresses
string memory json = "{";
json = string.concat(json, '"network": "', network, '",');
// Snowbridge contracts
json = string.concat(json, '"BeefyClient": "', vm.toString(address(beefyClient)), '",');
json = string.concat(json, '"AgentExecutor": "', vm.toString(address(agentExecutor)), '",');
json = string.concat(json, '"Gateway": "', vm.toString(address(gateway)), '",');
json =
string.concat(json, '"ServiceManager": "', vm.toString(address(serviceManager)), '",');
json = string.concat(
json,
'"ServiceManagerImplementation": "',
vm.toString(address(serviceManagerImplementation)),
'",'
);
json = string.concat(json, '"RewardsAgent": "', vm.toString(rewardsAgent), '",');
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
// EigenLayer contracts (existing on live network)
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
json = string.concat(json, '"DelegationManager": "', vm.toString(address(delegation)), '",');
fix: Resolve Foundry build errors and apply code formatting (#241) ## Summary Fixes the CI build failure in the `task-ts-build` workflow caused by Foundry v1.4.2's Solar linter not being able to resolve Snowbridge's context-specific import remappings. ## Problem The Snowbridge submodule uses context-specific remappings (prefixed with `:`) for its dependencies: - `lib/snowbridge/contracts/:openzeppelin/` → OpenZeppelin contracts - `lib/snowbridge/contracts/:prb/math/` → PRB Math library Foundry v1.4.2's Solar linter doesn't understand these context-specific remappings and fails with errors like: ``` error: file openzeppelin/utils/cryptography/MerkleProof.sol not found error: file prb/math/src/UD60x18.sol not found ``` ## Solution Added global remappings that the linter can understand: ```toml "openzeppelin/=lib/snowbridge/contracts/lib/openzeppelin-contracts/contracts/", "prb/math/=lib/snowbridge/contracts/lib/prb-math/", ``` ### Why This Works - The linter can now resolve `openzeppelin/` and `prb/math/` imports globally - These global remappings take **lower precedence** than context-specific ones during compilation - The compiler still uses the context-specific remappings (with `:`) when compiling Snowbridge contracts - The linter uses the global remappings when checking all files ## Changes ### Commit 1: Add global remappings - `contracts/foundry.toml`: Added 2 global remapping entries ### Commit 2: Apply forge fmt - Applied automatic formatting via `forge fmt` to ensure code style consistency - Multi-line formatting for long import statements and function signatures - No functional changes - purely formatting updates ## Testing ✅ Local build succeeds with `forge build` ✅ No Snowbridge import resolution errors ✅ `forge fmt --check` passes with no formatting issues ✅ Only linting notes/warnings remain (not errors) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude <noreply@anthropic.com>
2025-10-20 08:20:59 +00:00
json = string.concat(
json, '"StrategyManager": "', vm.toString(address(strategyManager)), '",'
);
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
json = string.concat(json, '"AVSDirectory": "', vm.toString(address(avsDirectory)), '",');
json = string.concat(
json, '"RewardsCoordinator": "', vm.toString(address(rewardsCoordinator)), '",'
);
json = string.concat(
json, '"AllocationManager": "', vm.toString(address(allocationManager)), '",'
);
json = string.concat(
json, '"PermissionController": "', vm.toString(address(permissionController)), '"'
);
json = string.concat(json, "}");
// Write to file
vm.writeFile(deploymentPath, json);
Logging.logInfo(string.concat("Deployment info saved to: ", deploymentPath));
}
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
// LIVE DEPLOYMENT FUNCTIONS
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
/**
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
* @notice Validate that the network is in the supported allowlist
* @dev Supported networks:
* - "hoodi", "stagenet-hoodi", "testnet-hoodi" (Hoodi testnet)
* - "ethereum", "mainnet-ethereum" (Ethereum mainnet)
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
*/
function _validateNetwork(
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
string memory network
) internal pure {
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
bytes32 h = keccak256(bytes(network));
if (
h == keccak256("hoodi") || h == keccak256("stagenet-hoodi")
|| h == keccak256("testnet-hoodi") || h == keccak256("mainnet-ethereum")
|| h == keccak256("ethereum")
) {
return;
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
}
feat: Add DH-AVS stagenet/testnet Hoodi deployment support (#422) ## Summary - Add multi-environment deployment support (stagenet, testnet, mainnet) to CLI and contracts - Configure stagenet and testnet runtimes with correct genesis hashes and Snowbridge Agent IDs - Add CLI commands for BEEFY checkpoint updates and rewards origin computation - Add ETH validator strategies (native beacon chain ETH + LSTs) to all config files ## Changes ### Runtime Configuration **Stagenet Runtime:** - Set `StagenetGenesisHash` to DataHaven stagenet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation **Testnet Runtime:** - Set `TestnetGenesisHash` to DataHaven testnet genesis hash - Configure `RewardsAgentOrigin` with computed Snowbridge Agent ID - Add tests verifying rewards account derivation and agent ID computation The Rewards Agent ID is computed following Snowbridge's location description pattern: ``` blake2_256(SCALE_ENCODE("GlobalConsensus", ByGenesis(genesis), "AccountKey20", rewards_account)) ``` ### CLI Enhancements - All contracts subcommands (`status`, `deploy`, `verify`, `update-metadata`) now accept `--environment` option - Config and deployment files use environment-prefixed naming (e.g., `stagenet-hoodi.json`, `testnet-hoodi.json`) - New `update-beefy-checkpoint` command that: - Connects to a live DataHaven chain via WebSocket RPC - Fetches all BEEFY data at the same finalized block for consistency - Uses parallel queries with `Promise.all` for better performance - Computes authority hashes (keccak256 of Ethereum addresses derived from BEEFY public keys) - Uses Snowbridge's quorum formula `n - floor((n-1)/3)` for strictly > 2/3 majority - New `update-rewards-origin` command that computes the Snowbridge Agent ID for the rewards pallet - Centralized validation via `contractsPreActionHook` for all contract commands - Environment validation against allowlist (`stagenet`, `testnet`, `mainnet`) ### Contract Changes - Network validation uses explicit allowlist instead of suffix matching - Added `initialValidatorSetId` and `nextValidatorSetId` fields to `SnowbridgeConfig` struct - `DeployBase.s.sol` now uses config values for validator set IDs instead of hardcoded 0/1 - `DeployParams.s.sol` loads validator set IDs from config with backwards compatibility ### Validator Strategies Added ETH-equivalent strategies to allow validators to stake using native ETH or LSTs: **All Networks:** - `0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0` - Native beacon chain ETH (virtual strategy) **Hoodi Testnet:** - `0xf8a1a66130d614c7360e868576d5e59203475fe0` - stETH - `0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d` - WETH **Ethereum Mainnet:** - `0x93c4b944D05dfe6df7645A86cd2206016c51564D` - stETH - `0x1BeE69b7dFFfA4E2d53C2a2Df135C388AD25dCD2` - rETH - `0x54945180dB7943c0ed0FEE7EdaB2Bd24620256bc` - cbETH ### Config Files - `stagenet-hoodi.json` - Hoodi testnet with stagenet EigenLayer addresses - `testnet-hoodi.json` - Hoodi testnet with testnet EigenLayer addresses - `mainnet-ethereum.json` - Ethereum mainnet with mainnet EigenLayer addresses - Removed `hoodi.json` (replaced by environment-prefixed files) ## Usage ```bash # Deploy to stagenet on Hoodi bun cli contracts deploy --chain hoodi --environment stagenet # Update BEEFY checkpoint from live chain bun cli contracts update-beefy-checkpoint \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Compute rewards origin for a chain bun cli contracts update-rewards-origin \ --chain hoodi \ --environment stagenet \ --rpc-url wss://services.datahaven-dev.network/stagenet # Check deployment status bun cli contracts status --chain hoodi --environment stagenet ``` --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 15:41:15 +00:00
revert(
string.concat(
"Unsupported network: ",
network,
". Supported: hoodi, stagenet-hoodi, testnet-hoodi, ethereum, mainnet-ethereum"
)
);
feat: ✨ Datahaven contracts deployment on public testnet (#123) ## Summary This PR introduces support for deploying Datahaven contracts to different chains (hoodi, holesky, mainnet), as well as a new cli command to manage this deployment separately from the regular deployment, while maintaining compatibility with it. #### New CLI command - **`bun cli contracts deploy`** - Deploy contracts to supported chains (Hoodi, Holesky, Mainnet) - **`bun cli contracts status`** - Check deployment configuration and status - **`bun cli contracts verify`** - Verify contracts on block explorers - Commands need the chain parameter: `--chain <hoodi | holesky | mainnet>` - Right now only `hoodi` and `holesky` are supported ### Deployment #### Hoodi & Holesky Network Support - Added **DeployBase.s.sol** as common ground for **DeployTestnet.s.sol** (also new) and **DeployLocal.s.sol** (existing). - **Hoodi configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. - **Holesky configuration** (`contracts/config/hoodi.json`) with deployed EigenLayer contract addresses to reference. #### Contracts being deployed - **DataHaven**: ServiceManager, VetoableSlasher, RewardsRegistry - **Snowbridge**: BeefyClient, AgentExecutor, Gateway, RewardsAgent - **EigenLayer**: References existing deployed contracts (not re-deployed) #### Deployment files When the deployment is done, a new file under `contracts/deployments` is generated with the addresses of the deployed contracts, for each chain (it will be overriden per chain if run multiple times). So we would have one `anvil.json`, `hoodi.json`, `holesky.json`, etc, with the addresses of the deployed contracts for reference and for later verification. #### Todo - [x] Test compatibility with existing `bun cli launch` and `bun cli deploy` commands #### For follow-up PRs - Fix verification issue with `foundry verify-contracts` when specifying the `chain` or `chain-id` parameter, needed for hoodi (https://github.com/foundry-rs/foundry/issues/7466). - Add `redeploy` feature to only override implementation contract and leave the proxy address untouched ## Usage Examples ```bash # Deploy to Hoodi network bun cli contracts deploy --chain hoodi # Check deployment status bun cli contracts status --chain hoodi # Verify contracts on block explorer bun cli contracts verify --chain hoodi ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added deployment and configuration support for new networks "hoodi" and "holesky", including new configuration and deployment files. * Introduced a CLI tool for managing contract deployments, status checks, and verification across supported chains. * Added example environment configuration and comprehensive deployment documentation. * Enabled contract verification and status reporting via the CLI with support for block explorer integration. * **Improvements** * Refactored deployment scripts for modularity, supporting both local and testnet environments. * Centralized and extended configuration loading to support additional contract addresses and network parameters. * Enhanced deployment utilities and typings to support multi-network deployments. * **Bug Fixes** * Improved input validation and error handling in CLI commands and deployment scripts. * Added explicit handling for zero address in operator strategy retrieval. * **Chores** * Updated documentation and configuration templates for easier onboarding and deployment management. * Improved logging and output formatting for deployment and verification processes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-08-21 10:02:31 +00:00
}
/**
* @notice Validate that a contract exists at the given address
*/
function _validateContractExists(
address contractAddress,
string memory contractName
) internal view {
require(
contractAddress != address(0), string.concat(contractName, " address cannot be zero")
);
uint256 codeSize;
assembly {
codeSize := extcodesize(contractAddress)
}
require(
codeSize > 0,
string.concat(
"No contract found at ", contractName, " address: ", vm.toString(contractAddress)
)
);
}
}