1. Before You Begin

• Submission, acceptance for review, and PR merging do not constitute an award. Verification, public review, confirmation, and announcement are separate stages.

• Only complete solutions to the original problem and complete Lean proofs are accepted. Partial progress—including special cases, intermediate lemmas, weaker conclusions, or conditional arguments relying on additional unproven assumptions—is not accepted. Lean proofs must not rely on sorry, admit (including placeholders in challenge templates), or new unproven assumptions introduced to fill missing steps. A complete mathematical solution does not make an incomplete formalization eligible for submission.

• Do not post payment addresses or mailing addresses on GitHub. Submit these only by email.

• The sole official contact email is thejustinsunprize@hejustinsun.com.

• We will only send emails from @hejustinsun.com and will never request private keys or seed phrases.

• Claims must be initiated by the contributors themselves. We do not submit claims on anyone’s behalf or proactively pursue contributors who have not claimed. No award is distributed for an unclaimed role, but this does not affect the other role’s progress for the same problem.

2. Step 1 · Participate in Verification

2.1 Choose a Problem

Problem catalog: https://github.com/TheJustinSunPrize/awards/tree/main/problems

2.2 Submit a PR Based on Your Contribution Type

First, fork this repository, edit the problem’s existing problems/catalog-XXXX-XXXX.md entry in your fork, and open a PR. The submission template will appear automatically; complete it as instructed.

Fork: https://github.com/TheJustinSunPrize/awards/fork

External PRs should modify only these four sections of the problem entry: Current status (including Proof contributors:), Lean proof, Attribution basis, and Publication details. Use only Open or Solved as status values. We will reconcile the index, status, and eligibility fields after review. Submit other record corrections through an Issue, and do not modify unrelated files.

Lean formalizers / Contributors claiming both roles

Register the repository containing your own Lean proof as the problem’s formalization source.

• The GitHub account submitting the PR must own that repository. Do not use a mirror or re-upload of someone else’s proof, or register a proof on another person’s behalf. Repository ownership alone does not establish authorship; authorship is verified separately under §3.2.

• Do not include proof source code, build artifacts, dependencies, or archives in the PR. Keep the proof itself in your own external repository.

• Complete the following PR sections:

  • Proof submission: Repository, branch, full 40-character commit SHA, proof file paths at that commit, and the fully qualified name of the theorem providing the complete proof.

  • Formal statement: Location of the formal statement, with links pinned to the full commit SHA; the target theorem’s fully qualified name; the statement’s source; and an explanation of how its definitions, assumptions, quantifiers, conclusions, and branches correspond to the original problem.

  • Reproduction: Lean version and lean-toolchain path; pinned dependency versions, including mathlib, and the dependency manifest path; a link to build instructions; commands to build from a clean checkout and check the target proof; and the command and output for the target theorem’s #print axioms.

• Your specified commit is both the version to be verified and the time reference used when comparing priority.

• The lean-verify skill is not part of the submission process. The repository’s skills/lean-verify/SKILL.md is our internal testing and checking tool. Participants are not required to run it; not running it is neither a submission defect nor a barrier to acceptance. Earlier versions incorrectly described a self-check as mandatory and a prerequisite for acceptance. That wording caused unnecessary misunderstandings and has been removed. We will independently check the theorem statement and reproduce the verification; acceptance depends on our verification findings.

• The PR template’s Pre-submission Lean verification section is optional. If you performed your own checks, you may provide the repository and full 40-character commit SHA checked, which must match the Proof submission section; the verification date and conclusion; and a brief result summary for each problem and proof version. Leaving this section blank does not affect acceptance.

Mathematical solvers without Lean formalization

You do not need a Lean repository. In the PR template:

1. Select Mathematical solver information under Submission type.

2. Remove the four Lean-specific sections: Formal statement, Proof submission, Reproduction, and Pre-submission Lean verification.

3. Under Problem, provide a public mathematical proof or publication link, with the relevant pages, theorem, version, or date.

4. Under Attribution, identify the solver and their contribution, any independent verifier, and public authorship evidence, such as the paper’s author list, an announcement by the author or project, or another public attribution source.

5. Update the catalog entry’s Current status (including Proof contributors:), Publication details, and Attribution basis.

Confirming that a problem has been mathematically solved — applicable to all submission types

The mathematical solution does not need to be reported by the solver personally. It may be confirmed through sources including:

• Solution attribution and references already recorded in the catalog entry.

• A link supplied with the PR establishing that the problem has been solved—for example, a paper, preprint, journal page, or announcement by the author or project. The person providing the link does not have to be the solver; a formalization contributor may provide it.

• Other independently verifiable public records.

