QVM tooling for building on Quantova
The Quantova Virtual Machine, Solidity on a post quantum trust model, post quantum precompiles, the Studio IDE, CodeLab and the developer documentation. One execution environment, quantum secure from first principles.
Quantova gives engineering teams in government, banking and finance a familiar contract model with the cryptographic posture rebuilt underneath it. Contracts compile and behave as developers expect, while authorization, hashing and verification are enforced by the protocol using NIST approved post quantum cryptography.
A single execution environment where security is a protocol property
The Quantova Virtual Machine is the execution environment in which every application on the network runs. It governs transaction authorization, state transition validation and execution recording through rules defined by the protocol, not by the application. Cryptographic policy is applied at the protocol level and enforced uniformly across every contract on the network.
This means a deployed contract does not choose its own security posture. It inherits the post quantum posture of the runtime. Authorization, hashing and finality are enforced by the QVM before any state change, so the assurances that protect the core protocol extend without gaps into application logic.
- ✓One execution environment shared by every application, with uniform rules
- ✓Cryptographic policy enforced at the protocol level, not left to application choice
- ✓Verification applied inside the QVM before any state transition is committed
- ✓Deterministic finality of about three seconds for every deployed contract
| Function | Authority |
|---|---|
| Transaction authorization | QVM, protocol level |
| State transition validation | QVM, protocol level |
| Cryptographic policy | QVM, protocol level |
| Hashing | SHA3 256 |
| Contract logic | Author defined |
| Finality | Deterministic, about 3 seconds |
Solidity on a post quantum trust model
Teams write contracts in Solidity, the contract language they already know. What changes is the trust model beneath it. Authorization no longer rests on elliptic curve signatures that a capable quantum computer can break.
Conventional contract platforms authorize accounts and transactions with elliptic curve schemes such as ECDSA and Ed25519. Those schemes rest on assumptions that are not regarded as durable under advancing computational models. On Quantova the same Solidity contract executes against accounts whose keys are post quantum keypairs, with addresses bound to the exact public key they first sign with.
Developers keep the contract model, the toolchain habits and the mental model they have. They gain a trust model where the signature scheme, the hash function and the finality path are post quantum by default. The migration is in the foundation, not in the application code.
Because policy is enforced by the runtime, a contract cannot silently fall back to a weaker scheme. Whatever the application logic, the authorization it depends on is post quantum from first principles.
| Layer | Trust model |
|---|---|
| Contract language | Solidity, unchanged |
| Account signatures | Falcon 512, Dilithium ML DSA, SPHINCS+ SLH DSA |
| Hashing | SHA3 256 |
| Address binding | Public key pinning |
| Key encapsulation | ML KEM |
| Standard | NIST approved |
Post quantum primitives available to contracts inside the QVM
The QVM exposes post quantum cryptographic operations as precompiles, so contracts can verify post quantum signatures and compute post quantum hashes directly, at native speed, without bundling their own implementations.
- ✓Signature verification for Falcon 512, Dilithium ML DSA and SPHINCS+ SLH DSA exposed as precompiles callable from contract code.
- ✓SHA3 256 hashing available as a precompile so contract level commitments use the same hash as the protocol.
- ✓ML KEM key encapsulation for contracts that establish post quantum secure channels or sealed inputs.
- ✓Precompiles execute as protocol primitives, so the cost and behavior are deterministic rather than dependent on a vendored library.
- ✓A contract that verifies signatures through a precompile inherits the same post quantum assurance the runtime enforces on every account.
// Verify a post quantum signature inside the QVM via a precompile contract Settlement { // QVM precompile addresses for post quantum verification address constant FALCON_512 = 0x0000000000000000000000000000000000000401; address constant DILITHIUM = 0x0000000000000000000000000000000000000402; // ML DSA address constant SPHINCS_PLUS = 0x0000000000000000000000000000000000000403; // SLH DSA function verify(bytes calldata pubkey, bytes calldata sig, bytes32 digest) public view returns (bool ok) { (ok, ) = FALCON_512.staticcall(abi.encode(pubkey, sig, digest)); // digest is SHA3 256, the hash enforced across the protocol } } # Deploy the contract to the QVM with qweb3.js qweb3 = new Qweb3("https://rpc.quantova.org") account = qweb3.account.fromKey(QSEC1_key) # post quantum keypair, Q1 address tx = qweb3.deploy(Settlement, { signWith: "Falcon 512" }) receipt = tx.confirm() # deterministic finality, about 3 seconds
Illustrative. Precompile addresses and method signatures are shown for explanation; consult the developer documentation for exact interfaces.
Studio IDE, CodeLab and developer documentation
A complete path from first contract to deployed application: a browser based development environment, a guided code lab and reference documentation, all aligned to the post quantum trust model of the QVM.
Studio IDE
A browser based development environment for writing, compiling and deploying QVM contracts against the post quantum runtime, with no local setup.
CodeLab
Guided, runnable lessons covering QVM execution templates, asset issuance, governance and post quantum cryptographic verification.
Developer documentation
Reference for the SDKs, the precompile interfaces, the contract model and the network endpoints, maintained alongside the protocol.
Start in the browser, deploy to the QVM
The Studio IDE removes the setup barrier. Open it in a browser, write a contract in Solidity, compile against the QVM and deploy to the post quantum runtime. CodeLab takes the same environment further with guided lessons, and the developer documentation provides the reference for every SDK, precompile and endpoint.
Quantum security at the execution layer, from first principles
Most contract platforms authorize execution with elliptic curve signatures that a capable quantum computer can break. Records can be captured today and decrypted later. Quantova removes that exposure at the layer where contracts actually run.
From first principles, the integrity of a contract platform rests on three things: that only the rightful holder can authorize a transaction, that state transitions are validated under fixed rules, and that the record cannot be reconstructed or forged later. Each depends on the cryptography enforced at the execution layer.
Quantova rebuilds that layer on NIST approved post quantum cryptography. Accounts are post quantum keypairs, addresses are the SHA3 256 hash of the public key with public key pinning, finality is verified with post quantum signatures, and the precompiles let contracts carry the same assurance into their own logic. Verification runs inside the QVM before any state change, so the assurance is structural rather than advisory.
The result is an execution layer where quantum security is a property of the runtime that every contract inherits, not an option a developer must remember to enable.
| Property | Detail |
|---|---|
| Account signatures | Falcon 512, Dilithium ML DSA, SPHINCS+ SLH DSA |
| Validator keys | Post quantum signing |
| Finality | Post quantum verification |
| Hashing | SHA3 256 |
| Address binding | Public key pinning |
| Contract primitives | Post quantum precompiles |
| Standard | NIST approved |
Owned by Quantova Inc. Released under the Business Source License 1.1.
