Core Tokens

Overview

Core tokens are genesis allocations granted through governance proposals that bootstrap new AIs with initial token supply. They serve as one-time permissions to mint Gems and are burned upon conversion.

Key Purpose: Enable community-controlled AI bootstrapping without centralized token issuance.

Lifecycle

Step-by-Step Process

1. Proposal Submission

   • Platform (e.g., Deva) submits MsgCoreGrantApplication via governance on behalf of AI creators

   • Specifies requested core allocation amount

   • Provides title and description

2. Community Voting

   • Token holders vote on proposal

   • Standard BitSDK governance process

   • Requires majority approval

3. Core Allocation

   • If approved → Cores allocated to creator's address

   • Permission recorded on-chain with expiry block height

   • Creator can now request cores via MsgRequestForCore via Platform

4. Gem Minting

   • Platform converts Cores to Gems via GemCoreNFT contract on behalf of users

   • 1 Core = 1 Gem (1:1 ratio)

   • Cores are burned in the process

   • Gems become tradeable AI-specific tokens

   • Users receive Gems without directly interacting with the blockchain

Core Grant Application

Data Structure

Key Properties

Governance-Controlled:

• All allocations require community approval

• No centralized control over core issuance

• Transparent on-chain process

Expiring Permissions:

• Core Grant Applications expire after configured block height

• Default: 1,000 blocks from creation

• Prevents indefinite core minting permissions

Accumulative:

• Multiple approved proposals increase total allocation

• Creator can submit new proposals for additional cores

• Each approval resets expiry timer

Removable:

• Governance can revoke permissions via MsgRemoveCoreGrantApplication

• Requires mandatory reason field for audit trail

• Useful for addressing security concerns or policy violations

Parameters

Parameter	Default	Description
max_core_grant_allocation	100	Maximum cores per single proposal
core_grant_application_expiry_height	1,000	Blocks before CGA expires

Usage Flow Example

Scenario: Creator wants to launch "AlphaAI" with 50 initial gems on Deva platform

Security Features

Quota System:

• Each CGA has fixed core allocation

• System deducts from quota on each RfC

• Prevents unlimited core minting

Expiry Mechanism:

• Permissions automatically expire

• Prevents stale permissions from being exploited

• Governance can extend by approving new proposal

Authorization Checks:

• Only governance can approve CGAs

• Only approved platform (e.g., Deva) can submit RfCs

• AI App address must match the approved platform's address

• Ensures only authorized platforms can submit contributions on behalf of users

Integration with x/brahma Module

Core tokens are managed by the x/brahma module:

• Storage: Stored in module state by requester address

• Validation: Checked on every MsgRequestForCore

• Minting: Executed via EVM contract call to GemCoreNFT

For detailed technical implementation, see x/brahma Module - Core Grant Application.

Design Rationale

Why Governance-Controlled? Prevents spam and ensures only legitimate AIs receive initial token supply.

Why Expiring Permissions? Reduces long-term risk of compromised accounts minting unlimited cores.

Why 1:1 Core-to-Gem Ratio? Simplifies mental model and ensures predictable initial supply.

Why Burn Cores? Cores are a scarce, freely tradeable reserve commodity token. Burning on conversion enforces the 1:1 Core-to-Gem issuance path and keeps the bootstrap process predictable.