Post Quantum Evidence for Autonomous Agents on the Quantova Virtual Machine

Abstract

Autonomous agents and superintelligence agents now make payments, decisions and filings on behalf of companies in banking, government, healthcare and finance. The records of what those agents did are held by the operators whose conduct the records describe. Such records can be rewritten by their custodian, and where they are signed at all they are signed with ECDSA, EdDSA or RSA, which Shor's algorithm allows a quantum computer to forge in polynomial time.

Qstamp is an open SDK and a set of Quanta smart contracts on the Quantova Virtual Machine (QVM) that turn agent records into durable evidence that anyone can verify, while the records themselves remain private with the operator. Each record is reduced to a SHA3 256 digest and bound to a fresh 256 bit salt. The resulting leaves are combined in an RFC 9162 hash tree of up to 2²⁰ leaves, and the tree is committed by one domain separated 32 byte value that binds the chain, the contract, the signer, the record kind and the batch size. The commitment is anchored by an attested Quanta smart contract in a transaction signed with ML DSA 65 and finalised by a validator committee that has signed every block with ML DSA 65 since genesis.

We define an evidence forgery game and prove that the advantage of any classical or quantum adversary is bounded by the collision and second preimage advantages against SHA3 256, a q fold EUF-CMA advantage against ML DSA 65 and the probability of a consensus failure. We state exactly what a receipt proves and what it does not, describe how the contracts are compiled, attested and deployed, give a verification procedure suited to orders of courts and regulators with a worked example from the Quantova test network, and relate the construction to record keeping obligations in the European Union, the United Kingdom, the United States, Japan, Korea and Hong Kong.

Keywords

1. Introduction and contribution summary

Software agents built on large models now call tools, move funds, approve credit and produce content on behalf of people and institutions. When such an action is later disputed, the question before a court, a supervisor or an insurer is factual. What did the agent do, under which model and policy, and when? The answer is almost always taken from records kept by the operator of the agent, which is also the party whose conduct is in question.

Two weaknesses follow. The first is custody. A record held in a database under the operator's administrative control can be changed by the operator, and nothing in the record itself reveals the change. The second is durability. Where records are protected cryptographically, the protection is a digital signature over ECDSA, EdDSA or RSA, and published resource estimates indicate that a fault tolerant quantum computer of sufficient size would forge such signatures in hours or days [10, 11, 8]. Many records must be retained for six to ten years [37, 35], which is long compared with the uncertainty in when such a machine might exist [13].

Qstamp addresses both weaknesses with one construction. Each record is reduced inside the operator boundary to a salted SHA3 256 commitment. A batch of up to 2²⁰ commitments is aggregated in a hash tree, and a single 32 byte value that binds the tree to its chain, contract, signer, kind and size is anchored through a Quanta smart contract on the Quantova Virtual Machine. Every signature on which that anchor depends, from the account that submits it to the committee that finalises it, is an ML DSA 65 signature [24], and this has been so since the genesis block of the network. The record never leaves the operator, and any party holding the record and its receipt can later verify it without trusting the operator or Quantova Inc.

This paper makes the following contributions.

1. A formal model of the operator as an insider adversary and of the quantum adversary against classical signatures, and a predicate that captures the record keeping requirements of current regulation (Section 2 and Section 3).
2. A complete specification of the Qstamp construction exactly as implemented in SDK release 0.1.4, including encodings, the stamping and verification algorithms and the three valued verification outcome (Section 5).
3. A reduction proving that evidence forgery against Qstamp is bounded by the collision and second preimage resistance of SHA3 256, the unforgeability of ML DSA 65 and the safety of consensus, together with binding, hiding and liveness properties and concrete classical and quantum bounds (Section 6).
4. A precise statement of what a receipt proves and does not prove for autonomous agents (Section 7), and a verification procedure for orders of courts and regulators illustrated with a real test network run (Section 8).
5. A mapping from legal obligations to the formal properties provided and their limits (Section 9), an analysis of why the properties require a post quantum layer 1 with attested contract code (Section 10), and measured cost and latency (Section 11).

The paper describes only what is live at the date of Version 1.0. The construction runs on the Quantova test network, whose receipts carry no evidential weight. Production use will take place on the Quantova main network once it launches. Planned features are identified as such in Section 6.7 and Section 12.

2. The problem, stated mathematically

Throughout, H denotes SHA3 256 [22], ‖ denotes byte concatenation, λ denotes the security parameter, and an algorithm is efficient if it runs in time polynomial in λ on a classical computer (PPT) or on a quantum computer (QPT).

2.1 Operator controlled records and the insider adversary

Signatures computed by O do not change this. If each entry carries σ_j = Sign(sk_O, e_j), then O, which holds sk_O, computes a valid σ′ for any replacement e′. A custodian's signature authenticates origin towards third parties but says nothing about integrity against the custodian. Integrity against O requires a witness W, a party or system whose state O cannot alter, that fixes a value derived from Λ before t_a. In current practice V's confidence in the state of W rests on signatures by W, almost always ECDSA over secp256k1 or P 256 [26, 29], Ed25519 [30] or RSA, or on no signature at all when the witness is an internal system of the operator.

2.2 Shor's algorithm and its published cost

2.2.1 The order finding reduction

Let N be an odd composite integer that is not a prime power, and let a be drawn uniformly from the units modulo N. The order of a is

If r is even and a^r/2 ≢ −1 (mod N), then N divides (a^r/2 − 1)(a^r/2 + 1) but neither factor, so

is a non trivial factor. For N with at least two distinct odd prime factors this event has probability at least one half over the choice of a [2, 12]. Factoring therefore reduces in classical polynomial time to computing orders, and Shor's contribution is a quantum algorithm for the latter [1, 2].

