> 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/3.-enterprise-and-frontier-ai-labs/3.1-bounty-creation.md).

# 3.1 Bounty Creation

The [Enterprise Portal](https://arcv.network/enterprise) is the campaign configuration surface for laboratories developing language models, evaluation teams measuring model behavior, and research groups commissioning specialized annotations. A successful campaign begins with a precise unit of work, a reproducible acceptance policy, and a budget that funds every promised payable outcome.

The present portal is a configuration and ingestion demonstration. Its confirmation modal does not transfer USDC, create a registry bounty, provision encryption, or deliver webhooks. New vault entries exist in browser page state. The Solidity registry implements native escrow and authorized disbursement, but this guide does not establish a verified production deployment. A live frontend is not evidence that these two components are connected.

## Define the campaign's payable unit

Source tasks, independent reviews, adjudicated outcomes, and archival batches are distinct units. A request for 5,000 source prompts with three reviews each creates up to 15,000 payable reviews. Combining those reviews into one training shard does not turn the shard into 15,000 payments.

The current registry treats each registered dataset as one payable sample with one contributor address and one fixed reward. It does not inspect the number of rows inside the artifact. Before funding, define how orchestration maps assignments to registration records and how it retains task identity, review identity, rubric version, and contributor attribution.

For preference collection, each task must compare responses to the same prompt under the same constraints. For evaluation-only studies, reserve an uncontaminated holdout and prohibit its reuse as training data. For corrections, preserve original outputs alongside the accepted Golden Patch so that a rewrite does not erase the evidence explaining its value.

## Enterprise workflow

### 1. Choose Express or Custom Enterprise

**Express Mode** provides a reduced workflow for modality, payload ingestion, payout, and escrow estimation. It supplies a standard rubric, open workforce, one review, and public-vault settings. Use it to exercise the interface with non-sensitive data and a straightforward task definition.

**Custom Enterprise Spec** exposes title, schema, workforce restrictions, privacy settings, consensus overlap, judge threshold, license, benchmark frequency, completion target, and webhook URL. These settings record intent. Selecting a policy does not deploy the service that enforces it.

In particular, an encryption switch does not produce ciphertext or distribute decryption keys. The current UI disables exports for entries marked encrypted because the service is not connected. Do not upload confidential data on the assumption that an interface badge establishes client-side encryption.

### 2. Specify modality and acceptance criteria

Choose RLHF Pairwise, Code Evaluation, Red-Teaming, or Multimodal according to the actual assignment. Give advanced campaigns a title identifying domain and version. The specification should define input eligibility, expected output, required expertise, permissible AI assistance, evidence standards, and the rule for ambiguous or unanswerable prompts.

For code tasks, pin the interpreter, dependencies, tests, and relevant resource limits. For retrieval-grounded tasks, provide authorized source versions and citation conventions. For adversarial evaluations, state the permitted refusal boundary and distinguish a successful defense from an unhelpful refusal of a benign request.

A task should be understandable without access to unpublished assumptions held by the sponsor. If a response is assessed against a hidden technical requirement, apparent reviewer disagreement can be an assignment-design failure rather than a workforce failure.

### 3. Upload and inspect the task payload

The dropzone accepts `.jsonl`, `.json`, and `.csv` up to its displayed 100 MB limit. JSON must contain a nonempty array of objects. JSONL supplies one object per nonblank line. CSV requires unique nonempty headers and consistent column counts; its values remain strings rather than automatically becoming nested objects or typed numbers.

The parser requires matching top-level field names across records. File telemetry reports name, size, detected rows, and keys. This establishes successful parsing and basic shape consistency, not factual correctness, PII removal, schema compliance, or licensing permission.

Uploading fills **Target Sample Count** from the detected row count. The field remains editable for planning, but deployment rejects a mismatch with the uploaded payload. To commission a smaller campaign, create and upload a matching subset; lowering the number alone does not define which source rows are included.

The sample buttons generate demonstration tasks. They are useful for exercising ingestion and cost calculations, not evidence that a production workload has been curated. Preserve source payloads and their digests outside browser state before planning a funded campaign.

### 4. Version the schema and quality policy

Use separate schemas for task inputs and completed annotations. The current textarea validates a shallow object-schema shape and required-field names. It does not apply a complete JSON Schema evaluator to every uploaded record. Run the external validation procedure in [Custom Schemas](/3.-enterprise-and-frontier-ai-labs/3.2-custom-schemas.md) before deployment.

A schema URI should identify an immutable version or be accompanied by a digest of the exact schema bytes. An ordinary mutable HTTPS URL is not a cryptographic version. The contract stores a nonempty URI string but does not fetch it, validate its content, or prove that a validator used it.

Custom controls include open or qualified workforce, automated PII policy, overlap of 1x/3x/5x, and an AI score threshold from 0.70 to 0.98. A judge score of 0.85 is not an 85% consensus rate. Three reviews do not automatically establish a two-of-three acceptance rule.

An implementable three-review policy must define:

* Three independently assigned review identities for each source item.
* Whether every accepted review is paid or only an adjudicated final outcome is paid.
* The acceptance quorum, treatment of ties, and handling of conflicting rubric scores.
* An escalation path when disagreement concerns a critical correctness defect.
* How missing, expired, or rejected reviews are replaced without overspending.

Do not expose earlier votes to later reviewers. Shared model suggestions and coordinated workers can create correlated agreement, so distinct wallets alone do not prove independence.

### 5. Set reward tiers and reserve bonuses

Let `N` be source items, `K` reviews per item, and `R` USDC per accepted review. Base review funding is `N × K × R`. Budget all requested payable units rather than assuming rejections will cover a funding shortfall.

| Budget component: 5,000 items, 3 reviews, 0.25 USDC    | Amount        |
| ------------------------------------------------------ | ------------- |
| Maximum payable reviews                                | 15,000        |
| Base review reserve                                    | 3,750.00 USDC |
| Separate reserve for 1,000 accepted patches at +0.50   | 500.00 USDC   |
| Combined reward liability before fees and gas          | 4,250.00 USDC |
| Current UI's 5% fee estimate on base reviews           | 187.50 USDC   |
| Current UI total, which excludes a separate patch pool | 3,937.50 USDC |

The portal has no dedicated patch-pool input. Publish bonus eligibility, maximum accepted count, acceptance rules, and the actual funding mechanism before promising **+0.50 USDC per accepted patch**. A possible future design uses a distinct fixed-reward correction campaign; another requires a bounded bonus extension to settlement. Neither is automatically created by current controls.

The form permits whole-number counts from 1 through 10,000,000 and rewards from 0.01 through 10,000.00 USDC with up to two decimals. It calculates its 5% estimate in cents with rounding. These limits and the fee are frontend behavior, not equivalent Solidity constraints.

The proposed 10% protocol economics elsewhere in this documentation also differs from the current 5% UI estimate. The registry implements neither fee. Do not add a fee-inclusive amount to `msg.value` for a contract requiring only base escrow: the exact-value check will revert. Network gas is an additional sender cost outside the escrow value.

## Native USDC escrow mechanics

Arc mainnet uses chain ID `5042` and native USDC with 18-decimal transaction-value units. The settlement interface is:

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

This function accepts native value, not an ERC-20 allowance. `targetCount` and `rewardPerSample` must be positive and the URI nonempty. Required escrow equals their product, with Solidity checked arithmetic. The caller must send exactly that amount.

For the review-level example, `targetCount` is 15,000, not 5,000. A `0.25 USDC` reward equals `250000000000000000` native base units and escrow equals `3750000000000000000000`. Use decimal strings and integer arithmetic rather than binary floating-point calculations.

The following runnable calculation separates review reserves, optional bonus reserves, and the UI estimate without sending a transaction:

```python
from decimal import Decimal

items = 5000
reviews_per_item = 3
reward = Decimal("0.25")
patch_count = 1000
patch_bonus = Decimal("0.50")
units = items * reviews_per_item
base = units * reward
bonus = patch_count * patch_bonus
native_reward = int(reward * 10**18)
native_escrow = units * native_reward

assert base == Decimal("3750.00")
assert bonus == Decimal("500.00")
assert native_escrow == 3750000000000000000000
print("Payable reviews:", units)
print("Base escrow USDC:", base)
print("Separate bonus reserve USDC:", bonus)
print("UI base plus 5% estimate USDC:", base * Decimal("1.05"))
print("Contract msg.value:", native_escrow)
```

Before a real deposit, independently verify deployed bytecode, ABI, governance, operational roles, network identity, URI version, and exact value. A successful receipt and `BountyCreated` event establish the assigned bounty ID. A broadcast hash alone does not establish success. Reconcile uncertain transactions before retrying; a second successful creation call opens a second funded bounty.

## Holds, reservations, and disbursement

```
Sponsor native value
        |
        v
Bounty remainingEscrow = targetCount * rewardPerSample
        |
        +-- bundler registers pending dataset -> reserves capacity
        |             |
        |             +-- validator rejects -> releases capacity, no payment
        |             |
        |             +-- validator accepts -> native payment to contributor
        |                                      reduces remainingEscrow
        |
        +-- no implemented expiry or sponsor cancellation exit
```

Registration requires the bundler role, a unique nonzero SHA-256, a syntactically valid unique storage identifier, a valid recipient, and available capacity. Pending plus paid records cannot exceed the funded target. Rejection frees a capacity slot but retains used hash and transaction-ID reservations; a rejected artifact cannot simply be registered again under the same identifiers.

Only a validator-role address can approve a pending record. The contract changes state and reduces escrow before the external native transfer, with reentrancy protection on disbursement. A failed recipient transfer reverts the transaction, restoring the prior state. These mechanics prevent duplicate payment through the same pending record; they do not make the validator's off-chain quality decision trustless.

The contract cannot inspect an Arweave payload, prove three independent evaluations, run a rubric, or detect a poisoned label. Authorized validators remain a substantive trust boundary. An administrator controls role assignments, so a production review must assess role custody and operational procedures as well as arithmetic invariants.

## Expiration and the absent cancelBounty mechanism

**`cancelBounty()` does not exist in the current contract.** The bounty structure has no expiration timestamp, cancellation state, or refund balance. The portal's 48-hour, 7-day, and 30-day completion targets are descriptive settings. Its refund-policy text explicitly says no refund contract is connected.

Consequently, an enterprise creator cannot invoke a documented timelock to reclaim unallocated escrow from this implementation. Rejection does not refund the sponsor, and the admin role has no general withdrawal function. Funds with no future payable submissions can remain locked indefinitely. This is a material funding limitation, not a missing UI convenience.

A future cancellation design must specify the following before it can support an operational refund promise:

| Required decision               | Why it matters                                                                  |
| ------------------------------- | ------------------------------------------------------------------------------- |
| Deadline storage and clock      | A UI date alone cannot constrain on-chain execution                             |
| Authorization                   | Only the entitled sponsor or explicitly defined authority may reclaim funds     |
| Pending review treatment        | A refund must not consume liabilities already reserved for valid in-flight work |
| Remaining liability calculation | Refunded value and payable obligations must not overlap                         |
| Terminal state and races        | Cancellation must prevent later registration or double use of refunded funds    |
| Failed transfer behavior        | Accounting must remain correct if the sponsor cannot receive a native transfer  |
| Events and auditability         | Operators need an unambiguous record of amount, recipient, and state transition |

These are design requirements, not a callable ABI. No refund transaction example is provided because there is no valid current function to call. A production funding release needs an implemented, reviewed, and tested policy or an explicit decision to accept non-refundable escrow risk.

## Delivery, privacy, and export reconciliation

License selection records a requested commercial arrangement; it does not itself execute EIP-712 assignment. Encryption requires actual ciphertext generation, authenticated key distribution, and controlled decryption. Public immutable storage cannot be made private by subsequently hiding a download button.

The optional HTTPS webhook field and `batch.sealed` preview do not implement delivery. A production receiver needs authenticated events, replay protection, idempotency, retry policy, and reconciliation with registry and archival evidence. Treat webhooks as notifications to verify rather than an independent source of payment truth.

The local vault exposes original payloads and JSONL or Parquet source exports for eligible entries. The Parquet representation contains raw source data, not tokenized accepted annotations. A production retrieval service must distinguish inputs, paid outputs, consensus aggregates, and transformed training artifacts, retaining lineage across each transformation.

Use [Provenance and Dataloaders](/3.-enterprise-and-frontier-ai-labs/3.3-provenance-and-dataloaders.md) to define the verification boundary between an authenticated archive and the records admitted into training.


---

# 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/3.-enterprise-and-frontier-ai-labs/3.1-bounty-creation.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.