# Signatures for Guests

> Initiative QL-03. Zk-friendly and post-quantum signature verification available to every guest as a call, so authorization inside a blockchain-native application is one line of code.

QL-03 Signatures for guests Status: active development

Almost every blockchain-native application asks the same question on every request: did the right key authorize this? In v1.0.0 a guest answers it with code. secp256k1 recovery is `k256` running over the delegated `MOD_MUL` and `EC_ADD` circuits, which makes Ethereum's own signatures affordable, and anything else is ordinary instructions. QL-03 makes signature verification a first-class guest operation.

## The schemes

A signature scheme is cheap to prove, or not, almost entirely because of its *verification* algorithm: what arithmetic it does, in which field, and which hash it calls. The signer never runs inside the proof. Four designs cover the space:

| Scheme | Idea | Why it matters to a guest |
| --- | --- | --- |
| Schnorr over a native curve | Schnorr's protocol on a curve whose base field is the proof system's own field, as Grumpkin is to BN254 | the cheapest by construction: arithmetic and hash both native to the circuit |
| ML-DSA (FIPS 204) | Schnorr carried to lattices, with a short response kept uniform by rejection sampling | NIST's primary post-quantum signature; cost dominated by its hash and, unless the key is fixed, its matrix expansion |
| FN-DSA (Falcon) | hash-and-sign with a lattice trapdoor, hidden by Gaussian sampling | the least arithmetic and the least hashing of the post-quantum three |
| SLH-DSA (FIPS 205) | signatures from a hash function alone | no algebra at all, and some two thousand hash calls; the most conservative assumption |

All four verifiers are compute-and-compare, with no secrets and no branching on secrets, which is what makes each of them provable. The expository [ZK-Friendly Signature Schemes](https://www.gweb3networks.com/expositories/zk-friendly-signature-schemes.html) works through each with a toy example and compares their in-circuit costs.

## What decides the cost

Two levers move every number:

- **The field the prover runs over.** A scheme is native when its arithmetic is the circuit's arithmetic. Which scheme is cheapest therefore follows the re-fielding of [QL-02](https://apogee.gweb3networks.com/docs/quantum-leap/post-quantum#refield), and the selection is made with it.
- **The hash.** The post-quantum verifiers are dominated by their standard hash, not by their algebra. Replacing it with an arithmetic hash leaves the standard, and is the variant the zk-oriented constructions choose; keeping it is what interoperability with existing keys requires. Both have a place, and the guest decides.

## For builders

The aim is a guest that verifies an authorization the way it computes a hash today: one call, delegated to a circuit, no cryptography in the application's own code. That opens the patterns blockchain-native applications are built on: accounts whose keys are not the chain's, multi-party approval inside the state-transition function, session keys, and identities that stay valid after the curves they were born on have fallen.

Back to the [mission brief](https://apogee.gweb3networks.com/docs/quantum-leap).