# Example bounties

> Three very different challenges — a computational benchmark, a data-curation task, and a piece of private know-how — and what makes each of them judgeable, plus the smallest complete bounty.

An Elgora bounty is anything a Poster can pay for and an independent Guardian
can decide from written criteria. That is a wider range than "run this script".
Use these sketches to explore how a result could be judged. Their requirements
belong to their own tasks; they do not limit what you can buy.

These are illustrative drafts, not ready-to-publish challenges. Some links
point to `example.org` and their hashes are made up. Supply real inputs, verify
their hashes, choose your amount and deadline, and run the
[readiness review](/docs/poster/readiness-review) before publishing.

All three examples rank by `submission_call_count`: Examples 1 and 3 to break
ties, Example 2 to pick the earliest valid Submission. Anyone can read it as
`Submission.submissionCallCount` in the [subgraph](/docs/reference/subgraph).

|                        | Computational                           | Data                                        | Private know-how                          |
| ---------------------- | --------------------------------------- | ------------------------------------------- | ----------------------------------------- |
| What is bought         | A method that beats a bar               | A structured dataset                        | Knowledge someone already has             |
| Deliverable            | Code + required supporting files        | A CSV + provenance                          | A written protocol + evidence             |
| How a Guardian decides | Re-runs one bounded evaluation          | Spot-checks a sampled subset                | Expert assessment against stated criteria |
| Why privacy matters    | Keeps the method from leaking to rivals | Keeps the curation effort from being copied | The whole value is that it is not public  |

***

## 1. Computational — beat a baseline, reproducibly

**The idea.** A group has a binding-affinity prediction baseline and wants
something better on a held-out set. They publish the inputs up front, commit the
labels by hash and release them after the deadline. That establishes the
intended release order, not proof that nobody previously knew the labels.
The evaluation measures the submitted predictor on those inputs. The Solver
chooses the method; this example does not prohibit adaptation to the input rows.

```markdown
---
profile: elgora_markdown_bounty_challenge_v1
escrow_amount: "25000000"
submission_deadline: 1801699200
payout_policy: winner_take_all
---

# Beat the baseline RMSE on a held-out binding-affinity set

## Summary
Submit a predictor that scores lower RMSE than the
baseline of 1.35 pKd units on a held-out set of protein–ligand complexes.

## Challenge details
The task is to predict binding affinity, expressed as pKd (the negative base-10
logarithm of the dissociation constant in mol/L), for protein–ligand complexes.
Each input row gives a complex identifier, the protein sequence and the ligand
SMILES. The bar is a fixed threshold set by the Poster: RMSE 1.35, the score of the Poster's current in-house model on this set. It is a parameter of this bounty, not a claim Guardians verify.

A passing Submission establishes only that its submitted predictor beats that
baseline on these 500 complexes. It does not establish accuracy on other
proteins, ligands or assay types.

The scoring labels are committed now by their hash and published after the
submission deadline. This score measures performance on this set; it does not
prove that the Solver had no prior access to its labels.

## What you need to submit (Deliverables)

| File | Required | Format | Purpose |
|---|---:|---|---|
| `predict.py` | yes | Python 3.11 | inference entry point |
| Supporting files | if needed beyond the named input and installed packages | files or folders at paths relative to the Submission root | data, code or model files needed by `predict.py` |
| `requirements.txt` | if `predict.py` imports a package outside the Python standard library | pip format, every package pinned with `==` to a version on PyPI | dependencies `predict.py` needs |
| `results.md` | no | UTF-8 Markdown | a method summary; informational only, not scored |

`predict.py` is invoked as `python predict.py heldout_v1_inputs.csv predictions.csv`
from the Submission root, with Python 3.11 and only the packages pinned in
`requirements.txt` installed. The prediction uses only the named input, submitted
files and files installed from `requirements.txt`. Scoring labels are used only
to calculate RMSE after prediction. Temporary files derived from these
prediction inputs and adaptation to the input rows are allowed.
It reads the input file named by its first argument and writes a UTF-8 CSV to
the path named by its second argument, with the header `id,predicted_affinity`
and one row per input row, in input order.

## Inputs, Materials and References

| File | Why it is needed | How to get it | SHA-256 content hash |
|---|---|---|---|
| `heldout_v1_inputs.csv` | the predictor's input: columns `id,protein_sequence,ligand_smiles`, 500 rows, no labels | public download at https://example.org/elgora/affinity/heldout_v1_inputs.csv; no sign-in | `3f1c9a0e7b2d4c6815e9a7f0b3d2c1e4a5968b7c0d1e2f3a4b5c6d7e8f9a0b1c` |
| `heldout_v1_labels.csv` | the scoring labels: columns `id,measured_affinity` (pKd), 500 rows | public download at https://example.org/elgora/affinity/heldout_v1_labels.csv, published after the submission deadline; no sign-in | `9e8d7c6b5a4f3e2d1c0b9a8f7e6d5c4b3a2f1e0d9c8b7a6f5e4d3c2b1a0f9e8d` |

Bytes with any other hash are not these inputs.

## Acceptance Criteria
1. `predict.py` runs as invoked above and exits with status zero.
2. `predictions.csv` has the header `id,predicted_affinity`, one row per input
   row with the same `id` in the same order, and a finite decimal
   `predicted_affinity` in every row.
3. The RMSE of `predicted_affinity` against `measured_affinity`, joined by `id`
   over all 500 rows, is strictly below 1.35.

## How is the winner selected?
- Valid Submissions are those meeting every acceptance criterion.
- Lowest RMSE wins.
- Equal RMSE is broken by the lowest `submission_call_count`: ElgoraHub's
  bounty-wide count of accepted submissions at that call, so the earlier
  active Submission wins.
- If none is valid, the outcome is `no_valid_submission`.

## Disqualification Conditions
A Submission fails if `predict.py` needs network access to produce its predictions.

## Out Of Scope
New experiments, interpretation of the predictions, and claims about
generalization beyond the specified set.

## Evaluation Procedure
RMSE is the square root of the mean squared difference between
`predicted_affinity` and `measured_affinity` over the 500 rows, computed without
rounding before the comparison with 1.35.

```

