Understand the chain before building on it.

Mainnet and the permanent Sandbox.

A chain ID provides replay protection, but it does not uniquely identify a deployed chain. Validate the genesis hash as well. Both released SDKs use the permanent Sandbox in examples without hard-coding it into transaction construction.

From an application request to chain state.

Validators and full nodes execute the same deterministic state transition. RPC gateways expose chain state and accept complete signed transactions. The chain does not know about SDK download users, Qustody vault accounts, application sessions, or your internal approval model.

Contract execution is familiar. Authorization is not.

Migration checklist

• Search contracts and dependencies for ecrecover, ECDSA recovery helpers, permits, meta-transactions, multisig verification, and account-abstraction validators.
• Replace every off-chain Ethereum signer with a Quantum-compatible signing implementation.
• Carry the public key with signatures wherever application protocols verify signed messages.
• Re-run gas estimates and size limits because Quantum signing material is larger.
• Test deployment, state-changing calls, events, and failure paths on Quantum Sandbox.

A Quantum account starts with a post-quantum keypair.

Private key

Secret signing material. It stays inside the chosen signing boundary and must never be sent to RPC.

Public key

The canonical 1,952-byte verification key. Signed transactions carry it so the sender can be derived and the signature can be checked.

Address

The low 20 bytes of Keccak-256(publicKey), displayed as a normal hexadecimal address.

Signing digest

The exact 32-byte Keccak-256 result produced from the canonical unsigned transaction serialization.

Signature

The canonical 3,293-byte signature over the signing digest.

Use QuantumWallet.generate() in JavaScript or Signer.generate() in Python for disposable development keys. For production, place keys behind an approved signer boundary. Do not derive Quantum accounts with a standard Ethereum wallet or secp256k1 mnemonic path.

The digest and wire bytes are protocol data.

Do not recreate these rules in application code. The SDKs mirror the authoritative Go implementation and expose immutable structured transactions plus canonical serialization helpers.

Legacy envelope

Dynamic-fee envelope

For an unsigned transaction, the signature and public-key fields are empty. The signing digest is Keccak-256 of that canonical unsigned serialization. After signing, both fields are attached and the transaction hash is Keccak-256 of the complete signed serialization.

1. Resolve chain ID, pending nonce, gas and fee fields.
2. Construct an unsigned transaction with binary calldata.
3. Digest the canonical unsigned bytes into exactly 32 bytes.
4. Sign through a Quantum-compatible signer.
5. Attach the exact signature and public key.
6. Serialize the signed transaction once.
7. Submit with qc_sendRawTransaction and retain the local hash.
8. Confirm a successful receipt before treating the operation as complete.

The QVM exposes a post-quantum verification precompile.

The precompile is at address 0x000000000000000000000000000000000000000b. It accepts exactly 5,277 bytes in this order:

It returns 32 bytes. The last byte is 0x01 when the signature is valid and 0x00 when it is invalid. An incorrect input length fails the call.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.24;

library QuantumSignature {
    address internal constant VERIFY = address(0x0b);

    function isValid(
        bytes32 digest,
        bytes memory publicKey,
        bytes memory signature
    ) internal view returns (bool) {
        if (publicKey.length != 1952 || signature.length != 3293) return false;
        (bool ok, bytes memory output) = VERIFY.staticcall(
            bytes.concat(digest, publicKey, signature)
        );
        return ok && output.length == 32 && uint256(bytes32(output)) == 1;
    }
}

Post-quantum signatures solve one part of the system.

They protect transaction authorization against the class of attacks addressed by the chosen post-quantum signature construction. They do not automatically secure application servers, private-key storage, dependencies, RPC access, smart-contract logic, governance, validators, or operational policy.

• Generate keys only through the controlled native implementation.
• Validate chain ID and genesis hash before signing.
• Show or validate the complete transaction intent before authorizing its digest.
• Keep private keys out of logs, errors, environment variables, RPC requests, and application telemetry.
• Bound RPC deadlines and response sizes and treat remote responses as untrusted.
• Audit contracts that authorize signatures, especially code ported from Ethereum.