LightChallenge: Trustless AI-Verified Stake Challenges

A Decentralized Protocol for Real-World Achievement Verification and On-Chain Settlement

Version 1.1 — May 2026

TL;DR

LightChallenge is a permissionless protocol where people stake LCAI on personal goals — running 50 km this month, hitting a Dota 2 win-rate, finishing a CS2 ladder — and an AI worker verifies the result on-chain. Winners take the losers’ stakes. There is no judge, no moderator, no platform that can rule against you for opaque reasons. The smart contract pays out automatically.

The protocol runs on LightChain, an EVM L1 with a permissionless AI worker network. We’re the first protocol to use that worker network as a referee for real-world activity. The AI is decentralised, the funds are escrowed in a bucketed contract that we cannot drain, and the verification is dispute-resolvable cryptographically by an independent Lightchain arbiter.

In one sentence: competitive accountability with skin in the game, verified by AI, settled by smart contracts.

1. Introduction

1.1 The Problem

People are bad at follow-through. 92% of New Year fitness resolutions fail. Pickup games dissolve. Casual ladder grinds peter out. The global “accountability market” is $10B+ for a reason — humans need a structure to keep them honest with themselves.

Today three kinds of products try to solve this. Each one has the same fatal flaw: trust.

The first kind has no consequences. The second kind has consequences but you have to trust the platform to call them fairly. The third kind has on-chain payouts but the economics depend on infinite new users — when growth stops, the whole thing folds.

LightChallenge is built on three claims that fix all three problems at once.

1.2 Our Thesis

1. Skin in the game changes behavior. People who put their own money on the line are ~3x more likely to follow through on a goal. The mechanism doesn’t have to be huge — even small stakes flip the psychology.
2. The judge can’t be us. Centralized judges always have a conflict somewhere — disputes resolve in favor of whoever pays the platform’s bills. Verification must be done by something we don’t control. Decentralised AI verification is the first technology that makes this affordable per-judgment.
3. The economy has to be zero-sum, not speculative. When losers fund winners, the system is sustainable forever. When new users fund old users’ rewards, the system is a ponzi waiting to collapse. We pick zero-sum.

These three combine into a fourth claim that is the whole proposition:

A challenge platform where neither the winners’ rewards nor the losers’ losses depend on anyone trusting the platform that runs it.

1.3 The LightChallenge Protocol

LightChallenge is an EVM smart-contract suite (Solidity 0.8.24, deployed on LightChain) plus a thin off-chain runner that bridges LightChain AI worker verdicts onto our verifier contract.

The full lifecycle in one image:

1. Create a challenge          ── "Walk 250k steps in October. 100 LCAI buy-in."
2. Anyone joins                ── Stake locked in a bucketed escrow contract.
3. You submit proof            ── Apple Health / Strava / Steam / Riot / GSI.
4. AI worker verifies it       ── llama3-8b on LightChain. Worker is staked + slashable.
5. Smart contract pays out     ── Winners take the pot. No human in the loop.

Five core contracts make this work. Each is small, has a single responsibility, and was designed to be impossible to use in a way that loses funds:

• Lightchallenge — the protocol entry point. Holds the lifecycle state machine (create / join / submit proof / finalize / claim) and enforces the rules of every challenge. Holds zero funds.
• LightchallengeTreasury — bucketed escrow. Every challenge is its own isolated bucket; no bug in one challenge can touch funds in another. Pull-based claims (we hand out allowances, the user pulls them) means once you’ve earned a payout, no admin action can stop you from claiming it.
• LightchallengeAttestor — bridges the AI verdict on-chain. Multi-of-N signature support; gated by the live LightChain worker registry; per-attestation audit trail of which worker said what.
• LightchallengeMetadataRegistry — challenge metadata (title, rules, evidence schema). On-chain pointer + off-chain content for cost.
• LightchallengeAchievement — soulbound NFT trophies (ERC-721 + ERC-5192). Non-transferable proof of completion.