2.2.2 The quantum Fourier transform

Choose Q = 2^ℓ with N² ≤ Q < 2N². A register of ℓ qubits is placed in uniform superposition and the map x ↦ a^x mod N is computed reversibly into a second register,

The quantum Fourier transform over ℤ_Q acts on the first register as

and is implemented exactly with O(ℓ²) one and two qubit gates. Because the second register is periodic in x with period r, a measurement of the first register after the transform returns, with probability Ω(1/log log N), a value y such that

for some integer s coprime to r. By Legendre's theorem s/r is then a convergent of the continued fraction expansion of y/Q, which yields r classically. Modular exponentiation dominates the cost, with O(ℓ³) gates for schoolbook arithmetic.

2.2.3 Discrete logarithms and elliptic curves

Let ⟨P⟩ be a cyclic group of prime order q and let Q′ = dP be a public key. The function

is constant exactly on the cosets of the subgroup L. A two register Fourier transform over ℤ_q² followed by measurement yields (u, v) with v ≡ ud (mod q), so d = v·u⁻¹ mod q whenever u ≠ 0 [2]. For an elliptic curve group the group law is evaluated reversibly with arithmetic over the base field [9]. Roetteler, Naehrig, Svore and Lauter give a concrete circuit for prime field curves of bit length n [8] that uses

and a Toffoli gate count of the order of 10¹¹ for n = 256. The estimate applies to secp256k1 and P 256, which underlie most ECDSA deployments, and with negligible change to the 255 bit curve of Ed25519. These are logical qubits. Fault tolerant implementation multiplies the physical count by the overhead of the error correcting code.

2.2.4 Resource estimates for RSA 2048

For RSA, Gidney and Ekerå estimated in 2019 that a 2048 bit modulus can be factored in about 8 hours with 20 million noisy qubits, assuming a physical gate error rate of 10⁻³, a surface code cycle time of one microsecond and a control system reaction time of ten microseconds [10]. Gidney revised the estimate in 2025 to fewer than one million noisy qubits and under one week of run time under the same hardware assumptions [11].

2.3 Consequence for signatures, ledgers and logs

The evidential consequence is retroactive. Let an entry e be signed at time t_c under pk, and let t_q be the first time at which the adversary can run A_Shor. At any time T ≥ t_q the adversary produces (e′, σ′) with Verify(pk, e′, σ′) = 1. A verifier at T holds two pairs that both verify, and signature verification gives no information about which existed at t_c. The adversary needs only pk, which is public and in ledgers is published with the first transaction of the account. Public keys and signed records can therefore be collected now and forged later. With x the period for which evidence must remain sound, y the time needed to migrate it and z the time until t_q, Mosca's condition [13]

identifies when evidence is exposed. Retention periods are long. Broker dealer records under Rule 17a 4 are kept for up to six years [37], and technical documentation of high risk AI systems for ten years after the system is placed on the market [35].

Smart contract platforms in production today authorise transactions with ECDSA or EdDSA. On such a platform the statement that an account authorised a transaction is evidenced only by a classical signature, and after t_q any account whose public key is known can be made to sign anything. Whether the order of past blocks remains trustworthy depends on how a verifier learns the canonical history. A participant who followed the chain continuously retains its knowledge. Where consensus is itself authenticated by classical signatures, a verifier who reconstructs history after t_q from signatures alone, as a court or an auditor would, cannot distinguish the canonical history from an alternative signed with recovered keys. Where ordering is secured by proof of work, ordering keeps hash based security but the authorisation of each transaction remains classical. It is the signature layer that breaks.

Hash functions are weakened but not broken. Grover's algorithm finds a preimage of an n bit function with O(2^n/2) evaluations [3], and this is optimal for generic search [4]. The algorithm of Brassard, Høyer and Tapp finds collisions with O(2^n/3) evaluations given quantum accessible memory of the same size [5], again optimal for generic functions [6]. Bernstein shows that, once the cost of that memory is counted, the quantum collision search is no cheaper than classical parallel collision search at about 2^n/2 [7]. For n = 256 the margins remain at least 2⁸⁵ in the most favourable model for the attacker and about 2¹²⁸ under realistic cost. This asymmetry between signatures and hashes is the foundation of the design in Section 5.

2.3.1 Classical primitives in agent infrastructure

The infrastructure through which agents are identified, authorised and audited today rests on a small set of public key primitives. The table states, for each, the problem on which it rests and the effect of Shor's algorithm.

Symmetric primitives behave differently. HMAC and the SHA2 family are not affected by Shor's algorithm and are only weakened by Grover's, so HMAC with a 256 bit key retains about 128 bits of security against key search. A message authentication code, however, proves nothing to a third party. Whoever holds the key can recompute a valid tag for any altered entry, and in an audit log the key holder is the operator, so Observation 1 applies unchanged. The same holds for a hash chain kept by the operator without an external anchor, which the operator can recompute from any altered point onwards.

2.4 The regulatory gap