**What this illustrates.** A comparison needs identified inputs, a metric and
a stated baseline.

The page defines *the test* — what runs, against
what, and how the metric is computed — and says nothing about *the tester*. No
wall clock, no memory ceiling, no retry rule, no sandbox configuration: those
are the Guardian's own, they differ between honest Guardians, and a bounty that
sets them makes its own retry budget decide who wins.

Note what stayed: a predictor that needs the network to produce its predictions
is a *disqualification condition of this challenge*, which is a rule about the
answer. "Run it in a sandbox with no network access" would be a rule about the
agent, and would block publication.

***

## 2. Data — curate something that does not exist yet

**The idea.** The Poster needs a structured dataset assembled from named
open-access sources. The work is real and tedious; the judging must not be.
The trick is a **bounded sampling protocol** instead of "check everything".

```markdown
---
profile: elgora_markdown_bounty_challenge_v1
escrow_amount: "20000000"
submission_deadline: 1801699200
payout_policy: winner_take_all
---

# Extract dose–response pairs from 40 named open-access papers

## Summary
Produce one CSV of dose–response measurements extracted from the tables of 40
listed papers, in the exact schema given, with a source citation for every row.

## Challenge details
A dose–response pair is one compound concentration and the percent inhibition
measured at that concentration, as printed in a numbered table of one of the 40
papers. Values shown only in figures, fitted parameters such as IC50, and
summary statistics across concentrations are not pairs and are not extracted.
Replicate values printed separately in a table are separate pairs.

The result is a machine-readable dataset of what the papers' tables report. It
does not establish that the reported measurements are correct.

## What you need to submit (Deliverables)

| File | Required | Format | Purpose |
|---|---:|---|---|
| `doses.csv` | yes | UTF-8 CSV, header row, schema below | the extracted dataset |
| `provenance.md` | yes | UTF-8 Markdown | papers with no qualifying table, and table values excluded for their unit, each with the reason |

Schema, in this column order:
`paper_doi,compound_name,dose_value,dose_unit,response_value,response_unit,replicate,table_number,page`

- `compound_name` is the name exactly as the table prints it.
- `dose_unit` is always `uM`. Convert nM (divide by 1,000) and mM (multiply by
  1,000). A dose printed in any other unit is excluded and listed in
  `provenance.md`.
- `replicate` is 1 for a single printed value, and numbers separately printed
  replicates 1, 2, 3 in the order the table prints them.
- `table_number` is the table's printed number without the word "Table": 3
  for "Table 3".
- `page` is the page of the paper's PDF at its DOI, counted from 1, on which
  the value is printed.
- `response_unit` is always `percent_inhibition`. A response printed as
  anything else is excluded and listed in `provenance.md`.

## Inputs, Materials and References

| File | Why it is needed | How to get it | SHA-256 content hash |
|---|---|---|---|
| `sources.csv` | the fixed list of 40 DOIs, one per row, column `paper_doi` | public download at https://example.org/elgora/doses/sources.csv; no sign-in | `5b2e8c1f0a7d3e6b9c4f2a1d8e7b6c5a4f3e2d1c0b9a8f7e6d5c4b3a2f1e0d9c` |
| drand `quicknet` beacon | the seed that picks the checked rows and papers | public at https://api.drand.sh/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/public/{round}; no sign-in | none: each value is checked by its drand signature |

Every listed paper is open access at its DOI.

## Acceptance Criteria
1. Every row's `paper_doi` is in `sources.csv`, and every one of the 40 papers
   either contributes at least one row or is listed in `provenance.md` with the
   reason it has no qualifying table.
2. `doses.csv` has at least 20 data rows, and no two rows are identical in
   every column. The header is not a data row.
3. **Spot check.** B is the `randomness` value, in lowercase hex, of
   the first `quicknet` round whose scheduled time is at or after
   `submission_deadline`: round = ceil((submission_deadline −
   1692803367) ÷ 3) + 1. No other round's value is B. With R data rows in
   `doses.csv`, numbered from 1 in file order after the header, 20 distinct
   rows are checked. For j = 1, 2, 3 and so on, n is the first 12 hex
   digits of the SHA-256 of the text `B:row:j`, read as a hexadecimal number,
   and row (n mod R) + 1 is picked. A row already picked is skipped. Picking
   stops at 20 distinct rows. A checked row is correct when every column
   matches its paper: its compound, dose and response are one pair in table
   `table_number` on `page`, after the unit conversion above, at the precision
   the paper prints, and its `replicate` follows the rule above. Any mismatch,
   including a wrong `table_number`, `page` or `replicate`, makes the row
   incorrect. At most 1 of the 20 checked rows may be incorrect.
4. **Completeness check.** With the 40 papers numbered from 1 in
   `sources.csv` order, 3 distinct papers are checked. For j = 1, 2, 3 and so
   on, n is the first 12 hex digits of the SHA-256 of the text `B:paper:j`,
   read as a hexadecimal number, and paper (n mod 40) + 1 is picked. A paper
   already picked is skipped. Picking stops at 3 distinct papers. Every
   dose–response pair in a checked paper's numbered tables is in `doses.csv`,
   or is listed in `provenance.md` as excluded for its unit, with the reason.
   At most 1 pair may be missing from both across the 3 checked papers.

## How is the winner selected?
- Valid Submissions are those meeting every acceptance criterion.
- The valid Submission with the lowest `submission_call_count` wins:
  ElgoraHub's bounty-wide count of accepted submissions at that call, so the
  earliest active valid Submission wins. The number of rows does not rank.
- If none is valid, the outcome is `no_valid_submission`.

## Out Of Scope
New measurements, values from figures or supplementary files, and judging
whether the papers' results are scientifically correct.

## Evaluation Procedure
Correctness is decided only on the 20 checked rows, by comparing each with the
table and page it cites. Completeness is decided only on the 3 checked papers,
by comparing their numbered tables with `doses.csv` and `provenance.md`.

```

