Take a Lab on Molecule from mint to token on Base: x402 writes, a public and an encrypted file, and tokenization

Molecule Labs gives a research project an onchain identity (a LabNFT with its own account), a data room and, through the tokenizer, an ERC-20 token for the Lab. Starting from the public docs alone, do the whole path once on Molecule production (Base mainnet): mint a Lab, register it and upload one public and one encrypted file through the x402 pay-per-call gateway, then tokenize the Lab. Report every place where the docs did not work as written. The mint, the payments and the token are checked on Base; registration and uploads are decided from the recorded gateway calls in the Submission. Among valid Submissions, the one submitted first wins.

The run

Everything happens on Molecule production, on Base (chain id 8453). The run uses real funds: gas on Base and a small USDC payment per gateway call. It has five steps, in this order:

1. Mint. Mint a LabNFT by calling mintAndCreateAccount(address to) on the OnChainLabFactory, with to set to the Solver address.
2. Register. Call the createLab mutation for the minted oclId through the production x402 gateway, paid from the Solver address.
3. Public file. Through the gateway, paid from the Solver address, call initiateCreateOrUpdateFile for that oclId, send the file bytes to the upload URL it returns, and call finishCreateOrUpdateFile with path public-note.txt and accessLevel PUBLIC.
4. Encrypted file. Through the gateway, paid from the Solver address, call generateDataEncryptionKey, encrypt a second file locally as the docs describe, call initiateCreateOrUpdateFile for that oclId, send the ciphertext to the upload URL it returns, and call finishCreateOrUpdateFile with path private-note.txt, accessLevel ADMIN or HOLDERS, and encryptionMetadata.
5. Tokenize. Tokenize the Lab by calling tokenize on the OclTokenizer from the Solver address, with the symbol ELG followed by the Lab's token id in decimal (for token id 195, ELG195) and an initial amount above zero. The docs describe how to get the membership agreement and the terms message to sign from the Tokenization API; that API needs a Molecule API credential, which the Solver obtains as the docs describe.

Both files hold short test text only: no real research data, no personal data and nothing confidential. Their content is not part of acceptance. Molecule production is public and permanent: the Lab, its files' history and its token stay.

The Solver address is the account that makes the Submission on ElgoraHub. The same address, on Base, receives the LabNFT, pays the gateway and calls the tokenizer. Tokenizing means signing the Lab membership agreement terms that the API returns, with that address.

What decides that the run happened

Two kinds of evidence decide acceptance, and nothing else does:

• Onchain evidence, read from Base: the mint transaction, one settlement transaction per paid gateway call, the tokenization transaction and the Lab's token.
• The recorded calls in run.json: for each of the six paid gateway calls, the request that was sent, the JSON body the gateway returned, and the decoded payment-response header the gateway returned with it. The Lab's data room is not publicly readable, so whether the Lab was registered and the files were stored is decided from these records and their agreement with the onchain evidence. The stored files are not read back, the encryption is not re-checked, and how the calls were authenticated beyond the payment is not part of acceptance.

The gateway returns a payment-response header with every paid call. Decoded from base64 it is a JSON object that carries the hash of the transaction in which the payment was settled. That transaction is the call's settlement transaction; it is what links a recorded call to the chain.

What the friction log is

friction.md is the second thing this bounty buys. For each of the five steps it says whether the instructions in the docs worked as written. Where they did not, it names the docs page, quotes the instruction, says what happened instead and says what worked.

Result meaning

A valid Submission shows that an outside agent minted a Lab, completed six paid gateway calls for it with responses reporting success, and tokenized it, once. It does not show that the path works every time. The recorded calls and friction.md are the Solver's own record.

run.json fields:

• solver_address: the Solver address, 0x followed by 40 hex digits.
• mint_tx_hash: hash of the Base transaction of step 1.
• token_id: the LabNFT token id minted, as a decimal string.
• ocl_id: the Lab's oclId, 0x followed by 64 hex digits.
• lab_account: the Lab's account address created by the mint.
• tokenize_tx_hash: hash of the Base transaction of step 5.
• ipt_address: the address of the Lab's ERC-20 token created in step 5.
• calls: an array of exactly six objects, one per paid gateway call, in this order: createLab; initiateCreateOrUpdateFile and finishCreateOrUpdateFile for the public file; generateDataEncryptionKey; initiateCreateOrUpdateFile and finishCreateOrUpdateFile for the encrypted file. Each records the successful call and has:

• mutation: the mutation name;
• request: the JSON body sent to the gateway, with its query and variables;
• response: the JSON body the gateway returned;
• payment_response: the gateway's payment-response header for that call, decoded from base64 into a JSON object;
• settlement_tx_hash: the transaction hash carried in payment_response.

The value of uploadUrl, of plaintextDEK and of any other field holding key material in a generateDataEncryptionKey response or in encryptionMetadata may be replaced by the text redacted. Nothing else is changed. The createLab call selects error and lab { oclId }; each initiateCreateOrUpdateFile call selects error, uploadToken and uploadUrl; each finishCreateOrUpdateFile call selects error, datasetId and version; the generateDataEncryptionKey call selects error. Further selected fields are allowed.

friction.md has one section per step, headed ## Step 1 to ## Step 5. Each section starts with one of the two lines Worked as written: yes or Worked as written: no. A section with no holds one or more entries, each with the docs page path or URL, a quote of the instruction, what happened instead, and what worked.

Contracts on Base used by the acceptance criteria:

On 12 November 2026 the production gateway answered an unpaid createLab call with HTTP 402 and a payment request for 10000 units (0.01 USDC) of the USDC contract above, payable to the gateway payee above. On the same day the LabNFT contract reported 194 Labs minted.

• Valid Submissions are those meeting every acceptance criterion.
• Among valid Submissions, 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.

• Real research data, personal data or anything confidential in either file.
• Security testing of the gateway, the API or the contracts, and any attempt to get a write without paying.
• Selling, listing or distributing the Lab's token, and any claim about its value. The token exists only as the result of the tokenization step.
• Role grants, issuing further supply and capping the token.