An evolving research intelligence for the post-quantum transition.
QAVEN exists to help digital identity, authority, and ownership survive a change in the foundations of trust.
A key can stand for a person, control an account, and authorize a transfer. Moving to a new cryptographic system changes more than the signature format. It changes which proof is trusted, when an old key loses power, and how a failed migration is handled.
Trust must survive the transition.
The intelligence we want to build
QAVEN is designed as a public research system with two AI roles. SEEKER searches for reproducible migration failures. KEEPER proposes bounded repairs. A fixed program checks whether a candidate respects the rules and keeps legitimate operations working.
The intelligence grows through a versioned memory of tested methods: failures it can reproduce, repairs it can justify, and regressions it must not forget.
A precise beginning, a long mission
The first chapter studies the retirement of an old key during a transition to ML-DSA signatures. The long-term ambition is a reusable security memory for wallets, identity systems, and signing services: a place where each verified failure helps the next implementation start further ahead.
Current stage The AI research service and the public submission backend are live. Two model roles run against the fixed verifier, and every finished research round is published in the archive.
The signature standards are here. The handoff still needs to work.
Post-quantum migration is becoming practical engineering work. We can test real signature algorithms today while studying the application behavior around them on ordinary CPUs.
Standardized signatures
NIST published FIPS 204 in August 2024, defining ML-DSA. A standardized signature gives the first chapter a concrete algorithm to use and a specification to respect.
Migration is a system problem
The NIST NCCoE migration project works on discovering cryptographic use and testing interoperability. Replacing an algorithm is only one part of a transition that also includes protocols, dependencies, identity, and operational behavior.
Implementation is accessible
OpenSSL documents ML-DSA support. The existing local QAVEN probe already performs real classical and ML-DSA signing and verification. No quantum hardware is required to test whether an application grants permission to the correct key.
Our opening
We focus on the gap between cryptographic proof and application authority. An algorithm can be correct while a handoff, fallback branch, or recovery process still violates the intended rules.
This is a case for preparation and testing. It does not depend on predicting a date when a quantum computer will break a particular live system.
A failure should become something the next builder can use.
The most valuable outcome is a lesson that outlives the experiment.
For people building identity and ownership
QAVEN aims to produce reproducible counterexamples, executable regression cases, versioned handling strategies, and evidence packages that another developer can inspect. These can help wallet, identity, and signing-service teams test the assumptions at a migration boundary.
For research
A visible chain from challenge to candidate to acceptance makes progress accountable. We can compare methods under matching resource conditions, preserve failure as well as success, and discover where a promising repair stops working.
For the public
A visitor can influence the research by contributing a case the system must face. A useful contribution has a concrete afterlife: it becomes an attributed issue, reduction, independent check, or regression in the research history.
The ambition
Over time, QAVEN could become a shared memory of the transition: less repeated discovery, clearer failure modes, and stronger starting points for the next generation of systems.
External adoption, commercial demand, and measurable improvement from AI are hypotheses to establish. This site does not claim those outcomes have already happened.
Within the threat model, SEEKER combines permitted events such as delay, reordering, replay, and predefined validation failures. It tries to find and reduce a sequence where an implementation disagrees with the fixed reference policy.
It can control only the keys and events allowed by the scenario. It cannot simply ask the new private key to authorize the attack.
KEEPER repairs
KEEPER receives a reproduced failure and proposes a restricted handling change. The implementation accepts structured strategies and a bounded rule language; it never executes model-written code.
The kernel verifies
The verifier is ordinary software. It checks real cryptographic results, current authority, valid user flows, regressions, and separate evaluation scenarios. A candidate that rejects every operation fails because legitimate access must keep working.
Algorithms, permission requirements, and acceptance rules stay fixed. The agents cannot improve their scores by changing what counts as correct.
What visitors can inspect
Public research notes show the objective, hypothesis, attempted sequence, evidence, proposed change, and verification outcome. These are reviewable research summaries, not a display of a model’s private internal chain of thought.
Inherited methods, bounded implementation changes, and evidence.
The proposed research loop improves methods around a fixed task. It does not require retraining foundation-model weights or adding a third AI judge.
What can change
SEEKER methods: how tests are generated, prioritized, combined, and reduced.
KEEPER candidates: the permitted migration-handling rules or implementation within the agreed sandbox.
The research archive: attributed cases, regressions, acceptance records, and links between method versions.
What stays fixed for a comparison
The cryptographic algorithms, permission specification, evaluation rules, model configuration, target version, and resource conditions must be recorded and fixed for the relevant comparison. Public records identify a resource profile and report whether conditions matched; the interface does not independently certify that report. Discovery and repair happen against an identifiable target.
How progress earns its name
Compare effective counterexamples, reproduction effort, continued success of valid operations, and performance on withheld scenarios under matching resource conditions and repeated runs. Reused development checks and a fresh final evaluation set have different roles; repeated exposure cannot be presented as unseen generalization.
What is inherited
An accepted candidate links to its parent method, the failure that motivated it, the test conditions, and the verifier’s decision. Later applicable versions inherit the regression obligation. A failure or a plateau remains visible.
Live boundary The loop now runs with real models against the fixed verifier. The first published round produced a verified finding; its repair candidate was evaluated and not retained. A retained improvement has not yet been demonstrated.
The signature is still real. Its authority has ended.
The first chapter establishes a small account model: a legacy key controls the account, a post-quantum key is prepared, the handoff completes, and the old key loses current authority.
Legacy control→Prepare PQ key→Confirm handoff→Retire old authority
Authenticity and authority
A request signed before the handoff can arrive afterward. Its historical signature may remain authentic. Whether it may execute now is a separate decision determined by the current policy, active key, epoch, and message context.
Two required layers
General retirement calibration covers delayed messages, replay, and revoked authority. Designed faults prove that the test machinery can detect known mistakes.
Real cross-algorithm cases use ML-DSA and check algorithm, key, epoch, and context binding. A failed required PQ signature must not silently reopen a legacy authorization path.
What a repair must preserve
The retired-key path must be correctly restricted while a valid current-key request still succeeds. Verification errors are distinct from invalid signatures; infrastructure failure is not evidence of a successful security decision.
Evidence boundaries
The account environment and deliberate faulty handlers are our test fixtures. They are not newly discovered vulnerabilities in an external production system. A claim about such a system would require reproduction and attribution of its own.
Select one of three predefined boundary sequences: a delayed old request, invalid post-quantum fallback, or a replayed request. The selected sequence is submitted within the experiment’s threat model.
Follow the result
The service gives each submission a public identifier and a traceable status: queued, running, completed, failed, or paused. A candidate repair can then link to the same issue.
What a useful contribution leaves
A new reproduced failure and its original submission.
A smaller trace that makes the same issue easier to verify.
An independent reproduction under recorded conditions.
An accepted repair linked to its evidence and parent version.
One issue is not counted again each time someone submits it. Discovery, reduction, reproduction, and repair can still receive separate attribution.
Your challenge becomes a memory
After validation and deduplication, a case can enter the regression archive. Later applicable versions must continue to face it. A player’s contribution then affects the research itself, not just a cosmetic score.
Try it today The challenge composer submits the selected boundary sequence to a published experiment under your contributor identity, and its status stays queryable. Rewards and on-chain records are not connected.
Deliver a complete first loop. Expand when the evidence supports it.
The outline contains four research directions. The first release combines the shared experiment system with Chapter One; the remaining three are conditional extensions.
01 — The Retired Key
Boundary: authority after a handoff. Test old-key retirement, replay, cross-algorithm bindings, and forbidden fallback. Deliver reproducible cases, fixed acceptance, evidence replay, and a complete challenge-to-result path.
02 — Split Trust
Boundary: coexistence while classical and PQ mechanisms are both in use. Test downgrade, policy disagreement, and hybrid acceptance without weakening the agreed requirements.
03 — Lost Identity
Boundary: recovery when current credentials are lost. Begin with one explicit recovery mechanism. Test whether revocation, old backup material, or changing participants can restore unauthorized power.
04 — Across Generations
Boundary: interoperability between implementations. Start with two selected implementations, compare their handling of the same material, and explain disagreements against explicit encoding and policy rules.
The release approach
Build a useful first chapter and a system that can load later tasks. Each new chapter needs a threat model, reference rules, fixtures, held-out evaluation, cost measurement, and a demonstrated reason to add it. A new season is a research expansion, not a scheduled promise of automatic improvement.
The live service runs on Python with a SQLite state store and file artifacts; scheduled rounds drive the research queue, and OpenSSL performs real signature operations. Evidence and version identifiers connect each stage.
Coordinate model execution
SEEKER and KEEPER call model APIs through a metered provider gateway in scheduled rounds. Strict structured outputs, allowed operations, step limits, and timeouts keep experiments controllable. Duplicate-call checks and an immutable spending ledger direct computation toward useful research.
Share results, schedule research
The service separates reading published records from scheduling new research: browsing the archive never starts an experiment or a model call. Shared results and bounded workers reduce duplicate calls and unnecessary computation, so compute serves effective research. The first live rounds provide initial cost and duration samples; the sustained production cadence is still being calibrated.
What needs measurement
Resource scheduling is evaluated against useful research work. Model API use and round duration are now measured on the live server; throughput under a sustained production cadence remains to be characterized.
The implementation order
The independent reference model, finite trace runner, inspectable evidence archive, AI roles, and public challenge service are implemented and live. The remaining work is calibrating the production cadence and spend limits from measured rounds.
Known inputs. Inspectable results. Clear attribution.
The recorded local probe
PROBE–03 records 13 of 13 fixed checks passing locally. It uses real classical and ML-DSA signature operations, records cryptographic verdicts, and includes designed retired-key and invalid-fallback cases.
This is a small fixed experiment on the existing local machine. It is not an AI-generated repair, a VPS load test, independent NIST-vector validation, FIPS certification, or a production audit.
The homepage context image shows the AQT dilution refrigerator, credited to Advanced Quantum Testbed / Berkeley Lab. It is sourced from the National Quantum Initiative image gallery, which permits reuse with attribution.
QAVEN’s experiments run on ordinary CPUs. The hardware photograph provides context; it is not equipment owned or operated by this project. The two-role diagrams are original explanatory schematics.
Research provenance
The public archive contains public test vectors with upstream notices, implementation contracts, and recorded verification runs. A source is evidence for a specific claim, not an endorsement of QAVEN by its author.
Documentation / updated 26 Oct 2026
Context photograph
The homepage hero shows cryogenic wiring in the Advanced Quantum Testbed dilution refrigerator at Berkeley Lab, from the U.S. Quantum image gallery. It is context only: it is not this project’s hardware, and no result recorded here was measured on it. National Quantum Initiative image gallery
A live research service. A published archive. Verified rounds on the record.
Available now
A deployed research service: SEEKER and KEEPER model calls, the fixed verification kernel, and immutable evidence and spending ledgers.
A public archive connected to the service; every finished round is published as it completes.
Public challenge submission with contributor identities, idempotent request keys, and queryable submission status.
The recorded local probe PROBE–03 with its report and public fixtures.
This English site with documentation and crystal brand assets.
Research operations
Research rounds run under configured scheduling and spending controls. Published records show each round’s status and outcome; production cadence and resource use are evaluated from measured runs.
The open research question
The loop is connected and measured per round. What remains to be shown, over many rounds, is whether it retains real improvements: repairs that pass the fixed evaluation, and methods that earn their place against the baseline.
Deployment and issuance
The research service is publicly deployed and serves the archive behind this site. This website does not connect wallets, issue tokens, or execute on-chain contributions.