Development Roadmap
Version: 1.0 | Status: Active | Updated: 2026-02-21
Six phases take the platform from foundational infrastructure to a fully operational decentralized gig-work economy. Each phase builds on the previous with clear milestones and deliverables.
Phase Overview
| Phase | Name | Duration | Focus |
|---|---|---|---|
| 1 | Foundation | 3–4 weeks | Monorepo, contracts, API, minimal frontend |
| 2 | Quest Completion | 3–4 weeks | GitHub integration, CI verification, payment release |
| 3 | Reputation and Payments | 3–4 weeks | Oracle, ranks, leaderboard, payment rails |
| 4 | NFT Badges and Skills | 2–3 weeks | ERC-721 badges, skill registry, portable credentials |
| 5 | Advanced Features | 3–4 weeks | Guilds, benevolent mechanics, disputes, incentive shares |
| 6 | Governance and Launch | 2–3 weeks | Community DAO, security audit, mainnet deployment |
Estimated total duration: 16–20 weeks
Phase 1: Foundation
Goal: Core infrastructure and basic Quest workflow
1.1 Development Environment
The monorepo is initialized with pnpm workspaces and TypeScript is configured across all packages. Hardhat is set up for smart contract development alongside ESLint and Prettier for code quality. Git hooks are added via Husky and a CI pipeline is created with GitHub Actions. Test infrastructure is configured using Jest for unit tests and Hardhat's built-in testing for contracts.
1.2 Core Smart Contracts
The Quest contract handles escrow deposit, farmer acceptance, completion state transitions, payment release, and expiry/refund logic. A Quest Factory contract manages deployment and the quest registry. A Protocol Fee contract collects the 2% fee and routes it to the appropriate treasuries. Unit and integration tests cover the full Quest lifecycle including edge cases like concurrent farmers and early expiry.
1.3 Backend API
The Node.js backend is set up with TypeScript and ESM modules deployed as Vercel serverless functions. Database schema design covers profiles, quests, mail, leaderboard, and DAO data. Quest CRUD endpoints are implemented alongside wallet-based user registration and SIWE signature authentication. OpenAPI documentation is generated for all endpoints.
1.4 Minimal Frontend
The Vite and React project is set up with wagmi for wallet connection. The core views are implemented: Quest creation form, Quest board listing, and Quest detail view. Wallet connection, network detection, and basic auth flow are functional end to end.
Milestone: Basic Quest Creation
A Giver can create a Quest via the web interface, deploying a smart contract with escrowed funds. The Quest appears in a public Quest Board.
Phase 2: Quest Completion Flow
Goal: End-to-end Quest workflow with GitHub integration
2.1 GitHub Integration
The GitHub OAuth flow is implemented, allowing Farmers to link their GitHub accounts. Repository linking and issue creation are handled from the Quest creation flow. PR status is tracked via webhooks and processed into quest state updates.
2.2 Fetch Quest GitHub Action
The CI action is built to parse test results and evaluate completion criteria defined by the Giver. On successful completion, the action calls the platform API to trigger the Review Window. Documentation and usage examples are provided for Givers setting up their repositories.
2.3 Testing Framework
A standardized testing framework defines the structure for Quest test cases, the result reporting format, and how the GitHub Action runner integrates with CI output. Givers use this framework to define verifiable completion criteria for their Quests.
2.4 Quest Lifecycle Completion
Farmer Quest acceptance enforces the 24-hour minimum holding period before submission is allowed. CI completion events trigger the 48-hour Review Window. Automatic payment release fires after the window closes without a dispute, and Quest expiry handling refunds Givers when deadlines pass.
2.5 Smart Contract Updates
The Quest contract is extended with Review Window state management and a completion verification interface for the CI callback. Multi-farmer tracking is implemented alongside the consolation pool logic that distributes partial rewards when a Quest ends without full completion.
Milestone: End-to-End Completion
A Farmer accepts a Quest, completes work in GitHub, triggers CI verification, and receives automatic payment after the Review Window.
Phase 3: Reputation and Payments
Goal: Reputation system and full payment options
3.1 Oracle Contract
The on-chain Oracle stores reputation scores and implements rank calculation logic for both Farmers and Givers. The leaderboard data structure is designed for efficient public querying with seasonal data support.
3.2 Reputation System
Farmer and Giver reputation is tracked separately, with Quest completion attribution driving rank progression. Seasonal Quest caps are enforced and cooldown periods prevent reputation farming. Historical reputation data is retained across seasons.
3.3 Review System
Post-Quest review prompts are displayed to both parties after a Quest completes. The review submission API stores ratings and written feedback. Reviews are displayed on public profiles and factor into reputation scores. Submitting a review increases a Farmer's probability of receiving an incentive share at season end.
3.4 Payment Rails
USDC via MetaMask is the default payment method. Square API integration with KYC flow is added for USD payments. Changelly handles USDC-to-USD conversion for Farmers who prefer fiat. Cash App and debit card payment options are added for broader accessibility. Fee estimation is shown at Quest creation and Givers have the option to cover Farmer fees.
3.5 Frontend Updates
User profile pages display reputation scores, rank badges, and Quest history. The leaderboard page shows Farmers, Givers, and Guilds with seasonal filters. Review interfaces allow both parties to rate each other. Payment method selection is integrated into the Quest creation flow.
Milestone: Reputation-Tracked Platform
Farmers and Givers accumulate reputation, progress through ranks, and appear on a public leaderboard. Multiple payment options are available.
Phase 4: NFT Badges and Skills
Goal: Portable credentials via NFT badges and skill system
4.1 Badge Contracts
An ERC-721 Badge contract is deployed with separate minting logic for rank badges and skill badges. Badge metadata is stored on-chain or pinned to IPFS. Minting authorization is gated by the Oracle contract so only users who have earned the rank or skill can mint the corresponding badge.
4.2 Skill System
A Skill registry contract defines skill categories and an initial set of recognized skills. Skill rank is tracked per user and used for Quest filtering. The registry is extensible so new skills can be added via governance without a contract upgrade.
4.3 Badge and Quest Integration
The badge minting interface shows gas estimates and displays minted badges on the user's profile. Skill requirements can be configured by Givers at Quest creation. The completion flow verifies skill requirements and awards skill progress when a Quest with a skill tag is completed.
Milestone: Portable Credential System
Farmers can mint NFT badges proving rank and skills. Givers can filter Quests by skill requirements.
Phase 5: Advanced Features
Goal: Guilds, benevolent mechanics, disputes, and incentive shares
5.1 Benevolent Mechanics
Helper registration allows users to delegate their Quest rewards to other Farmers or causes. Benevolent status and tier progression are tracked on-chain with corresponding badge minting at each tier. Demonstrated Benevolence tracking ensures delegations are genuine and the Conflict of Interest Limiter prevents abuse.
5.2 Negative Reputation
Sniping detection identifies Farmers who accept and immediately drop Quests without good cause. Malicious dispute activity is tracked separately from legitimate disputes. Negative reputation scores are displayed publicly on profiles and leaderboard entries.
5.3 Guild System
Guild creation deploys a dedicated contract with membership NFTs for each Guild member. Guild Quest acceptance distributes tasks across members and reward splitting is handled automatically by contribution weight. Guilds accumulate their own reputation score and appear on a dedicated Guild leaderboard.
5.4 Dispute Resolution
Either party can initiate a dispute during the Review Window, which pauses payment automatically. The Genesis Creator reviews the dispute and records the resolution outcome on-chain. Reputation impacts are applied to both parties based on the outcome and a timeout handler closes unresolved disputes after a defined period.
5.5 Incentive Shares
The Incentive Treasury contract accumulates 1% of all protocol fees throughout the season. Share calculation runs at season end, weighting contributions by Quest value and completion count. Distributions are sent directly to wallets and the treasury resets for the next season.
5.6 Advanced Quest Features
Competition mode allows Givers to choose between exclusive assignment (first Farmer to complete wins) and open completion (all completing Farmers earn). Farmer rank restrictions prevent under-qualified Farmers from accepting certain Quests. Recurrent Quest scheduling lets Givers set up automatically recurring work. The Preferred Farmer designation lets Givers signal preferred contractors without making a Quest invite-only.
Milestone: Full Feature Set
Guilds, Benevolent mechanics, Disputes, and Incentive Shares are all operational.
Phase 6: Governance and Launch
Goal: Community governance, security audit, mainnet launch
6.1 Community DAO
The Community Treasury contract, Genesis Creator NFT, and Community Share NFTs are deployed. The FQP submission interface lets any community member propose protocol changes. A voting mechanism handles proposal lifecycle and on-chain execution runs approved proposals automatically.
6.2 Governance Integration
Fee adjustment, treasury expenditure approval, and skill registry additions are all governable via FQP. The governance system is tested with a simulated vote cycle before launch to verify proposal execution works correctly end to end.
6.3 Security and Audits
An internal security review covers all smart contracts and API endpoints. An external smart contract audit is commissioned from a reputable firm. Penetration testing covers the frontend and API. A bug bounty program is set up to incentivize responsible disclosure during and after launch.
6.4 Documentation and Polish
User-facing documentation covers Quest creation, acceptance, and payment for non-technical Givers. Developer documentation covers the full API reference, contract ABIs, and deployment guides. UI/UX is polished across all flows with attention to error handling, loading states, and edge cases.
6.5 Deployment
Testnet deployment on Base Sepolia runs a public beta period to collect real-world usage data and surface edge cases. Mainnet contracts are deployed after the beta period closes and the audit report is addressed. Production environment setup covers monitoring, alerting, and incident response. A launch announcement is coordinated across community channels.
Milestone: Platform Launch
Fetch Quests is live on Base mainnet with full functionality.
Post-Launch
After the v1 launch, development continues based on community feedback and governance decisions. Planned improvements include a Master Farmer dispute panel that distributes dispute resolution to top-ranked community members, Agent Farmer features for automated Quest execution, a mobile application, additional L2 deployments to further reduce gas costs, additional payment integrations, and partnership development to expand recognition of Fetch Quests badges in the broader developer ecosystem.