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.

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.

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)
| Configuration | Ops / Second | Ops / Hour | Ops / Day |
|---|---|---|---|
| 2000 TX/block (MultiPayments) | 64,000 | 230.4M | 5.53B |
| 1000 TX/block (MultiPayments) | 32,000 | 115.2M | 2.76B |
| 500 TX/block (MultiPayments) | 16,000 | 57.6M | 1.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.


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:
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
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
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
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
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
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.

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.

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:
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.
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.
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.
Address Formation
Your SmartHoldem address is derived from your classic secp256k1 public key. This remains unchanged.
Second Key Activation
You register your post-quantum ML-DSA-44 public key as a second signature on your existing address.
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:
//! 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.

