Anchors, waves, vertices
Monolythium’s commit model uses DAG terms rather than Ethereum block terms.
| Tier | What it is | Cadence |
|---|---|---|
| Vertex | One operator’s proposal, represented as a DAG node | Continuous |
| Wave | A round of vertices across the operator set | 4-second target under the registered testnet profile |
| Anchor | Canonical committed point selected from the DAG | Release-defined; no public fixed cadence is certified |
The user-facing canonical unit is the anchor. Public consumers should use anchor and round terminology without inventing a fixed height-to-time conversion.
Why anchors
Section titled “Why anchors”In a DAG-BFT chain, many vertices can be committed per wave, but only selected points become canonical commits. Anchor is the right term because it is the unit that gets finality evidence, history position, and state commitment.
A skipped wave produces no anchor. Anchor numbers are monotonic, but they are not the same as wave numbers.
Quiet ranges
Section titled “Quiet ranges”Consumers must tolerate quiet periods without fabricating anchors or assuming a constant time-to-height mapping. Heartbeat and compact quiet-range terminology is public, but exact triggers, payloads, persistence, and recovery rules are release-specific and are not a public ABI or operator runbook.
Reading anchor state
Section titled “Reading anchor state”Use native methods:
lyth_currentRoundfor the latest committed round view.lyth_chainStatsfor chain id, latest height, peer count, mempool depth, and indexer status.lyth_peerSummaryfor aggregate peer and version information.lyth_runtimeProvenancefor exact runtime, commit, binary, and genesis identity.
For a method catalog, see RPC reference and lyth_* namespace.
Finality
Section titled “Finality”The registered consensus profile describes native finality material:
- ML-DSA-65 round certificate (7-of-10 bitmap multisig of independent per-operator signatures) for fast commit evidence.
- Release-specific checkpoint or proof material that must be consumed only through an explicitly supported trust and acceptance contract rather than reconstructed from historical prose.
The exact SDK may expose proof helpers, and a raw endpoint may return checkpoint rows. Those facts do not establish trusted signer roots, multi-validator finality, receipt acceptance, checkpoint cadence, or a production settlement policy. No certified end-to-end receipt/checkpoint verification API is published here.
Consensus signatures use ML-DSA-65. This page does not publish a leader-selection or randomness algorithm, and no such mechanism should be inferred from an older document.