Post-Quantum Signature Layer Falcon-512 Implementation

Why Atho chose Falcon-512 and how we made it practical.

Atho uses Falcon-512 to move beyond elliptic-curve-only security assumptions while still keeping transaction handling practical through SegWit-style sizing and compact binary encoding. This keeps operations in a Bitcoin/Litecoin-style UTXO workflow model while upgrading signature security assumptions.

Download Falcon Spec Download Tx Spec Download SegWit Spec Open BPoW

Active Falcon Constants

Canonical pubkey size 897 bytes (legacy 1024 bytes acceptance disabled by default).
Compressed signature target 666 bytes with consensus acceptance window 600..690 bytes.
Consensus verification path Witness size checks run before signature verify through Falcon CLI and policy-controlled verifier paths.
Binary hardening Pinned Falcon binaries and strict runtime checks protect signing/verification integrity.

Falcon vs Elliptic Curve

Lattice signatures and elliptic signatures have different strengths and size profiles.

Falcon-512 is lattice-based and selected for post-quantum resilience. Classical ECC signatures are smaller, but they rely on assumptions vulnerable to large-scale quantum attacks. Atho favors long-run security, then optimizes transaction structure to keep operations practical.

Security Model Contrast

Falcon-512 is designed for post-quantum threat models, while classical elliptic signatures target classical adversaries.

Threat-Model Driven Choice

Signature and Key Size Visual

Primitive-size comparison (not full transaction size): Falcon elements are larger, so Atho compensates through transaction layout and witness accounting.

Falcon signature

~666 B

ECC signature (typical)

~64-72 B

Falcon pubkey

897 B

ECC pubkey (compressed)

33 B

Atho consensus enforces Falcon witness size bounds before verify, keeping validation deterministic.

Consensus Size Policy

Implementation Pipeline

Atho keeps the signing path explicit: deterministic digesting, witness policy checks, and verified runtime binaries.

Deterministic Validation Path

The Breakthrough: SegWit-Style Sizing + Compact Encoding

The key breakthrough is not shrinking Falcon itself. The breakthrough is Atho’s transaction envelope: SegWit-style vsize accounting, compact binary transport (ATX2), compact input signature reference tokens, and witness separation. This keeps day-to-day transaction behavior in a practical UTXO operating range.

SegWit metric model weight = base_bytes * 3 + total_bytes, then vsize = ceil(weight/4).
Compact field strategy Inputs avoid embedding full signature blobs in base fields; witness carries raw signature/pubkey bytes.
Result Atho remains operationally comparable to Bitcoin/Litecoin-style UTXO workflows while using post-quantum signatures.

Current Reference Transaction Sizes

Shape vsize TPS @ 120s

1 in / 1 out ~513 vB ~56.86 TPS

1 in / 2 out ~566 vB ~51.53 TPS

2 in / 2 out ~615 vB ~47.43 TPS

3 in / 2 out ~664 vB ~43.93 TPS

These values are reference estimates from the current docs for compressed witness, no-metadata paths. The goal is practical fee-market behavior in the same operational class users expect from Bitcoin/Litecoin UTXO systems, even with larger Falcon witness primitives.

Post-quantum signatures, practical transaction operations.

Atho combines lattice-based signing, deterministic policy enforcement, and compact transaction engineering so the chain remains secure-forward and operationally efficient.

Falcon-512 witness target ~666 B Canonical Falcon pubkey 897 B SegWit-style vsize policy ATX2 compact binary codec Runtime binary pinning controls

Open References

Falcon Integration Doc Runtime model, byte policy, signing/verification flow, and binary pinning.
Transaction + SegWit Docs Full vsize rules, representative tx shapes, and throughput formula references.

Falcon Docs PDF Tx Docs PDF SegWit Docs PDF Open Docs Hub