# Quantum Leap

> Where Apogee goes next. The trajectory toward v2.0.0 — a proving core on lattices, a field chosen to match them, signatures guests can verify, and a deployment system that carries an application from repository to running chain.

Briefing Programme: Apogee VM Target: v2.0.0 Status: active development Release window:

Version 1.0.0 settles the question of whether the architecture holds at full scale: a whole Ethereum block, from a Rust guest to a contract that says `true`. Version 2.0.0 changes what that architecture rests on and whom it serves. Its proving core moves to mathematics a quantum computer does not break, and its developer surface grows from a repository into a system that deploys applications.

> [!IMPORTANT]
> This section describes work in progress. Nothing here changes the guarantees of v1.0.0, which are stated in full in [the security model](https://apogee.gweb3networks.com/docs/architecture/security).

## The four initiatives

- [Lattice commitments](https://apogee.gweb3networks.com/docs/quantum-leap/post-quantum#lattice): Replace the pairing-based commitment with one whose binding rests on Module-SIS, the assumption family under NIST's post-quantum signature standard.

- [Re-fielding](https://apogee.gweb3networks.com/docs/quantum-leap/post-quantum#refield): Move the arithmetization off BN254's 254-bit field to a small field matched to the lattice commitment, where every layer of every circuit gets cheaper.

- [Signatures for guests](https://apogee.gweb3networks.com/docs/quantum-leap/signatures): Zk-friendly and post-quantum signature verification, available to every guest as a single call.

- [The Deployment System](https://apogee.gweb3networks.com/docs/quantum-leap/deployment-system): A portal and toolchain that take an application from source to a running blockchain-native environment: resources, bridges, telemetry and a gateway for AI agents.

## The trajectory

| | v1.0.0, today | v2.0.0, the trajectory |
| --- | --- | --- |
| Commitments | Mercury over KZG: pairings, q-DLOG | Lattice-based, binding under Module-SIS |
| Field | BN254's scalar field, 254 bits | A small prime field with extension-field challenges, matched to the commitment |
| Against a quantum adversary | Every assumption is a discrete logarithm | A proving core resting on lattice problems |
| Signatures in guests | secp256k1 through delegated field and curve arithmetic | Zk-friendly and post-quantum schemes as guest calls |
| For builders | A repository, its tools and this manual | The Deployment System: portal, canonical bridges, telemetry, an AI gateway |

## What carries over

The leap is in the foundations, not in the model a builder writes against:

- **The guest.** Rust, RISC-V, three memory regions, an identity, a journal. Programs written for v1.0.0 keep their shape.
- **The GKR engine.** Layered circuits and sumcheck are defined over any field. The engine that funnels a circuit to one point is the part of Apogee that moves to the new field most directly.
- **The arguments.** One memory multiset over the whole execution, and LogUp channels, carry over as constructions; their tables and range arguments are re-derived for the new field's size.
- **The discipline.** Specification first, every layer checked against an independent oracle, every forgery class held by a tamper twin.

## Why now

A validity proof is only as quantum-safe as the system that produces it. A proof over BN254 rests on pairings and discrete logarithms, so a large enough quantum computer could forge one without touching anything the guest computed. Blockchain-native applications are meant to hold value for decades. The foundation they settle on has to outlast the machines that will one day break today's curves, and the time to move it is before those machines exist.

Read the initiatives: [Post-quantum proving](https://apogee.gweb3networks.com/docs/quantum-leap/post-quantum) · [Signatures for guests](https://apogee.gweb3networks.com/docs/quantum-leap/signatures) · [The Deployment System](https://apogee.gweb3networks.com/docs/quantum-leap/deployment-system).
