2025-03-17 16:57:14 +00:00
|
|
|
[package]
|
feat: ✨ Add CI license check (#269)
## Summary
- Adds automated license compliance checking via GitHub Actions CI
workflow
- Implements a license verification script that validates all Rust
dependencies against approved licenses, authors, and packages
- Standardizes author metadata across Cargo manifests to "Moonsong Labs"
## Changes
**CI Workflow** (`.github/workflows/task-check-licenses.yml`)
- Triggers on pull requests and manual dispatch
- Installs Rust 1.88.0 toolchain and `cargo-license` tool
- Executes license verification script to enforce compliance
**License Verification Script** (`operator/scripts/verify-licenses.sh`)
- Uses `cargo-license` to extract dependency license information
- Maintains three allowlists:
- **Licenses**: Apache-2.0, MIT, BSD variants, GPL-3.0, MPL-2.0, and
compatible combinations
- **Authors**: PureStake, Parity Technologies, Moonsong Labs, Frontier
developers, StorageHub Team
- **Package Names**: Known safe packages like ring
- Fails the build if any dependency has unapproved license/author/name
combination
**Cargo Manifest Updates**
- `operator/Cargo.toml`: Standardized workspace author to "Moonsong
Labs"
- `operator/precompiles/precompile-registry/Cargo.toml`: Uses workspace
author field
- `operator/runtime/common/Cargo.toml`: Added workspace author field
## Benefits
- **Legal Compliance**: Ensures all dependencies use OSI-approved or
compatible licenses
- **Supply Chain Security**: Validates dependencies come from trusted
sources
- **Automated Enforcement**: Catches licensing issues during PR review
rather than at release time
- **Transparency**: Provides clear audit trail of approved licenses and
authors
2025-11-02 21:32:59 +00:00
|
|
|
authors = { workspace = true }
|
fix: 🩹 update to allow BEEFY relayer to run correctly (#67)
This PR:
- Adds a check to make sure the BEEFY RPC endpoint is ready before
spinning up the BEEFY relayer, otherwise it would just fail and crash.
- Adds the `--enable-offchain-indexing=true` flag to the Datahaven nodes
run when starting up the E2E infra. This is needed because otherwise
nodes can't be queried by the relayer to generate the required proofs
since they would not store the MMR leafs/nodes/root, so the relayer
would just crash.
- Updates the way we were generating the merkle root of the validator
set.
- The BEEFY pallet (and as such, the relayer) generate the validator set
merkle tree by getting the validator list and treating it as an already
ordered set of merkle leafs, hashing each pair in succession without
caring what each leaf value is.
- Meanwhile, the OpenZeppelin crypto library (and as such, the
EigenLayer contracts) also gets the merkle leafs list but hashes each
pair of leafs in value order.
- This means that, for example, if the list of leafs is: ["0x124",
"0x123"]
- BEEFY would do `hash("0x124123")` to get the value of the parent node.
- OZ and EigenLayer would do `hash("0x123124")` to get the value of the
parent node.
- This created a mismatch between what the BEEFY relayer was expecting
and what was actually calculated in our script. A way to obtain a merkle
tree using the BEEFY way was added to solve this.
- Updates the authority set to not be a hardcoded array of keys, now the
BEEFY keys are obtained by directly querying the runtime before
deploying the BEEFY contracts.
- Renames a few files from `flamingo` to `datahaven`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added support for calculating and generating Merkle roots and proofs
without sorting, enabling new use cases for validator set management.
- Introduced dynamic fetching and configuration of Datahaven validator
authorities during network launch.
- Added readiness check for the BEEFY protocol before relayer startup,
improving reliability of relayer operations.
- **Bug Fixes**
- Fixed indentation issues in configuration files for improved
readability and consistency.
- **Chores**
- Updated validator lists and addresses in configuration files.
- Enhanced e2e test scripts and added new commands for relayer and
minimal test scenarios.
- Added new dependency to test package.
- Updated version strings in package metadata.
- **Refactor**
- Improved logging and configuration handling during network and relayer
launches.
- Simplified import statements and removed unused code.
- **Style**
- Reformatted configuration and TypeScript files for better readability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Tim B <79199034+timbrinded@users.noreply.github.com>
Co-authored-by: Facundo Farall <37149322+ffarall@users.noreply.github.com>
2025-05-16 01:56:19 +00:00
|
|
|
description = "Common code used through the DataHaven network"
|
2025-05-08 13:14:30 +00:00
|
|
|
edition = { workspace = true }
|
2025-05-08 23:32:55 +00:00
|
|
|
name = "datahaven-runtime-common"
|
2025-09-29 21:35:12 +00:00
|
|
|
version = { workspace = true }
|
2025-03-17 16:57:14 +00:00
|
|
|
|
|
|
|
|
[dependencies]
|
feat: ✨ Native Token Transfer to Ethereum (#88)
### Summary
- Implement native token transfers from DataHaven to Ethereum using
Snowbridge infrastructure
- Add comprehensive datahaven-native-transfer pallet with lock-and-mint
mechanism for cross-chain token representation
### Key Features
**New Pallet: datahaven-native-transfer**
- Cross-chain transfers: Transfer DataHaven native tokens to Ethereum
addresses via `transfer_to_ethereum extrinsic`
- Token locking mechanism: Secure token storage in deterministic
Ethereum sovereign account during transfers
- Fee management: Required fees for all transfers to compensate relayers
and prevent spam
- Emergency controls: Pause/unpause functionality
- Token registration: Integration with Snowbridge's token registration
for native token identification
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced the DataHaven Native Transfer pallet enabling secure
cross-chain transfers of DataHaven native tokens to and from Ethereum
via Snowbridge.
- Added token locking on DataHaven, minting on Ethereum, and mandatory
fee collection to cover gas costs and incentivize relayers.
- Implemented pause and unpause controls for emergency management of
token transfers.
- **Configuration**
- Integrated the new pallet into mainnet, stagenet, and testnet runtimes
with updated network, account, and treasury settings.
- Added Ethereum sovereign account constants and native token ID support
for optimized cross-chain operations.
- **Documentation**
- Added comprehensive README and inline documentation detailing pallet
features, extrinsics, events, errors, and security considerations.
- **Tests**
- Added extensive unit and integration tests covering token transfers,
native token registration, fee handling, pause functionality, and event
validation across all supported networks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-06-11 22:07:36 +00:00
|
|
|
codec = { workspace = true }
|
2025-09-10 06:15:27 +00:00
|
|
|
fp-account = { workspace = true, features = ["serde"] }
|
2025-05-08 13:14:30 +00:00
|
|
|
frame-support = { workspace = true }
|
2025-06-25 06:09:26 +00:00
|
|
|
frame-system = { workspace = true }
|
fix: change pallet_evm alias to EVM to fix `eth_getCode` (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names
## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
`twox_128("EVM") ++ twox_128("AccountCodes") ++ …`
Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
expectations so the override layers can pull bytecode correctly.
## Testing
- `cargo check -p datahaven-node`
- `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.
**Migration details:**
- **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
- **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)
**Testing the migration:**
```bash
# Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime
# Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
on-runtime-upgrade \
--blocktime 6000 \
--checks all \
--disable-spec-version-check \
live --uri wss://dh-validator-0.datahaven-kt.xyz
```
Test results from stagenet:
- ✅ Migration completes in 1 block
- ✅ PoV size: ~5.3 KB
- ✅ Weight consumption: <0.1% of block capacity
- ✅ All 39 keys successfully migrated
## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
- Old prefix: twox128("Evm") = 0x8b90cb...
- New prefix: twox128("EVM") = 0x6a5e91...
All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
|
|
|
log = { workspace = true }
|
2025-06-25 06:09:26 +00:00
|
|
|
pallet-authorship = { workspace = true }
|
|
|
|
|
pallet-balances = { workspace = true }
|
fix: change pallet_evm alias to EVM to fix `eth_getCode` (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names
## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
`twox_128("EVM") ++ twox_128("AccountCodes") ++ …`
Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
expectations so the override layers can pull bytecode correctly.
## Testing
- `cargo check -p datahaven-node`
- `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.
**Migration details:**
- **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
- **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)
**Testing the migration:**
```bash
# Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime
# Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
on-runtime-upgrade \
--blocktime 6000 \
--checks all \
--disable-spec-version-check \
live --uri wss://dh-validator-0.datahaven-kt.xyz
```
Test results from stagenet:
- ✅ Migration completes in 1 block
- ✅ PoV size: ~5.3 KB
- ✅ Weight consumption: <0.1% of block capacity
- ✅ All 39 keys successfully migrated
## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
- Old prefix: twox128("Evm") = 0x8b90cb...
- New prefix: twox128("EVM") = 0x6a5e91...
All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
|
|
|
pallet-timestamp = { workspace = true }
|
2025-09-12 07:45:26 +00:00
|
|
|
pallet-evm = { workspace = true }
|
|
|
|
|
pallet-evm-precompile-proxy = { workspace = true }
|
2025-09-24 10:27:44 +00:00
|
|
|
pallet-migrations = { workspace = true }
|
feat: Add SafeMode and TxPause Pallets (#192)
### Overview
This PR integrates the `pallet-safe-mode` and `pallet-tx-pause` from
Polkadot SDK to provide comprehensive emergency governance controls
across all DataHaven runtime networks (mainnet, stagenet, testnet).
### Key Changes
#### 🔧 **Core Integration**
- **Dependencies**: Added `pallet-safe-mode` and `pallet-tx-pause` from
`polkadot-stable2412-6`
- **Runtime Integration**: Integrated both pallets across all three
runtime networks with pallet indices 103 and 104
- **Call Filtering**: Implemented unified `RuntimeCallFilter` that
combines Normal, SafeMode, and TxPause restrictions
#### 🛡️ **SafeMode Pallet Configuration**
- **Duration**: 1 day activation period (`DAYS` constant)
- **Deposits**: Disabled permissionless entry/extension (all `None`)
- **Origins**: Root-only for all force operations (`force_enter`,
`force_exit`, `force_extend`, etc.)
- **Whitelisting**: SafeMode and Sudo calls are immune to restrictions
#### ⏸️ **TxPause Pallet Configuration**
- **Origins**: Root-only pause/unpause control
- **Whitelisting**: SafeMode and Sudo calls cannot be paused
- **Max Call Name Length**: 256 characters
#### 🏗️ **Architecture**
- **Shared Types**: Created `operator/runtime/common/src/safe_mode.rs`
with reusable configurations
- **Combined Filtering**: `RuntimeCallFilter` applies all three filter
layers (Normal + SafeMode + TxPause)
- **Consistent Config**: Identical configuration across mainnet,
stagenet, and testnet
#### 📊 **Infrastructure Updates**
- **Benchmarking**: Added both pallets to benchmark suites across all
networks
- **Weight Mappings**: Placeholder weights using Substrate defaults
(ready for chain-specific benchmarking)
- **Metadata**: Updated runtime metadata for new pallet exposure
#### 🧪 **Testing Framework**
- **Coverage**: Tests for individual pallet behavior, combined
restrictions, whitelisting, and edge cases
### Emergency Control Capabilities
**SafeMode Pallet** (8 calls):
- User calls: `enter`, `extend`, `release_deposit`
- Force calls: `force_enter`, `force_exit`, `force_extend`,
`force_slash_deposit`, `force_release_deposit`
**TxPause Pallet** (2 calls):
- `pause_call` / `unpause_call` - Granular transaction type pausing
---------
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-10-06 17:00:10 +00:00
|
|
|
pallet-safe-mode = { workspace = true }
|
|
|
|
|
pallet-tx-pause = { workspace = true }
|
2025-06-25 06:09:26 +00:00
|
|
|
pallet-treasury = { workspace = true }
|
2025-05-08 13:14:30 +00:00
|
|
|
polkadot-primitives = { workspace = true }
|
|
|
|
|
polkadot-runtime-common = { workspace = true }
|
2025-09-12 07:45:26 +00:00
|
|
|
precompile-utils = { workspace = true }
|
feat: ✨ Native Token Transfer to Ethereum (#88)
### Summary
- Implement native token transfers from DataHaven to Ethereum using
Snowbridge infrastructure
- Add comprehensive datahaven-native-transfer pallet with lock-and-mint
mechanism for cross-chain token representation
### Key Features
**New Pallet: datahaven-native-transfer**
- Cross-chain transfers: Transfer DataHaven native tokens to Ethereum
addresses via `transfer_to_ethereum extrinsic`
- Token locking mechanism: Secure token storage in deterministic
Ethereum sovereign account during transfers
- Fee management: Required fees for all transfers to compensate relayers
and prevent spam
- Emergency controls: Pause/unpause functionality
- Token registration: Integration with Snowbridge's token registration
for native token identification
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced the DataHaven Native Transfer pallet enabling secure
cross-chain transfers of DataHaven native tokens to and from Ethereum
via Snowbridge.
- Added token locking on DataHaven, minting on Ethereum, and mandatory
fee collection to cover gas costs and incentivize relayers.
- Implemented pause and unpause controls for emergency management of
token transfers.
- **Configuration**
- Integrated the new pallet into mainnet, stagenet, and testnet runtimes
with updated network, account, and treasury settings.
- Added Ethereum sovereign account constants and native token ID support
for optimized cross-chain operations.
- **Documentation**
- Added comprehensive README and inline documentation detailing pallet
features, extrinsics, events, errors, and security considerations.
- **Tests**
- Added extensive unit and integration tests covering token transfers,
native token registration, fee handling, pause functionality, and event
validation across all supported networks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-06-11 22:07:36 +00:00
|
|
|
scale-info = { workspace = true }
|
2025-05-08 13:14:30 +00:00
|
|
|
sp-core = { workspace = true, features = ["serde"] }
|
fix: change pallet_evm alias to EVM to fix `eth_getCode` (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names
## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
`twox_128("EVM") ++ twox_128("AccountCodes") ++ …`
Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
expectations so the override layers can pull bytecode correctly.
## Testing
- `cargo check -p datahaven-node`
- `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.
**Migration details:**
- **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
- **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)
**Testing the migration:**
```bash
# Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime
# Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
on-runtime-upgrade \
--blocktime 6000 \
--checks all \
--disable-spec-version-check \
live --uri wss://dh-validator-0.datahaven-kt.xyz
```
Test results from stagenet:
- ✅ Migration completes in 1 block
- ✅ PoV size: ~5.3 KB
- ✅ Weight consumption: <0.1% of block capacity
- ✅ All 39 keys successfully migrated
## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
- Old prefix: twox128("Evm") = 0x8b90cb...
- New prefix: twox128("EVM") = 0x6a5e91...
All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
|
|
|
sp-io = { workspace = true }
|
2025-05-08 13:14:30 +00:00
|
|
|
sp-runtime = { workspace = true, features = ["serde"] }
|
2025-06-25 06:09:26 +00:00
|
|
|
sp-std = { workspace = true }
|
2025-04-25 23:28:41 +00:00
|
|
|
xcm = { workspace = true }
|
2025-05-08 13:14:30 +00:00
|
|
|
|
2025-03-17 16:57:14 +00:00
|
|
|
[features]
|
|
|
|
|
default = ["std"]
|
|
|
|
|
std = [
|
feat: ✨ Native Token Transfer to Ethereum (#88)
### Summary
- Implement native token transfers from DataHaven to Ethereum using
Snowbridge infrastructure
- Add comprehensive datahaven-native-transfer pallet with lock-and-mint
mechanism for cross-chain token representation
### Key Features
**New Pallet: datahaven-native-transfer**
- Cross-chain transfers: Transfer DataHaven native tokens to Ethereum
addresses via `transfer_to_ethereum extrinsic`
- Token locking mechanism: Secure token storage in deterministic
Ethereum sovereign account during transfers
- Fee management: Required fees for all transfers to compensate relayers
and prevent spam
- Emergency controls: Pause/unpause functionality
- Token registration: Integration with Snowbridge's token registration
for native token identification
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced the DataHaven Native Transfer pallet enabling secure
cross-chain transfers of DataHaven native tokens to and from Ethereum
via Snowbridge.
- Added token locking on DataHaven, minting on Ethereum, and mandatory
fee collection to cover gas costs and incentivize relayers.
- Implemented pause and unpause controls for emergency management of
token transfers.
- **Configuration**
- Integrated the new pallet into mainnet, stagenet, and testnet runtimes
with updated network, account, and treasury settings.
- Added Ethereum sovereign account constants and native token ID support
for optimized cross-chain operations.
- **Documentation**
- Added comprehensive README and inline documentation detailing pallet
features, extrinsics, events, errors, and security considerations.
- **Tests**
- Added extensive unit and integration tests covering token transfers,
native token registration, fee handling, pause functionality, and event
validation across all supported networks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-06-11 22:07:36 +00:00
|
|
|
"codec/std",
|
2025-03-17 16:57:14 +00:00
|
|
|
"frame-support/std",
|
fix: change pallet_evm alias to EVM to fix `eth_getCode` (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names
## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
`twox_128("EVM") ++ twox_128("AccountCodes") ++ …`
Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
expectations so the override layers can pull bytecode correctly.
## Testing
- `cargo check -p datahaven-node`
- `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.
**Migration details:**
- **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
- **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)
**Testing the migration:**
```bash
# Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime
# Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
on-runtime-upgrade \
--blocktime 6000 \
--checks all \
--disable-spec-version-check \
live --uri wss://dh-validator-0.datahaven-kt.xyz
```
Test results from stagenet:
- ✅ Migration completes in 1 block
- ✅ PoV size: ~5.3 KB
- ✅ Weight consumption: <0.1% of block capacity
- ✅ All 39 keys successfully migrated
## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
- Old prefix: twox128("Evm") = 0x8b90cb...
- New prefix: twox128("EVM") = 0x6a5e91...
All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
|
|
|
"log/std",
|
2025-06-25 06:09:26 +00:00
|
|
|
"pallet-authorship/std",
|
|
|
|
|
"pallet-balances/std",
|
fix: change pallet_evm alias to EVM to fix `eth_getCode` (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names
## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
`twox_128("EVM") ++ twox_128("AccountCodes") ++ …`
Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
expectations so the override layers can pull bytecode correctly.
## Testing
- `cargo check -p datahaven-node`
- `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.
**Migration details:**
- **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
- **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)
**Testing the migration:**
```bash
# Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime
# Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
on-runtime-upgrade \
--blocktime 6000 \
--checks all \
--disable-spec-version-check \
live --uri wss://dh-validator-0.datahaven-kt.xyz
```
Test results from stagenet:
- ✅ Migration completes in 1 block
- ✅ PoV size: ~5.3 KB
- ✅ Weight consumption: <0.1% of block capacity
- ✅ All 39 keys successfully migrated
## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
- Old prefix: twox128("Evm") = 0x8b90cb...
- New prefix: twox128("EVM") = 0x6a5e91...
All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
|
|
|
"pallet-timestamp/std",
|
2025-09-12 07:45:26 +00:00
|
|
|
"pallet-evm/std",
|
|
|
|
|
"pallet-evm-precompile-proxy/std",
|
2025-09-24 10:27:44 +00:00
|
|
|
"pallet-migrations/std",
|
feat: Add SafeMode and TxPause Pallets (#192)
### Overview
This PR integrates the `pallet-safe-mode` and `pallet-tx-pause` from
Polkadot SDK to provide comprehensive emergency governance controls
across all DataHaven runtime networks (mainnet, stagenet, testnet).
### Key Changes
#### 🔧 **Core Integration**
- **Dependencies**: Added `pallet-safe-mode` and `pallet-tx-pause` from
`polkadot-stable2412-6`
- **Runtime Integration**: Integrated both pallets across all three
runtime networks with pallet indices 103 and 104
- **Call Filtering**: Implemented unified `RuntimeCallFilter` that
combines Normal, SafeMode, and TxPause restrictions
#### 🛡️ **SafeMode Pallet Configuration**
- **Duration**: 1 day activation period (`DAYS` constant)
- **Deposits**: Disabled permissionless entry/extension (all `None`)
- **Origins**: Root-only for all force operations (`force_enter`,
`force_exit`, `force_extend`, etc.)
- **Whitelisting**: SafeMode and Sudo calls are immune to restrictions
#### ⏸️ **TxPause Pallet Configuration**
- **Origins**: Root-only pause/unpause control
- **Whitelisting**: SafeMode and Sudo calls cannot be paused
- **Max Call Name Length**: 256 characters
#### 🏗️ **Architecture**
- **Shared Types**: Created `operator/runtime/common/src/safe_mode.rs`
with reusable configurations
- **Combined Filtering**: `RuntimeCallFilter` applies all three filter
layers (Normal + SafeMode + TxPause)
- **Consistent Config**: Identical configuration across mainnet,
stagenet, and testnet
#### 📊 **Infrastructure Updates**
- **Benchmarking**: Added both pallets to benchmark suites across all
networks
- **Weight Mappings**: Placeholder weights using Substrate defaults
(ready for chain-specific benchmarking)
- **Metadata**: Updated runtime metadata for new pallet exposure
#### 🧪 **Testing Framework**
- **Coverage**: Tests for individual pallet behavior, combined
restrictions, whitelisting, and edge cases
### Emergency Control Capabilities
**SafeMode Pallet** (8 calls):
- User calls: `enter`, `extend`, `release_deposit`
- Force calls: `force_enter`, `force_exit`, `force_extend`,
`force_slash_deposit`, `force_release_deposit`
**TxPause Pallet** (2 calls):
- `pause_call` / `unpause_call` - Granular transaction type pausing
---------
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-10-06 17:00:10 +00:00
|
|
|
"pallet-safe-mode/std",
|
|
|
|
|
"pallet-tx-pause/std",
|
2025-06-25 06:09:26 +00:00
|
|
|
"pallet-treasury/std",
|
2025-03-17 16:57:14 +00:00
|
|
|
"polkadot-primitives/std",
|
2025-04-25 23:28:41 +00:00
|
|
|
"polkadot-runtime-common/std",
|
2025-09-12 07:45:26 +00:00
|
|
|
"precompile-utils/std",
|
feat: ✨ Native Token Transfer to Ethereum (#88)
### Summary
- Implement native token transfers from DataHaven to Ethereum using
Snowbridge infrastructure
- Add comprehensive datahaven-native-transfer pallet with lock-and-mint
mechanism for cross-chain token representation
### Key Features
**New Pallet: datahaven-native-transfer**
- Cross-chain transfers: Transfer DataHaven native tokens to Ethereum
addresses via `transfer_to_ethereum extrinsic`
- Token locking mechanism: Secure token storage in deterministic
Ethereum sovereign account during transfers
- Fee management: Required fees for all transfers to compensate relayers
and prevent spam
- Emergency controls: Pause/unpause functionality
- Token registration: Integration with Snowbridge's token registration
for native token identification
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced the DataHaven Native Transfer pallet enabling secure
cross-chain transfers of DataHaven native tokens to and from Ethereum
via Snowbridge.
- Added token locking on DataHaven, minting on Ethereum, and mandatory
fee collection to cover gas costs and incentivize relayers.
- Implemented pause and unpause controls for emergency management of
token transfers.
- **Configuration**
- Integrated the new pallet into mainnet, stagenet, and testnet runtimes
with updated network, account, and treasury settings.
- Added Ethereum sovereign account constants and native token ID support
for optimized cross-chain operations.
- **Documentation**
- Added comprehensive README and inline documentation detailing pallet
features, extrinsics, events, errors, and security considerations.
- **Tests**
- Added extensive unit and integration tests covering token transfers,
native token registration, fee handling, pause functionality, and event
validation across all supported networks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-06-11 22:07:36 +00:00
|
|
|
"scale-info/std",
|
2025-05-08 13:14:30 +00:00
|
|
|
"sp-core/std",
|
fix: change pallet_evm alias to EVM to fix `eth_getCode` (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names
## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
`twox_128("EVM") ++ twox_128("AccountCodes") ++ …`
Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
expectations so the override layers can pull bytecode correctly.
## Testing
- `cargo check -p datahaven-node`
- `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.
**Migration details:**
- **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
- **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)
**Testing the migration:**
```bash
# Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime
# Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
on-runtime-upgrade \
--blocktime 6000 \
--checks all \
--disable-spec-version-check \
live --uri wss://dh-validator-0.datahaven-kt.xyz
```
Test results from stagenet:
- ✅ Migration completes in 1 block
- ✅ PoV size: ~5.3 KB
- ✅ Weight consumption: <0.1% of block capacity
- ✅ All 39 keys successfully migrated
## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
- Old prefix: twox128("Evm") = 0x8b90cb...
- New prefix: twox128("EVM") = 0x6a5e91...
All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
|
|
|
"sp-io/std",
|
2025-05-08 23:32:55 +00:00
|
|
|
"sp-runtime/std",
|
2025-06-25 06:09:26 +00:00
|
|
|
"sp-std/std",
|
feat: ✨ Native Token Transfer to Ethereum (#88)
### Summary
- Implement native token transfers from DataHaven to Ethereum using
Snowbridge infrastructure
- Add comprehensive datahaven-native-transfer pallet with lock-and-mint
mechanism for cross-chain token representation
### Key Features
**New Pallet: datahaven-native-transfer**
- Cross-chain transfers: Transfer DataHaven native tokens to Ethereum
addresses via `transfer_to_ethereum extrinsic`
- Token locking mechanism: Secure token storage in deterministic
Ethereum sovereign account during transfers
- Fee management: Required fees for all transfers to compensate relayers
and prevent spam
- Emergency controls: Pause/unpause functionality
- Token registration: Integration with Snowbridge's token registration
for native token identification
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced the DataHaven Native Transfer pallet enabling secure
cross-chain transfers of DataHaven native tokens to and from Ethereum
via Snowbridge.
- Added token locking on DataHaven, minting on Ethereum, and mandatory
fee collection to cover gas costs and incentivize relayers.
- Implemented pause and unpause controls for emergency management of
token transfers.
- **Configuration**
- Integrated the new pallet into mainnet, stagenet, and testnet runtimes
with updated network, account, and treasury settings.
- Added Ethereum sovereign account constants and native token ID support
for optimized cross-chain operations.
- **Documentation**
- Added comprehensive README and inline documentation detailing pallet
features, extrinsics, events, errors, and security considerations.
- **Tests**
- Added extensive unit and integration tests covering token transfers,
native token registration, fee handling, pause functionality, and event
validation across all supported networks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-06-11 22:07:36 +00:00
|
|
|
"xcm/std",
|
2025-03-17 16:57:14 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
runtime-benchmarks = [
|
|
|
|
|
"frame-support/runtime-benchmarks",
|
2025-09-24 10:27:44 +00:00
|
|
|
"pallet-migrations/runtime-benchmarks",
|
feat: Add SafeMode and TxPause Pallets (#192)
### Overview
This PR integrates the `pallet-safe-mode` and `pallet-tx-pause` from
Polkadot SDK to provide comprehensive emergency governance controls
across all DataHaven runtime networks (mainnet, stagenet, testnet).
### Key Changes
#### 🔧 **Core Integration**
- **Dependencies**: Added `pallet-safe-mode` and `pallet-tx-pause` from
`polkadot-stable2412-6`
- **Runtime Integration**: Integrated both pallets across all three
runtime networks with pallet indices 103 and 104
- **Call Filtering**: Implemented unified `RuntimeCallFilter` that
combines Normal, SafeMode, and TxPause restrictions
#### 🛡️ **SafeMode Pallet Configuration**
- **Duration**: 1 day activation period (`DAYS` constant)
- **Deposits**: Disabled permissionless entry/extension (all `None`)
- **Origins**: Root-only for all force operations (`force_enter`,
`force_exit`, `force_extend`, etc.)
- **Whitelisting**: SafeMode and Sudo calls are immune to restrictions
#### ⏸️ **TxPause Pallet Configuration**
- **Origins**: Root-only pause/unpause control
- **Whitelisting**: SafeMode and Sudo calls cannot be paused
- **Max Call Name Length**: 256 characters
#### 🏗️ **Architecture**
- **Shared Types**: Created `operator/runtime/common/src/safe_mode.rs`
with reusable configurations
- **Combined Filtering**: `RuntimeCallFilter` applies all three filter
layers (Normal + SafeMode + TxPause)
- **Consistent Config**: Identical configuration across mainnet,
stagenet, and testnet
#### 📊 **Infrastructure Updates**
- **Benchmarking**: Added both pallets to benchmark suites across all
networks
- **Weight Mappings**: Placeholder weights using Substrate defaults
(ready for chain-specific benchmarking)
- **Metadata**: Updated runtime metadata for new pallet exposure
#### 🧪 **Testing Framework**
- **Coverage**: Tests for individual pallet behavior, combined
restrictions, whitelisting, and edge cases
### Emergency Control Capabilities
**SafeMode Pallet** (8 calls):
- User calls: `enter`, `extend`, `release_deposit`
- Force calls: `force_enter`, `force_exit`, `force_extend`,
`force_slash_deposit`, `force_release_deposit`
**TxPause Pallet** (2 calls):
- `pause_call` / `unpause_call` - Granular transaction type pausing
---------
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
2025-10-06 17:00:10 +00:00
|
|
|
"pallet-safe-mode/runtime-benchmarks",
|
|
|
|
|
"pallet-tx-pause/runtime-benchmarks",
|
2025-03-17 16:57:14 +00:00
|
|
|
"polkadot-primitives/runtime-benchmarks",
|
2025-04-25 23:28:41 +00:00
|
|
|
"polkadot-runtime-common/runtime-benchmarks",
|
2025-05-08 13:14:30 +00:00
|
|
|
"sp-runtime/runtime-benchmarks",
|
2025-03-17 16:57:14 +00:00
|
|
|
]
|
|
|
|
|
|
fix: change pallet_evm alias to EVM to fix `eth_getCode` (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names
## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
`twox_128("EVM") ++ twox_128("AccountCodes") ++ …`
Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
expectations so the override layers can pull bytecode correctly.
## Testing
- `cargo check -p datahaven-node`
- `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.
**Migration details:**
- **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
- **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)
**Testing the migration:**
```bash
# Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime
# Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
on-runtime-upgrade \
--blocktime 6000 \
--checks all \
--disable-spec-version-check \
live --uri wss://dh-validator-0.datahaven-kt.xyz
```
Test results from stagenet:
- ✅ Migration completes in 1 block
- ✅ PoV size: ~5.3 KB
- ✅ Weight consumption: <0.1% of block capacity
- ✅ All 39 keys successfully migrated
## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
- Old prefix: twox128("Evm") = 0x8b90cb...
- New prefix: twox128("EVM") = 0x6a5e91...
All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
|
|
|
try-runtime = [
|
|
|
|
|
"frame-support/try-runtime",
|
|
|
|
|
"pallet-migrations/try-runtime",
|
|
|
|
|
"pallet-safe-mode/try-runtime",
|
|
|
|
|
"pallet-tx-pause/try-runtime",
|
|
|
|
|
"pallet-timestamp/try-runtime",
|
|
|
|
|
"polkadot-runtime-common/try-runtime",
|
|
|
|
|
"sp-runtime/try-runtime",
|
|
|
|
|
]
|
|
|
|
|
|
2025-03-17 16:57:14 +00:00
|
|
|
# Set timing constants (e.g. session period) to faster versions to speed up testing.
|
|
|
|
|
fast-runtime = []
|