Threat Model

Current implementation, supported use and explicit qualification limits.

Experimental Feature

This feature is experimental and may change significantly in future versions.

Current release status

Public document hashing and exact integer aggregation are live with signed results. Native consensus, mining, issuance, COMPUTE payments and rewards are inactive. Independent operation is not yet demonstrated.

Current status

The native compound candidate is implemented and isolated-tested, not production-qualified or activated. Earlier weighted BFT and simulated quorum demonstrations are not current live consensus.

Proposed ordering

A valid credited record requires a unique registered nonempty useful computation and fresh complementary resource work. Greatest fully validated accumulated expected resource work selects history. Identities, holdings, receipt counts and recycled payments confer no security weight.

Confirmations and recovery

Confirmations are probabilistic and reorganisable. There is no absolute-finality confirmation count or unconditional maximum reorganisation depth. Resource-majority, delay and eclipse assumptions matter. No qualifying useful jobs means a stalled head, never empty-work rewards. Administrative recovery must preserve validated history.

Activation

Ratified numerical parameters, genuine independent resource/WAN/funding evidence, qualified migration/writer fencing and separate production/payment authority are still required.

Native ordering and recovery — isolated candidate

The compound candidate requires useful computation plus fresh complementary resource work. Production consensus remains inactive, with parameters and economic/security commitments unratified.

BoundaryImplementation / evidenceMeaning
EligibilityUnique nonempty registered useful computationEmpty or duplicate work adds no canonical credit
OrderingGreatest fully validated accumulated expected resource workReceipt count, identity count and recycled payments add no weight
ConfirmationsProbabilistic / reorganisableNo unconditional finality depth or maximum reorganisation
AdmissionOrdinary keys can supply valid eligible workIndependent honest resources and propagation assumptions remain necessary

Practical procedure

  1. 1Independently validate the bootstrap and every record.
  2. 2Reject malformed work, unknown policy versions and duplicate semantic work.
  3. 3Compare fully validated resource weight; withhold confirmation on ambiguous equal-work forks.
  4. 4Recover validated current history; never administratively reset finalized accounting to a stale balance.
Technical reference · scope is explicit
Mandatory useful execution + fresh resource proof
  → full independent record validation
  → accumulated expected work comparison
  → probabilistic confirmations

No qualifying useful jobs → stalled head, not empty rewards.

Limits and failure cases

  • A resource-majority adversary can reorganise valid history, including payments.
  • Software tests do not establish economic security or an honest-resource budget.
  • Ratification, actual outside resources and separate production authority are required.