ServicesConsensus

How a Verdict Forms

Consensus never counts heads. Every attestation carries a weight, the weights race toward a confidence threshold, and quorum plus geographic diversity decide whether the verdict is tentative or final.

Vote weight

weight = 1.0 x reputation x geographic_bonus x stake_multiplier
  • reputation is the validator's score, clamped to 0.0-1.0. New validators start at 0.5.
  • geographic_bonus is 1.5 (by default) when the attestation carries both a country and a continent, otherwise 1.0.
  • stake_multiplier is 1 + reputation_stake / 1000, capped at 3.0 by default.

Verified: a fresh validator (reputation 0.5) attesting with stake 200 and a location produced weight: 0.9 - exactly 0.5 x 1.5 x 1.2. An otherwise-identical vote without a location produced 0.6, the bonus gone. The bonus and the diversity tally both key off the attestation's location, not the validator's registration, so send --country/--continent on every vote.

The determination ladder

Confidence is the leading side's share of total weight (unclear votes count in the denominator, so they dilute both sides). Three gates then pick the determination:

GatePassedFailed
confidence >= thresholdcontinueundetermined
total attestations >= minimum_validatorscontinuelikely_true / likely_false
distinct countries and continents >= minimumstrue / falselikely_true / likely_false

A tie in weight leans confirm. Nine confirming validators read likely_true (confidence 1.0, quorum of 10 not met); the tenth flipped the fact to true. disputed is never computed from votes - it is assigned when a challenge is upheld.

Attestations from unknown locations do not count toward the diversity gate: a fact attested only without locations showed {"countries": 0, "continents": 0}. The reported distribution_score measures spread against the server's configured minimums (a single-country, single-continent quorum scored 0.417 against minimums of 3 countries and 2 continents).

Phases and status

The phase mirrors the same gates in PBFT vocabulary:

  • proposal - no attestations yet; the fact reads pending_validation.
  • active_validation - votes exist but confidence is below threshold.
  • pre_commit - threshold met, quorum or diversity still missing.
  • commit - all gates passed; the fact reads consensus_reached.

challenged facts hold their status until resolution regardless of the tally, and re-derivation happens on every attestation and status read - which is also when an overdue fact flips to expired.

Challenge economics

A challenge freezes voting and puts the verdict in front of a platform admin. The stake is real only for challengers who are registered validators - it is debited from the stake balance at challenge time (verified: 1000 dropped to 700; a caller with no validator record can still challenge, committing nothing).

upholdreject
Factconsensus_reached + disputedreturns to its pre-challenge status and determination
Challenger stakereturnedforfeited
Rewarded (+0.05 reputation)deny votersconfirm voters
Slashed (-0.05 reputation)confirm votersdeny voters

Both branches: upholding a challenge against a 10-0 confirm verdict returned the 300 stake and slashed all ten validators (reputation 0.5 to 0.45); rejecting a later challenge forfeited its stake and moved the confirming validator from 0.5 to 0.55 with correct_attestations incremented. Resolutions are also ingested as events into the Reputation service under the domain named by CONSENSUS_REPUTATION_DOMAIN (default consensus).

Because reputation multiplies into every future vote weight, validators who vote against eventual resolutions literally count for less over time

  • that feedback loop is the registry's defense against brigading.

On this page