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

297 lines
12 KiB
Solidity
Raw Permalink Normal View History

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.27;
import {EmptyContract} from "eigenlayer-contracts/src/test/mocks/EmptyContract.sol";
import {Config} from "./Config.sol";
import {Script} from "forge-std/Script.sol";
Fix: 🏗️ Message encoding / decoding (#113) ## Summary of changes - We decided to remove the topics and nonce from the massage encoding since we don't use them (original commit: https://github.com/Moonsong-Labs/datahaven/commit/ee2a3f2fd432e0f8623a9798730ce697bfc52d34). - Besides, we already have a nonce at the Snowbridge message level https://github.com/Moonsong-Labs/datahaven/blob/f4ab5c2b2e93c775555ab4b8d0b2babaf5bc15b7/operator/primitives/snowbridge/inbound-queue/src/v2/message.rs#L105 - I had to recreate the static test for _encoding_ (happens in [DataHavenSnowbridgeMessages.sol](https://github.com/Moonsong-Labs/datahaven/blob/d12d40634f16eb9642b5b94cbc364b6679339393/contracts/src/libraries/DataHavenSnowbridgeMessages.sol) ) / _decoding_ (happens in [operator/primitives/bridge/src/lib.rs)](https://github.com/Moonsong-Labs/datahaven/blob/f9f9cc65fe33c86ac91f2097adbcb945b1746277/operator/primitives/bridge/src/lib.rs). Now it matches the current structure. The idea is that now we can test that we don't break the decoding in followup refactoring. - Fixes a problem with EigenLayer validator addresses. In all our contracts we were using `bytes32` to refer to a Solochain validator address. But on our Substrate change we actually expect AccountId20, so only 20 bytes. This was causing the decoding to fail. - I opted for the minimal change that would be to take the right-most 20 bytes to send that to our chain. But we might want aswell to limit our EigenLayer contracts to be only 20 bytes long. @ahmadkaouk showcase this [here](https://github.com/Moonsong-Labs/datahaven/commit/92a34c273ca439341bd8b61ff3592cef45ba4727) - Adds a bash script to run the static test. The test will compile the contracts, run the encoding test, compile the operator, and run the decoding test. This saves a huge amount of time since we don't need to run the full e2e setup. The way of running it is the following: ```bash cd operator/test/scripts ./test_message_encoding.sh ``` - As a consequence of this PR, the execution relayer now works properly. EDIT: > [!IMPORTANT] **We decided to use 20-byte addresses in our contracts**. So what is stated above is not valid anymore. The change implies that the mapping from Ethereum addresses to bytes32 addresses now it's a mapping as follows: https://github.com/Moonsong-Labs/datahaven/blob/dd3ba99ac0553a33448dc77efbbea08cacd278e6/contracts/src/DataHavenServiceManager.sol#L51-L52 I've updated helper functions, tests, etc to be compliant with this change. The execution relayer and beefy relayer look stable now. --------- Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-07-16 07:38:58 +00:00
import {TestUtils} from "../../test/utils/TestUtils.sol";
import {SafeCast} from "@openzeppelin/contracts/utils/math/SafeCast.sol";
contract DeployParams is Script, Config {
using SafeCast for uint256;
function getSnowbridgeConfig() public view returns (SnowbridgeConfig memory) {
SnowbridgeConfig memory config;
string memory configPath = string.concat(
vm.projectRoot(), "/config/", vm.envOr("NETWORK", string("anvil")), ".json"
);
string memory configJson = vm.readFile(configPath);
config.randaoCommitDelay = vm.parseJsonUint(configJson, ".snowbridge.randaoCommitDelay");
config.randaoCommitExpiration =
vm.parseJsonUint(configJson, ".snowbridge.randaoCommitExpiration");
config.minNumRequiredSignatures =
vm.parseJsonUint(configJson, ".snowbridge.minNumRequiredSignatures");
config.startBlock = vm.parseJsonUint(configJson, ".snowbridge.startBlock").toUint64();
config.messageOrigin = vm.parseJsonBytes32(configJson, ".snowbridge.messageOrigin");
// Load validators from file or generate placeholder ones in dev mode
bool isDevMode = keccak256(abi.encodePacked(vm.envOr("DEV_MODE", string("false"))))
== keccak256(abi.encodePacked("true"));
if (isDevMode) {
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
config.initialValidatorSetId = 0;
Fix: 🏗️ Message encoding / decoding (#113) ## Summary of changes - We decided to remove the topics and nonce from the massage encoding since we don't use them (original commit: https://github.com/Moonsong-Labs/datahaven/commit/ee2a3f2fd432e0f8623a9798730ce697bfc52d34). - Besides, we already have a nonce at the Snowbridge message level https://github.com/Moonsong-Labs/datahaven/blob/f4ab5c2b2e93c775555ab4b8d0b2babaf5bc15b7/operator/primitives/snowbridge/inbound-queue/src/v2/message.rs#L105 - I had to recreate the static test for _encoding_ (happens in [DataHavenSnowbridgeMessages.sol](https://github.com/Moonsong-Labs/datahaven/blob/d12d40634f16eb9642b5b94cbc364b6679339393/contracts/src/libraries/DataHavenSnowbridgeMessages.sol) ) / _decoding_ (happens in [operator/primitives/bridge/src/lib.rs)](https://github.com/Moonsong-Labs/datahaven/blob/f9f9cc65fe33c86ac91f2097adbcb945b1746277/operator/primitives/bridge/src/lib.rs). Now it matches the current structure. The idea is that now we can test that we don't break the decoding in followup refactoring. - Fixes a problem with EigenLayer validator addresses. In all our contracts we were using `bytes32` to refer to a Solochain validator address. But on our Substrate change we actually expect AccountId20, so only 20 bytes. This was causing the decoding to fail. - I opted for the minimal change that would be to take the right-most 20 bytes to send that to our chain. But we might want aswell to limit our EigenLayer contracts to be only 20 bytes long. @ahmadkaouk showcase this [here](https://github.com/Moonsong-Labs/datahaven/commit/92a34c273ca439341bd8b61ff3592cef45ba4727) - Adds a bash script to run the static test. The test will compile the contracts, run the encoding test, compile the operator, and run the decoding test. This saves a huge amount of time since we don't need to run the full e2e setup. The way of running it is the following: ```bash cd operator/test/scripts ./test_message_encoding.sh ``` - As a consequence of this PR, the execution relayer now works properly. EDIT: > [!IMPORTANT] **We decided to use 20-byte addresses in our contracts**. So what is stated above is not valid anymore. The change implies that the mapping from Ethereum addresses to bytes32 addresses now it's a mapping as follows: https://github.com/Moonsong-Labs/datahaven/blob/dd3ba99ac0553a33448dc77efbbea08cacd278e6/contracts/src/DataHavenServiceManager.sol#L51-L52 I've updated helper functions, tests, etc to be compliant with this change. The execution relayer and beefy relayer look stable now. --------- Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-07-16 07:38:58 +00:00
config.initialValidatorHashes = TestUtils.generateMockValidators(10);
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
config.nextValidatorSetId = 1;
Fix: 🏗️ Message encoding / decoding (#113) ## Summary of changes - We decided to remove the topics and nonce from the massage encoding since we don't use them (original commit: https://github.com/Moonsong-Labs/datahaven/commit/ee2a3f2fd432e0f8623a9798730ce697bfc52d34). - Besides, we already have a nonce at the Snowbridge message level https://github.com/Moonsong-Labs/datahaven/blob/f4ab5c2b2e93c775555ab4b8d0b2babaf5bc15b7/operator/primitives/snowbridge/inbound-queue/src/v2/message.rs#L105 - I had to recreate the static test for _encoding_ (happens in [DataHavenSnowbridgeMessages.sol](https://github.com/Moonsong-Labs/datahaven/blob/d12d40634f16eb9642b5b94cbc364b6679339393/contracts/src/libraries/DataHavenSnowbridgeMessages.sol) ) / _decoding_ (happens in [operator/primitives/bridge/src/lib.rs)](https://github.com/Moonsong-Labs/datahaven/blob/f9f9cc65fe33c86ac91f2097adbcb945b1746277/operator/primitives/bridge/src/lib.rs). Now it matches the current structure. The idea is that now we can test that we don't break the decoding in followup refactoring. - Fixes a problem with EigenLayer validator addresses. In all our contracts we were using `bytes32` to refer to a Solochain validator address. But on our Substrate change we actually expect AccountId20, so only 20 bytes. This was causing the decoding to fail. - I opted for the minimal change that would be to take the right-most 20 bytes to send that to our chain. But we might want aswell to limit our EigenLayer contracts to be only 20 bytes long. @ahmadkaouk showcase this [here](https://github.com/Moonsong-Labs/datahaven/commit/92a34c273ca439341bd8b61ff3592cef45ba4727) - Adds a bash script to run the static test. The test will compile the contracts, run the encoding test, compile the operator, and run the decoding test. This saves a huge amount of time since we don't need to run the full e2e setup. The way of running it is the following: ```bash cd operator/test/scripts ./test_message_encoding.sh ``` - As a consequence of this PR, the execution relayer now works properly. EDIT: > [!IMPORTANT] **We decided to use 20-byte addresses in our contracts**. So what is stated above is not valid anymore. The change implies that the mapping from Ethereum addresses to bytes32 addresses now it's a mapping as follows: https://github.com/Moonsong-Labs/datahaven/blob/dd3ba99ac0553a33448dc77efbbea08cacd278e6/contracts/src/DataHavenServiceManager.sol#L51-L52 I've updated helper functions, tests, etc to be compliant with this change. The execution relayer and beefy relayer look stable now. --------- Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-07-16 07:38:58 +00:00
config.nextValidatorHashes = TestUtils.generateMockValidators(10);
} else {
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
// Load validator set IDs (default to 0/1 for backwards compatibility)
try vm.parseJsonUint(configJson, ".snowbridge.initialValidatorSetId") returns (
uint256 val
) {
config.initialValidatorSetId = uint128(val);
} catch {
config.initialValidatorSetId = 0;
}
try vm.parseJsonUint(configJson, ".snowbridge.nextValidatorSetId") returns (
uint256 val
) {
config.nextValidatorSetId = uint128(val);
} catch {
config.nextValidatorSetId = config.initialValidatorSetId + 1;
}
Fix: 🏗️ Message encoding / decoding (#113) ## Summary of changes - We decided to remove the topics and nonce from the massage encoding since we don't use them (original commit: https://github.com/Moonsong-Labs/datahaven/commit/ee2a3f2fd432e0f8623a9798730ce697bfc52d34). - Besides, we already have a nonce at the Snowbridge message level https://github.com/Moonsong-Labs/datahaven/blob/f4ab5c2b2e93c775555ab4b8d0b2babaf5bc15b7/operator/primitives/snowbridge/inbound-queue/src/v2/message.rs#L105 - I had to recreate the static test for _encoding_ (happens in [DataHavenSnowbridgeMessages.sol](https://github.com/Moonsong-Labs/datahaven/blob/d12d40634f16eb9642b5b94cbc364b6679339393/contracts/src/libraries/DataHavenSnowbridgeMessages.sol) ) / _decoding_ (happens in [operator/primitives/bridge/src/lib.rs)](https://github.com/Moonsong-Labs/datahaven/blob/f9f9cc65fe33c86ac91f2097adbcb945b1746277/operator/primitives/bridge/src/lib.rs). Now it matches the current structure. The idea is that now we can test that we don't break the decoding in followup refactoring. - Fixes a problem with EigenLayer validator addresses. In all our contracts we were using `bytes32` to refer to a Solochain validator address. But on our Substrate change we actually expect AccountId20, so only 20 bytes. This was causing the decoding to fail. - I opted for the minimal change that would be to take the right-most 20 bytes to send that to our chain. But we might want aswell to limit our EigenLayer contracts to be only 20 bytes long. @ahmadkaouk showcase this [here](https://github.com/Moonsong-Labs/datahaven/commit/92a34c273ca439341bd8b61ff3592cef45ba4727) - Adds a bash script to run the static test. The test will compile the contracts, run the encoding test, compile the operator, and run the decoding test. This saves a huge amount of time since we don't need to run the full e2e setup. The way of running it is the following: ```bash cd operator/test/scripts ./test_message_encoding.sh ``` - As a consequence of this PR, the execution relayer now works properly. EDIT: > [!IMPORTANT] **We decided to use 20-byte addresses in our contracts**. So what is stated above is not valid anymore. The change implies that the mapping from Ethereum addresses to bytes32 addresses now it's a mapping as follows: https://github.com/Moonsong-Labs/datahaven/blob/dd3ba99ac0553a33448dc77efbbea08cacd278e6/contracts/src/DataHavenServiceManager.sol#L51-L52 I've updated helper functions, tests, etc to be compliant with this change. The execution relayer and beefy relayer look stable now. --------- Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com> Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-07-16 07:38:58 +00:00
config.initialValidatorHashes =
_loadValidatorsFromConfig(configJson, ".snowbridge.initialValidatorHashes");
config.nextValidatorHashes =
_loadValidatorsFromConfig(configJson, ".snowbridge.nextValidatorHashes");
}
return config;
}
function getAVSConfig() public view returns (AVSConfig memory) {
AVSConfig memory config;
string memory configPath = string.concat(
vm.projectRoot(), "/config/", vm.envOr("NETWORK", string("anvil")), ".json"
);
string memory configJson = vm.readFile(configPath);
address avsOwnerOverride = vm.envOr("AVS_OWNER_ADDRESS", address(0));
if (avsOwnerOverride != address(0)) {
config.avsOwner = avsOwnerOverride;
} else {
config.avsOwner = vm.parseJsonAddress(configJson, ".avs.avsOwner");
}
config.snowbridgeInitiator = vm.parseJsonAddress(configJson, ".avs.snowbridgeInitiator");
config.validatorsStrategies =
vm.parseJsonAddressArray(configJson, ".avs.validatorsStrategies");
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
try vm.parseJsonAddress(configJson, ".avs.validatorSetSubmitter") returns (address addr) {
config.validatorSetSubmitter = addr;
} catch {
config.validatorSetSubmitter = address(0);
}
return config;
}
function getEigenLayerConfig() public view returns (EigenLayerConfig memory) {
EigenLayerConfig memory config;
string memory configPath = string.concat(
vm.projectRoot(), "/config/", vm.envOr("NETWORK", string("anvil")), ".json"
);
string memory configJson = vm.readFile(configPath);
// Load from JSON config or use environment variables as fallback
config.pauserAddresses = _loadAddressesFromConfig(configJson, ".eigenLayer.pausers");
config.unpauserAddress = vm.parseJsonAddress(configJson, ".eigenLayer.unpauser");
config.rewardsUpdater = vm.parseJsonAddress(configJson, ".eigenLayer.rewardsUpdater");
config.calculationIntervalSeconds =
vm.parseJsonUint(configJson, ".eigenLayer.calculationIntervalSeconds").toUint32();
config.maxRewardsDuration =
vm.parseJsonUint(configJson, ".eigenLayer.maxRewardsDuration").toUint32();
config.maxRetroactiveLength =
vm.parseJsonUint(configJson, ".eigenLayer.maxRetroactiveLength").toUint32();
config.maxFutureLength =
vm.parseJsonUint(configJson, ".eigenLayer.maxFutureLength").toUint32();
config.genesisRewardsTimestamp =
vm.parseJsonUint(configJson, ".eigenLayer.genesisRewardsTimestamp").toUint32();
config.activationDelay =
vm.parseJsonUint(configJson, ".eigenLayer.activationDelay").toUint32();
config.globalCommissionBips =
uint16(vm.parseJsonUint(configJson, ".eigenLayer.globalCommissionBips"));
config.executorMultisig = vm.parseJsonAddress(configJson, ".eigenLayer.executorMultisig");
config.operationsMultisig =
vm.parseJsonAddress(configJson, ".eigenLayer.operationsMultisig");
// Use default values if not specified in config
try vm.parseJsonUint(configJson, ".eigenLayer.minWithdrawalDelayBlocks") returns (
uint256 val
) {
config.minWithdrawalDelayBlocks = val.toUint32();
} catch {
config.minWithdrawalDelayBlocks = 7 days / 12 seconds; // Default: 1 week in blocks at 12s per block
}
try vm.parseJsonUint(configJson, ".eigenLayer.delegationWithdrawalDelayBlocks") returns (
uint256 val
) {
config.delegationWithdrawalDelayBlocks = val.toUint32();
} catch {
config.delegationWithdrawalDelayBlocks = 7 days / 12 seconds; // Default: 1 week
}
try vm.parseJsonUint(configJson, ".eigenLayer.strategyManagerInitPausedStatus") returns (
uint256 val
) {
config.strategyManagerInitPausedStatus = val;
} catch {
config.strategyManagerInitPausedStatus = 0; // Unpause all
}
try vm.parseJsonUint(configJson, ".eigenLayer.delegationInitPausedStatus") returns (
uint256 val
) {
config.delegationInitPausedStatus = val;
} catch {
config.delegationInitPausedStatus = 0; // Unpause all
}
try vm.parseJsonUint(configJson, ".eigenLayer.eigenPodManagerInitPausedStatus") returns (
uint256 val
) {
config.eigenPodManagerInitPausedStatus = val;
} catch {
config.eigenPodManagerInitPausedStatus = 0; // Unpause all
}
try vm.parseJsonUint(configJson, ".eigenLayer.rewardsCoordinatorInitPausedStatus") returns (
uint256 val
) {
config.rewardsCoordinatorInitPausedStatus = val;
} catch {
config.rewardsCoordinatorInitPausedStatus = 0; // Unpause all
}
try vm.parseJsonUint(configJson, ".eigenLayer.allocationManagerInitPausedStatus") returns (
uint256 val
) {
config.allocationManagerInitPausedStatus = val;
} catch {
config.allocationManagerInitPausedStatus = 0; // Unpause all
}
try vm.parseJsonUint(configJson, ".eigenLayer.deallocationDelay") returns (uint256 val) {
config.deallocationDelay = val.toUint32();
} catch {
config.deallocationDelay = 7 days; // Default: 1 week
}
try vm.parseJsonUint(configJson, ".eigenLayer.allocationConfigurationDelay") returns (
uint256 val
) {
config.allocationConfigurationDelay = val.toUint32();
} catch {
config.allocationConfigurationDelay = 1 days; // Default: 1 day
}
try vm.parseJsonUint(configJson, ".eigenLayer.beaconChainGenesisTimestamp") returns (
uint256 val
) {
config.beaconChainGenesisTimestamp = val.toUint64();
} catch {
config.beaconChainGenesisTimestamp = 1616508000; // Mainnet default
}
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
// Load EigenLayer-specific contract addresses (if they exist in config)
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
try vm.parseJsonAddress(configJson, ".eigenLayer.delegationManager") returns (
address addr
) {
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
config.delegationManager = addr;
} catch {
config.delegationManager = address(0);
}
try vm.parseJsonAddress(configJson, ".eigenLayer.strategyManager") returns (address addr) {
config.strategyManager = addr;
} catch {
config.strategyManager = address(0);
}
try vm.parseJsonAddress(configJson, ".eigenLayer.avsDirectory") returns (address addr) {
config.avsDirectory = addr;
} catch {
config.avsDirectory = address(0);
}
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
try vm.parseJsonAddress(configJson, ".eigenLayer.rewardsCoordinator") returns (
address addr
) {
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
config.rewardsCoordinator = addr;
} catch {
config.rewardsCoordinator = address(0);
}
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
try vm.parseJsonAddress(configJson, ".eigenLayer.allocationManager") returns (
address addr
) {
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
config.allocationManager = addr;
} catch {
config.allocationManager = address(0);
}
try vm.parseJsonAddress(configJson, ".eigenLayer.permissionController") returns (
address addr
) {
config.permissionController = addr;
} catch {
config.permissionController = address(0);
}
return config;
}
function getETHPOSDepositAddress() public returns (address) {
string memory configPath = string.concat(
vm.projectRoot(), "/config/", vm.envOr("NETWORK", string("anvil")), ".json"
);
string memory configJson = vm.readFile(configPath);
// On mainnet, use the real ETH2 deposit contract. Otherwise, deploy a mock
if (block.chainid == 1) {
return 0x00000000219ab540356cBB839Cbe05303d7705Fa;
} else {
// For non-mainnet environments, check if there's a configured address or deploy a mock
try vm.parseJsonAddress(configJson, ".eigenLayer.ethPOSDepositAddress") returns (
address addr
) {
if (addr != address(0)) {
return addr;
}
} catch {}
// Deploy a mock ETH deposit contract if not configured
return address(new EmptyContract());
}
}
function _loadValidatorsFromConfig(
string memory configJson,
string memory path
) internal pure returns (bytes32[] memory) {
// Load validators from JSON config
string[] memory validatorsArray = vm.parseJsonStringArray(configJson, path);
bytes32[] memory validators = new bytes32[](validatorsArray.length);
for (uint256 i = 0; i < validatorsArray.length; i++) {
validators[i] = vm.parseBytes32(validatorsArray[i]);
}
return validators;
}
function _loadAddressesFromConfig(
string memory configJson,
string memory path
) internal pure returns (address[] memory) {
// Load addresses from JSON config
string[] memory addressStrings = vm.parseJsonStringArray(configJson, path);
address[] memory addresses = new address[](addressStrings.length);
for (uint256 i = 0; i < addressStrings.length; i++) {
addresses[i] = vm.parseAddress(addressStrings[i]);
}
return addresses;
}
}