# Helixium Protocol Specification v1.0

Status: v1.0 protocol freeze baseline  
Date: 2026-08-30  
Audience: protocol engineers, validator operators, SDK implementers, indexer developers, auditors

This document is the Helixium v1.0 protocol baseline. The core model defined
here is considered frozen for the v1.0 line: Helixium as a proof-native Layer-1
for verifiable digital evidence, the Create -> Prove -> Verify product model,
the Authorize -> Transfer -> Certify -> Guard technical lifecycle, Nukleoid
roles, Guard challenge handling, portable proof bundles, and the separation
between proof lifecycle finalization and block consensus finality.

Future edits may clarify wording, add implementation details, define compatible
API fields, or extend measured production parameters. They must not change the
core semantics of the v1.0 protocol without creating a new major protocol
version.

## 1. Protocol Positioning

Helixium is a proof-native Layer-1 protocol for verifiable digital evidence.

The public product message is:

```text
Create -> Prove -> Verify
```

The technical proof lifecycle is:

```text
Authorize -> Transfer -> Certify -> Guard
```

The protocol is not positioned as only a new coin, only a fast blockchain, or an
AI token. Block time, fixed supply, staking, validator operation, wallet support,
and explorer features are supporting properties. The core product is a chain
and proof system that lets users create, anchor, inspect, challenge, export, and
verify evidence.

## 2. Scope

This specification defines the Helixium v1.0 proof protocol surface:

- block-level assumptions;
- transaction and extrinsic structure;
- proof anchor structure;
- Nukleoid validator role model;
- A/T/C/G lifecycle transitions;
- validator assignment and quorum behavior;
- Guard challenge, fraud proof, invalidation, and slashing intent;
- portable proof bundle format;
- verifier endpoint expectations;
- cryptographic primitives and safety boundaries;
- failure and recovery behavior;
- versioning and presale freeze rules.

This document is deliberately separate from the whitepaper. The whitepaper
explains why Helixium matters. This specification defines how the protocol is
expected to behave.

## 3. Non-Goals

Helixium v1.0 does not claim that:

- DNA symbols replace binary cryptography;
- C in A/T/C/G replaces block consensus;
- ProofLifecycleFinalized means block-finality;
- an on-chain proof proves real-world truth by itself;
- AI-generated content is true, lawful, or non-deceptive;
- cross-chain portability means a trustless bridge is complete;
- adaptive testnet quorum is automatically safe for permissionless mainnet use.

Helixium proves recorded evidence state and detects inconsistency after evidence
creation. The protocol can prove that a digest, proof receipt, role lifecycle,
challenge state, and verifier-readable bundle were recorded and can be checked.

## 4. Terminology Lock

| Term | Canonical meaning |
| --- | --- |
| Helixium | A proof-native Layer-1 for verifiable digital evidence. |
| HLX | Native network token used for fees, staking, validator incentives, and protocol operations. |
| nucleo | Smallest HLX unit. Current policy: 1 HLX = 100,000,000 nucleo. |
| Helix Proof | A compact proof object built from a data digest, strand representation, checksum, lifecycle state, and verifier metadata. |
| Proof Anchor | On-chain record that binds a digest, checksum, creator, block context, lifecycle state, and portable bundle reference. |
| Nukleoid | A protocol-level validator role unit used in proof lifecycle verification. |
| A | Authorization. Verifies source authority, signer, origin, or permission context. |
| T | Transfer. Verifies payload movement, propagation, transaction inclusion, or bundle delivery context. |
| C | Certification. Verifies validator attestation, quorum context, and proof certification state. |
| G | Guard. Verifies digest integrity, strand/checksum consistency, challenge state, fraud evidence, and invalidation status. |
| A-T | Authorized Transfer link. Valid only when Authorization and Transfer are verified. |
| C-G | Certified Integrity link. Valid only when Certification and Guard are verified. |
| Consensus | Reserved for chain block consensus/finality only. It must not be used as the public meaning of C. |
| ProofLifecycleFinalized | Finalization of the proof lifecycle only. It is not block consensus finality. |
| Portable Proof Bundle | A verifier-readable package that lets external systems verify a proof without relying on a screenshot or a single website. |

Implementation compatibility note: current runtime storage may still contain
legacy keys such as `Consensus` or `ConsensusIntegrity`. Public APIs, explorer
labels, SDKs, documentation, and investor materials must expose these as
`Certification` and `CertifiedIntegrity` while preserving runtime compatibility
until a dedicated migration removes the legacy names.

