---
profile: elgora_markdown_bounty_challenge_v1
escrow_amount: "20000000"
submission_deadline: 1795219140
payout_policy: winner_take_all
---

# Find contradictions inside the Molecule developer docs at a pinned commit

## Summary
The Molecule developer docs (https://docs.molecule.xyz) describe the Labs API,
the x402 gateway, the onchain Lab contracts and how research data is stored.
They are written for developers and for AI agents, and parts of them are
maintained by an automated pipeline. Find places where two passages of the
docs cannot both be true, and report each as a pair of exact quotes with file
and line. Every finding can be checked by opening two lines of a public
repository at one fixed commit. The longer correct list wins.

## Challenge details

### The source
The only source is the public repository
https://github.com/moleculeprotocol/docs at commit
`35dcdb821518ca5ed447388379740c0e01d1e77d`. Only its Markdown files (paths
ending in `.md`) count, including those under `.gitbook/includes/`. The live
site, later commits, the API itself and onchain state are not sources: a
passage that is wrong about the real system but agrees with the rest of the
docs is not a finding.

### What a finding is
A **passage** is one line of one Markdown file at the pinned commit,
identified by its repository path and its 1-based line number.

A **finding** is a pair of passages, A and B, on different lines, where both
make a statement about the same fact and the two statements cannot both be
true as written. The fact is one of:

- a value: a default, limit, lifetime, price, size, count, date or version;
- an identifier: an address, chain id, URL, header name, or the name, type or
  nullability of a field, argument, enum value or type;
- a behaviour: what a call returns or requires, which error it gives, who may
  call it, where a piece of data is stored, or whether a feature exists, is
  required or is deprecated.

A sample request, sample response or code sample states what it shows. A
sample response that shows a value for a field states that the field has such
a value; a code sample that makes a call without a header or argument states
that the call works without it.

A pair is **not** a finding when:

- the docs themselves present the difference as intended, for example a
  sandbox value beside a production value, or a "before" beside an "after" in
  a changelog or migration note;
- one passage is only less detailed, vaguer or silent where the other is
  specific;
- the difference is spelling, formatting, letter case of prose, a broken link
  or a placeholder such as `0x…` or `YOUR_TOKEN`;
- the two passages are about different things that share a name, as the
  surrounding text of each shows.

Passage A and passage B may be in the same file. The surrounding text of each
passage, in its own file, is read to decide what the passage is about.

### Result meaning
A valid Submission is a list of places where the pinned docs disagree with
themselves. It does not establish which of the two passages is right, and it
does not establish that the docs hold no further contradictions.

## What you need to submit (Deliverables)

| File | Required | Format | Purpose |
|---|---:|---|---|
| `findings.csv` | yes | UTF-8 CSV, comma-separated, RFC 4180 quoting, header row, schema below | the findings |
| `method.md` | no | UTF-8 Markdown | how the findings were found; informational only, not scored |

`findings.csv` columns, in this order:
`id,fact,file_a,line_a,quote_a,file_b,line_b,quote_b,why`

- `id` is the row number, starting at 1 for the first data row.
- `fact` names the fact in a few words, for example
  `uploadUrlExpiry value` or `where file CIDs are stored`.
- `file_a` and `file_b` are repository paths, for example
  `api-reference/errors.md`.
- `line_a` and `line_b` are 1-based line numbers in those files at the pinned
  commit.
- `quote_a` and `quote_b` are verbatim text from that line: a run of 15 to
  300 characters copied from the line, or the whole line when the line is
  shorter than 15 characters. Every character matches the file apart from
  leading and trailing whitespace.
- `why` says in at most 300 characters why the two statements cannot both be
  true.

No passage is used twice: a file and line that appears in one row, as A or as
B, appears in no other row. A contradiction among more than two passages may
therefore be reported as more than one row only by using different lines for
each row.

## Inputs, Materials and References

| Input | Why it is needed | How to get it | SHA-256 content hash |
|---|---|---|---|
| Molecule docs repository | the only source of passages | `git clone https://github.com/moleculeprotocol/docs` and check out commit `35dcdb821518ca5ed447388379740c0e01d1e77d`; or browse https://github.com/moleculeprotocol/docs/tree/35dcdb821518ca5ed447388379740c0e01d1e77d ; no sign-in | none: the git commit id fixes the content |
| drand `quicknet` beacon | the seed that picks the checked rows | public at https://api.drand.sh/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/public/{round}; no sign-in | none: each value is checked by its drand signature |

At the pinned commit the repository holds 78 Markdown files. On 12 November
2026 the Poster read part of them and confirmed 8 findings that meet the
definition above; the minimum in the acceptance criteria comes from that
count.

## Acceptance Criteria

1. **Schema.** `findings.csv` has exactly the header above; `id` runs from 1
   upward in file order; every `file_a` and `file_b` is a Markdown file of the
   pinned commit; no file and line is used in more than one row; within a
   row, A and B are different lines. The header is not a data row.
2. **Minimum.** `findings.csv` has 5 or more data rows.
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 = 34138592. No other round's value is B. With R data rows in
   `findings.csv`, numbered from 1 in file order after the header, 10
   distinct rows are checked, or all R rows when R is below 10. 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 10 distinct rows. A
   checked row is correct when `quote_a` is found on line `line_a` of
   `file_a` and `quote_b` on line `line_b` of `file_b` at the pinned commit,
   and the pair is a finding under the definition in Challenge details. At
   most 1 of the checked rows may be incorrect.

## How is the winner selected?
- Valid Submissions are those meeting every acceptance criterion.
- The valid Submission with the most data rows in `findings.csv` wins.
- Among Submissions still tied, 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 none is valid, the outcome is `no_valid_submission`.

## Out Of Scope
- Whether the docs match the live API, the deployed contracts or the Molecule
  app. Only the docs against themselves are judged.
- Security findings, style, tone, missing documentation and broken links.
- Files that are not Markdown, and any commit other than the pinned one.

## Evaluation Procedure
Correctness is decided only on the checked rows, by reading the two quoted
lines and their surrounding text in the repository at the pinned commit. The
schema, the minimum and the row count are decided on the whole of
`findings.csv`.