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:

  1. Event-Driven Architecture: EVM events trigger BitSDK state changes via the precompile module's PostTxProcessing hook

  2. Bidirectional Communication: x/brahma can call EVM contracts (for minting), while EVM events trigger SDK messages (for governance)

  3. Governance Integration: Core allocations require governance approval, creating a trustless permission system

  4. Modular Upgradeability: UUPS pattern for GemCoreNFT, Beacon pattern for token contracts enable non-disruptive upgrades

Architecture Diagram:

spinner

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) (not GetBalance())

  • Check for nil module accounts and zero balances before proceeding

  • math.LegacyNewDecFromInt() converts sdk.Intmath.LegacyDec for multiplication

  • .TruncateInt() converts math.LegacyDecsdk.Int after multiplication

  • This pattern prevents precision loss during percentage calculations

Complete Workflow Example

Scenario: Core Grant Application → Approval → Minting

  1. User submits grant application via smart contract:

  2. Precompile hook detects event and creates governance proposal:

  3. Governance voting and execution:

  4. User contributes AI tensors:

  5. Ore minting and Core NFT distribution:

  6. Automated reward distribution each block:

Next Steps

Last updated