Module API

x/brahma Module

The Brahma module implements AI-driven token economics with governance-based core allocation and automated reward distribution.

Core Transaction Types

The Brahma module uses four main transaction types to manage the lifecycle of Core token allocations and AI contributions:

1. MsgCoreGrantApplication

Purpose: Request permission to mint Core tokens through governance approval.

Use Case: AI creators or contributors apply for a Core token allocation budget. Once approved by governance, the requester can subsequently mint cores by submitting AI tensor contributions (via MsgRequestForCore) until their allocation is exhausted.

Workflow: Typically triggered automatically via Application when it interacts with the Brahma precompile contract. Creates a governance proposal that validators must vote on. If approved, a CoreGrantApplication is stored in state with the allocated amount.

message MsgCoreGrantApplication {
  string authority = 1;          // x/gov module account
  string requester = 2;          // Address to receive allocation
  uint64 core_allocation = 3;    // Number of cores requested
  string title = 4;              // Proposal title (required)
  string description = 5;        // Proposal description (required)
  int64 created_at_height = 6;   // Creation block height (required)
}

All fields are required. This is a governance-only transaction - users cannot submit it directly via CLI.

2. MsgRequestForCore

Purpose: Exchange AI tensor contributions for Core tokens under an approved grant allocation.

Use Case: After receiving an approved CoreGrantApplication, the requester submits this message to contribute AI training data (tensors) and receive corresponding Core tokens. Each contribution decrements the remaining allocation.

Workflow: Application submits AI tensor data → Module validates sufficient allocation remains → Calculates cores to mint based on contributions → Mints cores via GemCoreNFT contract → Updates allocation balance.

Processing: Tensors are processed in batches with overflow protection. Multiple AIs and contribution types can be included in a single request.

3. MsgRemoveCoreGrantApplication

Purpose: Revoke an existing Core token allocation through governance.

Use Case: Used when a CoreGrantApplication needs to be cancelled (e.g., project abandoned, misuse detected, policy changes). Prevents the requester from minting additional cores.

Workflow: Governance proposal created → Validators vote → If approved, the CoreGrantApplication is removed from state and the requester can no longer mint cores under that allocation.

Reason field is required for audit purposes to maintain transparency about why allocations are revoked. This is a governance-only transaction.

4. MsgUpdateParams

Purpose: Modify module parameters through governance.

Use Case: Adjust economic parameters (creator/Application/contributor reward splits, siphon percentage), contribution types, processing limits, or EVM gas settings without requiring a chain upgrade.

Workflow: Governance proposal created with new parameter values → Validators vote → If approved, parameters are updated in state and take effect immediately.

Important: All 12 parameters must be supplied when updating (see Module Parameters section for complete list). This is a governance-only transaction.

Key Keeper Methods

Core Token Management:

AI Management:

Reward Distribution:

Market Cap & Inflation:

EVM Integration:

Module Parameters

The brahma module has the following governance-tunable parameters:

Parameter Accessors:

Constants (NOT tunable parameters):

• MaxAddressesPerMint = 100 - Max addresses per mint call

• MaxBatchSize = 100 - Max items per batch operation

• MaxMarketCapHistorySize = 100 - Max market cap snapshots per AI

Query Endpoints

gRPC/REST API:

Note: There is no /brahma/v1/ais or /brahma/v1/grants endpoint. Query individual items by ID/address.

State Storage

The module uses prefixed storage with different encoding patterns:

Key Construction Patterns:

Critical: Tensor keys use length-prefix encoding to prevent key-space collisions when aiID is variable-length. This is essential for security and for extracting the address component later.

x/precompile Module

The Precompile module bridges BitSDK functionality to EVM smart contracts through precompiled contracts at fixed addresses.

Available Precompiles

1. Staking (0x0000000000000000000000000000000000000800)

2. Distribution (0x0000000000000000000000000000000000000801)

3. Bank (0x0000000000000000000000000000000000000804)

4. Governance (0x0000000000000000000000000000000000000805)

5. ICS-20 Transfer (0x0000000000000000000000000000000000000802)

6. Slashing (0x0000000000000000000000000000000000000806)

7. Bech32 (0x0000000000000000000000000000000000000400)

8. Custom: Brahma Precompile

Address configured via governance parameters. Monitors EVM events to trigger governance actions:

Contract Address Management

Precompile Module Parameters:

The precompile module maintains addresses for dynamically deployed contracts:

Retrieve addresses via keeper methods:

Update via governance:

Next Steps

• Learn how contracts interact with modules in Smart Contract Integration

• Understand the complete flow in Module Interaction

• Review security best practices in Security Considerations

• Get started with development in Quick Start