Skip to content

DAG consensus

Public

How RP1's Narwhal-Bullshark runtime makes transaction data available, orders certificates, and commits application state.

Updated View as Markdown

RP1 production consensus is DAG-first. The Cosmos SDK application still owns state transitions, but a custom consensus server owns data availability, certificate formation, ordering, and the handoff into application execution.

Public flow

transaction

worker batches

primary authors vertices and certificates

validators exchange certificates over QUIC

Bullshark chooses an ordered commit sequence

executor calls FinalizeBlock and Commit

canonical RPC/API state is exposed

Data availability and ordering

Workers batch incoming transactions and provide bounded backpressure. Validators exchange signed availability and causality information, then the ordering layer selects a certified history for application execution. The exact persistence, ownership, and certificate formats are release-owned implementation details; external clients should use the transaction and header RPCs instead.

Application handoff

The consensus executor turns ordered history into application execution and commits the resulting state. A certificate or broadcast acknowledgement is not a user-visible completion by itself: integrations must query the committed transaction and verify its height, result code, and identity.

Finality and RPC

RP1 exposes canonical status and block-specific policies through its custom RPC layer. Status can reflect the canonical application head while a complete retained block header is still catching up; block-specific handlers must not fabricate a block, hash, app hash, or timestamp from an incomplete head.

For integrations, the practical rule is to use the current canonical query surface and verify the returned transaction identity and height. For operators, do not debug rp1d start as if CometBFT owns block production.

Transport and validator roles

Consensus networking uses QUIC and validator IDs derived from validator keys. The public node roles are active-validator and observer. Peer reachability, stable identity, and correct chain configuration are prerequisites for admission.

What this page intentionally omits

Retention-floor recovery, WAL reconciliation, certificate ownership transitions, and private topology are correctness-sensitive engineering details. They are not required to integrate with RP1 and should not be copied into external operators’ public runbooks without a reviewed source update.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close