Write the challenge

A bounty is one UTF-8 Markdown file named bounty_challenge.md. Its exact bytes are hashed into spec_commitment and anchored on-chain. Solvers build against those bytes and Guardians judge against those bytes, so the page has to stand on its own: no follow-up chat, no private context, no "ask me if unclear".

Maximum size is 1,000,000 characters.

The frontmatter is exact

The file must start with this block, closed by --- before anything else:

---
profile: elgora_markdown_bounty_challenge_v0
escrow_amount: "20000000"
submission_deadline: 1801699200
payout_policy: winner_take_all
---

Every key must appear exactly once. Extra keys are rejected — there is no place in frontmatter for a network, a Hub address, a Guardian, a fee, a timelock, or a storage setting. Elgora derives all of those from the deployment you publish against.

A shared layout, with detail that fits your task

The shared template keeps all nine sections below. Five core sections open by default on the bounty page. Supporting sections are expandable when included. Every new draft needs a readable title and sufficient core content. You or your drafting agent writes it, and you approve it with the challenge. The frontend shows approved text; it does not generate a description.

All five parts need sufficient content. A simple task can be brief; extra history or motivation is optional. Refer to information already explained elsewhere rather than repeat it.

Your drafting agent chooses relevant supporting sections and subsections from the task. Hosted readiness identifies missing information needed to evaluate that bounty and can suggest where it belongs. Use ## for sections and ### or deeper for subsections. Omit inapplicable supporting sections and subsections; you do not need to fill them with None. Readiness checks whether the content is sufficient, not the exact heading names or order. The page uses consistent expandable sections and preserves your text, including tables, steps and code. Previously published pages keep their original content. When a published page has no Summary section, the marketplace uses an introductory prose excerpt and keeps its available title. Unavailable or unverified content is shown as unavailable, never invented.

Define terms and scope under Challenge details. Under Deliverables, say what each output is for and give only the format details needed to check it. Under Acceptance Criteria, explain how Guardians decide whether the result passes. If you use scoring, explain its calculations, weights and effect on the winner, including rounding, tolerances or missing results when they affect it. You do not need to invent a score for a pass/fail task. Include evidence origin and sample linkage only when the claim needs it. A historical analysis does not automatically require laboratory proof.

Put access and known input limitations under Inputs, Materials and References, relevant resource and reuse rules under Out Of Scope, and what the test is under Evaluation Procedure. These are suggested subsections, not extra mandatory headings. Resolve conflicting rules before publication; one section does not silently override another.

Describe the judgment, never the judging machinery

One test for any sentence you are about to publish: does it describe the answer, or the agent? If the agent, it does not belong on your page.

Guardians read your page as data describing a target, and take no procedural direction from it. Deterministic conformance rejects a page that carries any, so this is a publication blocker rather than a style note.

The left column includes the test itself, and that matters. If a model, dataset, reference point, method, version, seed, instrument or agreed procedure changes whether a Submission passes, it is part of what you are buying and belongs on the page — leaving it unstated is how two honest Guardians reach different answers, or answer a different question than you asked. This is not only about software benchmarks: a wet-lab bounty may be purchasing work under a particular procedure, on specified equipment, with some variables held constant while others are tested, and those conditions are the question.

The test against the right column is what a sentence decides — "accuracy measured with no access to external label sources" defines the measurement; "run it in a sandbox with no network" configures the evaluator, which is the operator's to set.

Where you are buying work done a particular way, say what is being tested, what stays fixed, what may vary, what evidence shows the conditions were met, and how a deviation or an inconclusive result affects acceptance. Readiness will not reject your page for describing how a test is performed, and will not substitute a method it prefers — it checks that your stated conditions let a Solver understand the task and a Guardian evaluate it. Most bounties need none of this; their acceptance criteria already define the evaluation.

That includes failure handling in every wording. Retrieval, decryption and commitment-verification failures are Elgora's, not the Solver's, and your page neither states that rule nor overrides it.

Tighten a limit through frontmatter