## 5. Network Model

Helixium v1.0 is designed around a Substrate-based chain runtime with a native
HLX token and a proof lifecycle pallet.

The proof lifecycle is implemented at runtime level. It is not merely a website
graphic or off-chain marketing layer. Runtime storage and events are expected to
expose proof anchors, Nukleoid roles, stage voters, quorum state, validator
heartbeats, peer proof status, challenge state, fraud evidence, and lifecycle
finalization state.

The proof lifecycle is separate from the chain's block production and finality
engine. Aura, BABE, GRANDPA, or any future block consensus engine remains
responsible for producing and finalizing blocks. Helixium's A/T/C/G lifecycle
certifies proof evidence inside the chain's execution environment.

## 6. Block Structure

Helixium does not replace the normal block header model.

A Helixium block contains the normal Substrate block components:

- parent hash;
- block number;
- state root;
- extrinsics root;
- digest/log data required by the consensus engine.

Helixium-specific proof state is stored and updated by runtime execution. Proof
anchors and lifecycle events are included through extrinsics and runtime state,
not by inventing a custom block header format for v1.0.

The protocol can expose the following proof-related block context:

- anchor block number;
- lifecycle stage block numbers;
- ProofLifecycleFinalized block number;
- challenge open/resolution block numbers;
- compact receipt block;
- validator heartbeat block numbers.

## 7. Transaction and Extrinsic Model

A proof lifecycle begins when a user, application, wallet, SDK, or service
submits an anchor transaction.

Canonical extrinsic categories:

| Category | Purpose |
| --- | --- |
| `anchor_proof` | Create an on-chain proof anchor from digest, strand/checksum data, and metadata URI. |
| `sign_authorization` | Submit an Authorization role attestation. |
| `sign_transfer` | Submit a Transfer role attestation. |
| `vote_certification` | Submit a Certification role attestation. Runtime compatibility may still expose `vote_consensus`. |
| `sign_guard` | Submit a Guard role attestation if no unresolved challenge blocks finalization. |
| `validator_heartbeat` | Prove validator liveness for adaptive quorum and explorer visibility. |
| `register_validator_identity` | Register validator account, display name, endpoint, and peer identity metadata. |
| `verify_peer_proof` | Register a cryptographic peer-claim proof when available. |
| `open_guard_challenge` | Open a challenge against a proof after Certification and before Guard finalization. |
| `submit_fraud_proof` | Submit evidence against a challenged proof. |
| `resolve_guard_challenge` | Resolve the challenge as accepted or rejected under Guard quorum policy. |
| `finalize_proof_lifecycle` | Finalize a proof lifecycle after required roles, links, and challenge checks pass. |
| `compact_finalized_proof` | Replace verbose working state with a durable compact receipt after finalization. |

For public APIs and documentation, the C role must be called Certification even
if the current runtime method name remains `vote_consensus` for compatibility.

## 8. Proof Anchor Structure

A proof anchor binds a data object to on-chain lifecycle state.

Minimum anchor fields:

```text
proof_id
creator
digest
primary_strand
complementary_strand
helix_checksum
metadata_uri
anchor_block
lifecycle_enforced
portable_bundle_uri
```

The digest should be generated over canonical evidence bytes. The public proof
standard currently uses SHA-256 for evidence and bundle digests. Runtime storage
maps and Substrate internals may use the chain's native hashing algorithms for
keys, state roots, and trie operation.

The full evidence object should not be stored on-chain. The chain stores compact
commitments, lifecycle state, challenge state, and references to external
metadata or bundle storage.

## 9. Helix Proof Structure

A Helix Proof object contains:

```text
version
network
proof_id
creator
created_at
anchor_block
digest_algorithm
digest
primary_strand
complementary_strand
helix_checksum
lifecycle
links
challenge_state
finalization_state
portable_bundle_uri
```

The DNA-style strand representation is a deterministic proof encoding layer. It
is used to create a recognizable and checkable proof model, but it is not a
replacement for cryptographic hashing, signatures, Merkle state, or validator
attestations.

## 10. Nukleoid Role Model

A Nukleoid is the protocol's canonical role unit for proof lifecycle
verification.

Each proof may have four Nukleoid role records:

| Role | Name | Meaning |
| --- | --- | --- |
| A | Authorization | The source, signer, account, policy, or origin was authorized. |
| T | Transfer | The payload, transaction, or bundle moved through the expected transfer path. |
| C | Certification | Validator attestations certify the proof context under the configured quorum policy. |
| G | Guard | Integrity checks, challenge state, fraud evidence, and invalidation rules were evaluated. |

The roles are functional responsibilities. They are not permanently assigned to
fixed machines. A validator can participate in different roles at different
times if it is live, eligible, bonded if required, and selected by the runtime
or lifecycle worker policy.

## 11. Lifecycle State Machine

Canonical order:

```text
Created
-> AuthorizationPending
-> AuthorizationVerified
-> TransferPending
-> TransferVerified
-> CertificationPending
-> CertificationVerified
-> GuardPending
-> GuardVerified
-> ProofLifecycleFinalized
```

Challenge branch:

```text
CertificationVerified
-> GuardChallengeOpened
-> FraudProofSubmitted
-> GuardChallengeResolvedAccepted
-> ProofInvalidated
```

or:

```text
CertificationVerified
-> GuardChallengeOpened
-> FraudProofSubmitted
-> GuardChallengeResolvedRejected
-> GuardPending
-> GuardVerified
-> ProofLifecycleFinalized
```

Valid role statuses:

```text
Pending
Verified
Failed
Challenged
Invalidated
Slashed
Compacted
```

`ProofLifecycleFinalized` may be emitted only when:

- Authorization is verified;
- Transfer is verified;
- Certification is verified;
- Guard is verified;
- A-T link is verified;
- C-G link is verified;
- no active accepted Guard challenge invalidates the proof;
- required quorum and production safety policy are satisfied.

## 12. Pair-Link Rules

The lifecycle has two canonical links:

```text
A-T = Authorized Transfer
C-G = Certified Integrity
```

`A-T` is verified only after both Authorization and Transfer are verified.

`C-G` is verified only after Certification and Guard are verified. If a Guard
challenge is accepted, the `C-G` link must be invalidated and
`ProofLifecycleFinalized` must remain false.

Public labels must use `Certified Integrity`. Legacy runtime compatibility keys
may continue to reference `ConsensusIntegrity` until migration.

## 13. Validator Assignment

Helixium validators are not hardcoded as "validator 1 is A, validator 2 is T,
validator 3 is C, validator 4 is G."

The intended model is:

- every eligible validator can support A, T, C, and G;
- role participation is dynamic;
- assignment may be randomized or scheduled by proof ID, block context, validator
  set root, availability, and anti-repeat policy;
- the system should prefer maximum live validator participation;
- the same validator may sign more than one role when network conditions allow
  and policy permits it;
- a validator may be inactive for a given proof without blocking the network if
  quorum policy is satisfied.

Testnet behavior may allow a single live validator to complete A/T/C/G so the
chain can demonstrate liveness under severe failure. Production behavior must
define a stricter safety floor before permissionless mainnet.

## 14. Quorum Policy

Helixium distinguishes three quorum concepts:

| Quorum type | Meaning |
| --- | --- |
| Nominal quorum | Configured target under healthy network conditions. |
| Live quorum | Number of validators currently considered live by heartbeat policy. |
| Effective quorum | Runtime-enforced quorum for a specific proof stage after applying liveness and safety rules. |

Development and public demo mode may use adaptive effective quorum:

```text
effective_quorum = min(nominal_quorum, live_validator_count)
```

Production mode must support a non-zero safety floor:

```text
effective_quorum = max(production_floor, adaptive_target)
```

If live validators fall below the production floor:

- block production may continue if the chain consensus engine can continue;
- new proof lifecycles must not finalize;
- the verifier must report insufficient certification quorum;
- single-validator finalization must be disabled unless explicitly configured
  for a private deployment.

This separation is important: liveness and proof safety are different policies.

## 15. Guard, Challenge, Fraud Proof, and Invalidation

The Guard role is not a cosmetic final check. It is the dispute and integrity
boundary for a proof.

Guard must evaluate:

- digest consistency;
- primary/complementary strand consistency;
- Helix checksum consistency;
- active challenge status;
- submitted fraud evidence;
- challenge resolution votes;
- invalidation state;
- slash intent or bonded-stake slash where supported.

Challenge flow:

```text
CertificationVerified
-> open_guard_challenge
-> submit_fraud_proof
-> resolve_guard_challenge
```

If the challenge is accepted:

- the proof becomes Invalidated;
- Guard becomes Invalidated;
- C-G becomes Invalidated;
- ProofLifecycleFinalized remains false;
- eligible misbehaving validators may be slashed or marked for slash intent.

If the challenge is rejected:

- the challenge is closed;
- Guard may proceed;
- the challenger bond may be partially or fully slashed according to policy;
- the proof may finalize if all lifecycle rules pass.

For v1.0, slashing can operate in two modes:

| Mode | Meaning |
| --- | --- |
| Testnet slash intent | Runtime records that a slash would occur, but economic value may be simulated. |
| Bonded slash | Runtime reduces or locks validator bond according to configured staking policy. |

Production mainnet must not advertise strong economic security until bonded
staking, slashing limits, validator registry, appeal/governance procedure, and
audited slash conditions are complete.

## 16. Validator Identity and Peer Proof

A validator identity record should include:

```text
validator_account
display_name
endpoint
peer_id
active
registered_block
last_heartbeat_block
peer_proof_status
```

A stronger production model requires a cryptographic peer-claim signature:

```text
validator_account signs peer_id claim
peer private key signs challenge
runtime or verifier checks account signature and peer signature
```

Until this is enforced, public materials may say that validator identity,
endpoint, peer ID, heartbeat, and peer proof status are visible. They must not
claim that peer identity is fully cryptographically bound unless the signature
path is live and verified.

## 17. Portable Proof Bundle

Cross-chain proof portability is standardized as a verifier-readable proof
bundle. It is not described as a completed trustless bridge in v1.0.

Canonical bundle schema:

```json
{
  "standard": "helixium.portable_proof_bundle.v1",
  "network": "helixium",
  "proof_id": 0,
  "digest_algorithm": "sha256",
  "digest": "0x...",
  "creator": "account",
  "anchor_block": 0,
  "helix_checksum": "0x...",
  "nukleoid_roles": {
    "authorization": {"symbol": "A", "status": "verified", "voters": []},
    "transfer": {"symbol": "T", "status": "verified", "voters": []},
    "certification": {"symbol": "C", "status": "verified", "voters": []},
    "guard": {"symbol": "G", "status": "verified", "voters": []}
  },
  "links": {
    "authorized_transfer": {"symbols": "A-T", "status": "verified"},
    "certified_integrity": {"symbols": "C-G", "status": "verified"}
  },
  "challenge_state": {
    "active": false,
    "status": "none",
    "challenge_id": null
  },
  "finalization": {
    "proof_lifecycle_finalized": true,
    "finalized_block": 0
  },
  "validator_set_root": "0x...",
  "lifecycle_root": "0x...",
  "chain_reference": {
    "rpc": "https://helixium.org/substrate-rpc",
    "block_hash": "0x..."
  }
}
```

The bundle must be verifiable without trusting a screenshot. A verifier should
be able to recompute the digest and checksum, read or compare lifecycle state,
validate role/link status, and report challenge/finality boundaries.

## 18. Public Verifier API

Minimum public verifier endpoints:

```text
GET /proof/latest
GET /proof/{id}
GET /proof/{id}/bundle
GET /proof/{id}/verify
GET /proof/{id}/audit
GET /validators
GET /challenges
```

Verifier responses must distinguish:

- proof anchor existence;
- proof lifecycle finalization;
- block inclusion;
- block consensus/finality where available;
- current challenge state;
- invalidated proof state;
- validator votes;
- nominal quorum;
- effective quorum;
- live validators;
- peer proof status.

The verifier must not label a proof as fully verified if an accepted challenge
invalidates it or if a required production quorum floor was not satisfied.

## 19. Cryptographic Primitives

Helixium v1.0 uses conventional cryptographic primitives:

- SHA-256 for public evidence digest and proof bundle digest where specified;
- Helix checksum over canonical primary/complementary strand material;
- Substrate runtime hashing for storage keys, state trie operation, and runtime
  internals;
- account signatures for signed extrinsics;
- validator signatures or attestations for role votes;
- optional peer-claim signatures for validator peer identity binding;
- state roots and block hashes for chain context.

The protocol must treat cryptographic algorithms as versioned. Future upgrades
may add BLAKE2, Keccak, Merkle/MMR batching, BLS aggregation, or ZK proof
systems only through explicit versioned standards.

## 20. Storage and State Bloat Policy

Helixium must avoid storing large raw evidence on-chain.

On-chain storage should contain:

- digest;
- creator;
- anchor block;
- checksum;
- compact lifecycle state;
- quorum metadata;
- challenge status;
- compact receipt;
- bundle URI or content-addressed reference.

Off-chain storage may contain:

- original evidence;
- full metadata;
- large files;
- logs;
- images;
- AI prompt/output artifacts;
- external audit packages.

After lifecycle finalization, verbose working state may be compacted into a
durable receipt. Historical events should remain queryable through archive
nodes, indexers, or exported bundles.

Before production, storage deposits, compaction refunds, and benchmark-derived
weights must be defined.

## 21. Failure Handling

Validator failure:

- missing heartbeat removes a validator from the live validator count;
- effective quorum may adapt in testnet mode;
- production floor may block proof finalization if too few validators remain.

Stage failure:

- a stage remains Pending until enough valid attestations exist;
- invalid attestations are rejected;
- duplicate votes are rejected;
- unauthorized validators are rejected.

Challenge failure:

- Guard must not finalize a proof while an active challenge blocks finalization;
- accepted fraud invalidates the proof;
- rejected challenge returns the proof to the Guard path if other rules pass.

Network partition:

- block consensus handles block production and fork/finality rules;
- proof lifecycle must not confuse chain liveness with proof safety;
- verifier output must show insufficient quorum or unresolved challenge when
  applicable.

## 22. Recovery Behavior

After validator recovery:

- validators submit fresh heartbeats;
- live validator count updates;
- effective quorum recalculates;
- pending proofs may continue from their last verified stage;
- invalidated proofs remain invalidated unless explicit governance or appeal
  process exists;
- compact finalized proofs remain durable receipts.

The protocol must not silently rewrite proof history. Recovery resumes pending
state; it does not erase challenge, fraud, slash, or invalidation records.

## 23. Economic Rules

HLX may be used for:

- transaction fees;
- proof anchoring fees;
- validator staking;
- validator lifecycle participation rewards;
- Guard challenge bonds;
- fraud discovery rewards;
- slash penalties;
- storage deposits.

The maximum supply policy is:

```text
max_supply = 46,000,000 HLX
base_unit = nucleo
1 HLX = 100,000,000 nucleo
```

Exact fee and reward parameters must be benchmarked before mainnet. The protocol
must not assume validators perform extra A/T/C/G work for free.

## 24. Security Boundaries

Helixium provides:

- tamper-evident proof anchoring;
- explicit proof lifecycle state;
- visible role attestations;
- challenge and invalidation path;
- portable verifier-readable bundle;
- separation between proof lifecycle finalization and block finality.

Helixium does not provide by itself:

- legal truth of a document;
- factual truth of AI output;
- identity verification beyond the configured authorization and validator
  identity system;
- privacy for raw evidence if users publish it publicly;
- production economic security before staking and slashing are audited.

## 25. Product Acceptance Criteria Before Presale

Before any public presale, the following should be complete:

- Protocol Specification v1.0 approved and frozen;
- whitepaper terminology aligned with this specification;
- website terminology aligned with this specification;
- C exposed as Certification everywhere public-facing;
- public proof verifier route live;
- `/proof/{id}/bundle` live;
- `/proof/{id}/verify` live;
- explorer shows proof lifecycle state, validators, heartbeat, peer proof,
  nominal quorum, effective quorum, challenge state, and finalization state;
- testnet reliability report published;
- at least 3-validator live testnet proof run documented;
- target 4-validator testnet readiness documented if budget allows;
- wallet supports faucet, transfer, anchor proof, and proof read;
- known limitations listed honestly;
- no public claim that mainnet is live unless mainnet is actually deployed.

## 26. Versioning and Change Control

This specification is the v1.0 freeze baseline. After approval, changes must be
handled under explicit change control:

| Change type | Required version action |
| --- | --- |
| Typo or clarification | v1.0 patch note |
| Non-semantic wording improvement | v1.0 patch note |
| API field addition that preserves compatibility | v1.1 |
| Runtime storage migration that preserves public semantics | v1.1 |
| Runtime storage migration that breaks compatibility | v2.0 |
| A/T/C/G role semantic change | Not allowed without v2.0 |
| Nukleoid role model removal | Not allowed without v2.0 |
| ProofLifecycleFinalized meaning change | Not allowed without v2.0 |
| Quorum safety policy change | Governance/security note required |
| Proof bundle schema break | New bundle standard version required |
| Cryptographic primitive change | New algorithm version required |

