x/precompile Module
The x/precompile module serves as a central registry for precompiled contract addresses, making them accessible from the EVM layer. It also processes specific EVM events through the PostTxProcessing hook for reward claiming operations.
Overview
The module provides:
Precompile Address Registry: Stores and manages contract addresses for key system components
Event Processing: Handles
BplCoinClaimedevents for reward distributionGovernance-Controlled Updates: All addresses can be updated via governance proposals
Key Feature: The module maintains critical contract addresses (GemCoreNFT Factory, Uniswap contracts) and processes reward claiming events from the EVM layer.
Architecture
How It Works
1. Smart contract operations emit events
2. EVM executes transaction and generates receipt
3. x/precompile PostTxProcessing hook intercepts receipt
4. Module checks for BplCoinClaimed events
5. If found, processes reward claiming
6. Updates claimable balances in x/brahma moduleExample Flow:
Registered Contract Addresses
The module maintains a registry of important contract addresses used throughout the system:
Currently Implemented Addresses
GemCoreNFT Factory
Main factory contract for Core and Gem token operations
Handles minting, burning, and token management
Uses UUPS upgradeable pattern for future enhancements
Deploys ERC-20 and ERC-1155 token contracts via BeaconProxy pattern
BeaconFactory enables efficient deployment of multiple token instances with shared logic
CSR Turnstile
Contract-secured revenue operations
Manages revenue distribution mechanisms
Uniswap Integration
Router: DEX routing for token swaps
Factory: Liquidity pool creation and management
Placeholder Addresses (Future Development)
The module structure supports additional precompile addresses for future integration:
Governance precompile (for on-chain governance from EVM)
Staking precompile (for validator operations from EVM)
Brahma precompile (for direct EVM interaction with x/brahma)
These addresses are defined in the module parameters but are not yet implemented in the current version.
Event Interfaces
The module primarily processes events emitted by smart contracts:
BplCoinClaimed Event
This event is emitted when users claim their accumulated rewards through the EVM interface. The module's PostTxProcessing hook listens for this event and triggers the reward distribution from the x/brahma module.
Future Interface Support
The module architecture supports adding Solidity interfaces for:
Direct staking operations from smart contracts
Governance participation from EVM
Brahma module interactions
These interfaces will be implemented as the system evolves and requirements become clearer.
Event Processing
PostTxProcessing Hook
The module implements the EVM PostTxProcessing hook to process reward claiming events:
Flow:
EVM transaction completes
Hook receives transaction receipt with logs
Scans logs for
BplCoinClaimedeventsDecodes event data (user address and amount)
Triggers reward distribution through x/brahma module
Updates user's claimable balance
Implementation:
Module Parameters
The module stores precompile contract addresses as governance-controlled parameters:
gov_precompile
Custom governance interface address
staking_precompile
Custom staking interface address
brahma_precompile
Brahma module interface address
gem_core_nft_factory
GemCoreNFT factory contract address
csr_turnstile
CSR operations contract address
uniswap_router
DEX router contract address
uniswap_factory
DEX factory contract address
Features:
All addresses updatable via governance
Validates Ethereum address format (0x...)
Empty addresses allowed (precompile disabled)
Message Types
MsgUpdateParams
Updates precompile contract addresses:
Requirements:
Authority-only (governance module)
Validates all addresses are valid Ethereum hex format
Updates take effect immediately
Integration Examples
Example: Claiming Rewards from Smart Contract
Result: The PostTxProcessing hook detects the event and triggers reward distribution from the x/brahma module to the user's account.
Future Integration Patterns
As the system evolves, the precompile module will support more complex integrations:
Direct governance participation from smart contracts
Automated staking operations
Cross-module interactions through EVM
Type Conversions
The module handles conversions between EVM and Cosmos types:
Address Conversion:
Amount Conversion:
String Handling:
Security Features
Address Validation:
All precompile addresses validated as proper Ethereum hex
Invalid addresses rejected at parameter update
Authorization:
Governance-only control for precompile address updates
Event handlers validate caller permissions
Safe Type Conversion:
Overflow protection when converting BigInt to sdk.Int
Address format validation before Cosmos operations
Event Signature Verification:
Only registered event signatures processed
Unknown events ignored (no error)
Integration with x/brahma
The x/precompile module integrates with x/brahma primarily through:
Reward Claiming:
Processes
BplCoinClaimedevents from EVM contractsTriggers reward distribution in x/brahma module
Updates claimable balances for users
Contract Address Registry:
Stores GemCoreNFT factory address used by x/brahma for core minting
Maintains addresses for token operations
Future Integration Points: The architecture supports future enhancements for:
Direct Core Grant Application submission from EVM
Request for Core processing through smart contracts
Contribution type management via governance
Query Endpoints
Params Query:
Returns all configured precompile contract addresses.
Benefits
For Developers:
Use familiar Solidity syntax
Access native Cosmos features
No need to learn BitSDK message types
For Users:
Interact via standard Web3 wallets (MetaMask)
Unified interface for EVM and Cosmos operations
Transparent bridging between ecosystems
For the Ecosystem:
Seamless EVM-Cosmos integration
Enables hybrid AI Apps using both layers
Governance-controlled address updates
Limitations
Event-Driven Only:
Precompiles emit events, not return values
Cannot query Cosmos state directly from Solidity
Asynchronous execution model
Gas Considerations:
EVM gas paid by user
Cosmos gas consumed by module
Two-layer gas accounting
Address Format:
Must convert between Ethereum and Cosmos addresses
Users need both address types for full functionality
Last updated