Across jurisdictions, rules require that certain records be generated, retained for defined periods and protected against alteration, or kept so that alteration is detectable. The EU AI Act requires high risk AI systems to allow the automatic recording of events over their lifetime (Article 12), and requires providers and deployers to keep those logs for a period, appropriate to the intended purpose, of at least six months (Article 19 and Article 26(6)) [35]. The eIDAS 2 amendment gives legal recognition to electronic ledgers and attaches a presumption of integrity and of chronological ordering to qualified electronic ledgers (Articles 45h and 45i) [36]. SEC Rule 17a 4 requires broker dealers to keep electronic records either with a complete time stamped audit trail or in a non rewriteable, non erasable form [37]. UK GDPR Article 5(1)(f) requires appropriate security of personal data, including protection against unauthorised processing and accidental loss or damage [38]. The Japanese Electronic Books Maintenance Act requires measures that ensure the authenticity of electronic records, such as time stamps or systems that record corrections and deletions [39]. The safety measures required under Article 29 of the Korean Personal Information Protection Act include keeping access records and protecting them against forgery and alteration [40]. Data Protection Principle 4 of the Hong Kong Personal Data (Privacy) Ordinance requires data users to take all practicable steps to protect personal data against unauthorised or accidental access, processing, erasure, loss or use [41].

The same horizon is now governed by post quantum migration mandates. NIST IR 8547, in its initial public draft, proposes that quantum vulnerable public key algorithms at the 112 bit security level be deprecated after 2030 and that all quantum vulnerable public key algorithms be disallowed after 2035 [27]. Executive Order 14412 directs United States federal systems to adopt post quantum key establishment by 31 December 2030 and post quantum digital signatures by 31 December 2031 [28]. Records created today will therefore be inspected within their retention periods at a time when the signatures that protect them are formally disallowed.

Statutes state Ret explicitly through retention periods and state Int in terms such as protection against alteration or forgery, non rewriteable storage or audit trails. Ver and Time follow from the purpose of supervision and of evidence. The gap is that every mechanism whose Int rests on a classical signature satisfies Int only for 𝒜 restricted to adversaries active before t_q. Whenever t₀ + R > t_q the predicate fails for the remainder of the period. Qstamp is designed to provide Int, Ver and Time for all t in the period against classical and quantum adversaries, under the assumptions of Section 3. Ret remains the obligation of the custodian. No law cited here requires Qstamp. The laws require properties, and Section 9 sets out which of them Qstamp provides.

3. System model and threat model

3.1 Parties

• Operator O. Runs one or more agents, holds their records, and controls a signing key sk_S whose ML DSA 65 public key determines the chain address S. O runs the Qstamp SDK.
• Verifier V. A court, regulator, auditor, insurer or counterparty. V holds only public parameters, which are the genesis hash G of the chain, the address C of the official Qstamp contract and the published validator set, together with whatever O produces.
• Network. The Quantova chain, consisting of the QVM, a validator committee 𝒱 that finalises blocks, and RPC endpoints and an explorer that serve chain data.
• Adversary A. Any party that seeks to have V accept a false statement about a record.

3.2 Assumptions

3.3 Adversary classes

A classical adversary is PPT. A quantum adversary is QPT, may run Shor's and Grover's algorithms offline, and has quantum access to H where a random oracle model is used [16]. Both classes may corrupt the operator after a time t*, which models an insider who later wishes to rewrite history or a later compromise of sk_S. Both may control any other accounts, corrupt committee members up to the bound of T3, delay, reorder or drop network messages, and operate RPC endpoints of their own. The honest operator is assumed to stamp correctly before t*.

Three matters are outside the model and are stated so that they are not mistaken for guarantees. A record that was false when stamped remains false, since Qstamp fixes content and does not judge it. An adversary holding sk_S before a record is stamped can stamp in the name of S, which is a key custody question. Availability of the record and of its receipt is the custodian's responsibility, since a lost salt makes the corresponding inclusion unprovable.

4. The Quantova framework

This section describes the components on which Qstamp relies, as they are live at the date of this paper.

4.1 Quanta, the smart contract language

Quanta is the contract language of the Quantova chain. A Quanta contract compiles to a QVM container. Authority inside a contract derives only from verified signatures. The caller of an entry point is the verified signer of the transaction, and a contract can verify further ML DSA signatures over signed orders through the QVM instruction VERIFY_ML. Every such verification uses the FIPS 204 context string QVM/contract/v1, which FIPS 204 binds into the signed message as

so a signature produced for a contract order cannot be presented as a signature in any other context [24]. The open Qstamp contract is the following Quanta source, which holds no state, no funds and no owner.

The issuer and council templates add signed orders that carry a nonce held by the contract, a deadline and a per deployment domain value, so that an order cannot be replayed, used late or used on another deployment.

4.2 The attested compiler

A container c is identified by id(c) = H(c). The chain admits a deployment only if the identifier carries an ML DSA 65 signature by the compiler provenance key,

The signature establishes that the deployed container was produced by the attested compiler. Equality with reviewed source is then established by reproduction. A reviewer compiles the published source, compares the resulting container byte for byte with the deployed one, and so confirms that the code at C is the code that was reviewed. The published source of the open Qstamp contract compiles byte for byte to the contract deployed on the test network. The guarantee assumes the secure custody of the provenance key by Quantova Inc. For the code identity property only, this is a trust assumption additional to T1 to T5.

4.3 The Quantova Virtual Machine and execution layer

The QVM is a metered register machine with native instructions for ML DSA and SLH DSA [25] verification, hashing and hash trees. Before execution the QVM writes the verified sender of the transaction into contract memory as caller, so the recorded signer cannot be influenced by call data. Execution is atomic. With S the state, tx a transaction and m its meter limit,

where E is the list of emitted events. Events and state changes are recorded only on success, and events are committed to the event root of the block header. A finalised transaction without its event therefore proves nothing about a stamp, and verification in Section 5 requires the event.

4.4 Consensus and finality

