DAG (FireDAG)

FireDAG is YouthChain’s block format and its roadmap for parallel production. The live testnet currently runs single-leader-per-round — every block has a single parent (parent_hashes = [parent], k=1). The parallel proposals and path-weight DAG fork-choice described below are implemented and tested on a branch and activate once the certified-DAG fork-choice is enabled. Today the canonical tip is simply the block with the most commit signatures at the highest finalized height (ties broken by lowest hash).

Why a DAG?

Linear chains force a single leader at a time — throughput is capped by one block per slot. A DAG lets multiple validators propose in parallel and reference each other’s blocks as parents, reducing wasted work under load.

Block shape

Every block exposes:

pub struct Block {
    pub number: u64,
    pub hash: Hash,
    pub parent_hashes: Vec<Hash>,   // 1..=N parents
    pub dag_round: u32,             // logical layer in the DAG
    pub validator: Address,
    pub view: u32,
    pub transactions: Vec<Transaction>,
    pub timestamp: u64,
    // ... signatures, state root, etc.
}

block.number is defined as max(parent.number) + 1, not a strict successor. Two blocks at the same height with disjoint transaction sets both contribute to throughput.

Tips

A tip is any block with no known descendants in the local view. Tips are tracked in Chain::tips() and exposed over JSON-RPC:

curl -X POST https://rpc.54-237-170-237.sslip.io \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"yc_getTips","params":[],"id":1}'

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tips": ["0xabc...", "0xdef..."],
    "dag_round": 47
  }
}

The next proposal picks 1..=k tips as parent_hashes. The leader typically picks the single latest tip on its heaviest branch, plus any uncle branches it has seen, merging them back in.

Visualizing the DAG

yc_getDagGraph returns an adjacency list suitable for direct D3 / Cytoscape rendering:

curl -X POST https://rpc.54-237-170-237.sslip.io \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"yc_getDagGraph","params":[{"fromHeight":40,"toHeight":50}],"id":1}'

{
  "vertices": [
    { "hash": "0x...", "number": 40, "validator": "0x...", "dagRound": 30, "parentHashes": ["0x..."] },
    { "hash": "0x...", "number": 41, "validator": "0x...", "dagRound": 31, "parentHashes": ["0x...", "0x..."] }
  ]
}

The dashboard renders this graph live.

Fork choice on a DAG

Once parallel production is enabled, fork choice computes weight(tip) as the sum of ⌊2N/3⌋+1-BFT-finalized block weights on the path from tip back to genesis. The heaviest tip wins. Unfinalized blocks contribute zero weight, so unconfirmed branches never eclipse confirmed ones. Under today’s single-leader production this reduces to picking the tip with the most commit signatures at the highest finalized height.

Benefits

Property	Linear chain	FireDAG
Throughput under load	1 block/slot	k × (1 block/slot) where k = parallel leaders
Finality	Depends on reorg depth	BFT-finalized on commit
Leader failure	Wastes a slot	Peers produce in parallel
Gossip overhead	Low	Slightly higher (track uncles)
EVM compat	Native	Native (revm runs on each block)

Get Started

Concepts

Resources

Why a DAG?

Block shape

Tips

Visualizing the DAG

Fork choice on a DAG

Benefits

​Why a DAG?

​Block shape

​Tips

​Visualizing the DAG

​Fork choice on a DAG

​Benefits

Why a DAG?

Block shape

Tips

Visualizing the DAG

Fork choice on a DAG

Benefits