SmartHoldem Post-Quantum Node v0.25.48·Latest release

SmartHoldem · Web 4.0 Ecosystem

SmartHoldem Blockchain: Web 4.0 & Post-Quantum Security

Innovative DPoS Blockchain Infrastructure

SmartHoldem is the decentralized trust and settlement layer for Web 4.0. Rewritten from the ground up in Rust, it delivers a P2P architecture with built-in NAT traversal and quantum resilience.

SmartHoldem Web 4.0 P2P node mesh: servers, laptops, phones and home devices

Hover to see nodes. Home or server. One mesh.

Speed & Scale

Built for Speed and Scale

SmartHoldem's new Rust core breaks traditional blockchain limits: Node.js and PostgreSQL bottlenecks are replaced with an optimized engine and Sled DB, delivering lightning-fast sync and massive throughput.

Millisecond Block Processing

Blocks of 500 transactions are verified and applied in ~50 ms. Powered by a BFT finality gadget and parallel processing, the network achieves absolute, irreversible finality in just 1 slot (~8 seconds).

True Serverless Scalability

Powered by the Iroh P2P protocol. No centralized cloud providers needed, but you can run your own node. Any laptop, Raspberry Pi, or ARM64 mobile device can be a full, validating node behind any NAT, without a static IP.

Eco-Friendly & Lightweight

A full validating node now runs on just ~800 MB of RAM. DPoS combined with Rust's zero-cost abstractions makes this the most energy-efficient networks in existence.

Performance benchmarks

Benchmarks

Performance Benchmarks

Real-world load testing on the new Rust core confirms enterprise-grade, Visa-class scalability.

Performance is measured, not claimed. The following benchmarks reflect the new Rust + Sled architecture with parallel signature verification (Rayon) and optimized cryptographic pipelines:

256

MultiPayments per TX

5.53B

Ops / Day (peak)

ConfigurationOps / SecondOps / HourOps / Day
2000 TX/block (MultiPayments)64,000230.4M5.53B
1000 TX/block (MultiPayments)32,000115.2M2.76B
500 TX/block (MultiPayments)16,00057.6M1.38B

Under the Hood

Technical Stack

Core Blockchain Engine

  • Language: 100% Rust with parallel signature verification (Rayon), memory safety and zero-cost abstractions.
  • Database: Embedded Sled key-value store with zstd compression = 11.7M+ blocks in ~8 GB, replacing legacy PostgreSQL dependencies.
  • Consensus: DPoS with 21 active delegates, enhanced by a BFT finality gadget (deterministic finality in 1 slot).
  • Cryptography: Hybrid security model. Classic secp256k1 (BIP-Schnorr) + post-quantum ML-DSA-44 (NIST FIPS 204) via Quantum Shield.

API, SDK & SmartNet

  • Developer Bridge: Native window.smartholdem IPC for Tauri dApps. Secure, sandboxed access to signing, P2P storage, and network state.
  • Programmable Objects: Native SmartObjects & Tokens. Registries, issuance, zero smart-contract overhead and no EVM risks.
  • Data Storage: BLAKE3 content-addressed verification. Metadata anchored on-chain in SmartNetData, absolute integrity, with no external indexers.
  • API & SDK: 100% backward-compatible RESTful API + SDK. Real-time QUIC push streams for instant, polling-free updates.

Web 4.0 P2P Transport

  • Protocol: Built on Iroh (QUIC/UDP), providing encrypted, multiplexed connections with native NAT traversal and hole-punching. Nodes can produce and sync blocks from behind home routers without a static IP.
  • Network Topology: Dual-stack architecture. Primary communication occurs over the decentralized Iroh mesh, while a legacy WebSocket/Protobuf bridge (port 4001) is maintained strictly for backward compatibility with nodes on servers.
  • Decentralized Discovery: Peer discovery relies on Mainline DHT, local mDNS, and a cryptographically signed Peer Address Book, eliminating any dependency on centralized DNS or public relay services.

True Decentralization

Governed by the Community, Not Corporations

Decentralization is fundamental. The SmartHoldem DPoS blockchain is immutable, and all operations are irreversible. Any transaction is transparently available for viewing on the Block Explorer or via API at any time.

  • Democratic Voting

    Validators are chosen based on reputation, not centralized control.

  • No Frozen Coins

    Users vote with the power of their balance. Coins remain under complete user control.

  • Accountability

    Any STH holder can vote, elect, or cancel delegates. Ineffective delegates are swiftly replaced by the community.

  • Ownership

    Holding just >1 STH grants full voting rights on the network.