Every account, every transaction and every finality certificate on the Quantova chain has been signed with ML DSA 65 since the genesis block, with SLH DSA available as the alternative account scheme described above. An address is a 32 byte value derived from an ML DSA 65 public key. Blocks are finalised by a sampled committee whose certificate carries ML DSA 65 signatures meeting the finality threshold, and finality is reached in about 0.2 seconds. The block time is proposed in whole seconds. Under T4 an accepted block B with parent P satisfies

so block time never decreases and cannot run more than 15 seconds ahead of honest clocks.

4.5 Fees

Execution is metered, and the fee for a call that consumes m units of meter is

with unused reserve refunded. The stamp call has fixed length call data and emits one fixed length event, so its fee does not depend on the batch size N. On the test network one stamp costs 0.005 TQTOV, that is 5000 quon, regardless of N. TQTOV are test network units without monetary value.

5. The Qstamp construction

5.1 Notation

5.2 Leaves, tree and commitment

For record r_i with digest d_i = D_alg(r_i) the leaf is

an evaluation of H on exactly 1 + 14 + 1 + 32 + 32 = 80 bytes. The leaves form the tree of RFC 9162 Section 2.1 [31], whose interior nodes are

an evaluation of H on exactly 65 bytes.

The commitment is

an evaluation of H on exactly 1 + 14 + 32 + 32 + 32 + 8 + 8 + 32 = 159 bytes. The three roles are separated by their first byte and by their lengths, a property used in Lemma 1. The construction follows the hash tree of Merkle [18] and the linking idea of Haber and Stornetta [19], with the domain separation of RFC 9162 and an explicit binding of size and context.

5.3 Anchoring

K is split into two 16 byte halves (hi, lo) and submitted from S in a call to the official contract C,

The call data has fixed length, consisting of the 4 byte selector, 120 bytes of host context, the 32 byte commitment and the 8 byte kind. The event data has 72 bytes. Because the contract keeps no state, any number of stamps of any commitment may coexist, and no stamp can prevent another from being recorded.

5.4 Receipt

Each record receives its own receipt, the tuple

with fmt = qstamp-receipt/1, the chain name id and genesis G, the contract C, the kind k as a decimal string, the digest algorithm, digest and salt, the position, batch size and inclusion path, the tree root, and the anchoring transaction, block height h, block identifier B, block time t in seconds since 1970 and signer S. A receipt contains no part of the record. It does contain the digest and the salt, which matters for Section 6.5.

5.5 Algorithms

Verification returns one of three outcomes. Valid means that every check passed. Invalid means that at least one substantive check failed, including the case in which no record or digest was supplied. Indeterminate means that every failed check was a transport failure, such as an unreachable endpoint or a truncated event list. Indeterminate is never reported as valid. The checks are named format, contract, content, inclusion, chain, transaction, event and block, eight in all.

$ npm install @quantovainc/qstamp
added 2 packages

$ npx @quantovainc/qstamp --version
0.1.4

$ openssl rand -hex 32 > signer.key && chmod 600 signer.key
$ node account.js
address  Q1NUR6ETECQXEVE77TJ9YPZ6WAWYMT45WCJANV5J43X93SF79DWE0S0D572X
status   registered, ready to stamp

{
  "evaluation": {"approved_by": "Model Risk Committee", "auc": 0.871},
  "model": "risk-model 3.2.1",
  "time": "2026-10-09T09:39:27.273Z",
  "training_data": "dataset manifest 2026-09-30",
  "weights_sha3": "f01483b8e6269760c5c2e2025875b6e5d1b16402443e9a98d73e0a43156bf17b"
}

const qstamp = require('@quantovainc/qstamp');
const batch = [];

agent.on('action', (action) => {
  const bytes = Buffer.from(canonicalJson(action));
  log.write(bytes);
  batch.push({ digest: qstamp.digestBytes(bytes) });
});

setInterval(async () => {
  const records = batch.splice(0);
  if (records.length === 0) return;
  const receipts = await qstamp.stamp({
    seed, index: 0, kind: 'ai_agent_action', records,
    onPending: savePending,
  });
  receipts.forEach(storeBesideAction);
}, 60000);

{
  "agent": "credit-decision-agent-07",
  "amount_usd": 125000,
  "applicant": "APP-54a49c823275",
  "decision": "approve",
  "human_review": false,
  "model": "risk-model 3.2.1",
  "operator": "Example Bank plc",
  "policy": "retail-lending-policy 2026-10",
  "reasons": ["score_above_threshold"],
  "risk_score": 645,
  "time": "2026-10-09T09:39:25.132Z",
  "tool": "credit_bureau.lookup"
}

$ npx @quantovainc/qstamp hash action-04.json
  action-04.json

$ npx @quantovainc/qstamp verify action-04.json.qstamp.json --file action-04.json
pass format · pass contract · pass content · pass inclusion
pass chain · pass transaction · pass event · pass block
VALID  stamped no later than 2026-10-09T09:39:25Z in block 2011753

$ npx @quantovainc/qstamp verify action-04.json.qstamp.json --file altered.json
FAIL content  the content does not match the fingerprint in the receipt
INVALID

6. Security analysis

6.1 The evidence forgery game

The game captures the insider who rewrites history after the fact, since A obtains sk_S and still must attach r′ to an anchor from before t*. It captures the outsider who substitutes content, and the third party who attempts to frame S with a record S never stamped. A fresh stamp of r′ after t* is not a forgery, since its receipt states a later time.

6.2 Domain separation

Without the role prefixes an interior node could be presented as a leaf, the classical second preimage ambiguity of unprefixed Merkle trees that RFC 9162 removes [31]. Without u64(N) a root would not determine the shape of its tree, and one path could verify under several sizes.

6.3 Main theorem

