A High Performance, PQC-Native Layer 1 Blockchain Without TPS Penalty
ACE Chain is a Layer 1 public blockchain designed from cryptographic primitives upward. Its core methodology is not incremental optimization of existing blockchain systems, but a unified solution framework for seven systemic challenges facing the industry -- led by the quantum computing threat -- derived from a single fundamental design decision: identity-authorization separation.
All features described in this whitepaper have been fully implemented. Every protocol, algorithm, and architectural decision is formally specified in the ACE Chain Research Papers, which serve as the implementation basis for the entire system. The source code will be publicly available after the completion of a third-party security audit. Readers are encouraged to consult the paper repository for full mathematical proofs, security analyses, and protocol specifications underlying every component of ACE Chain.
Traditional blockchains follow the equation: Public Key = Identity = Address. ACE Chain breaks this by decomposing it into two independent layers:
- Identity layer:
idcom = Commitment(REV, salt, domain)-- a 32-byte cryptographic commitment that reveals no public-key information and is not bound to any signature algorithm. - Authorization layer:
credential = f(attest_key, payload)-- a replaceable credential that can be an Ed25519 signature, secp256k1 signature, HMAC-SHA256 MAC, or a post-quantum ML-DSA-44 signature.
This single design decision is a generative principle from which a series of previously independent problems are naturally resolved as corollaries.
| Industry Pain Point | Design Goal | Solution |
|---|---|---|
| Quantum computing threat | Native PQC, zero migration cost | Identity-authorization separation; dual-algorithm native layer (Ed25519 + ML-DSA-44) |
| Private-key trilemma | Simultaneous self-custody, inheritance, and yield | ACE-GF deterministic derivation; CT-DAP; Yault ERC-4626 vault |
| Signature verification bottleneck | Eliminate per-tx signature overhead | O(1) block verification via recursive ZK proofs |
| Addressing and recovery deficiencies | Human-readable payment and recovery | VA-DAR serverless recovery; HFI-Pay human-friendly identifier payment |
| Cross-chain identity fragmentation | Unified identity with multi-chain native execution | 7-stream HKDF derivation; n-VM multi-chain scheduling |
| Finality efficiency | Sub-second cryptographic hard finality | ZK proof-based two-tier finality (~600 ms hard finality) |
| Agent economy infrastructure | High-frequency micro-payments, policy boundaries, zero-fee DeFi | AESP protocol; in-runtime DeFi; ~$0.01/M tx |
ACE-GF (Atomic Cryptographic Entity Generative Framework) starts from a single memorized secret and deterministically generates a complete multi-chain cryptographic identity without persisting any key material. From a single REV (Root Entropy Value), seven cryptographically independent key streams are derived via HKDF-SHA256 domain separation:
| Stream | Domain Tag | Algorithm | Purpose |
|---|---|---|---|
| 1 | ACEGF-V1-ED25519-SOLANA |
Ed25519 | Solana signing |
| 2 | ACEGF-V1-ED25519-POLKADOT |
Ed25519 | Polkadot signing |
| 3 | ACEGF-V1-SECP256K1-EVM |
secp256k1 | Ethereum/EVM signing |
| 4 | ACEGF-V1-SECP256K1-BTC |
secp256k1 | Bitcoin Taproot |
| 5 | ACEGF-V1-SECP256K1-COSMOS |
secp256k1 | Cosmos signing |
| 6 | ACEGF-V1-X25519-IDENTITY |
X25519 | End-to-end encryption |
| 7 | ACEGF-V1-ML-DSA-44-PQC-IDENTITY |
ML-DSA-44 | Post-quantum signing |
Ed25519 (classical) and ML-DSA-44 (FIPS 204, post-quantum) operate as peer first-class citizens at the protocol layer from day one, achieved through a three-layer algorithm abstraction:
- Tagged cryptographic primitives -- every public key and signature carries a 1-byte algorithm identifier (
TaggedPubkey,TaggedSignature). - Multi-algorithm account model -- each account holds a primary authorization key and up to 3 additional keys, supporting Ed25519 and ML-DSA-44 coexistence. Users can switch algorithms at runtime via
OP_SET_AUTH_PUBKEYwithout changing address or migrating assets. - Unified verification dispatch -- a single
verify_signature()function dispatches to the corresponding verifier based on the algorithm tag.
ACE Chain employs a hybrid BFT + PoH + ZK consensus model:
- PoH (Proof-of-History): Serial SHA-256 hash chain for verifiable temporal ordering.
- BFT voting: 2/3 stake-weighted voting achieves soft finality (~400 ms). Votes are off-chain messages -- zero on-chain vote transactions.
- ZK proofs: STARK/FRI recursive proofs provide cryptographic hard finality (target ~600 ms), post-quantum secure.
A single recursive ZK proof covers all transactions in a block. Verification cost is O(1), independent of transaction count:
- Traditional (e.g., Solana):
T_verify = n * 76 usper transaction - ACE Chain:
T_verify ~ 0.5 ms(STARK/FRI verification), independent of n
The execution layer is an n-VM scheduler that routes transactions to the corresponding execution engine based on the opcode prefix:
| Opcode Range | Engine | Functionality |
|---|---|---|
| 0x01-0x0F | ACE Native | Native transfers, account creation |
| 0x10-0x1F | EVM (revm) | Ethereum smart contracts (Shanghai-compatible) |
| 0x20-0x2F | SVM | Solana BPF programs |
| 0x30-0x3F | BVM | Bitcoin Script + UTXO model |
| 0x40-0x4F | TVM | Tron-compatible contracts |
Native transaction formats from each chain can be submitted directly to ACE Chain for execution. Developers can deploy Solidity contracts or Solana programs as-is, enjoying post-quantum security and sub-second finality while maintaining full compatibility with native toolchains.
Because PQC capability resides in the authorization layer rather than the execution layer, all VM engines automatically inherit post-quantum signature protection without any VM-level modifications. A user can authorize EVM smart contract calls, SVM program execution, and BVM script operations using ML-DSA-44 signatures, without waiting for those ecosystems to upgrade to PQC themselves.
The context isolation property of ACE-GF naturally supports zero-coordination state sharding. Different HKDF context values produce cryptographically disjoint address spaces -- no cross-shard coordination is needed.
| Shards | Total Sustained TPS | Relative to Solana |
|---|---|---|
| 1 | ~5,000 | ~1.25x |
| 4 | ~17,000 | ~4.25x |
| 8 | ~31,000 | ~7.75x |
- VA-DAR (Vendor-Agnostic Deterministic Artifact Resolution): Serverless wallet recovery using only a password and a human-memorable identifier (e.g., email). The on-chain DiscoveryID registry enables full cryptographic identity restoration with zero server dependency.
- HFI-Pay (Human-Friendly Identifier Payment): Payment addressing reduced to the cognitive overhead of sending an email -- enter the recipient's email or phone number to complete a payment.
| Dimension | ACE Chain | Solana |
|---|---|---|
| Hard finality | Target ~600 ms (ZK proof) | ~12 s (31 confirmations) |
| Block verification | O(1) (single recursive proof) | O(n) (per-tx signature) |
| On-chain signature storage | None (consumed in proof) | 96 B/tx |
| Vote transactions | Off-chain messages | ~65% of total TPS |
| Cost per million tx | ~$0.01 | ~$2.86 |
The current devnet benchmark (single laptop, shared resources) demonstrates engineering stability at ~265 sustained TPS. Based on architectural modeling, we project significantly higher throughput with dedicated multi-node deployments and sharding enabled:
| Configuration | Projected Sustained TPS |
|---|---|
| Single shard, dedicated servers | ~5,000 |
| 4 shards | ~17,000 |
| 8 shards | ~31,000 |
These projections are derived from ACE Chain's structural advantages: zero vote transaction overhead, O(1) block verification, and HKDF-based zero-coordination sharding that scales TPS linearly with shard count. See the Whitepaper Section 8 for the full analysis.
To verify engineering stability, we deployed a 3-node devnet on a single MacBook Pro (Apple M3, 12 cores, 36 GB RAM) and conducted sustained stress testing with all transactions signed using ML-DSA-44 (NIST FIPS 204) post-quantum signatures -- a full end-to-end PQC pipeline including signing, verification, consensus, and finality.
The load generator employs an adaptive TPS probing strategy: it progressively increases the submission rate until the node begins rejecting transactions due to overload (HTTP 500 back-pressure), then automatically backs off to find the sustainable throughput ceiling. This is not a fixed-rate test -- the system actively seeks its own limits.
| Metric | Value | Notes |
|---|---|---|
| Sustained TPS | 265 | Successful transactions, 30s rolling average |
| Peak TPS | 368 | Single-second maximum successful throughput |
| P50 latency | <1 ms | End-to-end transaction confirmation latency |
| P90 latency | 1 ms | |
| P99 latency | 3 ms | |
| Block build time | 34-135 ms | Proposal build timing from node logs |
Ramp-up phase -- TPS climbing under adaptive load, peak burst reaching ~447 TPS, individual blocks packing up to 669 transactions:
Stabilized phase -- 30-second rolling average settling at ~300 TPS, single block peak at 767 transactions:
Steady state -- sustained ~293 TPS with a flat, stable curve and zero degradation over time:
Load runner console -- node-side block proposal logs (build_ms: 34-135 ms per block) and adaptive TPS probing output showing target_tps auto-adjustment based on error-rate feedback:
Key observation: The PQC (ML-DSA-44) performance curve is visually identical to the classical (Ed25519) benchmark under the same hardware conditions. This confirms ACE Chain's core thesis -- post-quantum cryptography introduces zero TPS penalty. The identity-authorization separation architecture absorbs PQC signature overhead (2,420-byte ML-DSA-44 vs. 64-byte Ed25519) entirely within the ZK proving layer, leaving the execution critical path untouched.
Note: These results reflect engineering stability, not production performance limits. All 3 consensus nodes and the load generator share a single laptop's CPU, memory, and I/O resources. For production-environment performance projections with dedicated servers, see the Whitepaper Section 8.
Test scripts are available in the devnet/ directory.
A browser extension wallet (Chrome Manifest V3) built on ACE-GF. Core cryptographic operations execute within a Rust-compiled WASM sandbox. Natively supports ML-DSA-44 post-quantum signatures, VA-DAR decentralized recovery, ZK-ACE zero-knowledge authorization, encrypted NFT storage (RWA), Verifiable Credentials (W3C VC 2.0), and unified multi-chain asset management across 10+ chains.
A self-custody asset management platform that simultaneously addresses yield generation and inheritance. Breaks the self-custody-inheritance-yield trilemma through CT-DAP (Condition-Triggered Dormant Authorization Paths) and ERC-4626 smart vaults with deep Chainlink integration (CRE, Data Feeds, Automation, CCIP, Functions).
An Agent economy protocol SDK enabling AI agents to autonomously execute economic actions under human sovereignty constraints. Includes a policy engine (8 deterministic checks), state-machine-driven inter-agent negotiation, EIP-712 structured commitments, and Google A2A (Agent-to-Agent) interoperability.
All features, protocols, and architectural decisions in ACE Chain are formally specified in peer-reviewed research papers. The complete paper repository is available at:
https://github.com/acechain-io/papers
| Paper | Topic | Whitepaper Sections |
|---|---|---|
| ACE-GF: A Generative Framework for Atomic Cryptographic Entities (arXiv:2511.20505) | Cryptographic identity framework, HKDF derivation, idcom | Sections 2, 3 |
| ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems (arXiv:2603.07974) | ZK circuit design, O(1) block verification | Sections 5.3, 9.4 |
| AR-ACE: ACE-GF-based Attestation Relay for PQC (arXiv:2603.07982) | Lightweight mempool propagation without on-path proofs | Section 6.2 |
| ACE Runtime: A ZKP-Native Blockchain Runtime with Sub-Second Cryptographic Finality (arXiv:2603.10242) | Consensus model, two-tier finality, transaction pipeline | Sections 5, 6, 8 |
| Condition-Triggered Cryptographic Asset Control via Dormant Authorization Paths (arXiv:2603.07933) | CT-DAP inheritance mechanism, Yault vault design | Sections 3.6, 10.2 |
| VA-DAR: PQC-Ready, Vendor-Agnostic Deterministic Artifact Resolution (arXiv:2603.02690) | Serverless wallet recovery, DiscoveryID | Section 4.2 |
| AESP: A Human-Sovereign Economic Protocol for AI Agents (arXiv:2603.00318) | Agent policy engine, negotiation, settlement | Section 10.3 |
| n-VM: A Multi-VM Layer-1 Architecture with Shared Identity and Token State (forthcoming) | Multi-VM execution, opcode routing, parallel scheduling | Section 6 |
| HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers (forthcoming) | HFI-Pay protocol, intent-based payment | Section 4.3 |
ACE Chain's security model addresses key leakage, identity forgery, signature forgery, replay attacks, quantum attacks, VA-DAR registration overwrite, and cross-shard attacks through a comprehensive set of defense mechanisms. See the Whitepaper Section 9 and the individual research papers for full security analyses.
- Website: https://www.acechain.io
- Research Papers: https://github.com/acechain-io/papers
- Contact: contact@acechain.io
Copyright 2026 ACE Labs. All rights reserved.