We use this evidence to confirm the mathematical solution and register a solver candidate. Registration does not constitute any commitment to the solver or mean that they have submitted a claim. Claims must still be initiated personally, as explained in 1 and §3.1.

2.3 Await Verification

Required review and registration order

We always confirm the mathematical solution and register the solver candidate before verifying the Lean proof and registering the formalization candidate. This order applies even when both contributions are submitted together.

A Lean submission must identify the corresponding accepted mathematical solution, the evidence supporting its acceptance, and the existing solver candidate record—or the solver’s award record if they have already received an award. Successful compilation does not allow these prerequisites to be skipped.

This does not require formalizers to wait for the solver to come forward. As explained at the end of §2.2, the mathematical solution may be confirmed from public sources.

Lean formalizers / Contributors claiming both roles

• After confirming the mathematical solution and registering the solver candidate, we verify the Lean formalization referenced in the PR.

• Once verification succeeds, we compare priority. If no formalization source has previously been recorded for the problem, the submission is treated as the earliest and merged. If multiple submissions pass verification during the same review period, the earliest is merged.

• We compare the timestamp of the specified commit in your own repository, not the date you opened a PR in this repository.

• A commit timestamp alone is not evidence of completion time. Git allows contributors to set author and committer dates themselves. Provide independently verifiable public history linking that proof version to the claimed date, such as public repository history, a public release, or a third-party archive. Where dates conflict or supporting evidence is missing, we will not replace an existing priority record until the dispute is resolved.

• Example: You completed and committed a Lean proof for JSP-000305 in your repository on March 1, 2026, but opened your PR on September 20, 2026. Another contributor completed their proof on June 1, 2026, and opened their PR on September 18, 2026. We compare March 1 with June 1, so your contribution has priority, subject to independently verifiable public history.

• PR merging means that the repository is recorded as the problem’s current formalization source. It does not constitute an award or start public review. The 14-day public review begins when the candidate entry for that role is published in the public notice register (v8 correction, as determined by the project owner on September 22, 2026). Publication is a separate action performed by our team, as described in §2.4. The merge date is not the start date. During public review, the entry may be replaced by an earlier submission that passes verification.

Mathematical solvers

• We review the public publication and authorship evidence you provide. If accepted, we merge the PR and register you as a solver candidate.

  • If the problem already has a formalization source: We publish the candidate entry in the public notice register after merging. The 14-day public review begins on the publication date.

  • If the problem does not yet have a formalization source: We register your submission and retain its timestamp, but public review does not begin. Once formalization is available, we notify you, and public review begins upon publication in the register.

• Mathematical attribution may be recorded before formalization, but award distribution requires the problem to have a formalization source. Formalization is a necessary condition for award consideration.

• Eligible to claim in the catalog describes the problem’s current verification status, not eligibility to participate (v7 correction, as determined by the project owner on September 22, 2026):

  • No: The problem does not currently have a submission that has passed verification. This does not exclude the problem from the prize or prevent anyone from submitting work or a claim. Once your complete solution is accepted, your claim is registered as usual; public review and distribution wait until formalization is in place.

  • Yes: The problem already has verified mathematical solution and formalization records. This is also one of the criteria for the special submission route in §2.6. These problems have undergone preliminary verification, and the earliest solution and formalization records identifiable from currently available public information have been recorded. The authors may claim directly without first submitting a PR.

  • These meanings are consistent: No does not prevent participation; Yes additionally provides a route that does not require a PR.

2.5 Enable Notifications

After submitting a PR, you will automatically receive notifications for that PR. Make sure email notifications are enabled on your GitHub account. We also recommend selecting Watch for this repository and choosing Participating and @mentions, or Custom with Pull requests selected, so you do not miss verification results or requests for corrections.

Your 14-day period begins when the candidate entry for your role appears in the public notice register. Publication therefore determines the start date. We recommend monitoring publication PRs under candidates/ and changes to candidates/public-notice.md.

2.6 Special Submission Route: Direct Claims for Work Already Recorded in the Catalog

Who may use this route

Authors may submit a claim-award Issue without first opening a PR if either condition applies:

1. The catalog entry is marked Eligible to claim = Yes. These problems have undergone preliminary verification, with the earliest solution and formalization records identifiable from currently available public information already recorded. A check of origin/main on September 21, 2026, identified 66 such problems out of 1,022.

2. The result was achieved in 2026 or later and has already been recorded in the catalog, regardless of whether the problem is marked Eligible to claim = Yes.

Why a PR may be skipped

These results have already undergone preliminary checks and been entered in the catalog. Procedurally, this is equivalent to the contribution PR having been merged but the candidate entry not yet having been published in the public notice register.