**What this illustrates.** Sampling is one way to bound a large check; a small
dataset may need no sampling.

"Verify a dataset" is unbounded; "verify 20 rows
chosen by this exact rule, allow at most one error" is not. Three choices keep
the check honest:

* **Same rows for every Guardian.** The rules are exact, so two Guardians
  check the same rows and papers and can agree.
* **No Solver knows the checks in advance.** The seed is a public beacon value
  scheduled for the deadline itself, when Submissions have closed. A Solver
  cannot predict it, or steer it by changing the file.
* **Nothing rewards invented rows.** The earliest valid Submission wins, and
  the row count does not rank. An invented row can only fail the spot check,
  and a missing row can fail the completeness check.

***

## 3. Private know-how — pay for what is not published

**The idea.** A lab cannot reproduce a published protocol. Somewhere, someone
has already hit the same wall and knows why. That knowledge is worth money
precisely because it is not in the literature — which is exactly the case where
Elgora's [private submissions](/docs/how-it-works/encryption) matter: a Solver
can disclose it to a small pinned roster of Guardians without publishing it to
the world, and only the winner's answer ever reaches the Poster.

```markdown
---
profile: elgora_markdown_bounty_challenge_v1
escrow_amount: "30000000"
submission_deadline: 1801699200
payout_policy: winner_take_all
---

# Identify why this cardiomyocyte differentiation protocol fails after passage 12

## Summary
Name the specific mechanism that makes the protocol below fail after passage 12
and supply a corrected, step-by-step protocol, with evidence a reviewer can
weigh without repeating the experiment.

## Challenge details
**Protocol.** Human iPSC line WTC-11 is maintained on Matrigel in mTeSR Plus and
passaged every 4 days with 0.5 mM EDTA at a 1:12 split. At 90% confluence,
differentiation starts: day 0, RPMI 1640 with B-27 minus insulin and 6 µM
CHIR99021; day 2, the same medium without CHIR99021; day 3 to day 5, the same
medium with 5 µM IWP2; from day 7, RPMI 1640 with B-27 (with insulin).

**Observed phenotype.** Up to passage 12, cultures reach 80–90% cTnT-positive
cells by flow cytometry on day 15 and beat from day 8. From passage 13 onward,
cTnT-positive cells fall below 20%, no beating appears, and most cells express
SOX17 by day 5.

**Already ruled out.** None of these restored differentiation after passage 12:
1. a new lot of CHIR99021;
2. a CHIR99021 titration from 4 to 12 µM;
3. thawing a fresh passage-10 vial and passaging it to passage 14, which failed
   again at passage 13.

A diagnosis is a single mechanism that explains why this protocol fails from
passage 13 and not before. The bounty buys that explanation and a corrected
protocol; it does not need the explanation to be confirmed experimentally.

## What you need to submit (Deliverables)

| File | Required | Format | Purpose |
|---|---:|---|---|
| `diagnosis.md` | yes | UTF-8 Markdown | the named mechanism and the reasoning for it |
| `protocol.md` | yes | UTF-8 Markdown | the corrected protocol, step by step |
| `evidence/` | no | a folder of PDF, PNG or CSV files | data or figures supporting the diagnosis |

## Inputs, Materials and References
Everything needed is on this page. No outside file is required.

## Acceptance Criteria
1. `diagnosis.md` names one specific mechanism — a reagent, a cell state or a
   step — not a list of possibilities, and explains why it produces the
   described phenotype from passage 13 and not earlier.
2. It states at least one **observable prediction**: something the Poster's lab
   would see if the diagnosis is right and would not see otherwise, precise
   enough to check in a single experiment.
3. It explains why each of the three ruled-out interventions did not fix the
   failure, consistently with the named mechanism.
4. `protocol.md` can be run without contacting the Solver: every changed
   reagent, concentration, timing and handling step is stated, and each change
   names the part of the mechanism it addresses.
5. Each claim offered as evidence for the named mechanism identifies its
   supporting source: a citation with a DOI or URL, or a submitted evidence
   file with measurement conditions described in `diagnosis.md`. Background
   sentences not offered as evidence do not require separate citations.

## How is the winner selected?
- Valid Submissions meet every acceptance criterion.
- If several are valid, the one whose diagnosis has the strongest support wins.
  Support is ranked by the strongest evidence the Submission gives, cited or
  submitted as an evidence file: first,
  measurements in human iPSC-derived cells; second, measurements in any other
  cell system; third, no measurements or no cell system identified in the
  supporting source. A measurement supports the diagnosis when it reports the
  predicted effect of the named mechanism or an intervention addressing it;
  unrelated measurements do not raise the rank.
- Submissions with the same rank are broken by the lowest
  `submission_call_count`: ElgoraHub's bounty-wide count of accepted
  submissions at that call, so the earlier active Submission wins.
- If none is valid, the outcome is `no_valid_submission`.

## Disqualification Conditions
- a reagent in `protocol.md` has neither a supplier and catalogue number nor
  its full composition. Availability, stock and price are outside this assessment;
- a submitted file contains private participant or donor identifiers, such as
  names linked to study records, medical records or donor IDs. Public author
  citations and cell-line names such as WTC-11 are allowed;
- a submitted file marks content as confidential or licensed on terms that
  forbid giving it to the Poster;
- a submitted file addresses the Guardian or judging process to request a
  verdict, rank or departure from these criteria. Argument and evidence for
  the diagnosis are allowed.

## Out Of Scope
Physical replication of the experiment. Guardians weigh only this page, the
submitted files and the sources the Submission cites.

```

