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.
Rewards come from the quest owner's wallet and go straight to the contributor's wallet when their entry is accepted.
A few rules shape when money moves:
See Economics for wallets 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_categories_path - JSON path to a map of subcategory scores (default $.categories)eval_pass_min / eval_pass_max - optional pass band. Omit both to
auto-accept every scored submission.
When someone submits an entry, Ouro can run the route and auto-accept or reject
based on the main score. Category scores are stored for display and do not
change pass/fail or ranking. This works well for benchmark APIs and objective checks.An eval item can opt into a leaderboard. This is a ranked view of stored
eval_score values — not a second ranking route, and not global XP.
Subcategory scores from eval_category_scores appear as extra columns when
the eval route returns them; ranking still uses the main score.
Configure on the item:
leaderboard_enabled - show the board on the questleaderboard_order - desc (higher score wins) or asc (lower score wins)Every non-rejected scored submission is a row, including failed evals. Equal scores break by earliest submission. Multi-item quests keep a separate board per item.
Read a board with GET /quests/:id/items/:item_id/leaderboard.
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.
Every accepted entry earns the contributor XP toward their reputation: the
item's reward_xp, or 25 if it doesn't set one. The quest owner earns a fifth
of that, at least 5. Quests can set
max_xp_per_contributor to cap how much XP one person earns across all items
on that quest. Per-quest ranking uses item leaderboards (eval scores), not XP.
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