Three more contracts handle adjacent concerns: a multi-outcome event router for ladder/bracket challenges, an EIP-2771 trusted forwarder for gasless flows, and a 2-of-3 multi-sig wallet that custodies the protocol fee bucket. They follow the same single-responsibility principle.

You can read each contract on the GitHub repo or audit them yourself — the build is bit-for-bit reproducible (pragma 0.8.24 pinned, optimizer 200 runs, bytecodeHash: "none").

2. Protocol Design

2.1 Challenge Lifecycle

Every challenge follows a deterministic state machine with three terminal states:

                  createChallenge()
                        │
                        ▼
                     Active
                    (Outcome.None)
                   /    │    \
                  /     │     \
    cancelChallenge()   │   finalize() [after endTime + proofDeadline]
         │              │         │
         ▼              │         ▼
      Canceled          │    Finalized
   (full refund)        │   (Success if winners exist,
                        │    Fail otherwise)
                        │
              submitProofFor / submitMyProof
              [startTs .. proofDeadlineTs window]
              → marks verified winners

Timing parameters govern the challenge lifecycle:

creation ──── joinClosesTs ──── startTs ──── endTime ──── proofDeadlineTs
   │              │                │            │               │
   │  join window │                │  activity  │  proof grace  │
   │  (open)      │                │  period    │  period       │
   └──────────────┘                └────────────┴───────────────┘
                                   proof submission allowed

• Join window: Open from creation until joinClosesTs (defaults to startTs)
• Activity period: startTs to endTime — when users complete the challenge
• Proof grace period: endTime to proofDeadlineTs — additional time for evidence submission
• Finalization: Only possible after both endTime and proofDeadlineTs have passed

2.2 Staking and Pooling

All funds are held in Treasury buckets, where bucketId = challengeId. Lightchallenge holds zero funds at all times — this is a protocol invariant.

Flexible staking: Participants can stake any amount above the global minimum (minStake). There is no fixed buy-in. Distribution is proportional to contribution, making the protocol accessible regardless of stake size.

Pool accounting:

• pool = sum of all participant contributions
• winnersPool = sum of contributions from verified winners
• losersPool = pool - winnersPool (computed at finalization)

Contributions are additive — a participant can increase their stake by joining multiple times, increasing both their exposure and potential reward.

2.3 Fee Architecture

Fees are configured globally and snapshotted into each challenge at creation time. This prevents retroactive fee changes from affecting existing challenges — a critical trust property.

When a challenge finalizes with at least one loser, the forfeited pool is distributed through a deterministic pipeline:

Losers' Pool (100%)
    │
    ├── Cashback to Losers (10%) ──── retention incentive
    │
    └── Remaining (90%)
         │
         ├── Protocol Fee (5%) ──── LightChallenge revenue
         │
         ├── Creator Fee (5%) ──── incentive for challenge creators
         │
         └── Winner Rewards (80%) ──── distributed pro-rata by contribution

Fee parameters (all in basis points, max 10,000):

Fee caps provide an immutable upper bound. Once set, forfeitFeeBps and cashbackBps cannot exceed the cap values, providing governance assurance that fees will never exceed published limits.

Rounding dust from integer division is assigned to the protocol address. Per-claim dust stays in the Treasury bucket and is recoverable via sweep().

2.4 Payout Distribution

Payouts are computed atomically in _snapshotAndBook() during finalize(). All grants are issued as Treasury allowances — no direct transfers.

Given a challenge with totalPool, winnersPool, and losersPool = totalPool - winnersPool:

Step 1: cashback       = losersPool × cashbackBps / 10000
Step 2: afterCashback  = losersPool − cashback
Step 3: feeGross       = afterCashback × forfeitFeeBps / 10000
Step 4: protocolAmt    = afterCashback × protocolBps / 10000
Step 5: creatorAmt     = afterCashback × creatorBps / 10000
Step 6: dust           = feeGross − (protocolAmt + creatorAmt) → protocol
Step 7: distributable  = afterCashback − feeGross
Step 8: perBonusX      = distributable × 1e18 / winnersPool
Step 9: perCashbackX   = cashback × 1e18 / losersPool

