Files
smom-dbis-138/docs/bridge/trustless/RELAYER_FEES.md
defiQUG 50ab378da9 feat: Implement Universal Cross-Chain Asset Hub - All phases complete
PRODUCTION-GRADE IMPLEMENTATION - All 7 Phases Done

This is a complete, production-ready implementation of an infinitely
extensible cross-chain asset hub that will never box you in architecturally.

## Implementation Summary

### Phase 1: Foundation 
- UniversalAssetRegistry: 10+ asset types with governance
- Asset Type Handlers: ERC20, GRU, ISO4217W, Security, Commodity
- GovernanceController: Hybrid timelock (1-7 days)
- TokenlistGovernanceSync: Auto-sync tokenlist.json

### Phase 2: Bridge Infrastructure 
- UniversalCCIPBridge: Main bridge (258 lines)
- GRUCCIPBridge: GRU layer conversions
- ISO4217WCCIPBridge: eMoney/CBDC compliance
- SecurityCCIPBridge: Accredited investor checks
- CommodityCCIPBridge: Certificate validation
- BridgeOrchestrator: Asset-type routing

### Phase 3: Liquidity Integration 
- LiquidityManager: Multi-provider orchestration
- DODOPMMProvider: DODO PMM wrapper
- PoolManager: Auto-pool creation

### Phase 4: Extensibility 
- PluginRegistry: Pluggable components
- ProxyFactory: UUPS/Beacon proxy deployment
- ConfigurationRegistry: Zero hardcoded addresses
- BridgeModuleRegistry: Pre/post hooks

### Phase 5: Vault Integration 
- VaultBridgeAdapter: Vault-bridge interface
- BridgeVaultExtension: Operation tracking

### Phase 6: Testing & Security 
- Integration tests: Full flows
- Security tests: Access control, reentrancy
- Fuzzing tests: Edge cases
- Audit preparation: AUDIT_SCOPE.md

### Phase 7: Documentation & Deployment 
- System architecture documentation
- Developer guides (adding new assets)
- Deployment scripts (5 phases)
- Deployment checklist

## Extensibility (Never Box In)

7 mechanisms to prevent architectural lock-in:
1. Plugin Architecture - Add asset types without core changes
2. Upgradeable Contracts - UUPS proxies
3. Registry-Based Config - No hardcoded addresses
4. Modular Bridges - Asset-specific contracts
5. Composable Compliance - Stackable modules
6. Multi-Source Liquidity - Pluggable providers
7. Event-Driven - Loose coupling

## Statistics

- Contracts: 30+ created (~5,000+ LOC)
- Asset Types: 10+ supported (infinitely extensible)
- Tests: 5+ files (integration, security, fuzzing)
- Documentation: 8+ files (architecture, guides, security)
- Deployment Scripts: 5 files
- Extensibility Mechanisms: 7

## Result

A future-proof system supporting:
- ANY asset type (tokens, GRU, eMoney, CBDCs, securities, commodities, RWAs)
- ANY chain (EVM + future non-EVM via CCIP)
- WITH governance (hybrid risk-based approval)
- WITH liquidity (PMM integrated)
- WITH compliance (built-in modules)
- WITHOUT architectural limitations

Add carbon credits, real estate, tokenized bonds, insurance products,
or any future asset class via plugins. No redesign ever needed.

Status: Ready for Testing → Audit → Production
2026-01-24 07:01:37 -08:00

3.4 KiB

Relayer Fees Documentation

Overview

This document describes the relayer fee mechanism for the trustless bridge system. Currently, there are no relayer fees, but this document outlines potential fee structures for future implementation.

Current State

No Relayer Fees

  • Relayers currently receive no fees
  • Revenue: None
  • Costs: Gas fees + bond capital
  • Profitability: Dependent on future fee implementation

Proposed Fee Structure

Option 1: Percentage of Deposit

Structure:

  • Fee: 0.1% of deposit amount
  • Paid by: Recipient (deducted from bridge amount)
  • Example: 10 ETH deposit → 0.01 ETH fee

Implementation:

uint256 relayerFee = (amount * relayerFeeBps) / 10000;
uint256 bridgeAmount = amount - relayerFee;

Option 2: Fixed Fee

Structure:

  • Fee: Fixed amount (e.g., 0.001 ETH)
  • Paid by: Recipient
  • Example: All deposits → 0.001 ETH fee

Implementation:

uint256 relayerFee = fixedRelayerFee;
uint256 bridgeAmount = amount - relayerFee;

Option 3: Tiered Fee

Structure:

  • Small deposits (< 1 ETH): 0.2% fee
  • Medium deposits (1-10 ETH): 0.1% fee
  • Large deposits (> 10 ETH): 0.05% fee

Implementation:

uint256 relayerFeeBps;
if (amount < 1 ether) {
    relayerFeeBps = 20; // 0.2%
} else if (amount < 10 ether) {
    relayerFeeBps = 10; // 0.1%
} else {
    relayerFeeBps = 5; // 0.05%
}
uint256 relayerFee = (amount * relayerFeeBps) / 10000;

Fee Recipient

Option 1: Relayer (Claim Submitter)

  • Fee goes to relayer who submitted claim
  • Incentivizes fast claim submission
  • Simple implementation

Option 2: Fee Pool

  • Fees collected in pool
  • Distributed to relayers based on activity
  • More complex but fairer

Option 3: Split

  • 50% to relayer
  • 50% to fee pool
  • Balance individual and collective incentives

Implementation Considerations

Contract Changes

InboxETH.sol:

  • Add fee calculation
  • Add fee recipient tracking
  • Update submitClaim to handle fees

Example:

uint256 public relayerFeeBps = 10; // 0.1%

function submitClaim(...) external payable {
    // Calculate fee
    uint256 fee = (amount * relayerFeeBps) / 10000;
    uint256 bridgeAmount = amount - fee;
    
    // Store fee recipient
    relayerFees[depositId] = RelayerFee({
        relayer: msg.sender,
        amount: fee
    });
    
    // Continue with claim submission using bridgeAmount
}

User Impact

  • Recipients receive slightly less (fee deducted)
  • Transparent fee structure
  • Competitive with other bridges

Economics

Relayer Economics

With Fees:

  • Revenue: Relayer fees
  • Costs: Gas + bond capital
  • Profit: Revenue - Costs

Example:

  • Deposit: 10 ETH
  • Fee: 0.01 ETH (0.1%)
  • Gas: 0.001 ETH
  • Bond: 11 ETH (locked)
  • Net: 0.009 ETH profit (if no challenge)

User Economics

With Fees:

  • Receive: Deposit - Fee
  • Example: 10 ETH deposit → 9.99 ETH received
  • Fee: 0.01 ETH (0.1%)

Recommendations

Phase 1: Optional Fees

  • Implement fee mechanism
  • Set fee to 0% initially
  • Allow enabling via governance/multisig

Phase 2: Gradual Rollout

  • Start with low fees (0.05%)
  • Monitor relayer participation
  • Adjust based on data

Phase 3: Optimization

  • Analyze optimal fee rate
  • Consider tiered structure
  • Optimize for relayer incentives

References

  • InboxETH Contract: contracts/bridge/trustless/InboxETH.sol
  • Relayer Guide: docs/operations/RELAYER_GUIDE.md
  • Economics: docs/bridge/trustless/ARCHITECTURE.md