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 exposedData 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.