HelixiumTechnical Whitepaper

TECHNICAL WHITEPAPER V1.1 · PRE-MAINNET

Helixium (HLX) Technical Whitepaper v1.1

The formal technical overview of Helixium's proof-native Layer-1 architecture, A-T-C-G proof lifecycle, validator authority model, security boundaries, portable verification, HLX economics, and governed network evolution.

Download Whitepaper PDF Protocol Specification
Network thesisProof-native Layer-1Structured, portable verification for digital evidence.
Core modelA / T / C / GAuthorization, Transfer, Certification, and Guard.
Maximum-supply policy target46,000,000 HLXPermanent runtime enforcement is pending.
Public flowCreate - Prove - VerifyA concise path from evidence creation to independent verification.

Whitepaper v1.1 includes the seven-category 46,000,000 HLX mainnet planning allocation and the Helixium +1 program. Explore the tokenomics summary.

01

WHY HELIXIUM

Verification should be a lifecycle, not a timestamp.

Conventional hash anchoring can prove that a document existed at a given block height, but it cannot fully describe who authorized it, how its context moved, who certified its integrity, whether it passed security controls, or whether it was later challenged.

Helixium treats proof objects as first-class runtime entities. Their lifecycle state, transition history, validator actions, and integrity status can be queried across the network. Raw source documents are not intended to be stored on-chain; the runtime may retain compact proof records, account data, role assignments, and other protocol state.

Lifecycle visibilityCreated, granted, transferred, archived, or invalidated.
Role accountabilityEvery transition records the responsible Nukleoid role.
Portable verificationProof bundles can be checked without depending on the issuing UI.
Compact proof dataSource documents stay with the responsible party; protocol records may be on-chain.
02

PROTOCOL ARCHITECTURE

Two views of one proof-native system.

AAuthorizationIdentity, signature, permission, nonce, and request validation.
TTransferPacket, routing, synchronization, and transfer-integrity validation.
CCertificationHash, receipt, timestamp, Merkle commitment, and certificate validation.
GGuardPolicy, evidence, state, challenge, quorum, and decision validation.
A
Authorization

Verifies public keys, signatures, permissions, nonce state, sessions, and request eligibility.

T
Transfer

Verifies packet construction, transport integrity, routing, synchronization, and retry state.

C
Certification

Builds and validates hashes, proof receipts, timestamps, Merkle commitments, and certificates.

G
Guard

Applies deterministic policy, evidence, state, challenge, quorum, and decision controls.

Full Engine Availability ≠ Full Decision Authority

Every validator may evaluate the complete A-T-C-G engine stack locally, but only an eligible validator assigned to a role may issue its authoritative attestation. Local evaluation is not a network decision, and ProofLifecycleFinalized does not mean block-consensus finality.

03

PORTABILITY & INTEGRITY

Verification that can leave the originating application.

PORTABLE PROOF BUNDLE

Self-contained evidence context

  • Unique proof identifier and compact receipt
  • Current lifecycle state
  • Ordered role and validator audit trail
  • Block references for every transition
  • Bundle integrity information
1
Challenge

A Guard may suspend progression and open review.

2
Evidence

Fraud evidence is committed with an auditable reference.

3
Review

Validators attest or contest under the required quorum.

4
Resolution

The lifecycle resumes or the proof becomes permanently invalid.

Deterministic core, extensible observations

External risk, malware, anomaly, reputation, or enterprise analyzers are an architectural extension. Signed observations must not directly control chain state; production deployment, security review, and governance policy remain mainnet-readiness requirements.

PUBLIC VERIFICATION/proof/:id/bundle/proof/:id/verify

API-assisted verification without the original interface. Independent offline verification is planned, not yet deployed.

04

NETWORK & ROADMAP

Fixed-supply economics and governed network evolution.

NATIVE COIN46,000,000 HLX

Mainnet maximum-supply policy target. Permanent enforcement and independent verification remain pending; the current testnet retains Sudo/Root authority.

Base unit
nucleo
Precision
10-8 HLX
Utility
Fees, proof operations, validator bonding, governance
  1. FoundationProof lifecycle coreA-T-C-G state machine, proof objects, compact receipts, and portable bundles.
  2. ExpansionValidator architectureEligibility, deterministic role assignment, heartbeat, timeout, and reassignment.
  3. HardeningSecurity and conformanceThreat-model coverage, SDK, CLI, benchmarks, monitoring, and independent review.
  4. Economic securityGoverned validator participationBonding, slashing hooks, governance controls, audits, and broader operator onboarding.
Security boundary: Validator expansion, economic penalties, governance controls, and production readiness require explicit conformance, audit, and deployment gates. The architecture does not claim attack immunity or unconditional decentralization.
COMPLETE TECHNICAL DOCUMENT

Read the full 34-page whitepaper offline.

Includes the Spec-121 testnet status, fee/rewards vault, mainnet planning allocation, validator model, roadmap, risk disclosures, FAQs, and glossary.

Download PDF v1.1
Document status and scope

This publication describes the Helixium technical model and intended protocol direction. Architectural goals must not be interpreted as an audited security guarantee, unconditional decentralization, regulatory approval, or an offer of financial return. The Protocol Specification remains the terminology authority for frozen protocol definitions.