Security

Settlement finality is underwritten by a validator set. The execution layer assembles a settlement proof once every hop succeeds, and that proof is confirmed by validators until a stake-weighted supermajority is reached. The quorum threshold is defined as a constant in @arc-route/shared (two-thirds of active stake). Reaching that threshold is what makes a committed route binding rather than advisory.

The validator model is what separates a routed transfer from an unsecured one: the path is not merely selected and executed, it is attested to by a quorum whose agreement constitutes finality.

The validator set is not static. It begins at a defined size and expands in cohorts as the network matures, with each expansion governed by the Genesis roadmap. Expanding in cohorts, rather than all at once, keeps the set auditable at each stage and avoids the trust dilution that can accompany rapid, unstructured growth.

Validator participation, set composition, and the rules governing expansion are part of the security model and evolve with the network's phases. The repository's SECURITY policy governs vulnerability reporting and disclosure.

Because finality requires a supermajority, a transfer is not considered settled until that threshold is met. This means the security guarantee is a property of the route's completion, not of its initiation — the system withholds the claim of finality until the validator set has actually attested. A transfer's ExecutionStatus moves through active states (pending, simulating, scoring, committed, executing, settling) and only then into a terminal settled state.