Community governance
21 delegates ring topology

The Delegate System

The TOP 21: Securing the Network

Delegates (also known as witnesses or block producers) are responsible for verifying transactions, creating new blocks, and protecting the SmartHoldem network. They cannot alter or influence transaction data.

21

Active Delegates in TOP

8s

Average Block Time

100%

Community Voted

0%

Centralized Control

The delegation system is highly competitive. A delegate can move into or out of the TOP 21 at any time. This sustainable scheme provides an opportunity for new delegates to prove themselves and attract the community's attention.

Economics

Sustainable Rewards. Zero Inflationary Emission.

There is no emission in the SmartHoldem (DPoS) blockchain. Delegates receive rewards exclusively from transaction fees, ensuring a deflationary, sustainable economic model.

The delegate who signs the block receives ALL NETWORK FEES for the transactions included in that block.

How Delegates Earn

500 STH

per block (max)

500 standard transactions in a block → up to 500 STH earned.

10,000 STH

registration fee

Delegate registration transaction → 10,000 STH earned.

500 STH

token issuance

50% of the fee is burned

Each new Web4 native token launch earns the delegate a reward.

Advanced Transaction Types

SmartHoldem supports a rich ecosystem of transaction types, generating diverse fee revenue:

Multi-paymentsGamingMulti-signaturesCrypto-signaturesSecond passphraseBurnHTLCCopyright registrationPQ Second SignatureName RegistrationEncryptedMemoConfidential TransfersMulti-Signature EscrowPaid MessagesSmartObjectsTokenMintSubscriptions
List of fees in the SmartHoldem blockchain

Participate

Become a SmartHoldem Delegate

Securing the network is no longer limited to corporate data centers. With the new Rust core and Iroh P2P transport, anyone can run a validating node and participate in consensus from anywhere in the world.

Recommended Node Specs

8 GB RAM, 4 CPU Cores, 64 GB HDD or 32 GB SSD.

  1. 1

    Register & Enter the Race

    Securing the network is no longer limited to corporate data centers. With the new Rust core and Iroh P2P transport, anyone can run a validating node and participate in consensus from anywhere in the world.

  2. 2

    Setup Your Node (No Static IP Needed)

    Download the lightweight sth-core-pq binary. It runs on just ~800 MB of RAM and ~8 GB of disk space. Thanks to Iroh QUIC NAT traversal, you do not need a static IP or open ports — produce blocks securely from your laptop, Raspberry Pi, or a server.

  3. 3

    Announce your delegate candidacy

    Submit a proposal in the Community Forum detailing your network configuration, proposed payout percentage, and additional services. Then introduce your delegate to the community via Telegram and active outreach.

  4. 4

    Earn Real Yield

    Earn 100% of the network fees from the blocks you produce. With zero inflationary emission, your rewards are backed by real network utility: transfers, token launches, name registration, P2P storage, dVPN relays, etc.

  5. 5

    Engage & Grow the Ecosystem

    Delegates are chosen by the community. Build trust by offering transparent reward sharing, running public Netfory seeders, or actively contributing to the Web 4.0 ecosystem.

How to become a SmartHoldem delegate: 8 GB RAM node, install, register 10,000 STH, declare, get votes into Top 21

Community

Community Connection

As a delegate, active participation and connection to the community is vital to getting votes. Generating delegate slots is competitive and requires more than node management.

Building new applications based on SmartHoldem

Offering code reviews and vulnerability reporting

Community outreach and education

Offering a percentage of rewards to voters (to reach TOP 21)

Reward is measured based on the voter's participation share and the delegate's payout percentage.

Quantum Shield

SmartHoldem Quantum Shield

How We Protect the Blockchain from Future Computers

While the market discusses charts, a threat capable of nullifying classical cryptography is maturing. Shor's algorithm on a sufficiently powerful quantum computer could break ECDSA — the mathematical foundation of most blockchains today. SmartHoldem is not waiting for a hypothetical 'Day X'.

We are building the shield today. Stage A (Post-Quantum Key Commitments) is already ACTIVE in the mainnet.

Quantum Shield

Roadmap

Implementation Plan: Hybrid Model

We rule out abrupt hard forks and forced mass migrations. The transition to quantum resilience is gradual, seamless, and backward-compatible:

P1

Phase 1

