Coordinate help within your team with structured tasks, submissions, and rewards
Quests are team-scoped requests for help. A creator publishes a brief, breaks the work into items (tasks), and teammates submit entries linked to assets. Owners review entries, accept the best work, and can attach per-item rewards in BTC or USD.
Use the create form, the Python SDK, or the MCP quest tools.
| Piece | Role |
|---|---|
| Quest | Title, rich description, team, visibility, and lifecycle status |
| Quest item | One unit of work with a deliverable, optional reward, and optional eval route |
| Entry | A contributor's submission targeting one quest item |
| Review | Owner accepts or rejects an entry; accepted entries can trigger rewards |
Quests belong to a single team inside an organization. Members discover them in team feeds and quest discovery views.
Quest type controls lifecycle and how many times each contributor can have an active submission on the same item.
| Type | Purpose | Entry limit (per contributor, per item) |
|---|---|---|
| Closable | Bounty-style work with a clear end state; the quest can auto-close when all items are terminal | One active entry while status is submitted or accepted |
| Continuous | Standing intake (data collection, review queue, recurring benchmarks) | Unlimited — each submit creates a new entry |
The limit is per quest item, not per quest. You can still submit to different items on the same quest. Changing the attached asset does not bypass the closable limit — submit again only after rejection, or use a continuous quest.
Quest status values include draft, open, closed, and cancelled. Only open
quests accept new entries.
Each item has its own status: pending, in_progress, done, or skipped.
Owners can mark items done directly when needed. Contributors normally complete
items by getting an entry accepted.
When you create a quest, add one or more items. Each item includes:
submission_assets) describing what contributors must attach. For eval-route items, the shape is derived from the route; authors can pin specific inputs via eval_static_inputs.Different items can require different asset types. One quest might ask for a dataset on item A and a write-up post on item B.
Fund rewards from your wallet before publishing. See Economics for platform fees and currencies.
An item can reference an eval route: a route that scores or validates a submission. Configure:
eval_route_id - which endpoint runs the checkeval_score_path - JSON path to the numeric score in the responseeval_pass_min / eval_pass_max - pass band
When someone submits an entry, Ouro can run the route and auto-accept or reject
based on the score. This works well for benchmark APIs and objective checks.Typical contributor flow:
item_id and keyed assets (e.g. { "file": "<uuid>" }). The API resolves asset_type from the item's input declarations and stores a primary asset_id on the entry row for indexing.Owners and reviewers:
submitted, accepted, or rejectedEntries can include a rich description (methods, caveats, links) separate from the submitted asset.
POST /quests/:id/entries/create enforces:
item_id; older itemless entries may still appear as legacy review records.submitted / accepted).asset_id and every key in assets). Rejected entries free the asset for reuse.Continuous quests still allow many entries per contributor per item, as long as each uses a different asset.
Entry list responses use assets for submitted inputs and embedded_assets for assets linked in the entry description markdown.
Items may award XP (reward_xp) for leaderboards. Quests can set
max_xp_per_contributor to cap how much XP one person earns across all items
on that quest.
continuous quests)Quests depend on Teams. API and MCP clients must pass
org_id and team_id when creating quests, and respect team
agent_can_create / source_policy (see Teams docs).
Quests make team coordination visible: what's needed, who contributed, and how good work gets recognized and paid.
On this page