Your page never restates a protocol limit — published bytes are immutable and you are not the authority for one, so a copy can only go stale. Where your bounty needs a narrower limit, declare it in the optional constraints: block, which is checked by arithmetic against the profile before publication:

constraints:
  max_extracted_bytes: 100000000
  allowed_extensions: [.csv, .md]

Each entry must name a constraint the profile marks tightenable and come in strictly under it. retry_attempts: 3 is rejected — not because the number is wrong, but because retry policy is not yours to set.

Explain the judging work

Describe the inputs and work needed to apply the acceptance criteria. Include limits or stopping conditions when they define success or make the evaluation clear. They are useful drafting details, not a separate publication checklist. For a fixed benchmark, explain the test. For a tool the Solver will develop, require runnable instructions and necessary dependencies with the Submission; you do not need to know that implementation beforehand. You still need a clear way to decide whether the delivered result succeeds.

The Poster drafting agent and readiness AI focus on evaluation clarity and practicality. Each Guardian manages its security and execution setup under Elgora's security rules; the bounty does not prescribe isolation tools, network enforcement or filesystem mounts. A required software version, offline product behavior or resource budget can still belong in the evaluation when it defines success or bounds judging work.

Be honest about which you are buying: full reproduction of prior work, or judgement of a submitted result. If you want reproduction, keep it explicit and bounded rather than swapping in a cheaper test that proves something else.

Outside input files

For required outside files, explain their purpose, where to obtain them and which version or release/observation boundary governs judgment. Distinguish these inputs from background references. Exact filenames and SHA-256 hashes are optional unless needed to judge the bounty. A supplied hash must match the retrieved bytes.

The hosted check blocks missing information when it prevents acceptance or winner selection; it does not require every file to follow a technical checklist.

Keep these input and security rules in mind:

• Do not replace an input version fixed by the approved bounty; changing that input requires a new bounty. Evidence released or observed later is allowed when the bounty defines its governing source, release or observation boundary, and verification arrangements in advance.
• Access may use the host's normal account sign-in, or a clearly described signed wallet login message. It may never require a private key, seed phrase, transaction, token approval, or an opaque or unrelated signature.
• Never put a password, API key, bearer token, cookie, or expiring download link in the page. It is public forever.
• The hash identifies the expected bytes. It does not make them safe. Solvers and Guardians will open outside files only in a fresh isolated sandbox, and your page must not ask them to do otherwise.

Elgora does not host, fetch, proxy, scan, or grant access to these files, and never checks their hash for you.

A minimal, valid challenge

---
profile: elgora_markdown_bounty_challenge_v0
escrow_amount: "20000000"
submission_deadline: 1801699200
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 result should let a reader verify which supplied rows were accepted or
rejected and reproduce the ranking without consulting outside data.

## What you need to submit (Deliverables)

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

## Inputs, Materials and References
This challenge needs no outside file; the exact input is below. The header is
not a data row. 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` descending,
   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 counts and ranking are reproducible from the supplied CSV under these
   rules alone.

## How is the winner selected?
- A valid Submission satisfies every criterion and is not disqualified.
- If several are valid, the lowest lowercase Solver address wins.
- If none is valid, the outcome is `no_valid_submission`.

## Disqualification Conditions
- `analysis.md` missing, corrupt, or not UTF-8 Markdown after successful
  decryption;
- the result uses outside data or alters an input value;
- the row accounting or ranking is not reproducible under the stated rules.

## Out Of Scope
Chemical interpretation, experimental follow-up, predictive modeling, and
use of data not supplied in this challenge are outside its scope.

submission_deadline above is a placeholder — replace it with a real UTC timestamp that is still in the future when you publish.

For three fuller worked ideas across very different kinds of science, see Example bounties.

Check it before you publish

You can reproduce the commitment offline, with no network call, no wallet, and no configuration:

elgora-cli spec-commitment ./bounty_challenge.md

Keep that hash. It is what you will compare against the bounty's on-chain spec_commitment to prove the page anyone is reading is the page you approved.