Key Commitments (Active)

  • Users can already anchor the SHA-256 hash of their future ML-DSA-44 public key via the vendorField (sthpq1:...).
  • This prevents 'race condition' attacks when Phase 2 activates, securing the wallet before the quantum threat materializes.
P2

Phase 2

Hybrid Second Signatures (Accepted)

  • Users can register a post-quantum ML-DSA-44 public key (NIST FIPS 204) as a second signature on their existing wallet.
  • From that moment, every transaction requires two signatures: the classic secp256k1 one and the new quantum-resistant one.
  • The classic key stays active for full compatibility, while the post-quantum key adds a quantum-resistant second layer — forming a robust hybrid scheme that protects your assets even if either algorithm is compromised.
P3

Phase 3

Full Network Resilience (Planned)

  • All 21 active delegates sign blocks with post-quantum signatures to prevent consensus spoofing.
  • The Iroh P2P transport layer uses hybrid key exchange (X25519 + ML-KEM-768) to secure messenger and dApp data (SHIP-40).

Architecture

Upgrade the Lock, Not the Vault

Unlike other networks that require users to create new wallets and mass-transfer assets, SmartHoldem leverages its unique second-signature architecture for a seamless quantum upgrade.

1

Address Formation

Your SmartHoldem address is derived from your classic secp256k1 public key. This remains unchanged.

2

Second Key Activation

You register your post-quantum ML-DSA-44 public key as a second signature on your existing address.

3

Hybrid Protection

Every transaction now requires both the classic and the post-quantum signature to be valid.

The Result

  • You do not need to change your wallet or address
  • Your coins stay exactly where they have been for years
  • No complex wallet migrations
  • Your account is now protected by a dual cryptographic layer
  • Even if a quantum computer derives your first private key, it cannot move your funds without the valid second (quantum-resistant) signature

For users on a single signature: You can activate a second signature at any time to instantly enable quantum protection, or migrate to new quantum-safe address types in the distant future.

Deep Tech

Technical Nuances & Network Protection

Delegates Under Protection

  • In a DPoS network, delegates sign blocks
  • Compromised delegate signatures threaten the entire blockchain's integrity
  • Implementing PQC at the protocol level makes SmartHoldem a "digital fortress" resistant to consensus spoofing

Optimized Signature Size

  • We selected ML-DSA-44 (NIST FIPS 204) for its optimal balance: ~2.4 kB signatures and sub-millisecond verification
  • The Rust core's parallel processing (Rayon) ensures these heavy transactions are verified instantly without losing sync speed

Algorithmic Agility

  • The protocol includes an alg_id byte in PQC objects
  • This allows seamless future upgrades (e.g., to FN-DSA-512 / Falcon) without requiring users to change addresses or migrate funds
  • For the user, this looks like a familiar wallet

Development

Code in Progress

The Rust core (sth-core-pq) already includes the cryptographic foundation for the new verification layer. Here is a glimpse of the hybrid integration:

RUST · STH-CORE-PQ · hybrid secp256k1 + ML-DSA-44
//! Quantum Shield: ML-DSA-44 (NIST FIPS 204) keys derived from a passphrase, plus the stage-A

//! commitment format (`sthpq1:<alg>:<sha256(pk)>` in a self-transfer vendorField). See docs/SPEC-PQ-V3.md.


use crate::error::{Error, Result};
use ml_dsa::{EncodedSignature, EncodedVerifyingKey, MlDsa44, Signature, SigningKey, VerifyingKey, B32};
use sha2::{Digest, Sha256};

/// Algorithm ids (first byte of every PQ object).

pub const ALG_ML_DSA_44: u8 = 0x01;
pub const PK_LEN: usize = 1312;
pub const SIG_LEN: usize = 2420;
/// Domain separation for the ML-DSA context string.

const CTX: &[u8] = b"sth-pq-v1";
/// Context of stage-C block signatures (`M_B = sha256(header || blockSignature)`).

pub const BLOCK_CTX: &[u8] = b"sth-pq-block-v1";
/// Commitment prefix in vendorField.

pub const COMMITMENT_PREFIX: &str = "sthpq1:";

pub struct PqKeyPair {
    signing: SigningKey<MlDsa44>,
}

impl PqKeyPair {
    /// Deterministic: seed ξ = sha256("sth-pq-v1" || passphrase). Same passphrase → same key on every device.

    pub fn from_passphrase(passphrase: &str) -> Self {
        let mut h = Sha256::new();
        h.update(CTX);
        h.update(passphrase.as_bytes());
        let seed: [u8; 32] = h.finalize().into();
        Self::from_seed(&seed)
    }