This route waives only the requirement to submit a PR first. Priority comparisons, public review timing, challenges and replacement, identity verification, and written recipient confirmation follow the normal process without different standards or reduced requirements.

How to submit

• Use the claim-award Issue template described in §3.1. The title and general content requirements remain unchanged.

• Include:

  1. A link to the problem’s catalog entry.

  2. A public publication link supporting the result, such as a paper, preprint, journal page, or announcement by the author or project.

  3. Your own author repository account:

     • Formalization claims: The account must own the repository containing your Lean proof. Include the full 40-character SHA of the commit on which your claim is based.

     • Mathematical solution claims: The account is used to establish your connection to the author of the public publication. Identity verification still follows §3.2.

• A merged PR link is not required. That requirement in §3.1 does not apply to this route.

Priority and replacement

As determined by the project owner on September 21, 2026, the same standards apply as in §2.3 and §3.3:

• Mathematical solutions: If someone provides an earlier public publication and establishes that it solves the problem, that contribution has priority and replaces the existing registration under this route.

• Formalizations: If another contributor references a repository containing a correct Lean proof, and their specified commit predates the currently registered proof commit, their contribution has priority.

• The existing constraints in §2.3 apply: commit timestamps alone do not establish completion time and must be supported by independently verifiable public history. Conflicting dates or insufficient evidence must be resolved before an existing priority record is replaced.

• The replacement procedures in §3.3 apply in full: the displaced claim is closed; the replacement candidate receives a new full 14-day period starting on publication in the public notice register; the replacement contributor must submit their own claim and complete their own identity verification; and the displaced claimant’s confirmation and payment or delivery information cannot be reused.

Public review start date

The same rule applies as for the standard route: public review starts when the candidate entry for that role is published in the public notice register (v8 correction).

This route has no PR merge date. The “deemed merge date” introduced in v6—the date of the repository commit that recorded the result in the catalog, or the acceptance date if that commit could not be identified—has been abolished in v8. The associated “pending final confirmation by the project owner” item is also closed. With a unified start-date rule, this route no longer needs a separate calculation.

3. Step 2 · Award Claims and Public Review Challenges

3.1 Submit an Award Claim Issue Using the claim-award Template

Form: https://github.com/TheJustinSunPrize/awards/issues/new?template=claim-award.yml

• The title automatically includes [Award claim] JSP-. Add the problem number.

• Include the problem’s catalog link and your merged PR link. If the two roles were accepted through separate PRs, include both.

  • Exception introduced in v6: For the special route in §2.6, provide the catalog entry, public publication link, and your own author repository account instead of a PR link. Formalization claims must also include the full 40-character commit SHA. All other requirements remain unchanged.

• The Follow-up contact email field specifies the address for subsequent communication. This address will be public in the Issue. You do not need to post a separate reply to specify an email address.

• For Original Lean proof repository, which is marked optional in the form:

  • Lean formalizers / Both roles: Provide your own repository already recorded as the formalization source. If its URL is missing, we will request it before approval.

  • Mathematical solution only, with an existing formalization source: You may leave this blank or link to the recorded source, even if it belongs to someone else. We rely on the source registered in the catalog.

  • Mathematical solution only, without a formalization source: Leave this blank or enter None. Your claim will be retained while awaiting formalization.

• Select one contribution type: Mathematical solution, Lean formalization, or Both. The two contribution types are reviewed separately, even when submitted by the same person.

• Submit personally using your own GitHub account. Claims and collection on another person’s behalf are prohibited.

• Use your GitHub account as your identity in the Issue; your real name is not required. If we have assigned you a recipient ID, you may use that instead. Submit your real name, affiliation, and other contact details only by email.

3.2 Send an Identity Verification Email

Send an email from the Follow-up contact email specified in your Issue to thejustinsunprize@hejustinsun.com. Reference your published Issue and merged PR to complete identity verification. See Chapter 5 for the email template.

• Mathematical solvers, including contributors claiming both roles, must complete identity verification. Lean-only contributors may not need a separate verification process if source-code attribution already establishes the connection between their account and the author. If that connection cannot be established—for example, because contributions were made by a bot, shared account, or another person—the independent verification process used for mathematical solvers applies. The claim remains pending until the connection is established.

• Acceptable verification methods include sending from an author email listed in the paper, responding through an established institutional or author website, or using a historical signing key already associated with the author. Other independently verifiable methods may be proposed. Each method requires a response to a fresh verification request or challenge initiated by our team. A sender display name, forwarded old email, or screenshot alone is insufficient. A newly created key carrying only a self-declared name is also insufficient.

