datahaven/operator/runtime/mainnet/tests/native_token_transfer.rs

459 lines
15 KiB
Rust
Raw Permalink Normal View History

// Copyright 2025 DataHaven
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
// This file is part of DataHaven.
// DataHaven is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
// DataHaven is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License
// along with DataHaven. If not, see <http://www.gnu.org/licenses/>.
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
#[path = "common.rs"]
mod common;
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
use codec::Encode;
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
use common::*;
use datahaven_mainnet_runtime::{
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
configs::EthereumSovereignAccount, currency::HAVE, AccountId, Balance, Balances,
DataHavenNativeTransfer, Runtime, RuntimeEvent, RuntimeOrigin, SnowbridgeSystemV2, System,
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
};
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
use dhp_bridge::NativeTokenTransferMessageProcessor;
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
use frame_support::{assert_noop, assert_ok, traits::fungible::Inspect};
use pallet_datahaven_native_transfer::Event as NativeTransferEvent;
use snowbridge_core::TokenIdOf;
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
use snowbridge_inbound_queue_primitives::v2::{
EthereumAsset, Message as SnowbridgeMessage, MessageProcessor, Payload,
};
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
use snowbridge_pallet_outbound_queue_v2::Event as OutboundQueueEvent;
use snowbridge_pallet_system::NativeToForeignId;
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
use sp_core::Get;
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
use sp_core::{H160, H256};
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
use sp_runtime::DispatchError;
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
use xcm::prelude::*;
use xcm_executor::traits::ConvertLocation;
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
const TRANSFER_AMOUNT: Balance = 1000 * HAVE;
const FEE_AMOUNT: Balance = 10 * HAVE;
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
const ETH_ALICE: H160 = H160([0x11; 20]);
const ETH_BOB: H160 = H160([0x22; 20]);
// Get the gateway address from runtime configuration
fn gateway_address() -> H160 {
use datahaven_mainnet_runtime::configs::runtime_params::dynamic_params::runtime_config::EthereumGatewayAddress;
EthereumGatewayAddress::get()
}
fn register_native_token() -> H256 {
let asset_location = Location::here();
let _ = SnowbridgeSystemV2::register_token(
root_origin(),
Box::new(VersionedLocation::V5(asset_location.clone())),
Box::new(VersionedLocation::V5(asset_location.clone())),
datahaven_token_metadata(),
);
let reanchored = SnowbridgeSystemV2::reanchor(asset_location).unwrap();
TokenIdOf::convert_location(&reanchored).unwrap()
}
fn setup_sovereign_balance(amount: Balance) {
let _ = Balances::force_set_balance(root_origin(), EthereumSovereignAccount::get(), amount);
}
fn create_message(token_id: H256, amount: Balance, claimer: H160, nonce: u64) -> SnowbridgeMessage {
SnowbridgeMessage {
gateway: gateway_address(),
nonce,
origin: H160::zero(),
assets: vec![EthereumAsset::ForeignTokenERC20 {
token_id,
value: amount,
}],
xcm: Payload::Raw(vec![0x01, 0x02, 0x03]),
claimer: Some(claimer.encode()),
value: 0,
execution_fee: 100,
relayer_fee: 50,
}
}
// === Token Registration Tests ===
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
#[test]
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
fn native_token_registration_works() {
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
ExtBuilder::default().build().execute_with(|| {
let asset_location = Location::here();
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Register the native HAVE token with Snowbridge
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
assert_ok!(SnowbridgeSystemV2::register_token(
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
root_origin(),
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
Box::new(VersionedLocation::V5(asset_location.clone())),
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
Box::new(VersionedLocation::V5(asset_location.clone())),
datahaven_token_metadata()
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
));
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Verify token was registered and assigned a valid token ID
let reanchored = SnowbridgeSystemV2::reanchor(asset_location).unwrap();
let token_id = TokenIdOf::convert_location(&reanchored).unwrap();
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
assert_ne!(token_id, H256::zero());
assert_eq!(
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
NativeToForeignId::<Runtime>::get(&reanchored),
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
Some(token_id)
);
});
}
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// === Outbound Transfer Tests ===
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
#[test]
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
fn transfer_to_ethereum_works() {
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
ExtBuilder::default().build().execute_with(|| {
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let _token_id = register_native_token();
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
let alice = account_id(ALICE);
// Record initial balances
let alice_initial = Balances::balance(&alice);
let sovereign_initial = Balances::balance(&EthereumSovereignAccount::get());
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Transfer native tokens to Ethereum
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
assert_ok!(DataHavenNativeTransfer::transfer_to_ethereum(
RuntimeOrigin::signed(alice.clone()),
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
ETH_ALICE,
TRANSFER_AMOUNT,
FEE_AMOUNT
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
));
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Verify Alice's balance decreased by transfer amount + fee
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
assert_eq!(
Balances::balance(&alice),
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
alice_initial - TRANSFER_AMOUNT - FEE_AMOUNT
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
);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Verify tokens were locked in sovereign account
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
assert_eq!(
Balances::balance(&EthereumSovereignAccount::get()),
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
sovereign_initial + TRANSFER_AMOUNT
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
);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Check event was emitted
assert!(System::events().iter().any(|e| matches!(
&e.event,
RuntimeEvent::DataHavenNativeTransfer(
NativeTransferEvent::TokensTransferredToEthereum { .. }
)
)));
});
}
#[test]
fn transfer_fails_when_paused() {
ExtBuilder::default().build().execute_with(|| {
let _token_id = register_native_token();
let alice = account_id(ALICE);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Pause the pallet
assert_ok!(DataHavenNativeTransfer::pause(root_origin()));
// Verify transfers are disabled when paused
assert_noop!(
DataHavenNativeTransfer::transfer_to_ethereum(
RuntimeOrigin::signed(alice),
ETH_ALICE,
TRANSFER_AMOUNT,
FEE_AMOUNT
),
pallet_datahaven_native_transfer::Error::<Runtime>::TransfersDisabled
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
);
});
}
#[test]
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
fn multiple_transfers_work() {
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
ExtBuilder::default().build().execute_with(|| {
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let _token_id = register_native_token();
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
let alice = account_id(ALICE);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let bob = account_id(BOB);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
assert_ok!(DataHavenNativeTransfer::transfer_to_ethereum(
RuntimeOrigin::signed(alice),
ETH_ALICE,
TRANSFER_AMOUNT,
FEE_AMOUNT
));
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
assert_ok!(DataHavenNativeTransfer::transfer_to_ethereum(
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
RuntimeOrigin::signed(bob),
ETH_BOB,
TRANSFER_AMOUNT,
FEE_AMOUNT
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
));
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let expected_sovereign_balance = TRANSFER_AMOUNT * 2;
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
assert_eq!(
Balances::balance(&EthereumSovereignAccount::get()),
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
expected_sovereign_balance
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
);
});
}
#[test]
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
fn treasury_collects_fees_from_multiple_transfers() {
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
ExtBuilder::default().build().execute_with(|| {
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let _token_id = register_native_token();
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
let alice = account_id(ALICE);
let bob = account_id(BOB);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let treasury_account = datahaven_mainnet_runtime::configs::TreasuryAccount::get();
let initial_treasury_balance = Balances::balance(&treasury_account);
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
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
let fee1 = 5 * HAVE;
let fee2 = 10 * HAVE;
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
assert_ok!(DataHavenNativeTransfer::transfer_to_ethereum(
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
RuntimeOrigin::signed(alice),
ETH_ALICE,
TRANSFER_AMOUNT,
fee1
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
));
assert_ok!(DataHavenNativeTransfer::transfer_to_ethereum(
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
RuntimeOrigin::signed(bob),
ETH_BOB,
TRANSFER_AMOUNT,
fee2
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
));
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let expected_treasury_balance = initial_treasury_balance + fee1 + fee2;
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
assert_eq!(
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
Balances::balance(&treasury_account),
expected_treasury_balance
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
);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
});
}
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// === Inbound Message Processing Tests ===
#[test]
fn message_processor_accepts_registered_token() {
ExtBuilder::default().build().execute_with(|| {
let token_id = register_native_token();
let alice = account_id(ALICE);
let message = create_message(token_id, TRANSFER_AMOUNT, ETH_ALICE, 1);
// Verify processor accepts messages containing registered native token
assert!(
NativeTokenTransferMessageProcessor::<Runtime>::can_process_message(&alice, &message)
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
);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
});
}
#[test]
fn message_processor_rejects_unregistered_token() {
ExtBuilder::default().build().execute_with(|| {
let fake_token_id = H256::from_low_u64_be(0x9999);
let alice = account_id(ALICE);
let message = create_message(fake_token_id, TRANSFER_AMOUNT, ETH_ALICE, 1);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
assert!(
!NativeTokenTransferMessageProcessor::<Runtime>::can_process_message(&alice, &message)
);
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
});
}
#[test]
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
fn message_processor_rejects_empty_assets() {
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
ExtBuilder::default().build().execute_with(|| {
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let token_id = register_native_token();
let alice = account_id(ALICE);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let mut message = create_message(token_id, TRANSFER_AMOUNT, ETH_ALICE, 1);
message.assets = vec![];
assert!(
!NativeTokenTransferMessageProcessor::<Runtime>::can_process_message(&alice, &message)
);
});
}
#[test]
fn inbound_message_processing_works() {
ExtBuilder::default().build().execute_with(|| {
let token_id = register_native_token();
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
let alice = account_id(ALICE);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let message = create_message(token_id, TRANSFER_AMOUNT, ETH_ALICE, 1);
// Setup sovereign account with sufficient balance
setup_sovereign_balance(TRANSFER_AMOUNT * 2);
let sovereign_initial = Balances::balance(&EthereumSovereignAccount::get());
// Process inbound message from Ethereum
assert_ok!(
snowbridge_pallet_inbound_queue_v2::Pallet::<Runtime>::process_message(alice, message)
);
// Verify tokens were unlocked to recipient
let recipient: AccountId = ETH_ALICE.into();
assert_eq!(Balances::balance(&recipient), TRANSFER_AMOUNT);
// Verify sovereign balance decreased by transfer amount
assert_eq!(
Balances::balance(&EthereumSovereignAccount::get()),
sovereign_initial - TRANSFER_AMOUNT
);
// Check unlock event was emitted
assert!(System::events().iter().any(|e| matches!(
&e.event,
RuntimeEvent::DataHavenNativeTransfer(NativeTransferEvent::TokensUnlocked { .. })
)));
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
});
}
#[test]
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
fn multiple_assets_processing_sums_amounts() {
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
ExtBuilder::default().build().execute_with(|| {
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let token_id = register_native_token();
let alice = account_id(ALICE);
let mut message = create_message(token_id, 0, ETH_ALICE, 1);
message.assets = vec![
EthereumAsset::ForeignTokenERC20 {
token_id,
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
value: 300 * HAVE,
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
},
EthereumAsset::ForeignTokenERC20 {
token_id,
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
value: 200 * HAVE,
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
},
EthereumAsset::ForeignTokenERC20 {
token_id,
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
value: 500 * HAVE,
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
},
];
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
setup_sovereign_balance(2000 * HAVE);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
assert_ok!(
snowbridge_pallet_inbound_queue_v2::Pallet::<Runtime>::process_message(alice, message)
);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let recipient: AccountId = ETH_ALICE.into();
feat: ✨ Standardize currency system to HAVE token with Wei-based units (#130) ## Summary This PR modernizes DataHaven's currency system by standardizing all three runtimes (mainnet, stagenet, testnet) to use Ethereum-compatible Wei-based units with HAVE as the native token name. ### Key Changes #### 🔄 Currency Unit Standardization - **Migrated from decimal-based to Wei-based system** (18 decimals) - **Wei units**: WEI → KILOWEI → MEGAWEI → GIGAWEI - **HAVE units**: MICROHAVE → MILLIHAVE → HAVE → KILOHAVE - **Zero Existential Deposit**: Enables dust account support with `insecure_zero_ed` feature #### 🏷️ Token Naming - **UNIT → HAVE**: Native token renamed to reflect DataHaven branding - **Consistent terminology**: All constants, comments, and documentation updated - **Supply factors preserved**: Mainnet (100x), Stagenet/Testnet (1x) #### ⚖️ Block Weights & Gas Configuration - **Solochain-optimized**: Updated MAX_POV_SIZE and block weight parameters - **EVM compatibility**: Fixed GasLimitPovSizeRatio (u32 → u64) and storage growth ratios - **Proper fee structure**: Aligned with Ethereum standards #### 🧪 Test Updates - **Treasury tests fixed**: Updated to handle zero existential deposit behavior - **All tests passing**: Currency references updated across all runtime tests - **Storage hub parameters**: Updated to use HAVE token terminology ### Breaking Changes ⚠️ **Currency precision changed from 12 to 18 decimals** - Applications using currency constants must update to new HAVE-based naming - ExistentialDeposit now 0 (was previously enforced minimum balance) ### Runtime Coverage - ✅ **Mainnet runtime** (supply factor: 100) - ✅ **Stagenet runtime** (supply factor: 1) - ✅ **Testnet runtime** (supply factor: 1) - ✅ **Storage hub parameters** (runtime params updated) ### Technical Details #### Fee Structure ```rust pub const TRANSACTION_BYTE_FEE: Balance = 1 * GIGAWEI * SUPPLY_FACTOR; pub const STORAGE_BYTE_FEE: Balance = 100 * MICROHAVE * SUPPLY_FACTOR; pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR / 4; ``` #### Block Configuration ```rust pub const MAXIMUM_BLOCK_WEIGHT: Weight = Weight::from_parts( WEIGHT_REF_TIME_PER_SECOND.saturating_mul(2), MAX_POV_SIZE as u64, ); ``` ## Test Plan - [x] All runtime builds compile successfully - [x] All unit tests pass across three runtimes - [x] Treasury fee handling verified with zero existential deposit - [x] Storage hub parameter compatibility confirmed - [x] EVM gas limit calculations validated ## Files Modified **27 files changed, 728 insertions(+), 342 deletions(-)** - Runtime lib.rs files (currency module definitions) - Cargo.toml files (insecure_zero_ed feature) - Configuration modules (block weights, gas limits) - Test suites (currency constant references) - Storage hub runtime parameters --- 🤖 *Generated with [Claude Code](https://claude.ai/code)* <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Introduced a unified currency module with HAVE units (18 decimals), fees, and a deposit helper. - Adopted dynamic block weight/length configuration (5 MB blocks) and re-exported gas-to-weight constants. - Improvements - Switched all runtimes and pricing parameters from UNIT/NANO_UNIT to HAVE/GIGAWEI. - Updated deposits, fees, and rewards to HAVE-based values across modules (including StorageHub and Snowbridge). - Made existential deposit runtime-configurable; enabled zero-ED mode on selected networks. - Updated metadata hash and token metadata to reference HAVE (symbol wHAVE, 18 decimals). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ahmad Kaouk <ahmadkaouk.93@gmail.com>
2025-08-18 11:26:30 +00:00
let total_amount = 1000 * HAVE;
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
assert_eq!(Balances::balance(&recipient), total_amount);
});
}
#[test]
fn processing_fails_without_claimer() {
ExtBuilder::default().build().execute_with(|| {
let token_id = register_native_token();
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
let alice = account_id(ALICE);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let mut message = create_message(token_id, TRANSFER_AMOUNT, ETH_ALICE, 1);
message.claimer = None;
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
assert_noop!(
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
snowbridge_pallet_inbound_queue_v2::Pallet::<Runtime>::process_message(alice, message),
DispatchError::Other("No claimer specified in message")
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
);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
});
}
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
#[test]
fn processing_fails_with_zero_amount() {
ExtBuilder::default().build().execute_with(|| {
let token_id = register_native_token();
let alice = account_id(ALICE);
let message = create_message(token_id, 0, ETH_ALICE, 1);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
assert_noop!(
snowbridge_pallet_inbound_queue_v2::Pallet::<Runtime>::process_message(alice, message),
DispatchError::Other("No native token found in assets")
);
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
});
}
#[test]
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
fn processing_fails_with_insufficient_sovereign_balance() {
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
ExtBuilder::default().build().execute_with(|| {
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let token_id = register_native_token();
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
let alice = account_id(ALICE);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
let message = create_message(token_id, TRANSFER_AMOUNT, ETH_ALICE, 1);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
setup_sovereign_balance(TRANSFER_AMOUNT / 2); // Insufficient balance
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
assert_noop!(
snowbridge_pallet_inbound_queue_v2::Pallet::<Runtime>::process_message(alice, message),
pallet_datahaven_native_transfer::Error::<Runtime>::InsufficientSovereignBalance
);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
});
}
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// === Integration Tests ===
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
#[test]
fn end_to_end_transfer_flow() {
ExtBuilder::default().build().execute_with(|| {
let token_id = register_native_token();
let alice = account_id(ALICE);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Step 1: Outbound transfer - Alice sends tokens to Ethereum
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
assert_ok!(DataHavenNativeTransfer::transfer_to_ethereum(
RuntimeOrigin::signed(alice.clone()),
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
ETH_ALICE,
TRANSFER_AMOUNT,
FEE_AMOUNT
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
));
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Verify message was queued for Snowbridge
assert!(System::events().iter().any(|e| matches!(
&e.event,
RuntimeEvent::EthereumOutboundQueueV2(OutboundQueueEvent::MessageQueued { .. })
)));
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Step 2: Simulate inbound processing - tokens returning from Ethereum
let message = create_message(token_id, TRANSFER_AMOUNT, ETH_BOB, 1);
setup_sovereign_balance(TRANSFER_AMOUNT * 3);
assert_ok!(
snowbridge_pallet_inbound_queue_v2::Pallet::<Runtime>::process_message(alice, message)
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
);
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Verify tokens were delivered to recipient
let recipient: AccountId = ETH_BOB.into();
assert_eq!(Balances::balance(&recipient), TRANSFER_AMOUNT);
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
});
}
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
#[test]
fn message_routing_works_correctly() {
ExtBuilder::default().build().execute_with(|| {
let token_id = register_native_token();
let alice = account_id(ALICE);
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
feat: ✨ Add native token transfer support from Ethereum to DataHaven (#97) ## Overview This PR implements the **return path** for DataHaven's native token bridge, enabling tokens that were previously transferred from DataHaven to Ethereum to flow back to DataHaven. **Context**: DataHaven native tokens can be transferred to Ethereum where they exist as wrapped ERC20 tokens. This PR completes the bidirectional bridge by implementing the mechanism to transfer these tokens back from Ethereum to DataHaven, effectively "unwrapping" them and restoring them to their native form. ## Key Changes - **Added `NativeTokenTransferMessageProcessor`** , a new message processor specifically designed to handle native token return transfers from Ethereum, and extended `InboundQueueV2` processor tuple to include native token transfer handling alongside existing EigenLayer message processing ## How It Works ### Detailed Flow: Ethereum → DataHaven #### 1. **Ethereum Initiation** - **User Transaction**: User calls `v2_sendMessage` on Snowbridge Gateway contract: ```solidity v2_sendMessage( assets: [{ kind: ForeignToken, assetId: <registered_native_token_id>, // Must match pre-registered token ID amount: <transfer_amount> }], claimer: <datahaven_recipient_as_h160>, // 20-byte recipient address (SCALE-encoded) message: [], // Empty for native transfers // ... standard Snowbridge fees ) ``` - **Token Burning**: Gateway burns the wrapped ERC20 tokens on Ethereum (removing them from circulation) - **Message Encoding**: Gateway encodes transfer details into standardized Snowbridge message format - **Event Emission**: `MessageAccepted` event logged on Ethereum for relayers to pick up #### 2. **Cross-Chain Delivery Infrastructure** - **Relayer Network**: Snowbridge relayers monitor Ethereum events and submit messages to DataHaven - **Consensus Verification**: DataHaven's `EthereumBeaconClient` pallet verifies Ethereum beacon chain consensus - **Cryptographic Proofs**: Messages include Merkle proofs and execution receipts for tamper-proof verification - **Direct Processing**: Relayers submit messages via `InboundQueueV2::submit()` which processes them immediately #### 3. **DataHaven Message Processing** **Immediate Processing Flow:** When a relayer calls `InboundQueueV2::submit()`, the message is processed immediately using a tuple-based processor system: ```rust type MessageProcessor = ( EigenLayerMessageProcessor<Runtime>, // Handles validator operations NativeTokenTransferMessageProcessor<Runtime>, // Handles native token returns ); ``` **Processing Steps:** 1. **Message Verification**: Cryptographic verification and nonce checking (prevents replay attacks) 2. **Processor Selection**: Evaluation of processors (First processor returning `true` handles the message): - `EigenLayerMessageProcessor::can_process_message()` - returns `false` for token transfers - `NativeTokenTransferMessageProcessor::can_process_message()` - validates: - Native token is registered via `SnowbridgeSystemV2::register_token()` (`T::NativeTokenId::get().is_some()`) - All assets are `ForeignTokenERC20` with matching native token ID - Assets array is not empty **Token Unlocking Process:** 1. **Recipient Extraction**: Decodes H160 address from `claimer` field → converts to DataHaven AccountId (must contain valid SCALE-encoded H160 address) 2. **Sovereign Account Transfer**: Moves tokens from Ethereum sovereign account to recipient (requires sufficient balance from previous outbound transfers) 3. **Event Emission**: `TokensUnlocked` event confirms successful transfer completion --------- Co-authored-by: Tobi Demeco <50408393+TDemeco@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
2025-07-03 14:41:51 +00:00
// Native token message should be accepted
let native_message = create_message(token_id, TRANSFER_AMOUNT, ETH_ALICE, 1);
assert!(
NativeTokenTransferMessageProcessor::<Runtime>::can_process_message(
&alice,
&native_message
)
);
// Non-native token message should be rejected
let fake_token_id = H256::from_low_u64_be(0x8888);
let non_native_message = create_message(fake_token_id, TRANSFER_AMOUNT, ETH_ALICE, 2);
assert!(
!NativeTokenTransferMessageProcessor::<Runtime>::can_process_message(
&alice,
&non_native_message
)
);
});
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
}