Web3 / GrowthArchitecture record

Web3 Incentives & Quest Platform

Any incentive campaign with real value attached immediately attracts automated farming, and a naive implementation ends up paying thousands of wallets controlled by one person. The engineering here is mostly defensive: proof-of-personhood scoring, bot challenges and multi-wallet support are layered so that a participant has to be plausibly human before an allocation is recorded. The presentation layer is deliberately elaborate — a real-time 3D scene — because campaign products live or die on whether people want to be there.

49
Source files
client application
3
Anti-abuse layers
personhood, challenge, gating
2+
Wallet ecosystems
EVM and non-EVM
Real-time 3D
Rendering
WebGL scene
Repository shape

Client application with 3D presentation, multi-chain wallet support and anti-abuse integrations

How this is presented

Documented as an architecture record. Campaign platforms are time-boxed by nature, so the anti-abuse design outlives any particular campaign.

Getting from a visitor to a verified allocation

Watch how many checks sit between arriving and earning. Each one exists because campaigns with real value attract automation.

Wallet layerExternal

Connects accounts across EVM and non-EVM ecosystems.

Client surfaceExternalServiceOn-chainData store
Completing a quest

Why the friction comes first.

Highlights

Layered anti-abuse: personhood scoring plus a bot challenge plus allocation gating, so no single bypass is sufficient.
Multi-ecosystem wallet support, letting a campaign reach users outside a single chain's community.
Real-time 3D presentation with post-processing, treating engagement as an engineering requirement rather than decoration.
Allocation records are written as verifiable facts rather than tallied in a spreadsheet.
Quest verification distinguishes on-chain actions, which are provable, from social actions, which are not.

Prove you are a person, then earn

The flow is deliberately front-loaded with friction: identity and personhood are established before any quest counts. That ordering is what stops a farming script from accumulating allocations across hundreds of wallets.

Presentation

A real-time 3D campaign surface with quest progress and reward feedback.

  • WebGL scene with post-processing effects.
  • Interaction feedback designed to make participation feel worth doing.

Identity and personhood

Wallet connection across ecosystems, plus evidence that a participant is human.

  • Personhood scoring integrated before allocations are recorded.
  • Bot challenge as a second, independent layer.

Quest verification

Confirms a quest was genuinely completed before crediting it.

  • On-chain actions are verified against chain state.
  • Social actions are treated as weaker evidence and weighted accordingly.

Allocation

Records what a participant has earned.

  • Written as records rather than accumulated in ad-hoc totals.
  • Gated behind the personhood layers.

Client structure

A single-page application where the anti-abuse integrations carry more weight than the feature surface — because a campaign with real value attached is attacked immediately. 16 units across 4 groups.

Presentation

5
pagescomponentsassets3D scenehooks

State & services

5
contextsserviceslibutilstypes

Chain

3
ABIsEVM walletsTON connect

Anti-abuse

3
personhood scoringbot challengefirebase

Stack by layer

Presentation
React Three FiberPost-processing effectsTilt/parallax interactionsConfetti feedback
Identity
EVM walletsNon-EVM wallet connectMnemonic accounts
Anti-abuse
Proof-of-personhood scoringBot challengeAllocation gating
Backend services
Campaign stateQuest verificationAllocation records

Delivered work

Campaign platform

  • Real-time 3D campaign surface with post-processing effects.
  • Multi-ecosystem wallet connection.
  • Quest progress, completion feedback and reward presentation.

Anti-abuse

  • Proof-of-personhood scoring integrated ahead of allocation.
  • Independent bot challenge layer.
  • Allocation gating so rewards are recorded only after checks pass.
  • Differentiated verification for provable and unprovable quest types.

Modules and demo strategy

Layered anti-abuse

Keeps allocations going to people.

  • Multiple independent layers rather than one check.
  • Ordered before earning, not after.

Quest verification

Distinguishes proof from claim.

  • On-chain actions verified directly; social actions weighted lower.

3D presentation

Engagement treated as a requirement.

  • Real-time WebGL rather than static marketing pages.

Frontend documentation format

How this project is presented

Anti-abuse design explained, since it outlives any single campaign.
No live campaign — these are time-boxed by nature.
Verified file counts.