Claim types:

Edge cases:

• No winners (winnersPool == 0): Outcome is Fail. The entire distributable amount routes to the protocol. Losers still receive cashback.
• All winners (losersPool == 0): No fees, no distributable. Each winner claims exactly their principal.
• Single participant who wins: Claims their own principal — no bonus since losers’ pool is zero.

3. Treasury Architecture

Treasury.sol implements bucketed, claim-based custody using OpenZeppelin AccessControl. It is designed around four properties:

3.1 Bucketed Isolation

Every challenge has its own bucket (bucketId = challengeId). Funds in one bucket cannot be used for another. This means a bug in one challenge’s payout logic cannot drain funds belonging to other challenges — a critical safety property that eliminates systemic risk.

3.2 Operator Grants

Lightchallenge holds OPERATOR_ROLE on the Treasury. During finalization, it calls grantETH(bucketId, to, amount) to create allowances for winners, losers (cashback), creators, and the protocol.

3.3 Pull-Based Claims

Recipients call claimETH(bucketId) on the Treasury directly. Once an allowance is granted, no admin action can prevent the claim. This provides unstoppable withdrawal guarantees — even if Lightchallenge is paused or compromised, existing allowances remain claimable.

3.4 Sweep Safety

The SWEEPER_ROLE can only recover truly free funds:

free = onchainBalance − outstandingAllowances − totalBucketBalances

Active challenge funds and pending claims are always protected. The sweep function cannot touch allocated funds under any circumstances.

3.5 Accounting Model

                ┌──────────────────────────┐
 deposit() ────→│  bucketBalance[id] (+)   │
                │  totalBucketBalance (+)  │
                └──────────┬───────────────┘
                           │
                     grant()
                           │
                ┌──────────▼───────────────┐
                │  bucketBalance[id] (−)   │
                │  allowanceOf[id][addr](+)│
                │  outstanding (+)         │
                └──────────┬───────────────┘
                           │
                     claim()
                           │
                ┌──────────▼───────────────┐
                │  allowanceOf[id][addr](−)│
                │  outstanding (−)         │
                │  → ETH transfer to addr  │
                └──────────────────────────┘

4. AI Verification: Proof-of-Intelligence

LightChallenge is a client of the Lightchain AIVM network. We submit inference requests and consume finalization events. We do not operate worker or validator nodes — verification is performed entirely by independent Lightchain network participants.

4.1 Why Decentralized AI Verification?

Traditional challenge platforms use one of three verification models:

LightChallenge uses Proof-of-Intelligence (PoI) consensus — a novel verification model where independent AI workers process evidence, commit to results cryptographically, and validators attest to correctness before results are finalized on-chain.

4.2 Evidence Pipeline

The verification pipeline transforms raw user activity data into cryptographically verified on-chain proofs through eight phases:

Phase 1 — Evidence Collection Users submit fitness or gaming data through the iOS app, web app, or API. Supported data sources:

Evidence is normalized by adapter-specific ingestors and stored with cryptographic hashes for integrity.

Phase 2 — Evidence Evaluation The evidenceEvaluator worker runs the appropriate evaluator (fitness or gaming) against challenge rules. The result is a verdict — pass or fail with detailed reasons and a score — stored in the database.

Phase 3 — Per-Participant Dispatch The challengeDispatcher queues one aivm_jobs row per (challenge_id, passing-verdict participant) pair (UNIQUE constraint enforced since migration 050_aivm_jobs_per_participant.sql). A challenge with multiple joiners produces multiple independent jobs that run in parallel.

Phase 4 — Single-Pass Run The challengeWorker claims jobs by (challenge_id, subject) and calls runLightchallengeLightchainJob, which performs three steps for the participant being verified:

1. Judge — judgeChallengeViaLightchain(...): SIWE auth to gateway → assigned worker → ECDH-encrypted relay → AES-GCM verdict decrypt
2. Attest — LightchallengeAttestor.attest(challengeId, subject, jobId, jobCompletedTx, responseHash, ciphertextHash, worker, true)
3. Submit proof — Lightchallenge.submitProofFor(challengeId, subject, encodedProof) calls attestor.verify() which reads the row and returns true; c.winner[subject] is set to true on chain

Phase 5 — Finalize and Pay Out After proofDeadlineTs, anyone calls Lightchallenge.finalize(id). The contract’s _snapshotAndBook snapshots winners/losers and books fees. If winnersPool == 0, the entire distributable loser pool is granted to the protocol multi-sig as a Treasury bucket allowance — this is the intentional admin recovery path. The autoDistributeWorker then reads on-chain state, calls autoDistribute(id, winners[], losers[]), and pushes Treasury allowances to recipient wallets.

Phase 6 — On-Chain Proof Verification (attestor.verify)

LightchallengeAttestor.verify() reads the attestation row recorded in step 2 and checks:

1. The attestation row exists for (challengeId, subject)
2. passed == true
3. The proof’s responseHash matches what was attested
4. The proof’s worker matches the attested worker

If any check fails, submitProofFor does NOT mark the participant as winner. The on-chain JobCompleted event from the LightChain worker (emitted by JobRegistry) is the public audit trail anyone can verify against the attested data.

Pre-2026-04-28 architecture (archived). The previous AIVM v1 path used AIVMInferenceV2 + LCAIValidatorRegistry + LightchallengeAivmPoiVerifier + aivmIndexer for a commit-reveal-PoI ceremony. That contract trio remains on chain but is unused; source code archived in .attic/v1-aivm-path/.

4.3 aivm_jobs States

queued → processing → done                          (judge → attest → submitProofFor all succeeded)
                    ↘ rejected                      (LightChain worker returned FAIL; terminal, no retry)
                    ↘ failed → (retry → ) processing  (transient gateway/RPC error)
                              ↘ dead                  (exceeded MAX_ATTEMPTS — manual triage)
                    ↘ canceled                      (challenge reached terminal state before claim)

The runner writes its own done/rejected status — there’s no event-watching indexer in the verification path. Audit trail per participant lives at challenges.proof->'lightchainAttestations'->lower(<address>) (jobId, worker, jobCompletedTx, attestTx, submitProofTx, attestedAt).

5. Security Model

5.1 Fund Safety Invariants

Zero balance in Lightchallenge. All deposits route to Treasury.depositETH() or Treasury.depositERC20From(). Lightchallenge’s address(this).balance should always be zero. Funds are never at risk from Lightchallenge vulnerabilities.

Bucketed isolation. Each challenge’s funds live in a separate Treasury bucket. A bug in one challenge’s payout cannot drain another’s bucket. This eliminates the catastrophic failure mode where a single exploit drains the entire protocol.

Pull-based claims. Treasury allowances are unstoppable: once grantETH(bucketId, to, amount) is called, the recipient can claim regardless of any admin action on Lightchallenge.

Sweep safety. Treasury.sweep() can only touch funds where balance > outstanding + bucketBalances. Active challenge funds and pending claims are always protected.

5.2 Fee Safety

Snapshot at creation. Fee parameters are copied into each challenge struct at createChallenge(). Admin fee changes do not affect existing challenges. This prevents bait-and-switch attacks where a challenge is created under one fee structure and finalized under another.

Underflow prevention. protocolBps + creatorBps <= forfeitFeeBps is enforced at configuration time. The computation losersAfterCashback - feeGross cannot underflow.

Fee caps. FeeCaps provides immutable upper bounds. Once set, forfeitFeeBps and cashbackBps cannot exceed the cap values — even by the admin.

5.3 Access Control

5.4 Challenge Integrity