**What this illustrates.** The purchase is an evidence-backed explanation, not
experimental confirmation. Guardians assess the reasoning and cited evidence
against the stated criteria; a winning diagnosis is not proof that the mechanism
is true or that submitted measurements actually occurred.

Written Verdicts are public, so a Guardian explaining *why* an answer won must
do it without revealing the answer — see [How judging works](/docs/how-it-works/verdicts).

***

## The pattern in all three

Whatever the domain, a challenge survives review when it can answer four
questions in writing:

1. What exactly is delivered?
2. What evidence and criteria make acceptance decidable?
3. Which of several valid Submissions wins, and how are ties broken?
4. What is out of scope or disqualifying?

Definitions, input access, and evidence rules support these decisions.

## The smallest complete bounty

A short task with its input written into the page, to show the format. Its
deadline is a placeholder; choose your own.

````markdown
---
profile: elgora_markdown_bounty_challenge_v1
escrow_amount: "20000000"
submission_deadline: 4102444800
payout_policy: winner_take_all
---

# Rank the most active compounds in a supplied assay table

## Summary
Analyze the supplied assay table and return a concise, reproducible
ranking of the three compounds with the highest valid activity scores.

## Challenge details
The input table contains one measurement per row. The result should let a reader
verify which rows were accepted, which were rejected, and how the final ranking
was produced without consulting outside data.

