Mining Configuration

Citrate uses GhostDAG (Greedy Heaviest-Observed Sub-Tree Directed Acyclic Graph) for block production, which allows multiple miners to produce valid blocks simultaneously. Unlike traditional blockchain mining where only one miner wins per round, GhostDAG includes all valid blocks in the DAG structure, meaning more miners can earn rewards without wasted work. This guide covers mining configuration, optimization, and reward strategies.

Understanding GhostDAG Mining

In a traditional blockchain, miners race to produce a single block and all other work is discarded. GhostDAG changes this by maintaining a DAG of blocks rather than a single chain. Multiple blocks produced at the same "height" are all included, and the protocol determines ordering afterward.

Key concepts for miners:

Block production rate: The network targets a combined rate of 10 blocks per second across all miners
Parallel blocks: Multiple valid blocks can reference the same parent blocks
Blue score: Blocks that align with the majority DAG structure earn higher scores
Merge set: Each block references multiple parent blocks, merging parallel chains

This means mining on Citrate is more predictable than on Ethereum or Bitcoin -- even small miners produce blocks regularly, with rewards proportional to their hashrate contribution. We designed it this way so that solo miners can participate meaningfully without needing to join a pool.

Enabling Mining

Enable mining in your node configuration:

# In ~/.citrate/config.toml
 
[mining]
enabled = true
coinbase = "0xYOUR_COINBASE_ADDRESS"
threads = 0                          # 0 = auto-detect (all cores)
extra_data = "my-mining-node"        # Up to 32 bytes, appears in block header
 
# GhostDAG-specific parameters
[mining.ghostdag]
k_cluster_size = 18                  # Maximum number of parallel blocks per level
target_blocks_per_second = 1         # Per-miner target; network target is 10
max_block_parents = 10               # Maximum parent block references
orphan_resolution_depth = 100        # How deep to search for orphaned blocks

Start mining:

Start the node with mining enabled:

citrated start --config ~/.citrate/config.toml

Or enable mining on a running node via RPC:

curl -X POST http://localhost:8545 -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"miner_start","params":[0],"id":1}'

Block Production Settings

Fine-tune your block production for optimal performance:

[mining.block]
gas_limit = 30000000                 # Maximum gas per block
gas_floor = 5000                     # Minimum gas price to include (in wei)
max_transactions = 500               # Maximum transactions per block
block_time_target_ms = 1000          # Target time between your blocks
priority_fee_threshold = 1000000000  # Minimum priority fee (1 gwei)

The gas_floor setting determines the minimum gas price for transactions you will include. Setting this too high excludes legitimate transactions; setting it too low wastes block space on low-value transactions.

Monitor your block production:

Check mining status:

citrate-cli mining status --rpc http://localhost:8545

View recent blocks you produced:

citrate-cli mining blocks --coinbase 0xYOUR_COINBASE_ADDRESS --count 20 --rpc https://rpc.cnidarian.cloud

Parallel Chain Parameters

The GhostDAG k parameter controls how many parallel blocks the network tolerates at each level. This is a network-wide parameter, but understanding it helps you optimize your mining strategy.

# Query current network parameters
citrate-cli network params --rpc https://rpc.cnidarian.cloud

With k = 18, up to 18 blocks at the same DAG level are considered valid "blue" blocks. Blocks beyond this limit are "red" blocks -- they are still included in the DAG for data availability, but they earn reduced rewards.

To maximize your blue block rate:

Minimize latency: Ensure your node has fast connectivity to peers so your blocks propagate before competing blocks
Reference recent parents: Always reference the most recent block tips to avoid building on stale state
Optimize block size: Smaller blocks propagate faster, increasing the chance they are included in the blue set

Reward Optimization

Mining rewards on Citrate consist of two components:

Component	Description
Block reward	Fixed SALT reward per block (decays over time per supply schedule)
Transaction fees	Priority fees from included transactions

Strategies for maximizing rewards:

Check the current block reward:

citrate-cli mining reward-info --rpc https://rpc.cnidarian.cloud

Estimate daily earnings based on your hashrate:

citrate-cli mining estimate --hashrate $(citrate-cli mining hashrate --rpc http://localhost:8545) --rpc https://rpc.cnidarian.cloud

Advanced miners can run transaction ordering strategies to capture more fee revenue:

[mining.ordering]
strategy = "fee_priority"            # Options: fee_priority, fifo, mev_aware
bundle_enabled = false               # Enable transaction bundling

The mev_aware strategy considers transaction ordering for maximum extractable value but requires more CPU resources. For most miners, fee_priority provides the best balance of revenue and simplicity.

Dual Role: Validator + Miner

You can run both validator and miner roles on the same node. This increases your SALT earnings but requires more hardware resources.

[consensus]
role = "validator"
validator_key = "~/.citrate/keys/validator.key"
 
[mining]
enabled = true
coinbase = "0xYOUR_COINBASE_ADDRESS"
threads = 8                          # Reserve some cores for validation

When running both roles, allocate at least 4 CPU cores exclusively for validation duties to ensure you do not miss BFT votes while mining. I'd start with mining only and add the validator role once you are comfortable with your node's stability.