    pub fn from_seed(seed: &[u8; 32]) -> Self {
        Self { signing: SigningKey::<MlDsa44>::from_seed(&B32::from(*seed)) }
    }

    /// FIPS 204 pkEncode — 1 312 bytes.

    pub fn public_key(&self) -> Vec<u8> {
        self.signing.expanded_key().verifying_key().encode().to_vec()
    }

    pub fn public_key_hex(&self) -> String {
        hex::encode(self.public_key())
    }

    /// Deterministic ML-DSA-44 signature (2 420 bytes) over `message` with the sth context.

    pub fn sign(&self, message: &[u8]) -> Result<Vec<u8>> {
        self.sign_with_ctx(message, CTX)
    }

    pub fn sign_with_ctx(&self, message: &[u8], ctx: &[u8]) -> Result<Vec<u8>> {
        let sig = self.signing.expanded_key().sign_deterministic(message, ctx).map_err(|_| Error::Serialization("ml-dsa sign".into()))?;
        Ok(sig.encode().to_vec())
    }

    /// What a wallet publishes in stage A: `sthpq1:01:<sha256(pk) hex>`.

    pub fn commitment(&self) -> String {
        commitment_for_public_key(&self.public_key())
    }
}

pub fn commitment_hash(public_key: &[u8]) -> [u8; 32] {
    Sha256::digest(public_key).into()
}

pub fn commitment_for_public_key(public_key: &[u8]) -> String {
    format!("{COMMITMENT_PREFIX}{:02x}:{}", ALG_ML_DSA_44, hex::encode(commitment_hash(public_key)))
}

pub fn verify(public_key: &[u8], message: &[u8], signature: &[u8]) -> Result<bool> {
    verify_with_ctx(public_key, message, signature, CTX)
}

pub fn verify_with_ctx(public_key: &[u8], message: &[u8], signature: &[u8], ctx: &[u8]) -> Result<bool> {
    if public_key.len() != PK_LEN || signature.len() != SIG_LEN {
        return Ok(false);
    }
    let pk = EncodedVerifyingKey::<MlDsa44>::try_from(public_key).map_err(|_| Error::Serialization("ml-dsa pk".into()))?;
    let sig = EncodedSignature::<MlDsa44>::try_from(signature).map_err(|_| Error::Serialization("ml-dsa sig".into()))?;
    let Some(sig) = Signature::<MlDsa44>::decode(&sig) else { return Ok(false) };
    Ok(VerifyingKey::<MlDsa44>::decode(&pk).verify_with_context(message, ctx, &sig))
}

/// Stage B: PQ public key registered by a wallet (type 1, v3). Lives in `WalletState.pq_key`, so undo is automatic.

#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct PqKey {
    pub algorithm: u8,
    /// Raw PQ public key, hex (1 312 bytes for ML-DSA-44).

    pub public_key: String,
    pub since: u64,
}

/// Parsed stage-A commitment.

#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct PqCommitment {
    pub algorithm: u8,
    /// sha256(public key), hex.

    pub commitment: String,
    pub height: u64,
}

/// `sthpq1:<alg 2 hex>:<64 hex>` → (alg, hash hex). Only known algorithm ids are accepted.

pub fn parse_commitment(vendor_field: &str) -> Option<(u8, String)> {
    let rest = vendor_field.strip_prefix(COMMITMENT_PREFIX)?;
    let (alg, hash) = rest.split_once(':')?;
    if alg.len() != 2 || hash.len() != 64 || !hash.bytes().all(|b| b.is_ascii_hexdigit() && !b.is_ascii_uppercase()) {
        return None;
    }
    let alg = u8::from_str_radix(alg, 16).ok()?;
    (alg == ALG_ML_DSA_44).then(|| (alg, hash.to_string()))
}

Quantum supremacy is not the end of cryptography, but its next evolutionary stage. We are choosing mathematics that cannot be 'solved' by brute force and integrating it directly into the core of our Web 4.0 DPoS network. The future is already here. And it is secured. The future is already here. And it is secured.

Join the Network

Your Node. Your Rules. Your Web 4.0.

You can secure the network in many ways: produce blocks as a delegate, seed dApps as a Netfory operator, run a dVPN relay, or simply hold and vote. There is zero inflation, real utility rewards, and a quantum-resistant foundation built in Rust. The decentralized internet needs builders — and it starts with you.