Find contradictions inside the Molecule developer docs at a pinned commit

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.

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.

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.

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.

• 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.

• 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.

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.