Bitgold Next - High-Performance EVM L1

Bitgold Next is an EVM-compatible Layer 1 and the next-generation chain in the Bitgold Network family. It targets workloads that need sub-second finality and predictable inclusion, including high-frequency trading, real-time payments, confidential finance, and agent-driven activity. Under the proposed Parlia design, cross-block BLS votes target transaction-order finality in under one second at the 200 ms block interval. SubBlocks provide an earlier preconfirmation at approximately 20 ms. Execution finality occurs only after a subsequent block records the ExecutionCommitment and that block itself finalizes.

Key Features and Advantages

Execution runs off the consensus critical path, so ordering never waits on it. State lives in a flat key-value store under a cumulative lattice-hash commitment, with no Merkle-Patricia trie underneath. Account UX and privacy are protocol primitives, not contracts layered on top of the EVM.

Quantum resistance

Bitgold Next is designed against a post-quantum threat model at the state layer:

• Hash-based state commitments. World state is committed with a cumulative lattice-hash (LtHash) accumulator built from BLAKE3. The construction uses hash functions and modular sums, not elliptic-curve pairings, RSA, or a Merkle-Patricia trie, so it does not inherit the quantum weaknesses of those pre-quantum structures.
• No trie proofs to break. State is proven from the accumulator rather than from Merkle paths, and eth_getProof is not part of the RPC surface. There is no trie-proof attack surface whose security depends on pre-quantum assumptions.
• Post-quantum authorization is reserved. The protocol reserves a post-quantum authorization scheme for account keys. It is not enabled on devnet yet, and current accounts still sign with secp256k1, so quantum resistance today covers state integrity rather than every transaction signature.

Scope

Quantum resistance is a property of the state-commitment design. It is not a claim that every cryptographic primitive on the current devnet is post-quantum. See State DB for the construction and Privacy for the reserved post-quantum authorization work.

Where Bitgold Next Fits

Phase	Network	Description
2025	Bitgold Network	general-purpose EVM L1, chain ID 618
Next	Bitgold Next	latency-first EVM L1, optimized end to end

Bitgold Network remains the broad-base chain for the existing ecosystem. Bitgold Next is a clean-slate design for the workloads that outgrow it. It stays fully EVM-compatible and keeps BTG at the economic center, on the same tooling as Bitgold Network.

Architecture

Layer	What’s in it	Read more
Application	DeFi, payments, confidential finance, AI agents. An opt-in native shielded pool hides sender, recipient, and amount, and transparent transactions are unaffected	Privacy
Account & UX	Gas sponsorship, passkey (WebAuthn/P256) signing, batched calls, and scoped access keys, all as a native transaction type (0x76). No bundler, no entry-point contract, and the sender need not hold BTG	Account Abstraction
Execution	Parallel EVM, with ordering decoupled from execution: consensus liveness does not depend on execution throughput. Multi-Lane reserves gas capacity per transaction class, so latency-sensitive traffic can’t be crowded out	Async Execution · Multi-Lane
Consensus	Enhanced Parlia uses cross-block BLS votes to target transaction-order finality in under one second, at the target 200 ms block interval. SubBlocks can provide a preconfirmation in approximately 20 ms. Execution finality follows only after a later block records the result and itself finalizes.	Consensus · Pre-confirmation
Network	P2P block and sub-block gossip. Transactions are routed straight to the current and next proposer instead of a global mempool	JSON-RPC Endpoint
Storage	Flat key-value store under a cumulative lattice-hash (LtHash) commitment instead of a Merkle-Patricia trie	State DB
Cryptography	BLAKE3-based lattice-hash state commitments with no elliptic-curve pairing or Merkle-Patricia proof in the state path	State DB
Governance	Token-weighted (govBTG) proposal / vote / timelock control over protocol parameters, including the Multi-Lane quotas	Governance

Role of BTG

BTG is the native asset of Bitgold Next, and no new token is issued. It is bridged from Bitgold Network and pays for gas, through a native Bitgold Network ↔ Bitgold Next bridge that is still in development. Staking it with StakeHub mints govBTG 1:1, a non-transferable voting ledger that carries governance weight once it is delegated.

What This Means for Developers

Existing Solidity contracts and standard wallet flows run unchanged. Contracts, opcodes, and EVM behave exactly as on any other EVM chain, since execution builds on reth and revm. Four things around it changed:

• You pay for your declared gas limit, not gas used. Block space is sold by declared gas before execution runs (details).
• There is no global mempool. Transactions go directly to the current and next block producer, which is part of what makes pre-confirmation and Multi-Lane packing possible.
• eth_getProof is unsupported, and so are EIP-4844 and EIP-7702 transactions. JSON-RPC Endpoint lists every difference in the RPC surface.
• New features are additive. Account abstraction, pre-confirmation, Multi-Lane, and the shielded pool run alongside standard transactions, and none of them change how an existing contract behaves.

Start with Migrating from Bitgold Network if you already ship on Bitgold Network, or the Quick Guide if you don’t.

Network Parameters

Parameter	Value
Block interval	200 ms
Finality	sub-second (BLS fast finality)
Pre-confirmation	~20 ms (sub-block)
Turn length (blocks per validator, per rotation)	16
Consensus	enhanced-Parlia
Gas asset	BTG (bridged from Bitgold Network)

Current Status

Bitgold Next runs today as a multi-validator devnet with real block production and end-to-end finality. Public testnet and mainnet are still ahead, and each feature page calls out what’s shipped versus still in progress.

Every interface in this manual has been exercised against a devnet built from source: the eth_*/newl1_* RPC surface, the full governance lifecycle, account-abstraction key management and the 0x76 envelope, and the complete shielded-pool flow. The only corrections that came out of it were minor response shapes, already reflected here. The client has moved on since, so the JSON-RPC Endpoint page is kept current against client source, and its newer methods are documented from the implementation rather than from a live call.