An evolving research intelligence for the post-quantum transition.
EVORPH 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
EVORPH 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 This site is an interactive frontend prototype. A fixed local cryptographic probe exists. The AI research service and public submission backend are the next implementation stages.
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 EVORPH 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
EVORPH 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, EVORPH 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. The prototype 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 first implementation should accept structured strategies and a bounded rule language rather than execute arbitrary 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.
Prototype boundary The website illustrates this process. Real model-driven improvement has not yet been demonstrated by the current local probe.
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.
Combine allowed delivery conditions: delay an old request, change an event order, replay existing signed bytes, or trigger a predefined verification failure. Contributions stay within the experiment’s threat model.
Follow the result
The intended service will give a submission an experiment identifier and a traceable status: reproduced, invalid, duplicate, unresolved, or ready for a separate evaluation. 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 current challenge composer saves a local draft and exports JSON. Public submission, contributor accounts, 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 planned service uses Python and FastAPI, a persistent task queue, SQLite plus file artifacts, and an officially maintained OpenSSL release for real signature operations. Evidence and version identifiers connect each stage.
Coordinate model execution
The planned SEEKER and KEEPER service would use official model APIs in scheduled batches. Structured outputs, allowed operations, step limits, and timeouts are intended to keep experiments controllable. Duplicate-call checks and bounded retries would direct computation toward useful research.
Share results, schedule research
The intended service separates reading published records from scheduling new research. Shared results and bounded workers are intended to reduce duplicate calls and unnecessary computation, so compute serves effective research. Resource scheduling and operational behavior still need implementation and measurement.
What needs measurement
Resource scheduling should be evaluated against useful research work. Actual server throughput, model API use, and operational behavior remain to be measured with the fixed runner and first model batch. This is a design direction, not a demonstrated operating result.
The implementation order
Finish the independent reference model and finite trace runner; validate the algorithm interface against matched NIST material; expose inspectable evidence; then add the AI roles and public challenge service. The current browser prototype is the presentation layer.
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.
EVORPH’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 EVORPH by its author.
An independent research engine, with an issuance layer to decide separately.
Robinhood Chain remains the preferred future issuance direction. BSC is the alternative under consideration. The research experiments run off-chain and do not depend on x402.
The role of a future token
Research-task funding, bounded experiment budgets, and verified-contribution rewards are possible design areas. Mechanics, supply, contracts, distribution, and economic demand are not established by the frontend.
The security boundary
Using ML-DSA inside the experiment does not make an entire chain, its wallet ecosystem, or a project token quantum-resistant. The guarantees of the experiment and the guarantees of a settlement network must be evaluated separately.
Brand identity
The electric-lime visual language reflects the preferred ecosystem direction while keeping EVORPH’s own identity. It does not imply an official Robinhood affiliation. The brand and avatar page contains the current identity assets for review.
A real first probe. A reviewable frontend. A research service still to build.
Available now
The mission, product outline, chapter model, architecture contracts, and curated source foundation.
A local fixed cryptographic probe with recorded report and public fixtures.
This English frontend with a data-driven public research archive, local challenge drafts, documentation, and crystal brand assets. The archive is not connected to a research service.
Next implementation work
An independent reference model, bounded trace executor, matched NIST-vector checks, and an evidence replay path. These establish the fixed acceptance layer before model-generated candidates are introduced.
After the fixed foundation
Connect SEEKER and KEEPER through controlled API budgets, preserve method versions and evaluation conditions, add public challenge submission and contributor attribution, and measure whether the loop actually improves.
Deployment and issuance
No public research service, wallet connection, token issuance, or live on-chain contribution system is part of the current frontend. The interface is reviewed before implementation proceeds.