Proof sketch. Let A win with output (r′, ρ′), where ρ′ names alg′, d′, s′, position i, size N′, path π′, root′, kind k′, transaction tx, height h, time t ≤ t* and signer S. Validity of all eight checks gives the following facts. G and C are the official values. D(r′) = d′. RootFromPath(L′, i, N′, π′) = root′ with L′ the leaf of (alg′, d′, s′). Under T5 the finalised block at height h contains tx from S to C and an event of C with data S ‖ K′ ‖ u64(k′), where K′ = Commit(G, C, S, k′, N′, root′). We partition the winning event.

1. Consensus failure. The block reported at height h is not the unique finalised block at that height. This contradicts T3 except with probability Adv_consensus, after excluding forged committee signatures, which fall under the next case.
2. Signature forgery. The canonical block at height h carries a transaction from S that the challenger did not sign before t*, or a committee signature that no honest member produced. Before t* the honest stamps are exactly the signing queries, so B₃ guesses which of the q keys is forged, embeds its challenge key there and outputs the forgery. This costs at most q · Adv^EUF-CMA.
3. Honest anchor. Otherwise the event was emitted by an honest stamp with batch (r₀, …, r_N−1), salts s_i, kind k and commitment K, since every transaction from S before t* is honest and the event data names S. Event matching gives K′ = K and k′ = k. By Lemma 1 either (N′, root′) = (N, root) or B₁ or B₂ outputs a collision of two 159 byte strings.
4. Same tree. With equal size and root, Algorithm 3 recomputes root from L′ along a path whose shape depends only on (i, N). Walk from the root towards the leaf. At the first level at which the honest and the presented node inputs differ, both inputs hash to the same output, which by Lemma 1 is a collision of two 65 byte strings. If no level differs then L′ = L_i.
5. Same leaf. By Lemma 1 either (alg′, d′, s′) = (alg, d_i, s_i) or the two 80 byte inputs collide.
6. Same digest. Then D(r′) = d_i = D(r_i) with r′ ≠ r_i, since A wins, which is a collision of D = SHA3 256.

It remains to attribute each collision found in cases 3 to 6 to B₁ or B₂. If the honest input of the colliding pair is a function of values chosen by A alone, as when A chose the batch and the colliding input contains no fresh salt, the pair is a collision and is output by B₁. If the honest input contains a value not chosen by A, namely a salt s_i or a record supplied by an honest party, then the honest input is a target fixed before A searches, and A has found a second input with the same image. This is a second preimage in the sense of Rogaway and Shrimpton for targets drawn from the honest distribution [17], and is output by B₂. The two attributions are disjoint, so a union bound over cases 1 to 6 gives (22). ∎

For alg = 2 the digest step of case 6 relies on SHA 256 and the bound gains the corresponding SHA 256 terms. Binding requires only T1 to T3 in the standard model. Hiding in Section 6.5 uses the random oracle model [15, 16].

6.4 Binding of context, replay and front running

This follows from Lemma 1, and it has five consequences. A commitment anchored on one chain does not verify against another, because G differs, and a relaunched network with a new genesis cannot verify old receipts. A receipt does not verify against a different contract, because C differs. A front runner F that copies K from a pending transaction and submits stamp(K, k) from its own account obtains an event naming F, and a receipt naming F verifies only if K = Commit(G, C, F, k, N, root), a collision. Because the open contract is stateless, the copy does not prevent the original transaction of S from being recorded, so front running neither steals nor blocks a stamp. The declared kind cannot be relabelled after anchoring. The batch size is fixed, which removes the size ambiguity of bare RFC 9162 roots.

6.5 Hiding

The caveat is essential. A receipt holder knows s_i and d_i. Since d_i = D(r_i) is unsalted, a receipt holder can test a guess for a low entropy record, such as an amount or a short code, with one hash evaluation. Receipts must therefore be protected like the records they describe. Hiding protects content against observers of the chain, not against holders of receipts.

6.6 Concrete bounds

NIST category 3 means that breaking the scheme requires resources comparable to or greater than key search on a block cipher with a 192 bit key [24]. FIPS 202 states a collision resistance of 128 bits and a preimage and second preimage resistance of 256 bits for SHA3 256 against classical attack [22].

6.7 Liveness, indeterminacy and the trusted endpoint

Stamping liveness. A stamp completes when the committee finalises its transaction. If finality is not observed within the timeout, Algorithm 1 returns the persisted pending batch, which holds the salts, the commitment and the transaction identifier. The receipts are completed later from that batch without a second payment. An error raised while the transaction was being submitted also carries the pending batch, so salts are never lost to a network failure.

The trusted endpoint of release 0.1. Checks 1 to 4 run on the verifier's machine and depend on no outside party. The chain, transaction, event and block checks are answered by RPC endpoints, so T5 is required. An endpoint operated dishonestly could report an anchor that does not exist. Release 0.1 mitigates this by defaulting to the official endpoint, by checking that every endpoint serves the chain named in the receipt, by requiring every consulted endpoint to agree, and by reporting which endpoints were consulted. Without T5, (22) gains a term Adv_endpoint equal to the probability that every consulted endpoint lies consistently. T5 also covers the channel to each endpoint. Responses travel over TLS, which is transport security outside the Quantova protocol and may use classical key exchange and certificates, so an adversary able to impersonate an endpoint at the transport layer is counted in the same term.

Planned offline finality proofs. A forthcoming release will carry in each receipt the block header of height h, the finality certificate of the committee and an inclusion proof of the Stamped event against the event root of the header. Verification then needs only the receipt, the record and the published validator set. The endpoint term disappears and the chain checks reduce to ML DSA 65 verification under T2 and T3, so (22) holds without T5.

