2025-04-03 17:06:32 +00:00
|
|
|
// 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";
|
2025-07-16 07:38:58 +00:00
|
|
|
import {TestUtils} from "../../test/utils/TestUtils.sol";
|
2026-01-22 12:48:27 +00:00
|
|
|
import {SafeCast} from "@openzeppelin/contracts/utils/math/SafeCast.sol";
|
2025-04-03 17:06:32 +00:00
|
|
|
|
|
|
|
|
contract DeployParams is Script, Config {
|
2026-01-22 12:48:27 +00:00
|
|
|
using SafeCast for uint256;
|
|
|
|
|
|
2025-04-03 17:06:32 +00:00
|
|
|
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");
|
2026-01-22 12:48:27 +00:00
|
|
|
config.startBlock = vm.parseJsonUint(configJson, ".snowbridge.startBlock").toUint64();
|
2026-03-09 13:33:43 +00:00
|
|
|
config.messageOrigin = vm.parseJsonBytes32(configJson, ".snowbridge.messageOrigin");
|
2025-04-03 17:06:32 +00:00
|
|
|
|
|
|
|
|
// 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;
|
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;
|
2025-07-16 07:38:58 +00:00
|
|
|
config.nextValidatorHashes = TestUtils.generateMockValidators(10);
|
2025-04-03 17:06:32 +00:00
|
|
|
} 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;
|
|
|
|
|
}
|
|
|
|
|
|
2025-07-16 07:38:58 +00:00
|
|
|
config.initialValidatorHashes =
|
|
|
|
|
_loadValidatorsFromConfig(configJson, ".snowbridge.initialValidatorHashes");
|
|
|
|
|
config.nextValidatorHashes =
|
|
|
|
|
_loadValidatorsFromConfig(configJson, ".snowbridge.nextValidatorHashes");
|
2025-04-03 17:06:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
2025-12-10 16:38:21 +00:00
|
|
|
address avsOwnerOverride = vm.envOr("AVS_OWNER_ADDRESS", address(0));
|
|
|
|
|
if (avsOwnerOverride != address(0)) {
|
|
|
|
|
config.avsOwner = avsOwnerOverride;
|
|
|
|
|
} else {
|
|
|
|
|
config.avsOwner = vm.parseJsonAddress(configJson, ".avs.avsOwner");
|
|
|
|
|
}
|
refactor: rename rewardsInitiator to snowbridgeInitiator (#476)
## Summary
Renames the rewardsInitiator state variable, modifier, internal check
function, setRewardsInitiator function, and RewardsInitiatorSet event in
DataHavenServiceManager to their snowbridgeInitiator-prefixed
equivalents, to better reflect the role of this address.
## Motivation
The previous rewardsInitiator naming was misleading — the address
filling this role is specifically the Snowbridge relayer/gateway.
Renaming it end-to-end clarifies intent and aligns the codebase with the
actual architecture.
## Changes
* DataHavenServiceManager.sol: renamed state variable, modifier,
internal check, setRewardsInitiator → -> setSnowbridgeInitiator,
RewardsInitiatorSet -> SnowbridgeInitiatorSet
* IDataHavenServiceManager.sol: updated event, function signature, and
NatSpec
* Deploy scripts & configs: updated field names across all environments
(anvil, testnet, stagenet, mainnet)
2026-03-24 11:41:36 +00:00
|
|
|
config.snowbridgeInitiator = vm.parseJsonAddress(configJson, ".avs.snowbridgeInitiator");
|
2025-04-16 15:49:35 +00:00
|
|
|
config.validatorsStrategies =
|
|
|
|
|
vm.parseJsonAddressArray(configJson, ".avs.validatorsStrategies");
|
2025-04-03 17:06:32 +00:00
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2025-04-03 17:06:32 +00:00
|
|
|
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
|
2025-04-11 23:54:20 +00:00
|
|
|
config.pauserAddresses = _loadAddressesFromConfig(configJson, ".eigenLayer.pausers");
|
2025-04-03 17:06:32 +00:00
|
|
|
config.unpauserAddress = vm.parseJsonAddress(configJson, ".eigenLayer.unpauser");
|
|
|
|
|
config.rewardsUpdater = vm.parseJsonAddress(configJson, ".eigenLayer.rewardsUpdater");
|
|
|
|
|
config.calculationIntervalSeconds =
|
2026-01-22 12:48:27 +00:00
|
|
|
vm.parseJsonUint(configJson, ".eigenLayer.calculationIntervalSeconds").toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
config.maxRewardsDuration =
|
2026-01-22 12:48:27 +00:00
|
|
|
vm.parseJsonUint(configJson, ".eigenLayer.maxRewardsDuration").toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
config.maxRetroactiveLength =
|
2026-01-22 12:48:27 +00:00
|
|
|
vm.parseJsonUint(configJson, ".eigenLayer.maxRetroactiveLength").toUint32();
|
|
|
|
|
config.maxFutureLength =
|
|
|
|
|
vm.parseJsonUint(configJson, ".eigenLayer.maxFutureLength").toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
config.genesisRewardsTimestamp =
|
2026-01-22 12:48:27 +00:00
|
|
|
vm.parseJsonUint(configJson, ".eigenLayer.genesisRewardsTimestamp").toUint32();
|
|
|
|
|
config.activationDelay =
|
|
|
|
|
vm.parseJsonUint(configJson, ".eigenLayer.activationDelay").toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
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
|
|
|
|
|
) {
|
2026-01-22 12:48:27 +00:00
|
|
|
config.minWithdrawalDelayBlocks = val.toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
} 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
|
|
|
|
|
) {
|
2026-01-22 12:48:27 +00:00
|
|
|
config.delegationWithdrawalDelayBlocks = val.toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
} 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) {
|
2026-01-22 12:48:27 +00:00
|
|
|
config.deallocationDelay = val.toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
} catch {
|
|
|
|
|
config.deallocationDelay = 7 days; // Default: 1 week
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
try vm.parseJsonUint(configJson, ".eigenLayer.allocationConfigurationDelay") returns (
|
|
|
|
|
uint256 val
|
|
|
|
|
) {
|
2026-01-22 12:48:27 +00:00
|
|
|
config.allocationConfigurationDelay = val.toUint32();
|
2025-04-03 17:06:32 +00:00
|
|
|
} catch {
|
|
|
|
|
config.allocationConfigurationDelay = 1 days; // Default: 1 day
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
try vm.parseJsonUint(configJson, ".eigenLayer.beaconChainGenesisTimestamp") returns (
|
|
|
|
|
uint256 val
|
|
|
|
|
) {
|
2026-01-22 12:48:27 +00:00
|
|
|
config.beaconChainGenesisTimestamp = val.toUint64();
|
2025-04-03 17:06:32 +00:00
|
|
|
} 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)
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
2025-04-03 17:06:32 +00:00
|
|
|
|
|
|
|
|
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());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-04-11 23:54:20 +00:00
|
|
|
function _loadValidatorsFromConfig(
|
2025-04-03 17:06:32 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2025-04-11 23:54:20 +00:00
|
|
|
function _loadAddressesFromConfig(
|
2025-04-03 17:06:32 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|