FAQ

Is Bitgold Next EVM-compatible?

Yes, at the execution layer: revm semantics are a hard design invariant, so existing Solidity contracts and standard transaction flows work unmodified. The RPC surface above that has a few explicit differences (no eth_getProof, no global mempool, no EIP-4844/EIP-7702 transactions) that some wallets or infra tooling may need to account for. See Overview and JSON-RPC Endpoint.

How is it different from Bitgold Network?

Same Parlia PoSA + BLS fast-finality consensus family, but with a faster block interval, decoupled ordering/execution, and several new protocol features not present on Bitgold: native account abstraction, transaction pre-confirmation, Multi-Lane, and a native shielded pool. See Overview for the full comparison.

Is Bitgold Next quantum-resistant?

At the state layer, yes: state is committed with a BLAKE3-based lattice-hash (LtHash) accumulator instead of a Merkle-Patricia trie, so state integrity does not rely on elliptic-curve pairings or pre-quantum proof structures. Account authorization is not post-quantum yet: current devnet accounts use secp256k1 signatures, and a post-quantum authorization scheme is reserved as a protocol extension. See State DB.

Is Bitgold Next live on mainnet?

Not yet. It is still under active development, currently runs as an internal multi-validator devnet. Endpoints will be published on Network Information once a network is available.

Do I need to use ERC-4337 tooling (bundlers, paymasters) for account abstraction?

No. Bitgold Next’s account abstraction is native, enforced by consensus rather than by a deployed EntryPoint contract, so no bundler or paymaster contract is involved. See Account Abstraction.

Can I treat a pre-confirmed transaction as final?

No. Pre-confirmation is a fast (~20ms), best-effort signal that can still be revoked before the block finalizes. For anything irreversible, wait for execution-finalized. See Transaction Pre-confirmation.

Is the shielded pool safe to use with real funds today?

Not yet. The circuits are unaudited, and the deployment runs on an imported trusted setup rather than a Bitgold Next ceremony. Both are open items before mainnet. See the warning in Privacy.

Why doesn’t eth_getProof work?

Bitgold Next commits state with a cumulative hash accumulator instead of a Merkle-Patricia trie, so there’s no trie-based proof to serve. See State DB.

How do I get my contract reserved capacity?

Register your contract’s address in the LaneRegistry system contract with a basis-point gas reservation, via governance. See Multi-Lane.

What asset is used for gas and staking?

BTG, as the native token, bridged in from Bitgold Network. It is the same gas asset as Bitgold Network.