7. Application to autonomous agents and superintelligence agents

7.1 Canonical action records

An action a of an agent is evidence only through a byte encoding canon(a), and the digest is d = D(canon(a)). The encoding must be fixed and versioned by the operator, since two serialisations of the same content give different digests. A change of serialisation produces a false invalid verdict, never a false valid one. A canonical JSON form with lexicographically sorted keys and no insignificant whitespace, such as the scheme of RFC 8785 [32], meets this need. The SDK hashes exactly the bytes it is given and does not impose a serialisation. A useful action record names the agent, the operator, the model and its version, the policy in force, the tool invoked, the inputs relied on, the decision or output, whether a human reviewed it and the time asserted by the agent.

7.2 Batching

An operator collects actions over a window Δ, or up to a count, and stamps them as one batch. An action taken at time τ then has an anchor whose block was finalised no later than τ + Δ + t_fin, where t_fin is the stamping latency. The cost per action is fee / N. Material actions, such as payments above a threshold, can be stamped individually before or after execution so that the record is final before the action completes. The onPending hook lets the operator persist each submitted batch before waiting for finality.

7.3 Record kinds

The kind is a 64 bit value bound into K and emitted in the event. It states what S declared the batch to contain. It is not a verified classification of the content.

7.4 Model passports

A model passport is a pattern of use, not a separate mechanism. At release the operator stamps, with kind ai_model, a record that lists the digests of the model artefacts, the digest of the dataset manifest stamped with kind ai_dataset, and the digests of the evaluation reports. Each later action record names the model version and the digest of its passport, so the receipt for an action leads to the receipt that fixed the model on which the action depended.

7.5 What a receipt proves and what it does not

8. Evidentiary procedure for a court order

Suppose a court or a regulator orders an SI company to show what its agent did in a given matter. The procedure below requires nothing from the company beyond production of documents, and nothing from the verifier beyond public parameters and computation.

1. Production. The company produces the record r and its receipt ρ. The order may also require the canonicalisation rule used for records of that type.
2. Recomputation. The verifier recomputes d = H(r), the leaf L from (alg, d, s), the root from (L, i, N, π) with Algorithm 3, and K from (G, C, S, k, N, root). This step needs no network access and can be performed with the SDK, with the command qstamp verify, or with an independent implementation of Section 5.
3. Anchor. Using the public chain, through one or more independent RPC endpoints and in the explorer, the verifier checks that the transaction named in ρ was sent by S to the official contract C and that block h contains the Stamped event of C with data S ‖ K ‖ u64(k). The explorer is a view of chain data that lets a non technical reader confirm the same facts. It is not a separate trust anchor.
4. Finality. The verifier checks that the transaction is final and that the block at height h has identifier B and time t.
5. Result. If every check passes, the result is valid, and Proposition 5 states what has been established. If a substantive check fails, the result is invalid, and the failed check identifies which link does not hold. If the network could not be consulted, the result is indeterminate and the procedure is repeated.

8.1 Worked example from the Quantova test network

A credit decision agent produced the following record, serialised as canonical JSON with sorted keys and no insignificant whitespace.

The record was stamped in a batch of six records. The values below are taken from that run.

The anchoring transaction can be inspected at https://qvmscan.io/tx/QTX1V53JW528S64SZYD6EDZ563N0PUUA2ARGNQHV4LTJMNH24PQS5VPQTAH8RQ.

Verification of the receipt against the record returned valid, with all eight checks passing.

The amount in the record was then changed by 1000 and the verification repeated with the same receipt. The content check failed and the result was invalid. The other checks are unaffected by the change, which is the intended behaviour, since the verdict names the exact link that broke. For illustration, replacing 125000 by 126000 gives the digest

Two features of the example deserve comment. First, the time field inside the record, 09:39:25.132, is an assertion of the agent and is not certified. The block time is a whole second, 09:39:25, and agrees with the record at that resolution. Second, the time measured from submission to observed finality was about 0.7 seconds, which includes the polling interval of the SDK.

9. Regulatory mapping

The table relates each obligation to the formal property that Qstamp provides and to the limits of that property. The paraphrases are summaries for orientation and do not replace the legal texts [35, 36, 37, 38, 39, 40, 41, 27]. No law cited requires Qstamp. Each requires properties of records, and Qstamp provides some of them.

Each organisation remains responsible for meeting the full requirements of the laws that apply to it, and should take its own legal advice.

10. What distinguishes this construction

We argue that durable evidence for agents requires four properties together, and that a classical chain cannot acquire the first of them for its existing history by migration alone.

1. R1. Post quantum authentication of the whole history. Every signature on which an anchor depends, from the submitting account to finality, is post quantum, back to genesis, and the protocol accepts no classical signature that could establish a competing fact.
2. R2. Independent witness. The anchor is fixed by a committee independent of the custodian, not by the custodian or by one authority.
3. R3. Attested code. The code that records an anchor is provably the reviewed code, and it cannot be replaced at the same address.
4. R4. Programmable authority. Institutional policies, such as authorised issuers, multi party approval and revocation, execute under post quantum authentication.

The condition in Proposition 6 describes a real remedy, which should be stated fairly. Evidence can be preserved by renewal, in which old evidence is committed under stronger primitives before the old ones fail, as in the renewal of Haber and Stornetta [19] and the Evidence Record Syntax of RFC 4998 [34]. Renewal must happen before t_q, must itself be verifiable, and protects only what was renewed. A network that is post quantum from genesis has nothing to renew for its own history. That is the sense in which retrofitting a classical chain leaves its earlier history forgeable unless it is renewed in time.

