Questfire

Questfire is a quest marketplace for outcome-based growth campaigns. Sponsors fund rewards on Arc, participants complete public tasks, and GenLayer verifies whether each submission actually satisfies the quest before payout is released.

The product is designed around a simple premise: bounty systems should not rely on manual review, screenshots passed around in DMs, or payout decisions that live offchain. Questfire turns campaign funding, submission verification, and reward settlement into one auditable flow.

Why Questfire

Most quest and bounty systems break in one of three places:

• rewards are not escrowed up front
• verification is manual or easy to game
• payout decisions are slow, inconsistent, and hard to audit

Questfire addresses each of those failure points directly:

• Arc is the funding and settlement layer
• GenLayer is the verification and decision layer
• the application orchestrates both into a single sponsor and participant workflow

Why Arc and GenLayer

Arc

Questfire uses Arc as the value rail because Arc is built for stablecoin-native applications:

• Arc Testnet uses USDC as the native gas token
• Arc exposes deterministic finality and EVM compatibility in its documented architecture
• the product can keep sponsorship budgets, fees, and participant rewards in the same stablecoin-native operating model

Relevant Arc docs:

• Welcome to Arc
• Connect to Arc
• Gas and Fees

GenLayer

Questfire uses GenLayer for the hard part: deciding whether a submission actually completed the task. That is a better fit for GenLayer’s Intelligent Contract model than for deterministic-only smart contracts:

• quest specs are registered onchain
• submissions are evaluated inside an Intelligent Contract
• public web evidence can be fetched during verification
• non-deterministic decisions are checked through the Equivalence Principle

Relevant GenLayer docs:

• Architecture Overview
• The Equivalence Principle
• Web Access

What This Repository Ships

The current implementation includes:

• sponsor-side quest creation and budget funding
• Arc escrow-backed campaign funding and reward claims
• GenLayer verifier registration and submission writes
• typed submission intent signing from the participant wallet
• support for text, url, image, and video evidence types
• fetch-and-confirm verification for public URL quests
• request-driven orchestration through API routes or the local orchestrator
• fallback manual review when automation cannot safely finalize a decision

Product Flow

1. A sponsor creates a quest with clear acceptance criteria and a fixed reward budget.
2. The sponsor funds that quest on Arc through the escrow contract.
3. The quest is registered in the GenLayer verifier with a normalized verification spec.
4. A participant submits evidence and signs a typed submission intent.
5. The orchestrator writes the verification request to GenLayer.
6. The GenLayer verifier evaluates the submission, including public web evidence where applicable.
7. If approved, the orchestrator signs a claim authorization.
8. The participant claims the reward from Arc escrow.

Architecture At A Glance

• contracts/arc/QuestRewardsEscrow.sol Arc-side escrow, claim authorization, refunds, and platform fee handling.
• contracts/genlayer/QuestArenaVerifier.py GenLayer Intelligent Contract that evaluates submissions against registered quest specs.
• scripts/server/handlers.ts Control plane for quest registration, verification submission, decision sync, and Arc claim authorization.
• src/lib/protocol/* Typed adapters that keep Arc settlement logic and GenLayer verification logic separated.

More detail lives in:

• docs/protocol-architecture.md
• docs/vercel-neon-deployment.md

Running The Project

Local UI mode

Use this for fast product iteration without live chain dependencies.

pnpm install
pnpm dev

Hybrid mode

Use this when exercising the full Arc + GenLayer flow.

1. Copy .env.example to .env and fill the required values.
2. Install dependencies:

pnpm install

3. Deploy the Arc escrow contract:

pnpm arc:deploy:escrow

4. Deploy the GenLayer verifier:

pnpm genlayer:deploy:verifier

5. Start the orchestrator:

pnpm orchestrator:serve

6. Start the frontend:

pnpm dev

Production Shape

The intended production topology is:

• Vercel frontend
• Vercel API routes for the orchestrator surface
• Neon Postgres for published quests and verification jobs
• Arc for funding and payout settlement
• GenLayer for submission verification

The current request-driven backend design means Questfire does not require an always-on worker for the core hybrid loop.

Current Scope

The current build is opinionated in a few important ways:

• public URLs are the primary evidence format for non-text tasks
• media storage is intentionally out of scope for the current repo
• verification decisions are persisted and reconciled through the orchestrator
• local mode exists for product iteration, but hybrid mode is the real protocol path

Validation Commands

pnpm test
pnpm typecheck:infra
pnpm build

Positioning

Questfire is not trying to be a generic bounty board. It is a stablecoin-native campaign primitive for internet tasks that need two things at once:

• deterministic money movement
• non-deterministic proof evaluation

That split is the reason the product belongs at the intersection of Arc and GenLayer.