0deg: Real-World Quests on Stellar

1. Abstract

0deg (“zero degrees”) is a mobile-first protocol that turns the physical world into a quest map. Navigators post quests (tasks anchored to real geographic coordinates) and fund them with XLM or USDC. Scouts discover quests on a live map, complete them on location, and submit verifiable proof. Rewards are held in a Soroban smart contract from the moment a quest is created and released automatically according to protocol rules, with no intermediary custody at any point.

By combining Stellar’s sub-cent fees and ~5-second finality with GPS-gated participation and an optimistic review model, 0deg makes paying strangers for real-world work as safe as paying a trusted contractor, without the platform holding anyone’s money.

2. The Problem

Getting small, location-bound tasks done remotely is still remarkably hard. Existing options fail in one of three ways:

• Trust asymmetry. Classified boards and social media offer no payment guarantee in either direction: workers risk not being paid, posters risk paying for work never done.
• Custodial platforms. Gig marketplaces solve trust by becoming the bank: holding funds, charging 15-30% fees, imposing withdrawal delays and geographic restrictions, and excluding the unbanked entirely.
• No location guarantee. None of the above can verify that the person who accepted a task is actually able to be where the task is.

The result: an enormous long tail of small real-world jobs (verify this storefront is open, photograph this notice board, check the price of this item, deliver this envelope across town) that are simply not worth the coordination overhead today.

3. The 0deg Solution

0deg replaces the custodial platform with three primitives:

1. On-chain escrow.The reward leaves the Navigator’s wallet at quest creation and sits in a Soroban smart contract. The contract, not 0deg, decides who gets paid, based on rules both parties agreed to upfront.
2. Geofenced participation. A quest can only be taken by a Scout physically inside its take radius, verified at take time. This filters participants down to people who can actually do the work.
3. Optimistic review with hard deadlines. The Navigator reviews submitted proof and approves or rejects. Every state has a deadline with a contract-enforced fallback, so neither party can grief the other by going silent.

The protocol is fully non-custodial: users connect their own Stellar wallets (Freighter, xBull, Albedo, Ledger, and any wallet supported by Stellar Wallets Kit), sign every transaction themselves, and interact directly with the contract.

4. Protocol Architecture

4.1 On-chain: the Soroban escrow contract

A single Rust contract on Stellar implements the entire quest state machine. Key design decisions:

• Per-quest escrow and per-quest token. Each quest independently locks its reward in the reward asset chosen by the Navigator (native XLM or Circle USDC via their Stellar Asset Contracts). Fee balances are likewise tracked per token.
• Typed contract events. Every state transition emits a structured event (QuestCreated, QuestTaken, QuestCompleted, QuestApproved, and so on), forming a complete, replayable audit log.
• Operational controls without custody. The contract supports pause (new activity only), admin rotation, and in-place WASM upgrades, but by construction, no admin function can redirect or freeze user escrow. Settlement paths are never pausable.

4.2 Off-chain: build-tx pattern and indexer

The application layer never holds keys or funds. The flow for every on-chain action:

1. The API validates off-chain rules (e.g. GPS radius) and returns an unsigned transaction.
2. The user signs it in their own wallet.
3. The client submits it directly to the Stellar network.
4. An indexer mirrors contract events into a queryable database. The chain remains the single source of truth, and the database is never updated optimistically.

This means the worst-case failure of 0deg’s servers is a degraded UI, never lost funds: escrowed rewards remain claimable directly on-chain.

5. Quest Lifecycle & User Flows

5.1 State machine

5.2 Navigator flow

1. Connect wallet and authenticate by signing a message (SEP-53), with no passwords.
2. Define the quest: title, rich description, category, location and take radius, proof type (photo / video / document), reward asset and amount, completion deadline, and review window.
3. Review the summary including the fee breakdown, then sign one transaction that creates the quest and locks the reward.
4. When proof arrives, review it and approve or reject with a single signature.

5.3 Scout flow

1. Open the live map and browse nearby quests, filtered by what is reachable.
2. Walk into the quest radius and take the quest. The take transaction records the commitment on-chain.
3. Do the work; submit proof plus an optional note before the deadline.
4. On approval, the payout lands in the wallet within seconds, linked to a public transaction hash.

5.4 Deadline protections

• Scout goes silent: after the completion deadline, the Navigator reclaims the escrow.
• Navigator goes silent: the review window bounds how long proof can sit unreviewed, so a submission can never be held hostage indefinitely.

6. Location Verification

Location is verified off-chain at take time: the app obtains a device GPS fix and the API checks it against the quest’s coordinates and radius before building the take transaction. Coordinates are deliberately kept off-chain: publishing precise user locations on a public ledger would be a privacy failure, and on-chain GPS proofs are not yet practical.

This is an explicit trust trade-off: GPS can be spoofed by a motivated attacker. The protocol’s defense is layered: the Navigator still reviews proof of the actual work (which itself typically evidences presence), reputation makes serial abuse visible, and rejected work costs the Scout the time spent with nothing paid out.

7. Proof System

Each quest declares the proof type it requires, and the protocol enforces it at submission:

Proof files are stored in private object storage and served only through the application to the parties involved. Scouts can attach a note (up to 1,000 characters) providing context for the reviewer.

8. Economic Model & Revenue

8.1 Fee structure

The protocol charges a single fee: 5% of the reward, deducted at payout, only when a quest is approved. The fee is enforced by the smart contract (500 basis points in contract config) and accrues to a per-token fee balance inside the contract itself.

