KVANTA5 is the world's first SHA-256 proof-of-work settlement chain secured by NIST FIPS 204 ML-DSA-87 quantum-resistant signatures from Genesis. Every transfer is protected at Security Level 5 — with 6-minute finality.
Whether you are moving funds for the first time or the thousandth, the process is the same — straightforward on the surface, rigorously secured at every layer below it.
01
Create Address
Generate your quantum-resistant KV5 wallet address. No central authority. Your keys, your funds.
02
Initiate Transfer
Enter the recipient address and amount. Set your fee priority. Review and confirm.
03
Network Validates
Your transaction enters the mempool. Miners confirm it in the next block — typically under 60 seconds.
04
Settled in 6 min
After 6 block confirmations, your transfer is irreversibly settled. Track it in real time.
02 // Why KVANTA5
The architecture of permanence
Three battle-tested technologies. One unified settlement layer. No novel cryptographic assumptions. No experiment. Just proven components, precisely assembled.
LAYER 01
⬡
SHA-256 Proof of Work
The same consensus mechanism that has secured trillions in value since 2009. ASIC-compatible, commodity-classified, and battle-hardened against all known attacks.
LAYER 02
🔐
ML-DSA-87 Signatures
Every transaction is signed with NIST FIPS 204 Level 5 quantum-resistant cryptography from the very first block. Not added later — built in from genesis. Future-proof by design.
LAYER 03
⚡
DGW Style DAA
Adaptive difficulty recalibrates every block using a 24 block window with a ±300% per-block cap. Block times remain stable under extreme hashrate fluctuations.
ASSURANCE
○
Fixed Supply Cap
231,000,000 KV5, hard-capped at the protocol level. No inflation, no discretionary issuance. Full supply schedule documented in the Technical Prospectus.
Against Quantum Attacks
Protected
From block #0 — not patched in later
Settlement Speed vs Bitcoin
10× Faster
6 min vs 60 min average
Total Supply
231,000,000
KV5 — permanently hard-capped
Attack Neutralization
5 blocks
~5 minutes to isolate bad actors
Settlement Network
Track Your Transfer
Enter a Transaction ID or Wallet Address to see the current status of your transfer
Paste your full transaction hash or the sending / receiving address
—
Last updated: just now
Transfer Progress
0%—100%
○
Step 1 — Received
Your transaction was received and accepted by the network nodes
For node operators, pool operators, miners & infrastructure partners
Infrastructure Requirements
KVANTA5 was built to move large value at high throughput with post-quantum signatures — not to run comfortably on a leftover box. This is what real participation actually costs in compute, memory, storage, and bandwidth, and why.
STATUS · ACTIVE — MAINNETAUDIENCE · OPERATORS / MINERS / POOLSSIGNATURE · ML-DSA-87
Block Interval
60s
fixed target
Max Block Size
32 MB
vs ~1 MB, comparable PoW chains
Signature Scheme
ML-DSA-87
Dilithium · FIPS 204 Level 5
Signing Cost / TX
1–5ms
≈10–100× heavier than ECDSA chains
01 — THE CLOCK
The 60-Second Budget
Every block has sixty seconds to be built, fragmented, encrypted, transmitted, reassembled, validated, and rebroadcast network-wide before the next one is due. This is the constraint everything else here is sized against.
Block propagation cycle, single hop
window: 60.0s target · margin matters more than average case
FRAGMENT
ENCRYPT ×5
TRANSMIT
REASSEMBLE
VALIDATE
REBROADCAST
01
Sender splits the assembled block into 5 chunks
02
Each chunk is encrypted independently
03
All 5 encrypted chunks transmit to each peer
04
Receiver decrypts and reassembles into one block
05
Full ML-DSA-87 signature validation, every input
06
Validated block relays onward to the next peer set
Bitcoin-class chains broadcast a block as a single message and validate with ECDSA at sub-millisecond cost per signature. KVANTA5 does five times the message handling per hop and roughly 10–100× the per-signature compute at up to 32× the payload size. None of those multipliers are optional, and none of them shrink the clock.
02 — COMPARISON
Why This Isn't Bitcoin-Class Hardware
Three design decisions compound against each other. Each one alone would be manageable. Together, they define a different class of machine.
Factor
Bitcoin-class PoW chain
KVANTA5
Max block size
~1–4 MB effective
32 MB
Block interval
600s (10 min)
60s
Signature scheme
ECDSA (secp256k1)
ML-DSA-87 (Dilithium, FIPS 204 L5)
Sign time, single input
~0.05–0.30 ms
~1–5 ms
Bytes per signed input
~108 bytes
~7,219 bytes (≈67×)
Block transmission
single message
5-chunk fragment / encrypt / reassemble
Third-party software
Bitcoin forks generally work
must be purpose-built for KV5
03 — DEPLOYMENT
Infrastructure Tiers
Not every role on the network carries the same load. A wallet checking a balance and a relay node propagating max-size blocks to forty peers are not the same hardware problem. Pick the tier that matches what you're actually running.
This tier is in the direct path of "did the block reach the network in time." No shared-tenant virtualization, no exceptions. Dedicated, bare-metal-class hardware only.
CPU
1× minimum, 2× preferred — 12+ core, AMD preferred, large L1/L2/L3 cache. 2nd-gen EPYC as a starting baseline.
Memory
32 GB DDR4 minimum. Required for signature verification handling and batch transaction signing under load.
Storage
1 TB SSD minimum. Multi-TB RAID arrays preferred, and required by month 6 of operation.
Network
1 Gbps+ low-latency fiber minimum, 10 Gbps+ preferred. Burst-shaped or contended bandwidth is disqualifying.
Hosting class
Dedicated / bare-metal only. No shared-core cloud VMs — CPU steal and noisy-neighbor jitter directly threatens the propagation window.
Why it matters here
This tier absorbs the full fragment / encrypt / transmit / reassemble / validate / rebroadcast cycle on every block, on every peer connection, with no slack in the clock.
Full relay node
Pool block-template source
Network seeders
RPC + ZMQ (internal only)
Heavy, sustained compute — but with slightly more tolerance for jitter than the propagation-critical path. Still dedicated CPU. Storage and network can flex with scale.
CPU
Dedicated cores required — high single-thread performance matters for CKpool share validation; multi-core matters for indexing.
Memory
32 GB+ recommended. RocksDB block-cache performance scales directly with available RAM for range queries and pagination.
Storage
NVMe, SSD sized to chain growth — a single fanout transaction can add hundreds of thousands of index entries. Plan growth in months, not years.
Network
Stable, low-latency connection to the Tier 1 node — private network strongly preferred over public RPC exposure.
Hosting class
Dedicated-vCPU cloud acceptable; bare-metal preferred at scale.
Why it matters here
Mining pool payout batching must account for ML-DSA-87 signature weight directly — naive batch sizes produce unminable blocks.
CKpool (solo / PPLNS)
RocksDB chain indexer
Exchange / custodial nodes
P2QR multisig vault infrastructure
Read-heavy, cacheable, and not on a 60-second clock. This is where general-purpose hosting is genuinely fine.
CPU
2–4 vCPU, shared-tenant acceptable for low-to-moderate traffic.
Memory
4–8 GB typical, more if serving high explorer traffic with large result sets.
Storage
Standard SSD — this tier holds no chain data of its own; it queries Tier 2 via API.
Network
Standard hosting bandwidth, CDN-fronted for public traffic where possible.
Hosting class
Any reputable VPS or static/edge hosting. This is the one tier where a low-cost box is a legitimate choice, not a compromise.
Why it matters here
Isolating this tier means a traffic spike on the public explorer can never threaten block propagation or pool reliability.
Block explorer UI
Pool front-end (miner dashboard)
Wallet interfaces
Light / SPV clients
04 — STORAGE ENGINE
RocksDB, Mandated
This is not a recommendation among several reasonable options. It is a requirement for any indexer, explorer backend, or chainstate implementation built against KVANTA5.
Why RocksDB
Built for exactly this problem
RocksDB was built at Facebook because no existing database was fast enough to handle their content at scale — they designed and built their own rather than force-fit one that wasn't built for the job. KV5's indexing load is the same kind of problem: high-volume, high-throughput, write-heavy at a scale general-purpose databases weren't designed for.
Ruled Out
BerkeleyDB, SQLite, and similar
Tested directly against KV5's actual load — fanout transactions with hundreds of thousands of outputs, 30MB+ blocks landing every 60 seconds. Nowhere near fast enough. This isn't a theoretical concern; it's a result.
Engine
Status for KV5
Notes
RocksDB
Mandated
Required for indexers, explorers, and the planned wallet/chainstate migration.
BerkeleyDB
Ruled out
Tested. Throughput insufficient for KV5 block/transaction volume.
SQLite
Ruled out
Tested. Write throughput insufficient at fanout-transaction scale.
Generic relational (Postgres/MySQL)
Not evaluated for this role
Not the target use case — column-family key/value access pattern fits RocksDB, not row-oriented relational storage.
Looking ahead, RocksDB is also the planned target for KV5 wallet storage and node chainstate, not just third-party indexing. Any infrastructure built on a different engine today should plan for that migration path rather than treating the current architecture as a permanent branch point.
05 — KNOWN FAILURE MODES
What Will Not Work
Specific mistakes we expect operators to make, because they're the same mistakes Bitcoin-class assumptions naturally lead to.
Failure Mode
Forking Bitcoin-derivative software
Explorers, wallets, and pool software built by forking Bitcoin-ish codebases will not handle 32 MB blocks, ML-DSA-87 signatures, or P2QR script types correctly. Third-party software must be purpose-built for KV5.
Failure Mode
Sizing for empty blocks
A low-end box will run fine while traffic is light. That is not the same thing as production infrastructure. Size for the network doing its actual job, not for the demo.
Failure Mode
Shared-core cloud VMs for Tier 1
CPU steal and bandwidth contention on shared-tenant virtualization directly threaten the 60-second propagation window. This is disqualifying for relay nodes and pool block sources, not a matter of preference.
Failure Mode
Naive payout batching
KVANTA5 can support very large P2QR fanout transactions, but payout software cannot assume Bitcoin-sized spends later. P2QR outputs are compact to create; spending them requires ML-DSA-87 authorization data. Pools, exchanges, and custodians must size fees, consolidation windows, and block-policy behavior against KV5’s P2QR spend model, not legacy ECDSA input assumptions
06 — QUICK REFERENCE
Find Your Role
A quick reference for which tier applies to what you're actually planning to run.
Runs the network
Relay node operator
Validates and propagates blocks to peers. Directly in the path of the 60-second budget. The fragment/encrypt/reassemble cycle runs on every connection.
Required: Tier 1
Serves miners
Pool operator
Block template sourcing sits at Tier 1. CKpool itself, share validation, and payout batching sit at Tier 2. Most pool operators need both.
Required: Tier 1 + Tier 2
Serves users
Explorer / indexer operator
The indexer doing RocksDB writes on every block is Tier 2. The public-facing explorer UI querying that indexer is Tier 3.
Required: Tier 2 + Tier 3
Holds custody
Exchange / custodial operator
Full validation, multisig vault infrastructure, and high-reliability uptime expectations. No tolerance for the shortcuts a hobby node can take.
Required: Tier 1 + Tier 2
Mines
Solo / pool miner
Mining hardware itself isn't covered here — but if you're solo mining with your own node rather than pointing at a pool, that node is Tier 1.
Solo: Tier 1 · Pooled: no node required
Holds coins
Wallet user
Light and SPV wallet usage is Tier 3 — any reasonable consumer device or basic hosting. This is the one role this document is not trying to scare off.
The institutional-grade quantum-resistant settlement chain
KVANTA5 is a live SHA-256 proof-of-work blockchain engineered for post-quantum settlement from genesis. Its native P2QR output system uses ML-DSA-87 spend authorization, eliminating ECDSA exposure from the transaction path while preserving wrapped P2SH compatibility for pool and exchange infrastructure. With 60-second target blocks, KVANTA5 is designed for rapid probabilistic settlement: six confirmations target approximately six minutes, and confidence deepens with every additional block of accumulated proof-of-work. KV5 has a fixed 231,000,000 coin supply, consisting of a transparent 21,000,000 KV5 Block #1 Development Fund allocation with Network Consensus scheduled and controlled unlock and 210,000,000 KV5 distributed to the public through proof-of-work mining.
Ticker
KV5
Total Supply
231,000,000 KV5
PQ Security
NIST Level 5
Block Time
60 Seconds
Consensus
SHA-256 PoW
Status
Mainnet Live
00 // KEY PERFORMANCE INDICATORS
At A Glance
Settlement Finality
~6
minutes — 6 confirmations
Security Level
5
NIST FIPS 204 — AES-256 eq.
Total Supply
231M
KV5 — hard cap
Staking
0%
proof-of-work only
Attack Neutralization
5
blocks — ~5 minutes
DAA Response
±300%
per block cap
vs Bitcoin Settlement
10×
faster confirmation
Legal Classification
Commodity
PoW — no staking yield
01 // ARCHITECTURE
Technical Foundation
KVANTA5 is built on battle-tested components: Bitcoin's SHA-256 proof-of-work, the Dark Gravity Wave difficulty algorithm proven on live networks since 2014, and the ML-DSA-87 P2QR quantum-resistant signature primitive — assembled into a single institutional-grade settlement chain. No novel consensus mechanism. No unproven cryptographic assumptions at the chain layer. Proven components, new combination.
⛏ Consensus Layer
AlgorithmSHA-256 Proof of Work
Block time target60 seconds
DAADGW-style per-block adjustment
DAA window24-block history
Adjustment cadenceEvery block
Design goalResponsive hashrate tracking
ASIC compatibleYes — standard SHA-256 hardware
🔐 Signature Layer
SchemeML-DSA-87 (Dilithium)
StandardNIST FIPS 204
Security levelLevel 5 — AES-256 equivalent
Output typeNative P2QR
Signature size4,627 bytes per input
Public key size2,592 bytes
PQ fromBlock #1
⚡ Settlement Layer
Target block time60 seconds
6 confirmations~6 minutes
vs Bitcoin10× faster
vs Ethereum PoSComparable
Finality modelProbabilistic PoW
Legal classCommodity
Staking yieldNone — no securities risk
🛡 Attack Profile
Attack neutralized in5 blocks (~5 min)
Max extraction~250 KV5 per attack
Recovery min1–4 blocks
Recovery max~24 blocks
Strip-mine epochsNone — no epoch boundaries
Testnet validatedMay 30, 2026
Attack tested1 PH/s vs 8 TH/s
Why three proven components: KVANTA5 deliberately avoids experimental consensus design. Its foundation combines established proof-of-work, a production-tested difficulty adjustment approach, and a custom quantum-resistant transaction-output layer built specifically for this chain.
The consensus foundation is SHA-256 proof-of-work, the same mining primitive that has secured Bitcoin since 2009. Difficulty adjustment uses a DGW-style per-block mechanism, derived from an approach that has operated in production networks since 2014. The signature foundation is ML-DSA-87, implemented from the CRYSTALS / ML-DSA reference lineage. The cryptography is standardized; the custom engineering is KVANTA5’s P2QR output scheme, address handling, wallet integration, script classification, relay policy, mining policy, and validation path.
Native P2QR outputs use KVANTA5’s consensus-defined marker:
`OP_KVANTA5_P2QR <32-byte program>`
At the script byte level, `OP_KVANTA5_P2QR` is KVANTA5’s named use of opcode `0x50`, historically `OP_RESERVED` in Bitcoin script. Native P2QR outputs are classified as `TxoutType::KVANTA5_P2QR` and validated under the explicit `SCRIPT_VERIFY_KVANTA5_P2QR` flag. This gives KVANTA5 a native quantum-resistant output class rather than a convention layered on top of legacy ECDSA templates.
The integration has already been demonstrated on mainnet under live SHA-256 proof-of-work. Block #21797 created a P2QR fanout transaction with 4,001 P2QR outputs totaling 179,536 bytes. Block #21798 then consolidated 4,000 P2QR inputs in a single 29,072,055-byte transaction, averaging approximately 7,268 bytes per input. A separate 2-input transaction of 14,632 bytes independently confirmed the same per-input sizing behavior at a radically different scale, averaging approximately 7,253 bytes per input.
KVANTA5 also completed a large-scale architectural demonstration on mainnet. Block #24521, mined June 19, 2026, included a single transaction creating 715,001 P2QR outputs inside a 29.34 MB block, approaching KVANTA5’s 32 MB maximum serialized block size. This was not a simulated benchmark or private test harness; it was a live proof-of-work block demonstrating the chain’s ability to support extreme P2QR output fanout within the configured block-size envelope.
KVANTA5’s test coverage includes a complete sighash mutation harness, validating that transaction-critical mutations invalidate the signature commitment as expected. For institutional due diligence, the separation is clear: SHA-256 proof-of-work is inherited, DGW-style adjustment is production-tested, ML-DSA-87 is standardized, and P2QR is the KVANTA5-native transaction-output and validation layer proven through live mainnet operation.
02 // QUANTUM SECURITY
Level 5 Protection
KVANTA5 addresses both quantum attack surfaces that existing proposals leave partially or fully unresolved. No ECDSA key exists anywhere in the signing path — not at broadcast, not historically, not retroactively.
✓ Short Exposure — Eliminated
The mempool attack window: when a transaction is broadcast, the ECDSA public key is visible for approximately 9 minutes before confirmation. Google estimates a CRQC can break ECDSA in under 9 minutes. P2QR has no ECDSA key to harvest from the mempool.
✓ Long Exposure — Eliminated
Any address that has made an outgoing transaction has its public key permanently on-chain. A CRQC can retroactively derive the private key. KVANTA5 has no ECDSA history — every coin mined, every transaction confirmed, uses ML-DSA-87 exclusively.
→ BIP-360 Comparison
Bitcoin's BIP-360 partially mitigates short exposure by hiding keys in tapscript leaves. It does not address long exposure attacks against historically exposed keys. KVANTA5's P2QR eliminates both surfaces by removing ECDSA from the protocol entirely.
Max block P2QR outputs715,001 outputs — mainnet block #24521, June 19, 2026
Block size with 715K outputs29.34 MB — single transaction, under live PoW
Mainnet validation4,000-input consolidation (29MB) · 4,001-output fanout · 715,001-output transaction in 29.34M B block — June 18–19, 2026
Verification ledgerAll claims verified on KV5 explorer — kvanta5.live — "EVERY CLAIM VERIFIED" section
03 // TOKENOMICS
Supply Architecture
231,000,000 KV5 hard cap. 210,000,000 KV5 mineable exclusively through SHA-256 proof-of-work. 21,000,000 KV5 created at block #1 as a transparent development reserve, locked by consensus and released only when scheduled unlock heights are reached: 1,000,000 KV5 every six months over 10.5 years. No ICO. No presale.
Total Supply
231M
KV5 hard cap
Mineable
210M
KV5 — PoW only
Block #1
21M
KV5 — 10.5yr vest
Block Reward
50
KV5 per block (Era 1)
Halving Interval
2.1M
blocks (~4 years)
Daily Emission
72K
KV5/day
Emission Schedule
EraRewardProgressKV5 MinedCumul %
Era 150 KV5
105,192,00050.09%
Era 225 KV5
52,596,00075.13%
Era 312.5 KV5
26,298,00087.66%
Era 46.25 KV5
13,149,00093.92%
Era 53.125 KV5
6,574,50097.05%
Era 6+Halving tail
~5,190,500~100%
Development Fund — 21,000,000 KV5
40%
Core Development
8,400,000 KV5
25%
Security Audits
5,250,000 KV5
20%
Infrastructure
4,200,000 KV5
15%
Legal & Compliance
3,150,000 KV5
Development Funding Allocation: 21,000,000 KV5 was created at block #1 as a transparent development reserve. The reserve is locked by KVANTA5 consensus rules and unlocks in scheduled tranches of 1,000,000 KV5 every six months over 10.5 years. Locked tranches cannot be spent early by any wallet, signer, developer, company, or third party. Before each required unlock height is reached, nodes reject attempted spends as invalid. All unlocks and movements are publicly verifiable in the source code and on-chain.
05 // INSTITUTIONAL TARGETS
Why Institutions Need This
Bitcoin's institutional holders face a hard choice: wait years for governance consensus that may never arrive, or move to a chain that was quantum-resistant from day one. KVANTA5 is that chain — purpose-built for settlement security, SHA-256 PoW, and NIST Level 5 signatures from Genesis. Three unresolved problems, one clean migration path.
THIRD-PARTY VALIDATION
BIS Project Leap — Central Bank Proof of Concept
In 2025, the Bank for International Settlements' Innovation Hub ran Project Leap: a proof-of-concept demonstrating that NIST post-quantum algorithms (including ML-DSA) can protect central bank RTGS and cross-border payment systems from quantum attack. Participating central banks confirmed feasibility, performance, and compliance with the same NIST FIPS 204 standard that underpins every KV5 transaction. What central banks proved in a controlled lab environment, KVANTA5 has deployed in production from block #0.
Problem 01
Quantum Vulnerability of Holdings
Every institutional Bitcoin address that has made an outgoing transaction has its public key on-chain. A CRQC derives the private key. BlackRock's ETF holdings are in permanently exposed addresses. No insurance policy covers this. KVANTA5 has no ECDSA history.
Problem 02
Governance Paralysis on Migration
BIP-361 proposes freezing Satoshi's coins. The Bitcoin community is fractured. Institutions cannot force governance outcomes — they are passengers. KVANTA5 made the quantum migration decision at genesis. No debate required.
Problem 03
Regulatory Exposure Timeline
Canada's April 2026 PQC mandate. NIST NSM-10. EU quantum readiness framework. By 2028, compliance officers will ask: are our digital asset holdings quantum-resistant? KVANTA5 answers yes with an audited implementation.
KVANTA5 Answer
The Quantum-Resistant Bridge Asset
KVANTA5 is not a Bitcoin replacement — it is a quantum-resistant parallel reserve asset for institutions that hold Bitcoin and need a provably secure alternative as quantum computing timelines accelerate. Level 5 security. Commodity classification. Audited code.
Entry Point 01
Compliance Infrastructure First
Chainalysis, Elliptic, TRM Labs — the compliance infrastructure every regulated institution uses. KVANTA5 integration with these platforms precedes institutional conversations. When an institution's compliance team asks "can we monitor KV5?" the answer is already yes.
Entry Point 02
Regulated Crypto Firms
Galaxy Digital, Grayscale, Arca, Bitwise — regulated firms that move faster than banks. One research note from Galaxy Digital's research team reaches every digital asset desk on Wall Street simultaneously. Target: Q3 2027.
All security claims are sourced from peer-reviewed publications, official NIST standards, or empirical testnet data. Nothing here requires trust.
MILESTONE · BLOCK #283 · JUNE 2026
First Native Spent P2QR Transaction in History
TXID: 62572d2127da3d42afb0b20757edb844b0820851f4d8340cbc7e26954ae6272c · 7,388 bytes · Wrapped P2SH → native P2QR address. The first spent P2QR transaction on a live PoW mainnet — P2QR output types exist from block #1, but Block #283 marks the first time one was spent. Permanently recorded on-chain by contributor KV5 DevTeam.
P2QR Output Scalability — 715,001 Outputs in Single Block
Single transaction with 715,001 P2QR outputs (1 payment + 715,000 micro-outputs) confirmed in a 29 MB block under live PoW. Routine mainnet operation, not a stress test. Demonstrates output-side scalability at production scale — the chain handles ultra-large output counts with no special handling or performance degradation.
CRQC possible by ~2029 per hardware researchers. Migration urgent.
Feb 2026
BIP-360 / BIP-361
Lopp, Beast, Heilman et al.
Bitcoin governance paralysis documented. Long exposure unaddressed.
Aug 2024
NIST FIPS 204
NIST
ML-DSA-87 standardised. Level 5 = AES-256 equivalent. Used by KVANTA5.
May 2026
KVANTA5 Testnet5
KV5 DevTeam
DGW 4/4 validated. 1 PH/s stress test (125× hashrate cliff). Peak block: 19,309s. Full organic recovery in ~24h. Zero developer intervention.
Jun 2026
KVANTA5 Mainnet
KV5 DevTeam
Genesis block mined (unspendable Coinbase). Block #1 mints the 21,000,000 KV5 genesis allocation. First ML-DSA-87 Level 5 PoW chain live.
Jun 2026
First P2QR Transaction
KV5 DevTeam
Block #283 · TXID: 62572d2127da3d42afb0b20757edb844b0820851f4d8340cbc7e26954ae6272c · 7,388 bytes · Wrapped P2SH → native P2QR address. First spent P2QR transaction on a live PoW mainnet (P2QR outputs exist from block #1; Block #283 is first spend).
Jun 2026
P2QR Output Scalability — Block #24521
KV5 DevTeam
Single transaction with 715,001 P2QR outputs confirmed in a 29.34 MB block under live PoW. Architecture Demonstration on live Mainnet. Not a "TestNet Maybe", a Mainnet Fact. Demonstrates output-side scalability at production scale.