Verifier immutability. When proofTightenOnly is enabled, the proof deadline can only be reduced, not extended. This prevents rule changes that disadvantage participants after they’ve joined.

Cancel blocked after winners. Once any participant has a verified proof, the challenge cannot be canceled. This prevents creators from canceling challenges to avoid payouts.

Finalize requires deadline passage. No early finalization is possible — block.timestamp >= endTime && block.timestamp >= proofDeadlineTs is required.

Double-claim prevention. Dedicated claimed mappings (winnerClaimed, loserClaimed, refundClaimed) prevent any form of double withdrawal.

5.5 Reentrancy Protection

All state-mutating public functions use OpenZeppelin’s ReentrancyGuard (nonReentrant modifier). Treasury claims follow the checks-effects-interactions pattern.

5.6 Proof Integrity

The database is a staging area. Everything that controls money — proofs, finalization, payouts — is verified against on-chain state, not the database. Even if the database is compromised, on-chain proofs require a LightchallengeAttestor.attest(...) row signed by the rotatable LIGHTCHALLENGE_BACKEND_PK, and that signature is checked at submitProofFor time. The on-chain JobCompleted event from a staked LightChain v2 worker is the public audit trail backing the attestation.

5.7 UI integrity (the on-chain-truth rule)

The webapp lifecycle.ts resolver explicitly ignores verdicts.pass (DB-only, can lag the chain) when an autoDistribute has fired. The label is chosen from claimedTotalWei + chainOutcome in that order — wei that actually moved is the truth. This rule was added after incident #13, where a late evaluator iteration set verdict_pass = true on an already-finalized challenge and the UI flipped to “Reward Sent” despite an on-chain LoserClaimed(amount=0).

6. Achievement System

ChallengeAchievement.sol mints soulbound (non-transferable) ERC-721 tokens implementing ERC-5192.

Properties:

• Soulbound — all transfers revert; locked(tokenId) always returns true
• Claim-based — users call mint(challengeId, achievementType) themselves
• Double-mint protection — minted[challengeId][user][type] prevents duplicates
• On-chain verification — reads Lightchallenge state via ILightchallenge view interface; no admin action required

ChallengeAchievement has a strict one-way dependency on Lightchallenge (read-only). Lightchallenge has no knowledge of ChallengeAchievement.

7. Event Routing

EventChallengeRouter.sol enables multi-outcome event resolution — mapping real-world events (matches, competitions, predictions) to multiple Lightchallenge challenges.

An event contains N outcomes, each bound to a challengeId and a subject address:

Event "Team A vs Team B"
  ├── Outcome 0: "Team A wins" → challengeId=42, subject=0xabc...
  └── Outcome 1: "Team B wins" → challengeId=43, subject=0xdef...

When the real-world outcome is known, the owner calls finalizeEvent(eventId, winnerIndex, proof), which:

1. Calls submitProofFor() on the winning challenge
2. Calls finalize() to settle the winning challenge
3. Losing challenges expire naturally with no winners (Outcome.Fail)

8. Technology Stack

8.1 Smart Contracts

• Language: Solidity 0.8.24
• Framework: Hardhat with hardhat-deploy
• Standards: ERC-721 (achievements), ERC-5192 (soulbound), EIP-2771 (gasless), EIP-712 (typed signatures)
• Security: OpenZeppelin’s ReentrancyGuard, AccessControl, Pausable

8.2 Off-Chain Services

• Runtime: TypeScript on Node.js
• Workers: Polling-based with configurable intervals
• Database: PostgreSQL (Neon) — challenges, participants, evidence, verdicts, AIVM jobs, identity bindings, claims
• Chain interaction: ethers v6

8.3 Web Application

• Framework: Next.js 14 with App Router
• Wallet: wagmi v2, RainbowKit, WalletConnect v2
• Supported wallets: MetaMask, WalletConnect, Coinbase Wallet, Rainbow, Trust Wallet, Phantom

8.4 Mobile Application

