Help turn a design into verified behavior.

Understand and explain

Read the introduction and key limitations, then follow the white paper’s target requirements. Help make the difference between delivery, inclusion, maturity and finality understandable. Bring a specific question or a correction to the community forum.

Reproduce an exact public result

Choose a named package, verify its manifest and checksums, and follow its pinned toolchain and fresh-directory commands. Record the source, inputs, topology, timing, observed behavior and limits. Keep successful cycles separate from subsequent failed fault scopes.

A useful next experiment states a falsifiable hypothesis, a discriminating observation, a bounded budget and the decision each outcome will support. More logs or repetitions alone are insufficient.

Review a payment or custody boundary

Look for a smallest reproducible case involving ownership, value conservation, repeated imports, incomplete proofs, restart, epoch changes or bounded capacity. Every carried envelope still needs authentication. Keep thresholds and deadlines unchanged when evaluating a reported result.

For a suspected security vulnerability, use the maintainer contact described in the developer guide to request a private reporting route before sharing exploit details. Public reports must omit keys, credentials, wallet backups and private node/caller/signing state.

Improve source, documentation and the website

Submit a focused issue or proposed change to the relevant public repository. Explain the trigger, expected behavior, observed counterexample and validation. Website corrections belong to the website repository; protocol reproduction discussions belong with the published package and Nodes & Development.

Independent operational and custody evidence is a separate requirement. A reproduction under one owner can clarify engineering behavior without claiming independent operation or a deployed stellar link.

One frozen design; separately qualified releases

The final white paper has 21 chapters and 39 references. Sections 18–21 state the normative architecture, 24 risk records and operational obligations, embedded acceptance gates and continuity rules. Current code, a mutable plan or an older fixture cannot lower that contract.

The frozen publication has no version label. Its content hashes and audit commit are recorded separately. Executable protocol profiles, cryptographic suites, validator and key epochs still require authenticated versions, activation and renewed qualification when their assumptions change. Freezing the paper does not freeze the software or approve a mainnet.

Qualification is a complete, bounded evidence contract

A release needs a complete executable protocol profile and authenticated pre-mainnet decisions, including root/admission/recovery authorities, consensus and epoch rules, suites and canonical encodings, issuance, limits, custody and retention, funding, privacy and qualification horizon. Missing decisions stop the affected qualification.

Section 20 embeds the A–G foundations, I1–I12 requirements, N1–N10 native implementation gates and P1–P8 pre-mainnet gates. Two independent verifiers, reproducible builds, supply-chain provenance and qualified device/archive recovery are mandatory. Deployment is a separate acceptance stage, followed by separately measured physical routes.

Each R1–R24 risk record specifies adversary, assumptions, mechanisms, residual risk, detection, affected value, recovery authority, safe-stop condition, payer and discriminating tests. Failures remain failures. Repeating a run, extending its deadline or reducing its threshold cannot convert it into qualification. Current no-value fixtures leave full qualification open.