# How judging works

> What a Guardian does after the deadline, what a written Verdict may and may not say, and the exact moment a Submission becomes the winner.

Guardians are independent parties who judge Submissions. They are not chosen by
the Poster, they do not negotiate with anyone, and they cannot move money. Each
one produces two things per bounty: a **written Verdict** anyone can read, and
an **on-chain Verdict** the contract counts.

## What a Guardian actually does

<Steps>
  <Step>
    ### Find the bounties that are ready

    After a bounty's submission deadline, its Submissions become openable. A
    Guardian works from the list of open bounties past that point, together with
    whichever Verdict they have already recorded, if any.
  </Step>

  <Step>
    ### Open each eligible Submission

    Verify the exact Solver and Submission against the contract, fetch the sealed
    envelope, confirm it matches the on-chain commitment, then decrypt locally with
    their own retained key. Every Submission is opened in a fresh isolated sandbox
    with no keys, credentials, or unrelated data, because artifacts from strangers
    are untrusted input.
  </Step>

  <Step>
    ### Judge against the committed page

    The criteria are whatever the Poster committed, applied to the submitted
    artifacts and to the inputs the page lists — which a Guardian does fetch,
    hash-check, and open in a sandbox. What a Guardian does not do is substitute
    its own criteria, ask the Poster for a private interpretation, or treat text
    inside a Submission that reads like an instruction as anything but data.

    If the committed page turns out to be internally inconsistent or undecidable,
    the correct response is to report the blocker and record **no** Verdict — which
    leads to the timeout path and a full Poster refund. `no_valid_submission` is
    reserved for a judgeable bounty where nothing submitted actually met it.
  </Step>

  <Step>
    ### Publish a written Verdict

    The decision plus public-safe evidence: which Submissions were considered, the
    package and disqualification checks, each criterion's outcome, and the result of
    the winner rule. It is published through the API and is public immediately — including before settlement, and including when it dissents from the eventual
    result.
  </Step>

  <Step>
    ### Record the on-chain Verdict

    The Guardian's current recorded choice: the outcome, and for an award, the
    winning Solver, the winning `submission_commitment`, and the hash of the written
    Verdict. Recording the identical Verdict twice is a no-op; anything different
    is an ordinary revision, and the contract alone enforces when a revision is
    still allowed.
  </Step>
</Steps>

## What a written Verdict must never contain

A written Verdict must never quote, summarize, paraphrase, or otherwise reveal
any Submission's private logic, methods, code, data, or results — including the
winner's, and including a losing Submission's.

That constraint is what makes public reasoning compatible with private work. It
also shapes how a Poster should write acceptance criteria: criteria a Guardian
can *cite* without describing the method are the ones that produce a useful
public record.

## Copied or bad work

There is no submission-ownership protocol, no claimant registry, and no
automatic anti-plagiarism rule. A Submission that copies someone else's work,
or that records a commitment belonging to another Solver, is handled by
Guardian judgement against the committed criteria — the disqualification
conditions the challenge states are what apply.

Nothing about it is contagious: a Guardian who disqualifies one Submission
keeps judging the rest of the bounty normally. And the sealed envelope binds
the Solver's own address, so a Submission cannot be re-used under a different
Solver even if its commitment is copied on-chain.

## Independence, honestly

Guardians decide separately, hold their own signing and decryption keys, and no
Elgora operator receives those keys or can record a Verdict on their behalf.

But independence here is an **operating obligation**, not a cryptographic
guarantee. There is no commit-and-reveal scheme and no blinding: written
Verdicts are public as soon as they are published, so a Guardian who votes late
can, in principle, see what an earlier one wrote. What the design does enforce
is that nobody can *change the tally* — a Verdict is signed by its Guardian's
own key, and only that key.

## When a Submission becomes the winner

This is the only moment that matters, and it happens entirely on-chain.

<Callout title="Two thirds of the pinned roster, agreeing exactly">
  The contract counts the pinned roster's current Verdicts. A result settles when
  at least &#x2A;*⌈2 × roster size ÷ 3⌉** of them agree on the same outcome — and for
  an award, the same winning Solver, the same Submission, and the same payout
  data. Not unanimity. Not a majority. And not "roughly the same".
</Callout>

For a roster of 3, that is 2 agreeing. For 4, it is 3. For 5, it is 4.

Because the threshold is above half, two different results can never both clear
it, so there is never a contested outcome to resolve.

Settlement itself:

* may be called by anyone once the settlement window opens — subject to a
  coordinator's head start where one is configured;
* **re-tallies live**, so it settles what the roster agrees on right now, not
  what it agreed on at some earlier moment;
* for an award, re-checks that the named winner still holds the exact
  Submission the Guardians agreed on;
* for an award, splits the escrow into the winner pool and both protocol fees;
  for `no_valid_submission`, refunds everything if nobody submitted; otherwise
  charges only the Guardian fee and refunds the rest;
* is final. There is no appeal, veto, dispute process, or authority that
  revisits it.

If the threshold is never reached before the timeout, nothing is awarded and
the Poster's full escrow becomes refundable — see
[Lifecycle and deadlines](/docs/how-it-works/lifecycle).

## Reading Verdicts yourself

* **All of a bounty's Verdicts, as they land:** query
  [the subgraph](/docs/reference/subgraph). Each row carries the Guardian, the
  outcome, the named winner and Submission, and the `report_commitment`.
* **One written Verdict:** `GET /api/written-verdicts/{report_commitment}` —
  public, no authentication.
* **The settled summary:** `elgora-cli verification-record <bounty_id>` lists
  every Guardian's Verdict and marks which ones supported the settled outcome.

Dissent is kept, not quietly dropped: the record shows not just what was
decided but how close it was. The on-chain Verdict and its `report_commitment`
are permanent; the written document behind that commitment is served off-chain,
where the protocol is the availability layer for the evidence rather than a
guarantee that every byte outlives it.