# ✨ Implement Dynamic Fee Adjustment Mechanism
## Overview
Implements a dynamic fee adjustment mechanism, replacing the constant
fee multiplier with an adaptive multiplier that responds to network
congestion, following Moonbeam's pattern.
## Changes
- Replaces `ConstFeeMultiplier` with `TargetedFeeAdjustment` across all
runtime configurations (mainnet, stagenet, testnet)
- Implements an EIP-1559-like slow-adjusting fee mechanism that prevents
DoS attacks by adjusting fees based on block fullness
- **Configurable Parameters**:
- Target block fullness: 35%
- Adjustment variable: 4/1000 (responds in ~1 hour at extreme
congestion)
- Two modes:
- `SlowAdjustingFeeUpdate` for mainnet and testnet.
- `FastAdjustingFeeUpdate` for stagenet.
- Adds tests coverage for different fee scenarios
## Technical Details
The fee adjustment algorithm works as follows:
```
diff = (previous_block_weight - target) / maximum_block_weight
next_multiplier = prev_multiplier * (1 + (v * diff) + ((v * diff)^2 / 2))
assert(next_multiplier > min)
```
**Where:**
- `v` = AdjustmentVariable
- `target` = TargetBlockFullness
- `min` = MinimumMultiplier
`SlowAdjustingFeeUpdate` sets a minimum multiplier of `1x` for a
conservative fee adjustment, while `FastAdjustingFeeUpdate` sets it to
`0.1x`, which is mainly used for dev networks / testing.
This PR fixes the E2E checkout failure by fetching full history instead
of a depth-1 clone so the Snowbridge forge-std submodule can resolve its
pinned commit.
In this PR, we pin the forge version use in the linter task. When forge
make a new release it brokes the linter task.
In the future we can update the forge version explicitly.
---------
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
In this PR, we fix the ci error indicating we reached the number of
volumes allow by deleting automatically after tests the volumes.
We also remove the step that collect logs because the container that are
interesting to us to debug are being removed entirely. Therefore the
logs from the nodes are not being collected in this step.
This PR remove the `cargo chef` step used to build the docker image used
in deployment. We noticed that `cargo chef` was adding more time to the
build and that removing it was saving us 40min.
Also in this PR, we removed the base image from parity which was really
heavy and was filling the rest of the disk space. This broke the build.
After some investigation it doesn't seem to add a lot to the build. It
has been replace with the official rust image as a base to build our
node.
The image used to run the image has been replaced with
`debian:trixie-slim`.
In the end those changed **should not** break any of the current
behavior and makes save a bit of CI time.
In this PR we have a fix for the linter. We also allow for the non-null
assertion operator `!` to be used in typescript.
The typescript being used to setup tests and some convenient scripts we
should allow some the convenient feature of typescript.
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
## 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>
# Add Referenda Precompile
This PR introduces the referenda precompile from Moonbeam to enable
governance functionality through EVM calls.
## Changes Made
- Added `operator/precompiles/referenda/` with complete implementation
- Updated all runtime configs (mainnet, stagenet, testnet) to include
the referenda precompile
- Adapted track processing logic to work with DataHaven's runtime
configuration
- Adapted tests and mock according to our runtime
---------
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
## Summary
- Adds support for both Docker and Podman container engines in
`build-runtime-srtool.sh` via `IS_PODMAN` environment variable
- Uses `--userns=keep-id` for Podman (proper user namespace handling)
and `--user $(id -u):$(id -g)` for Docker
- Sets `IS_PODMAN=true` in `task-publish-runtime.yml` workflow to enable
Podman by default
## Changes
**`operator/scripts/build-runtime-srtool.sh`:**
- Added conditional logic to detect `IS_PODMAN` env var
- Dynamically selects between `podman` and `docker` as container engine
- Sets appropriate user/namespace flags based on container engine
**`.github/workflows/task-publish-runtime.yml`:**
- Added `IS_PODMAN: true` environment variable to the srtool build step
- Updated comment to use generic "container user" instead of "docker
user"
Co-authored-by: Claude <noreply@anthropic.com>
This PR upgrades the StorageHub dependencies to tag
[v0.0.6-alpha](https://github.com/Moonsong-Labs/storage-hub/releases/tag/v0.0.6-alpha).
This includes the fix to connect through TLS to a Postgres DB (allowing
connecting to an AWS hosted DB for instance), and a fix for a missing
indexer DB migration.
Additionally, it adds a new runtime API.
EDIT (previously breaking changes):
As of the new version, the name of a column in the indexer DB has
changed. This can affect the functionality of nodes running a Postgres
DB with the old schema. A
[migration](05d269a26d)
is included in the new
[tag](https://github.com/Moonsong-Labs/storage-hub/commits/v0.0.6-alpha/),
so no need to mark it as breaking.
---------
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
Co-authored-by: Gonza Montiel <gonzamontiel@users.noreply.github.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
## 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.
## Summary
- Fixes srtool build failure with `UnknownOpcode(252)` error during
metadata hash generation
- Removes hardcoded `WASM_BUILD_STD=0` to allow srtool to auto-detect
correct settings based on Rust version
- Adds `metadata-hash` feature to node Cargo.toml for CheckMetadataHash
extension
## Root Cause
The `WASM_BUILD_STD=0` setting forced srtool to use pre-built standard
library crates that were compiled with incompatible WASM features.
During metadata hash generation, the runtime builder encountered opcode
252 (likely from bulk memory operations) which the deserializer couldn't
recognize, causing the build to fail with:
```
thread 'main' panicked at metadata_hash.rs:73:10:
`Metadata::metadata_at_version` should exist.: RuntimeConstruction(Other("cannot deserialize module: UnknownOpcode(252)"))
```
## Changes
1. **operator/scripts/build-runtime-srtool.sh**: Removed hardcoded `-e
WASM_BUILD_STD=0` line
- Allows srtool to determine appropriate setting based on Rust version
- For Rust < 1.84: defaults to WASM_BUILD_STD=1 (enabled)
- For Rust >= 1.84: defaults to WASM_BUILD_STD=0 (disabled)
2. **operator/node/Cargo.toml**: Added `metadata-hash` feature
propagation
- Enables metadata-hash feature for all runtime variants (stagenet,
mainnet, testnet)
- Required for CheckMetadataHash extension support
## Test Plan
- [x] Successfully built stagenet runtime with srtool 1.88.0
- [x] Build completed in ~14 minutes without metadata hash errors
- [x] Verified WASM artifacts generated correctly
## Testing Command
```bash
GH_WORKFLOW_MATRIX_CHAIN=stagenet \
RUNTIME_BUILD_OPTS="--features=on-chain-release-build" \
RUNTIME_BUILD_PROFILE="production" \
GH_WORKFLOW_MATRIX_SRTOOL_IMAGE="paritytech/srtool" \
GH_WORKFLOW_MATRIX_SRTOOL_IMAGE_TAG="1.88.0" \
WASM_BUILD_STD=1 \
./operator/scripts/build-runtime-srtool.sh
```
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
In this PR, we remove the caching of the sccache folder because it is
too big (~3GB) and fill our cache too fast.
What to expect ?
* It will make the build a bit slower but it is fine because it only
build on `main`. We are preparing another PR that will speed up the
build of the prod image. Also we are not sure the cache is actually
being used (`gha` cache is in beta).
* Will free some space for caching and stop deleting our cache which
make other jobs work faster.
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
Co-authored-by: Gonza Montiel <gonzamontiel@users.noreply.github.com>
## Add Preimage Precompile
This PR integrates the Preimage precompile from Moonbeam into the
DataHaven runtime across all three environments (mainnet, stagenet,
testnet).
**Key Changes:**
- Added Preimage precompile implementation at address `2067` in all
runtime configurations
- Updated precompile sets in mainnet, stagenet, and testnet runtimes
- Updated `is_governance_precompile()` for the Preimage precompile
## Add Conviction Voting Precompile
This PR introduces a new EVM precompile for conviction voting
functionality, enabling smart contracts to interact with the Substrate
conviction voting pallet.
### Key Changes
- **New Precompile**: Added `ConvictionVotingPrecompile` at address
`0x0000000000000000000000000000000000000812` (2066)
- **Solidity Interface**: Complete Solidity interface
(`ConvictionVoting.sol`) with all conviction voting operations
- **Runtime Integration**: Integrated precompile across all runtime
configurations (mainnet, testnet, stagenet)
- **Comprehensive Testing**: Inherits test suite from Moonbeam
### Features
- Vote casting with different conviction levels (None, Locked1x-6x)
- Vote delegation and undelegation
- Poll management and tallying
- Support for all conviction voting pallet operations
---------
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
## Add Collective Precompile
Adds the pallet collective precompile to `mainnet`, `stagenet`, and
`testnet` according to Moonbeam's configuration.
### Changes:
- Added `pallet-evm-precompile-collective` dependency to workspace
- Configured collective precompile at address `2064` using
`TreasuryCouncilInstanc`
- Configured collective precompile at address `2068` using
`TechnicalCommitteeInstance`
The precompile provides EVM access to collective governance
functionality including proposal execution, voting, and membership
management.
---------
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
## Add Identity Precompile
Adds the pallet Identity precompile to `mainnet`, `stagenet`, and
`testnet` according to Moonbeam's configuration.
### Changes:
- Added `pallet-evm-precompile-identity` dependency to workspace
- Added and configured at address `2072` for all runtimes
The precompile provides a Solidity interface access to the Substrate
Identity pallet functionality.
---------
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
