Module Interaction
Architecture Overview
The Bitplanet architecture bridges two distinct execution environments: the BitSDK layer (native blockchain modules) and the EVM layer (Ethereum-compatible smart contracts). This dual-layer design enables seamless interaction between Bitplanet's custom modules and EVM-based applications.
Key Components:
BitSDK Layer:
x/brahma manages AI token economics, processing tensor contributions and distributing rewards
x/precompile acts as the bridge, monitoring EVM events and triggering SDK actions via hooks
x/gov handles governance proposals for core allocations and parameter updates
BitEVM Module provides the EVM execution environment
EVM Contract Layer:
GemCoreNFT (UUPS upgradeable) orchestrates the NFT ecosystem, managing Core and Gem tokens
MintableERC1155 contracts (Beacon proxies) represent individual gem collections with upgrade capability
ERC20Adapter contracts bridge ERC1155 NFTs to fungible ERC20 tokens (10^19 scaling factor)
Precompiled Contracts expose BitSDK functionality (staking, governance, etc.) to EVM contracts
Flow Highlights:
Event-Driven Architecture: EVM events trigger BitSDK state changes via the precompile module's PostTxProcessing hook
Bidirectional Communication: x/brahma can call EVM contracts (for minting), while EVM events trigger SDK messages (for governance)
Governance Integration: Core allocations require governance approval, creating a trustless permission system
Modular Upgradeability: UUPS pattern for GemCoreNFT, Beacon pattern for token contracts enable non-disruptive upgrades
Architecture Diagram:
EVM Hook Mechanism
Implementation Location: x/precompile/keeper/evm_hooks.go
The precompile module implements the EvmHooks interface to process EVM events and trigger BitSDK state changes.
1. Event Detection (PostTxProcessing Hook)
When an EVM transaction completes, the precompile module scans emitted events:
Hook Registration:
Hooks are registered in the app setup (
evmd/app.go)Multiple precompile handlers can be chained
Each handler processes specific contract events
2. Event Processing
Different events trigger different BitSDK actions:
CoreGrantApplicationEvent:
Note: The MsgCoreGrantApplication created by the hook only populates Authority, Requester, and CoreAllocation. The Title, Description, and CreatedAtHeight fields are NOT set in the hook—they're passed separately to SubmitProposal or must be set when manually creating proposals.
OreRequestEvent:
3. BeginBlock Reward Distribution
Every block, the Brahma module siphons inflation and distributes rewards:
Critical implementation details:
Must fetch module account first:
GetModuleAccount(ctx, distributiontypes.ModuleName)Use
GetAllBalances()then.AmountOf(baseDenom)(notGetBalance())Check for nil module accounts and zero balances before proceeding
math.LegacyNewDecFromInt()convertssdk.Int→math.LegacyDecfor multiplication.TruncateInt()convertsmath.LegacyDec→sdk.Intafter multiplicationThis pattern prevents precision loss during percentage calculations
Complete Workflow Example
Scenario: Core Grant Application → Approval → Minting
User submits grant application via smart contract:
Precompile hook detects event and creates governance proposal:
Governance voting and execution:
User contributes AI tensors:
Ore minting and Core NFT distribution:
Automated reward distribution each block:
Next Steps
Review module APIs for detailed transaction types in Module API
Explore smart contract implementations in Smart Contract Integration
Learn about security patterns in Security Considerations
Begin development with Quick Start
Last updated