• If the author email listed in the paper differs from your follow-up email, still contact us from your follow-up address and identify the author email in the message. We will independently verify and connect the two channels. Do not send only from the author email, as that would not establish the connection to your Issue. A message from a newly supplied contact address alone does not prove identity.

• Send private materials only by email, never in an Issue.

• All contribution types require written recipient confirmation before distribution, as described in §4.1.

3.3 Public Review Period — 14 Days

• Public notice register: candidates/public-notice.md in this repository. Mathematical solution and formalization roles have separate review periods and do not wait for one another.

• Start and completion: Each role’s review begins when its candidate entry is published in the public notice register. Dates are recorded in UTC, and the period is a full 14 days. The PR merge date is not the start date; merging only records the repository as the problem’s formalization source.

• Public review and claiming run in parallel: Timing begins on publication in the register, independently of when you submit a claim Issue or complete identity verification. Neither action restarts or delays a review period already underway. Conversely, completion of public review does not authorize distribution by itself; written recipient confirmation is still required.

• How to challenge: Use the Formal dispute Issue form at .github/ISSUE_TEMPLATE/dispute.yml. Identify the challenged candidate, problem number, related claims, relevant dates, and public evidence. Send private identity materials to the official email, not the Issue. Challenges may concern correctness, attribution, priority, identity, or award eligibility. A challenge may be upheld based on an identified defect without a replacement proof. If you also wish to submit a replacement proof or catalog update, open a separate linked PR using the standard submission template and cross-link it with the dispute Issue. Replacement proofs must meet the same evidence and review requirements as initial submissions.

  • Formalization priority challenges: Identify the earlier commit in your own original repository and pass the same verification process.

  • Mathematical solution priority challenges: Provide an earlier complete proof or publication, publicly verifiable date evidence, and authorship evidence. No Lean repository is required; we review the mathematical contribution separately.

  • Routine record corrections: Use the Correction Issue form rather than a formal challenge.

• Challenge upheld with an accepted replacement: We explain the decision in the displaced claimant’s Issue and close the affected claim. If the Issue covers both roles, only the displaced role is closed; the Issue remains open while the other role is still in progress. The replacement candidate receives a new full 14-day period starting when their entry is published in the public notice register. The unaffected role keeps its existing timing. The replacement contributor must submit their own claim and complete their own identity verification and written confirmation. They may not reuse the displaced claimant’s confirmation, payment information, or mailing details. We assign a new recipient ID before identity is confirmed.

• Correctness challenge upheld without a replacement: The contribution is withdrawn from public review, the catalog is corrected, and the award process for that role stops. No new 14-day period begins. If the problem no longer has a valid formalization source, the solver’s award cannot proceed either; their claim and its timestamp are retained while awaiting a new formalization.

• Challenges raised during public review: The review cannot conclude until the challenge has been verified and resolved. If the challenge is rejected, the original review clock is neither restarted nor extended.

• Routine corrections do not affect timing: Catalog corrections, documentation updates, or supplementary evidence for an accepted contribution whose content has not changed do not create a new candidate entry or restart the review period.

3.4 Final Check Before Public Review Concludes — Standard Team Procedure

Before declaring a role’s public review complete, we check current claims and submissions to confirm that no claim or submission from the same identity for that problem and role remains under review without a decision.

• If such an item exists, public review does not conclude until that review batch is complete and priority has been determined.

• The unaffected role continues on its own timeline.

• The review findings and identifiers of the items checked are recorded internally, not in the public notice register.

A role proceeds to award distribution only after the public review period has elapsed, no challenges remain unresolved, and the final check confirms that no items for that role remain pending review. Expiration of the review period alone is insufficient.

3.5 Other Submission Channels

• Routine record corrections: If a recorded result, proof, attribution, or priority detail is incorrect but does not constitute a challenge to a candidate’s eligibility, use the Correction Issue form. Include the record’s exact location, current wording, proposed correction, and supporting sources.

• Recommend a problem: Use the Recommend a problem form. Provide a precise statement, its significance, original literature, known results, and formalization links.

• All forms are located under .github/ISSUE_TEMPLATE/. Link to existing Issues rather than opening duplicates.

4. Step 3 · Award Distribution

4.1 Written Recipient Confirmation and Identity Check

We complete recipient confirmation with you by email. Until confirmation is complete, the entry remains in public review or candidate status and is not added to the official award list.

4.2 Provide Any Remaining Award Delivery Information

Provide any information not already supplied in your §3.2 email, including the payment network, receiving address, and mailing address. Submit these only by email, never in an Issue.

4.4 Official Award Announcement and Distribution

Once confirmation is complete, the entry is moved into the corresponding monthly award batch under awards/<YYYY-MM>/ and formally announced. We then distribute the prize money and medal and confirm delivery.

Thank you for participating.