> For the complete documentation index, see [llms.txt](https://docs.arcv.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arcv.network/0.-quickstart-guides/0.2-how-to-create-bounties.md).

# 0.2 How to Create Bounties

**Goal:** Prepare a task batch, define acceptance criteria, fund verified work, and retrieve an integrity-checked training dataset.

**Current implementation:** The enterprise console labels its escrow flow as simulated. It prepares a local campaign demonstration; it does not deposit funds into a deployed registry. The workflow below distinguishes those preparation steps from the production transactions and retrieval evidence required before a campaign is operational.

## 1. Open the enterprise console

Visit [the enterprise portal](https://arcv.network/enterprise). Use an enterprise-controlled wallet authorized by your organization. Configure Arc mainnet, chain ID **5042**, using the [wallet setup guide](/0.-quickstart-guides/0.1-how-to-annotate.md), and retain native USDC for escrow and gas.

Choose **Express Mode** for the default configuration or **Custom Enterprise Spec** to inspect the schema, workforce, consensus, privacy, and campaign settings. Signing into the prototype does not verify enterprise authorization on-chain.

## 2. Load tasks and define acceptance rules

1. Select the modality, such as RLHF Pairwise or Code Evaluation. In Custom mode, give the campaign a descriptive title.
2. Drop a `.jsonl`, `.json`, or `.csv` task file into the ingestion area, or load a sample preset. The upload limit is 100 MB. Inspect the detected row count and parsed keys.
3. Review **Target Sample Count**. Uploading a dataset fills this from detected rows; a manually entered target can estimate costs but does not create missing task records.
4. In Custom mode, paste a JSON Schema into **JSON Schema rubric**, use a preset, or provide the optional schema URI. The task upload is a payload upload, not a separate schema-file uploader.
5. Set the reward per verified submission and, where applicable, the review overlap. Three reviews per input item require three payable submissions per item.
6. Record Golden Patch funding, acceptance thresholds, and campaign deadlines in your specification. Frontend controls alone do not enforce these conditions in the registry.

The demo checks schema shape rather than full JSON Schema compliance. Validate both sample tasks and expected output records with an appropriate schema validator before funding. See [production schema examples](/3.-enterprise-and-frontier-ai-labs/3.2-custom-schemas.md).

## 3. Review costs and production escrow prerequisites

The console's current estimate uses a 5% fee convention; the documented target economics specify a different 10% settlement policy. Neither is implemented as a fee in the current registry. Do not approve funding until the deployed contract, quote, and worker reward terms agree.

The current contract interface is:

```solidity
function createBounty(
    uint256 targetCount,
    uint256 rewardPerSample,
    string calldata dataSchemaURI
) external payable returns (uint256 bountyId);
```

For this implementation, the required native transaction value is exactly `targetCount * rewardPerSample`. Amounts use native base units with 18 decimals. No ERC-20 allowance is required for native-value funding. The count represents payable records, so map multi-review work to funded units explicitly.

Before sending real funds, verify the registry address, chain, deployed code, ABI, roles, and creator account. The current registry does **not** implement campaign expiration or `cancelBounty()`: do not assume unused escrow can be reclaimed through that function. Consult [deployment interfaces](/5.-smart-contracts-and-arc-network-settlement/5.4-deployments-and-interfaces.md).

Clicking **Deploy Bounty & Lock Escrow** currently opens the simulated flow. A production deposit must instead produce a successful wallet transaction and a registry creation record matching your funding and schema. A new local vault row is not that proof.

## 4. Monitor accepted work

Use **Dataset Ingestion & Vault** to inspect the demonstrated campaign records. In a production integration, reconcile submission IDs, contributor identities, review counts, validation decisions, and settlement receipts with your campaign.

Telemetry and LLM judge results need an operational off-chain service. Displayed scores alone do not prove that service ran. Track submitted, pending, rejected, and paid records separately; uploaded row count is not accepted annotation count.

## 5. Retrieve and verify the dataset

Obtain the finalized dataset identifier, actual Arweave transaction ID, exact payload hash, and corresponding registry record. Download through the recorded Arweave/Irys location, compute SHA-256 over the exact committed bytes, and compare against the on-chain commitment before parsing or training.

The current registry uses `usedHashes` for replay reservations; a true value alone does not prove acceptance or payment. Inspect the associated dataset status and successful settlement. Proprietary payloads additionally require valid access and decryption entitlements.

Use the [verified Hugging Face and PyTorch loaders](/3.-enterprise-and-frontier-ai-labs/3.3-provenance-and-dataloaders.md) to verify the full object before yielding training records. A local download from a demo vault is not proof of permanent archival. Preserve the manifest, hash, and transaction references alongside each training run.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.arcv.network/0.-quickstart-guides/0.2-how-to-create-bounties.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.