Research governance
How we scope, check, and share the work.
A guide to the project's current research boundaries and source policies, with links to the underlying records.
01 / Scope
Research with a declared boundary.
The cryptographic program studies secp256k1 ECDLP and the applicability of candidate research routes. An idea, a formal lemma, a bounded experiment, and an authorized target evaluation are distinct stages.
Project experiments require the scope, inputs, budget, validation method, and authorization recorded in the decision contract. A completed run does not authorize another run or promote an attack route.
The external pilot accepts synthetic instances, published challenges, or owned and explicitly authorized instances that do not protect live funds, accounts, or third-party assets. It is not a key-recovery service.
02 / Evidence
State exactly what the checker accepted.
Formal results are linked to Lean declarations and their stated assumptions. Trust labels disclose the checker path, including compiler trust where applicable. A checked statement does not automatically establish that a model captures a real-world system.
Empirical observations and independently replayed runs retain their instance and budget limits. Scoped negatives do not rule out every wider approach. ECDLP and ResearchOS results remain in separate canonical ledgers.
03 / Publication
Open work, with its provenance intact.
Original project contributions use Apache-2.0 under the repository's licensing policy. Existing contributor rights, attribution, third-party licenses, and notices are preserved. Citing a paper does not license the paper.
Before publication, each artifact must respect its applicable rights and obligations, including third-party material, confidential information, and any applicable provider or program terms.
These project research controls do not add a research-only or noncommercial restriction to Apache-2.0.
04 / Information handling
Keep sensitive material out of public intake.
Do not submit private keys, seed phrases, API credentials, personal records, or confidential datasets to public issues. Use public or sanitized examples when discussing a research workflow.
For a sensitive security or integrity finding, use GitHub private reporting when enabled, or first ask the maintainer for a private channel without including the sensitive details. The project does not promise a response deadline.
Security and integrity reporting · Pilot information boundary
05 / Accountability
Project decisions remain reviewable.
Maintainers own decisions to accept results, authorize experiments, and change public claims. Proposed changes are reviewed through the repository; generated pages follow canonical state and checked-in sources.
This page describes the current project workflow. It is not a certification, external audit, or claim of approval by an AI provider or access program.