## What you need to submit (Deliverables)

| File | Required | Format | Purpose |
|---|---:|---|---|
| `analysis.md` | yes | UTF-8 Markdown | method, row checks, and final ranking |

Additional explanations or supporting files are optional and do not affect
acceptance or ranking.

## Inputs, Materials and References

This example needs no outside file: the exact input is included below. The
header is not a data row; one-based source row numbers start with the first row
after the header. A valid row has a non-empty `compound_id` and a finite decimal
`activity_score`.

```csv
compound_id,activity_score
CMP-001,7.2
CMP-002,not_available
CMP-003,9.1
,8.4
CMP-004,9.1
CMP-005,6.8
```

## Acceptance Criteria

1. `analysis.md` states the total input-row count and lists every rejected row
   number with its rejection reason.
2. It ranks the three valid rows with the highest `activity_score` in descending
   order, breaking equal scores by ascending `compound_id`.
3. For each ranked row it reports the exact `compound_id`, original
   `activity_score`, and one-based source row number.
4. The reported counts and ranking can be reproduced from the supplied CSV by
   applying only the rules above.

## How is the winner selected?

- A valid Submission satisfies every acceptance criterion.
- If multiple Submissions are valid, the active Submission with the lowest
  `submission_call_count` wins. `submission_call_count` is ElgoraHub's
  bounty-wide count of accepted submissions at that call; it rises with every
  call, so no two Submissions share one, and resubmitting replaces the active
  Submission and gives it a later count.
- If no Submission is valid, the outcome is `no_valid_submission`.

## Out Of Scope

Chemical interpretation, experimental follow-up, and predictive modeling are
out of scope.

````