After v1.0 is frozen, marketing, website, whitepaper, SDK, explorer, and
investor decks must follow this terminology.

The following v1.0 invariants are locked:

- Helixium is a proof-native Layer-1 for verifiable digital evidence.
- The public flow is Create -> Prove -> Verify.
- The technical lifecycle is Authorize -> Transfer -> Certify -> Guard.
- A means Authorization.
- T means Transfer.
- C means Certification.
- G means Guard.
- Consensus is reserved for block consensus/finality.
- ProofLifecycleFinalized finalizes the proof lifecycle only.
- A-T means Authorized Transfer.
- C-G means Certified Integrity.
- Nukleoid means protocol-level validator role unit.
- Portable Proof Bundle means verifier-readable proof package.
- Testnet adaptive quorum and production proof safety floor are separate
  policies.
- Raw evidence should remain off-chain; compact commitments, lifecycle state,
  challenge state, and receipts belong on-chain.

Any document, product screen, API response, pitch material, or whitepaper that
contradicts these invariants is considered out of date.

## 27. Gamma PDF Generation Prompt

Use the following prompt if this specification is converted into a polished PDF
with Gamma or a similar presentation/document tool:

```text
Create a professional A4 technical protocol specification PDF for Helixium.

Strict format rules:
- Use true A4 portrait pages only.
- Do not create long scrolling pages.
- Each page must fit inside a normal A4 printable page.
- Keep margins consistent.
- Use page numbers.
- Use American English.
- Keep the technical wording precise and conservative.
- Do not add marketing claims that are not in the source text.
- Do not mention social impact.
- Do not use C as Consensus. C must mean Certification.
- Consensus must be reserved for blockchain block consensus/finality only.
- ProofLifecycleFinalized must be described as proof lifecycle finalization only, not block finality.

Title:
Helixium Protocol Specification v1.0

Subtitle:
Layer-1 Protocol for Verifiable Digital Evidence

Core message:
Create -> Prove -> Verify

Technical lifecycle:
Authorize -> Transfer -> Certify -> Guard

Visual style:
Premium technical blockchain document. Dark navy, deep teal, white, and restrained gold accents. Use clean protocol diagrams, lifecycle state machines, compact tables, validator network diagrams, proof bundle JSON callouts, and subtle circuit/helix patterns. Avoid excessive decoration.

Logo guidance:
Use a gold geometric Helixium H mark: two tall angular bracket-like outer pillars forming an H silhouette, with a sharp lightning/helix-like central zigzag stroke. Metallic gold outline, clean premium blockchain style, no Bitcoin symbols, no copied coin text, no unrelated brand marks.

Required sections:
1. Protocol Positioning
2. Scope and Non-Goals
3. Terminology Lock
4. Network Model
5. Block Structure
6. Transaction and Extrinsic Model
7. Proof Anchor Structure
8. Helix Proof Structure
9. Nukleoid Role Model
10. A/T/C/G Lifecycle State Machine
11. Pair-Link Rules: A-T and C-G
12. Validator Assignment
13. Adaptive Quorum and Production Safety Floor
14. Guard, Challenge, Fraud Proof, and Invalidation
15. Validator Identity and Peer Proof
16. Portable Proof Bundle
17. Public Verifier API
18. Cryptographic Primitives
19. Storage and State Bloat Policy
20. Failure Handling
21. Recovery Behavior
22. Economic Rules
23. Security Boundaries
24. Product Acceptance Criteria Before Presale
25. Versioning and Change Control

Important content constraints:
- Say Helixium is a proof-native Layer-1 for verifiable digital evidence.
- Say the public product flow is Create -> Prove -> Verify.
- Say the technical proof lifecycle is Authorize -> Transfer -> Certify -> Guard.
- Define Nukleoid as the protocol-level validator role unit.
- Explain that every eligible validator may support A, T, C, and G; validators are not permanently assigned to one role.
- Explain that testnet adaptive quorum may allow degraded operation, but production must define a non-zero safety floor.
- Explain that raw evidence should stay off-chain and only compact commitments, lifecycle state, challenge state, and receipts should be on-chain.
- Explain that portable proof bundles are verifier-readable proof packages, not a completed trustless bridge.
- Explain that current implementation may retain legacy runtime keys such as Consensus for compatibility, but public-facing terminology must expose Certification.
- Include a presale readiness checklist and state that protocol terminology must be frozen before public presale.
```