Struct ConstraintConstants 

pub struct ConstraintConstants {
    pub sub_windows_per_window: u64,
    pub ledger_depth: u64,
    pub work_delay: u64,
    pub block_window_duration_ms: u64,
    pub transaction_capacity_log_2: u64,
    pub pending_coinbase_depth: usize,
    pub coinbase_amount: u64,
    pub supercharged_coinbase_factor: u64,
    pub account_creation_fee: u64,
    pub fork: Option<ForkConstants>,
}

Protocol constraint constants that define core blockchain behavior.

These constants configure fundamental aspects of the Mina protocol including consensus, transaction processing, economic parameters, and ledger structure. They are compile-time parameters that must be consistent across all nodes in a network.

Consensus and Timing Parameters

The consensus mechanism relies on slot-based timing where blocks are produced in discrete time slots. The timing hierarchy is:

• Slots: Basic time units for block production
• Sub-windows: Groups of slots within an epoch
• Windows: Collections of sub-windows that define epoch structure
• Epochs: Complete consensus periods

Economic Parameters

The protocol defines economic incentives through fees and rewards:

• Coinbase rewards: Paid to block producers for successful blocks
• Account creation fees: Required to create new accounts on the ledger
• Supercharged rewards: Multiplier for enhanced block producer rewards

Ledger and Transaction Structure

The ledger uses a Merkle tree structure for efficient verification:

• Ledger depth: Determines the maximum number of accounts (2^depth)
• Transaction capacity: Limits transactions per block for performance
• Pending coinbase: Manages delayed coinbase payouts

Usage Example

use mina_core::constants::constraint_constants;

// Access global constraint constants
let constants = constraint_constants();

// Calculate slots per window
let slots_per_window = constants.sub_windows_per_window;
println!("Sub-windows per window: {}", slots_per_window);

// Get block timing
let block_time_ms = constants.block_window_duration_ms;
println!("Block time: {}ms", block_time_ms);

// Check economic parameters
let coinbase_reward = constants.coinbase_amount;
let creation_fee = constants.account_creation_fee;
println!("Coinbase: {} nanomina, Account fee: {} nanomina",
         coinbase_reward, creation_fee);

Network Differences

While most constraint constants are identical across networks, some parameters may differ between mainnet and testnets for development purposes.

Related OCaml implementation: https://github.com/MinaProtocol/mina/tree/compatible/src/config Protocol specification: https://github.com/MinaProtocol/mina/blob/compatible/docs/specs/types_and_structures/serialized_key.md

Fields

sub_windows_per_window: u64

Number of sub-windows that make up a complete window.

Used in the consensus mechanism to structure epoch timing. Combined with slots_per_sub_window from protocol constants, this determines the total slots per window: slots_per_window = slots_per_sub_window × sub_windows_per_window.

Value: 11 (both mainnet and devnet)

ledger_depth: u64

Depth of the account ledger Merkle tree.

This determines the maximum number of accounts that can be stored in the ledger: max_accounts = 2^ledger_depth. The depth affects proof sizes and verification time. A larger depth allows more accounts but increases computational overhead.

Value: 35 (supports ~34 billion accounts) Usage: Account addressing, sparse ledger proofs, zkSNARK constraints

work_delay: u64

Number of blocks to delay before SNARK work becomes available.

This creates a buffer period between when a block is produced and when the associated SNARK work can be included in subsequent blocks. This delay helps ensure fair distribution of SNARK work opportunities.

Value: 2 blocks Usage: SNARK work scheduling, proof marketplace timing

block_window_duration_ms: u64

Duration of each block production slot in milliseconds.

This is the fundamental time unit for the consensus protocol. Block producers attempt to create blocks during their assigned slots. The duration affects network synchronization requirements and transaction confirmation times.

Value: 180,000ms (3 minutes) Usage: Consensus timing, slot calculations, network synchronization

transaction_capacity_log_2: u64

Log₂ of the maximum number of transactions per block.

The actual transaction capacity is 2^transaction_capacity_log_2. This logarithmic representation is used because the value directly affects zkSNARK circuit constraints. Higher capacity allows more transactions but increases block processing time.

Corresponds to transaction_capacity in the protocol specification, which defines the maximum transactions per block (represented as two_to_the).

Value: 7 (supports 2^7 = 128 transactions per block) Usage: Transaction pool management, block construction, circuit constraints

pending_coinbase_depth: usize

Number of confirmations before coinbase reward is spendable.

Coinbase rewards are not immediately spendable and require a certain number of block confirmations before they can be used. This parameter defines the depth of the pending coinbase Merkle tree structure used to track these delayed rewards until they mature.

Value: 5 (coinbase rewards require 5 block confirmations) Usage: Coinbase reward management, staged ledger operations, reward maturity

coinbase_amount: u64

Block reward amount in nanomina (10⁻⁹ MINA).

This is the base reward paid to block producers for successfully creating a block. The amount is specified in nanomina, where 1 MINA = 10⁹ nanomina. Block producers may receive additional rewards through the supercharged coinbase mechanism.

Value: 720,000,000,000 nanomina (720 MINA) Usage: Block producer rewards, economic incentives, reward calculations

supercharged_coinbase_factor: u64

Multiplier for supercharged coinbase rewards.

Supercharged rewards were designed to provide double block rewards (factor of 2) to block producers staking with unlocked tokens during the early mainnet period following the 2021 launch. This mechanism incentivized participation and orderly markets after mainnet launch.

Historical values:

• Original mainnet: 2 (double rewards for unlocked tokens)
• Berkeley hardfork (June 2024): 1 (supercharged rewards removed via MIP1)

The removal was decided by community vote on January 1, 2023, as proposed by community member Gareth Davies. This change ensures uniform rewards for all tokens and reduces inflation, promoting a sustainable economic model.

References:

• Berkeley Upgrade: https://minaprotocol.com/blog/minas-berkeley-upgrade-what-to-expect
• Supercharged Rewards Removal: https://minaprotocol.com/blog/update-on-minas-supercharged-rewards-schedule
• Original Proposal: https://github.com/MinaProtocol/mina/issues/5753

Usage: Enhanced reward calculations, incentive mechanisms

account_creation_fee: u64

Fee required to create a new account in nanomina.

When a transaction creates a new account that doesn’t exist on the ledger, this fee is charged in addition to the transaction fee. This prevents spam account creation and manages ledger growth.

Value: 1,000,000,000 nanomina (1 MINA) Usage: Account creation, transaction validation, fee calculations

fork: Option<ForkConstants>

Optional fork constants defining a protocol upgrade point.

When present, these constants specify the blockchain state at which a protocol fork or upgrade occurred. This allows the protocol to handle transitions between different versions while maintaining consensus.

Usage: Protocol upgrades, compatibility handling, genesis configuration

Trait Implementations

impl BinProtWrite for ConstraintConstants

fn binprot_write<W: Write>(&self, w: &mut W) -> Result<()>

impl Clone for ConstraintConstants

fn clone(&self) -> ConstraintConstants

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ConstraintConstants

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl From<&ConstraintConstants> for ConstraintConstantsUnversioned

fn from(constraints: &ConstraintConstants) -> Self

Converts to this type from the input type.