Candidate validation
A proposal is checked against the chain context and required state-transition rules before it can gain the votes needed for finalization.
Inside MACA
Agreement you can follow, step by step.
Inspect MACA’s proposal, prevote, precommit, and finalization model, including quorum, message separation, and view changes.
Consensus ArchitectureIllustrated study
Shared rules. Separate actors.
Illustrated coordination. No live network activity.
01 / Built for a purpose
Make the decision reproducible.
MACA’s consensus core operates on explicit proposals, validator state, and signed messages. Networking delivers the inputs; the consensus rules determine what those inputs justify.
More than two-thirds
The quorum threshold is calculated from stake, with overflow-safe intermediate arithmetic. Empty stake cannot form a valid quorum.
Phase and round binding
Signatures include a message domain and relevant block, height, epoch, and round context. This binds a vote to the decision it was intended to support.
A controlled change of view
When a candidate fails or a proposer times out, validators can advance to another view under explicit rules instead of improvising a fallback.
Epoch boundaries
Epochs provide a defined point for validator-set transitions and derivation of the next election seed. The next round operates against an explicit participant set.
Model checking with a defined scope
The protocol includes a formal model for bounded safety analysis. Model results depend on their assumptions and do not replace deployment testing or prove every liveness condition.
02 / From intent to outcomeA clear path through
A clear path through
consensus architecture.
- 01
Inspect the proposal
Check the candidate block, expected context, and validity conditions.
- 02
Collect phase-specific votes
Accumulate the required prevotes and precommits from the active stake.
- 03
Produce a decision
Finalize with the supporting precommits, or follow the view-change path when progress stalls.
The details matterGood questions.
Good questions.
Clear answers.
What is the difference between safety and liveness?
Safety concerns avoiding conflicting finalized decisions. Liveness concerns continued progress. Each depends on stated network and fault assumptions, and must be evaluated separately.
Does a formal model certify the deployed network?
No. It provides evidence about the modeled rules and assumptions. Software implementation, operator behavior, configuration, and live network conditions require additional verification.
Keep exploringOne capability.