8.2 Minimum reward

Every quest must fund at least 5 XLM or 1 USDC, enforced when a quest is created. The floor keeps the map meaningful: it makes mass spam expensive (each junk quest still locks real capital in escrow), guarantees the protocol fee never rounds to dust, and ensures a payout is worth a Scout’s trip. The smart contract additionally enforces a universal 0.1-unit dust floor on-chain, so sub-dust quests cannot exist even through direct contract calls that bypass the app. The per-asset minimums live in application configuration and can be tuned as market prices move, without any contract change.

8.3 Why success-only fees

Charging only on success aligns the protocol’s revenue with the health of the marketplace: 0deg earns nothing from failed matches, spam, or disputes. There are no listing fees, subscription tiers, or withdrawal fees, and because settlement is on Stellar, network costs are negligible for both sides.

8.4 Revenue allocation

Accrued fees fund protocol operations in this order of priority: infrastructure and storage costs, security (audits, multisig operations, monitoring), and continued development of the roadmap. As the dispute-resolution jury launches (§11), a share of the protocol fee will be redirected to jurors as compensation for honest review work, turning the fee into the budget that secures the marketplace.

8.5 No token

0deg has no protocol token and no plans for one. Quests settle in assets people already hold and trust (XLM and USDC), which keeps rewards legible (a 10 USDC quest is worth 10 dollars) and avoids reflexive tokenomics entirely.

9. Reputation

Every settled quest updates public, per-role reputation derived from on-chain events: quests created and completed, approval and rejection counts, and lifetime earnings per asset. Profiles are public and portable context for both sides of every future quest, and a top-10 leaderboard highlights the most reliable participants.

Because reputation is derived from contract events rather than self-reported activity, it cannot be fabricated: the underlying history is independently verifiable on the Stellar ledger.

10. Security & Trust Model

10.1 What users must trust

• The contract: open-source Rust, covered by an extensive test suite, with reproducible builds: the deployed WASM hash can be verified against the source.
• Each other, bounded:the counterparty risk in any quest is bounded by its reward and resolved by deadlines; no outcome depends on 0deg’s goodwill.

10.2 What users do not have to trust

• 0deg with funds: the protocol admin cannot withdraw, redirect, or freeze user escrow. Pause affects only new quest creation and takes. Settlement (approve, reject, cancel, expiry claims) can never be paused.
• 0deg with identity: authentication is wallet-signature based; there are no passwords or custodial accounts.

10.3 Operational security

• Admin functions (pause, admin rotation, upgrade, fee withdrawal) each require the admin’s signature; the mainnet admin is a multisig-protected account.
• In-place WASM upgrades preserve the contract address and all quest state, allowing fixes to ship without migrations or redeployments.
• All admin actions emit audit events (PauseToggled, AdminChanged, ContractUpgraded) that anyone can monitor.

11. Roadmap

The roadmap is organized by quarter, starting at Q2 2026 — there is no Q1 milestone because the protocol did not exist before then. Each phase builds on a live, working core rather than a promise: Q2 is already shipped, Q3 is in progress, and Q4 is planned.

Q2 2026 — Shipped: live protocol on Stellar mainnet

• Fully on-chain questing: escrow contract with the full quest lifecycle and multisig-protected admin controls
• XLM and USDC rewards with trustline safety guards
• Geofenced takes; photo, video, and document proof with review deadlines and anti-ghosting self-claim
• Reputation, public profiles, and top-10 leaderboard
• First installable, mobile-first PWA with multi-wallet sign-in (Albedo, xBull, Freighter, LOBSTR)
• Deployed and settling real value on Stellar mainnet

Q3 2026 — In progress: mobile apps & partnership program

• Native mobile apps published on Google Play and the App Store
• Partnership program: co-branded quest campaigns run with brands, communities, and local organizations
• Brandable cosmetics: partners can theme the on-map experience — custom quest pin markers, map assets, and quest cards styled to their brand
• Sponsored quest pools funded by partners
• Push notifications and two-sided ratings

Q4 2026 — Planned: collaborations & the quest economy

• Ecosystem collaborations: joint quest campaigns with Stellar projects and regional partners across APAC
• Challenge → jury (flagship): a rejected Scout can challenge; the dispute escalates to a randomly selected panel of staked, high-reputation reviewers (e.g. 2-of-3). Jurors earn a verification fee and are slashed for voting against the majority, replacing unilateral review and turning proof of real-world action into a decentralized verification primitive.
• Proof liveness: server-issued nonce that must appear in the submitted photo, plus timestamp and device attestation, as a defense against GPS spoofing.
• Local anchors and SEP-24 fiat on/off-ramps (e.g. IDR, PHP, VND), connecting quest rewards to local economies beyond XLM and USDC
• Recurring and multi-Scout quests for businesses (mystery shopping, field audits, mapping data collection), business dashboards, and a public quest API
• Scout bonds slashed on abandoned or junk work, reputation-gated quest tiers, and DePIN / disaster-response pilots

12. Disclaimer

This document describes the 0deg protocol as designed and implemented at the date above and is provided for informational purposes only. It is not financial, legal, or investment advice, and nothing in it constitutes an offer to sell any asset. Protocol parameters and roadmap items may change as the project evolves; the deployed smart contract and its on-chain configuration are always the authoritative description of protocol behavior. Using 0deg involves risks inherent to blockchain systems, including smart-contract risk and asset volatility. Participate only with funds you can afford to lose.