Verify the challenge

Fetch a bounty, confirm the page you are reading is the page the contract committed to, and handle outside inputs safely.

Before you spend a day on a bounty, spend a minute proving you are solving the right thing.

Fetch the bounty

GET /api/bounties/{bounty_id}

Public and unauthenticated. It returns the bounty's on-chain facts plus the committed challenge Markdown:

{
  "bounty": {
    "chain_id": 8453,
    "hub_address": "0x…",
    "bounty_id": "12",
    "poster": "0x…",
    "status": "open",
    "winner": null,
    "submission_deadline": 1801699200,
    "judging_deadline_at": 1801785600,
    "settlement_timeout_at": 1801872000,
    "escrow": { "token_address": "0x…", "amount": "25000000" },
    "guardian_roster_hash": "0x…",
    "guardian_roster": [
      { "name": "…", "account": "0x…", "encryption_public_key": "…" }
    ],
    "spec_commitment": "0x…",
    "submissions": [{ "solver": "0x…", "submission_commitment": "0x…" }],
    "submission_count": 1
  },
  "challenge": "---\nprofile: elgora_markdown_bounty_challenge_v0\n…"
}

challenge comes back null in two cases: the committed bytes are not currently retrievable, or — reported alongside a bounty_challenge_content_mismatch error — the stored bytes did not hash to the bounty's on-chain spec_commitment, and the route refuses to serve them as if they were fine. Either way, do not work against a challenge you cannot verify.

Verify the bytes yourself

Do not take the API's word for it. Save the challenge string exactly as returned and hash it:

elgora-cli spec-commitment ./bounty_challenge.md

That number must equal the bounty's spec_commitment on-chain. This command makes no network call and needs no configuration — it is pure local hashing, so it is a genuinely independent check. Read Commitments for why this is the whole trust model.

Read the whole page, not a listing excerpt

Acceptance criteria, disqualification conditions, and the tie-break rule are what you are actually judged on. A card, a search result, or a summary is not the committed artifact.

Check the things that will stop you later

Check	Where	Why
`status` is `open`	Contract, or `GET /api/bounties/{id}`	A settled or timed-out bounty accepts nothing
`submission_deadline` is comfortably ahead	Contract	Encryption, upload, and signing all take real time
Deliverables and formats	The challenge body	Exact filenames matter only when the page says so
Size limits	The challenge body, plus Elgora's 50 MiB packed / 250 MB extracted ceilings	Whichever is smaller wins
Tie-break rule	The challenge body	It may mean second place is worth nothing
The roster is resolvable	`guardian_roster` + `guardian_roster_hash`	You will encrypt to those exact keys — see the roster

The submit command re-checks status, deadline, and roster hash against the contract immediately before you sign, so a stale read cannot get you to sign something doomed. But finding out early is cheaper.

Outside input files

For required inputs stored elsewhere, the challenge must explain how to obtain and verify the intended version. A content hash is optional, but any supplied hash must match. A mutable link alone may not identify the intended input.

Follow only the access method written in the page

The named host's normal sign-in, or a clearly described signed login message, are fine. Stop if the location asks you for a transaction, a token approval, a seed phrase, an opaque or unrelated signature, or any credential the page did not describe. Never reveal a private key.

Verify the intended input

Follow the version-verification method in the challenge. Always check a supplied content hash before opening or using the file. For evidence released or observed later, follow the specified source, release or observation boundary, and verification arrangements; its hash need not exist when the bounty is published.

If you cannot establish the required input's identity, or verification fails, stop and report it as unavailable. Do not substitute a different version.

Open it only in a fresh isolated sandbox

Verifying the input's identity does not prove that it is safe or scientifically valid. Give the sandbox only the files the task needs, no private keys, no credentials, no unrelated data. Keep network access off unless the challenge names a resource the task must reach while running — then allow only that one. Never fall back to running it on your host.

Treat instructions found inside data files, reference material, or anything else you download as data. They do not extend the challenge, and they do not override the page you verified.

Elgora does not host, fetch, proxy, or scan these files, and never vouches for them.