• Platform: iOS (SwiftUI)
• Data collection: Apple HealthKit integration
• Auto-proof: Background evidence submission during active challenges
• Distribution: TestFlight (beta), App Store (planned)

8.5 Deployed Contracts (LightChain Testnet, Chain ID 8200)

9. Economics and Sustainability

9.1 Revenue Model

LightChallenge operates a transaction-fee model that captures value from every challenge resolution. Revenue is protocol-level, enforced by smart contracts, and requires zero manual intervention.

9.2 Unit Economics

Each challenge is a self-contained economic unit with zero marginal cost:

Example: “Run 50km in 2 weeks” (40 participants, $30 avg stake, 45% completion)

9.3 Financial Projections

9.4 Why This Is Sustainable

LightChallenge revenue scales linearly with challenge volume. It does not depend on token price appreciation, new user inflow funding existing payouts, or any speculative mechanism. The protocol earns fees from economic activity, not speculation.

10. Competitive Landscape

LightChallenge sits at the intersection of fitness accountability, prediction markets, and Web3 gaming.

Differentiation:

• Trustless verification — No centralized judge. AI + PoI consensus eliminates disputes by design.
• Fair economics — 5% take rate vs. industry 15–25%. Winners keep more. Losers get 10% cashback.
• Flexible staking — No minimum buy-in barrier. Pro-rata distribution regardless of stake size.
• Multi-category — Fitness and gaming on one protocol, with planned expansion to education, productivity, and any measurable domain.

11. Roadmap

Phase 1: Foundation (Q1–Q2 2026) — Current

• Lightchain testnet deployment (complete)
• iOS app on TestFlight
• Fitness challenges: steps, running, cycling, hiking
• Core integrations: Apple Health, Strava, Garmin, Fitbit
• Seed community of 500+ active users

Phase 2: Growth (Q3–Q4 2026)

• Mainnet launch on Lightchain
• Android app release
• Gaming challenges: Steam, Riot Games, FACEIT
• Creator tools: custom rules, branding, private groups
• Referral system with on-chain rewards
• First sponsored challenge partnerships

Phase 3: Scale (2027)

• Corporate wellness partnerships (B2B)
• White-label API for fitness apps and platforms
• Tournament and competition engine
• Cross-chain deployment (Ethereum L2s)
• Premium features and subscription tiers
• Target: 5,000+ monthly challenges

12. Gasless Transactions

TrustedForwarder.sol implements EIP-2771 meta-transaction relay, enabling gasless user interactions. Users sign transactions off-chain; a funded relayer submits them on-chain, paying gas fees on behalf of users.

Lightchallenge’s _msgSender2771() extracts the original sender from the calldata tail when the call comes from the trusted forwarder. This enables complete gasless onboarding — users can join challenges without holding native tokens for gas.

Status: Deployed and integrated. Pending relay service configuration for production use.

13. Conclusion

LightChallenge introduces a new primitive: trustless, AI-verified stake challenges with autonomous on-chain settlement. By combining Lightchain’s Proof-of-Intelligence consensus with battle-tested smart contract patterns (bucketed Treasury, pull-based claims, snapshotted fees, 20-check proof verification), the protocol achieves something no existing platform offers:

• Zero trust required — outcomes determined by decentralized AI consensus, not centralized judges
• Zero operational cost — smart contracts handle all settlement, claim distribution, and fee collection
• Zero speculative dependency — revenue comes from real activity, not token price or user growth

The protocol is live on Lightchain testnet with the full pipeline validated end-to-end: evidence submission → AI evaluation → AIVM verification → on-chain finalization → Treasury payout. Every component — from the iOS evidence collector to the 20-check proof verifier — has been tested against real network infrastructure.

We believe accountability should be trustless, rewards should be fair, and verification should be autonomous. LightChallenge is the infrastructure layer where real-world achievement meets on-chain settlement.

Built on Lightchain · Verified by Proof-of-Intelligence · Settled by Smart Contracts