A post quantum time stamp authority satisfies R1 but rests on one authority and offers no programmable policy. A ledger without attested code satisfies R2 and R4, but a verifier must audit the bytecode at the contract address independently. The table summarises typical deployments of each category as of 2026. It describes categories, not named products.

To our knowledge, few production networks combined R1 to R4 from genesis at the date of this paper. We do not claim that the combination is exclusive to Quantova, and the argument of this section depends only on the properties, not on the identity of any network.

11. Economics and performance

By (15) the fee of a stamp depends only on the meter consumed by the fixed length call, so one stamp costs 0.005 TQTOV, 5000 quon, on the test network for any N. The amortised cost per record is

On chain each stamp adds 164 bytes of call data and a 72 byte event, independent of N. Local verification costs one digest of the record and at most ⌈log₂N⌉ + 2 further SHA3 256 evaluations on inputs of fixed length. Chain verification costs four queries per endpoint, for chain identity, transaction, events and block.

In the test network run that produced the example of Section 8, the time from submission of a stamp to observed finality was about 0.7 seconds, against a chain finality of about 0.2 seconds. The difference is attributable to submission and to the 400 millisecond polling interval with which the SDK observes finality. Four stamps cost 0.02 TQTOV in total, that is 0.005 TQTOV each. These figures are measurements on the test network and are not guarantees of main network performance or price.

12. Limitations and future work

1. Offline finality proofs. Release 0.1 confirms chain facts through RPC endpoints and therefore relies on T5. Embedding the block header, the finality certificate and the event inclusion proof in each receipt, as described in Section 6.7, is planned and will remove that reliance.
2. Per deployment domain in the templates. The issuer and council templates reject orders whose domain value differs from that of the deployment. The value is a 64 bit number chosen by the deployer, and its freshness is an operational obligation. A contract address depends only on the deploying account and its transaction count, so after a relaunch or on a fork a new deployment can receive the address of an earlier one, and only a fresh domain value then prevents orders signed for the earlier deployment from being accepted.
3. Revocation is not yet checked by the SDK. The issuer template records the withdrawal of a commitment with a reason code, but Verify does not consult that state. A receipt for a withdrawn commitment still verifies as valid, and a verifier who relies on withdrawals must query the issuer contract separately.
4. Third party audit. The SDK and the contracts were reviewed internally before publication. The contract templates are published as examples, and an independent audit by a qualified third party is required before any production deployment of them and recommended before reliance on the SDK in production.
5. Time resolution. Block time has a resolution of one second, is bounded above by T4 and below only by the time of the parent block. Receipts establish existence no later than finality, not an earliest time.
6. Completeness. A receipt proves inclusion, not completeness. Consecutive numbering and chaining of batches, as suggested in Section 7.5, are practices of the operator and are not enforced by the contract.
7. Network status. All results in this paper concern the test network. Receipts produced there carry no evidential weight, and production use will take place on the Quantova main network once it launches.

13. Legal status of this paper

This paper is a technical specification and description of Qstamp provided by Quantova Inc for information. It does not by itself create any contractual obligation, warranty, representation or undertaking, and it is not legal, regulatory, tax or investment advice. Use of Qstamp, of the Qstamp SDK and of the Quanta contract templates is governed by the Terms of Use, by the licences under which the software is published and by any agreement signed with Quantova Inc, which prevail over this paper in case of conflict. Statements about laws and regulations are summaries for orientation. Statements about future features describe present intentions and may change.

Small print. Every statement in this paper that Quantova or Qstamp is post quantum, or does not rely on classical signatures, concerns the Quantova protocol, meaning the signatures on accounts, transactions and finality certificates, the attestation of contract code, and consensus. It does not extend to transport security outside the protocol, such as the TLS connections, certificates and key exchange used by websites, the explorer, RPC gateways and other web hosting, which may use classical algorithms. In release 0.1 the chain checks of verification rely on the integrity of responses received from RPC endpoints, which are protected in transit by that transport security (assumption T5 and Section 6.7). Until receipts carry offline finality proofs, a verifier who requires post quantum assurance for those checks should obtain chain data over a channel it trusts or from several independently operated endpoints.

© 2026 Quantova Inc. Qstamp and Quantova are trademarks of Quantova Inc.

14. References

1. [1]P. W. Shor. Algorithms for quantum computation: discrete logarithms and factoring. In Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), IEEE, 1994, pp. 124 to 134.
2. [2]P. W. Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM Journal on Computing 26(5), 1997, pp. 1484 to 1509.
3. [3]L. K. Grover. A fast quantum mechanical algorithm for database search. In Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC), 1996, pp. 212 to 219.
4. [4]C. H. Bennett, E. Bernstein, G. Brassard and U. Vazirani. Strengths and weaknesses of quantum computing. SIAM Journal on Computing 26(5), 1997, pp. 1510 to 1523.
5. [5]G. Brassard, P. Høyer and A. Tapp. Quantum cryptanalysis of hash and claw-free functions. In LATIN '98: Theoretical Informatics, Lecture Notes in Computer Science 1380, Springer, 1998, pp. 163 to 169.
6. [6]S. Aaronson and Y. Shi. Quantum lower bounds for the collision and the element distinctness problems. Journal of the ACM 51(4), 2004, pp. 595 to 605.
7. [7]D. J. Bernstein. Cost analysis of hash collisions. Will quantum computers make SHARCS obsolete? In Workshop Record of SHARCS 2009, Special-purpose Hardware for Attacking Cryptographic Systems, 2009.
8. [8]M. Roetteler, M. Naehrig, K. M. Svore and K. Lauter. Quantum resource estimates for computing elliptic curve discrete logarithms. In Advances in Cryptology, ASIACRYPT 2017, Lecture Notes in Computer Science 10625, Springer, 2017, pp. 241 to 270.
9. [9]J. Proos and C. Zalka. Shor's discrete logarithm quantum algorithm for elliptic curves. Quantum Information and Computation 3(4), 2003, pp. 317 to 344.
10. [10]C. Gidney and M. Ekerå. How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits. Quantum 5, 433, 2021. First circulated as arXiv:1905.09749, 2019.
11. [11]C. Gidney. How to factor 2048 bit RSA integers with less than a million noisy qubits. arXiv:2505.15917, 2025.
12. [12]M. A. Nielsen and I. L. Chuang. Quantum Computation and Quantum Information. Cambridge University Press, 2000.
13. [13]M. Mosca. Cybersecurity in an era with quantum computers. Will we be ready? IEEE Security and Privacy 16(5), 2018, pp. 38 to 41.
14. [14]S. Goldwasser, S. Micali and R. L. Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing 17(2), 1988, pp. 281 to 308.
15. [15]M. Bellare and P. Rogaway. Random oracles are practical. A paradigm for designing efficient protocols. In Proceedings of the 1st ACM Conference on Computer and Communications Security (CCS), 1993, pp. 62 to 73.
16. [16]D. Boneh, Ö. Dagdelen, M. Fischlin, A. Lehmann, C. Schaffner and M. Zhandry. Random oracles in a quantum world. In Advances in Cryptology, ASIACRYPT 2011, Lecture Notes in Computer Science 7073, Springer, 2011, pp. 41 to 69.
17. [17]P. Rogaway and T. Shrimpton. Cryptographic hash-function basics. Definitions, implications, and separations for preimage resistance, second-preimage resistance, and collision resistance. In Fast Software Encryption, FSE 2004, Lecture Notes in Computer Science 3017, Springer, 2004, pp. 371 to 388.
18. [18]R. C. Merkle. A digital signature based on a conventional encryption function. In Advances in Cryptology, CRYPTO '87, Lecture Notes in Computer Science 293, Springer, 1988, pp. 369 to 378.
19. [19]S. Haber and W. S. Stornetta. How to time-stamp a digital document. Journal of Cryptology 3(2), 1991, pp. 99 to 111.
20. [20]L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler and D. Stehlé. CRYSTALS-Dilithium. A lattice-based digital signature scheme. IACR Transactions on Cryptographic Hardware and Embedded Systems 2018(1), pp. 238 to 268.
21. [21]E. Kiltz, V. Lyubashevsky and C. Schaffner. A concrete treatment of Fiat-Shamir signatures in the quantum random-oracle model. In Advances in Cryptology, EUROCRYPT 2018, Lecture Notes in Computer Science 10822, Springer, 2018.
22. [22]National Institute of Standards and Technology. SHA-3 Standard. Permutation-Based Hash and Extendable-Output Functions. FIPS PUB 202, August 2015.
23. [23]National Institute of Standards and Technology. Secure Hash Standard (SHS). FIPS PUB 180-4, August 2015.
24. [24]National Institute of Standards and Technology. Module-Lattice-Based Digital Signature Standard. FIPS 204, August 2024.
25. [25]National Institute of Standards and Technology. Stateless Hash-Based Digital Signature Standard. FIPS 205, August 2024.
26. [26]National Institute of Standards and Technology. Digital Signature Standard (DSS). FIPS 186-5, February 2023.
27. [27]D. Moody, R. Perlner, A. Regenscheid, A. Robinson and D. Cooper. Transition to Post-Quantum Cryptography Standards. NIST Internal Report 8547, Initial Public Draft, National Institute of Standards and Technology, November 2024.
28. [28]Executive Order 14412. Securing the Nation Against Advanced Cryptographic Attacks. The White House, Washington, signed 22 June 2026.
29. [29]Certicom Research. SEC 2. Recommended Elliptic Curve Domain Parameters. Standards for Efficient Cryptography, Version 2.0, 2010.
30. [30]S. Josefsson and I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032, Internet Engineering Task Force, January 2017.
31. [31]B. Laurie, E. Messeri and R. Stradling. Certificate Transparency Version 2.0. RFC 9162, Internet Engineering Task Force, December 2021.
32. [32]A. Rundgren, B. Jordan and S. Erdtman. JSON Canonicalization Scheme (JCS). RFC 8785, Internet Engineering Task Force, June 2020.
33. [33]C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161, Internet Engineering Task Force, August 2001.
34. [34]T. Gondrom, R. Brandner and U. Pordesch. Evidence Record Syntax (ERS). RFC 4998, Internet Engineering Task Force, August 2007.
35. [35]Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L series, 12 July 2024.
36. [36]Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Official Journal of the European Union, L series, 30 April 2024.
37. [37]United States Securities and Exchange Commission. Rule 17a-4, Records to be preserved by certain exchange members, brokers and dealers. 17 CFR 240.17a-4.
38. [38]Regulation (EU) 2016/679 as it forms part of the law of the United Kingdom (UK GDPR), Article 5(1)(f).
39. [39]Japan. Act on Special Provisions concerning Preservation Methods for Books and Documents Related to National Tax Prepared by Means of Computers (Act No. 25 of 1998), and its Enforcement Regulation.
40. [40]Republic of Korea. Personal Information Protection Act, Article 29, and the standards on safety measures for personal information issued under it by the Personal Information Protection Commission.
41. [41]Hong Kong Special Administrative Region. Personal Data (Privacy) Ordinance (Cap. 486), Schedule 1, Data Protection Principle 4.