PumpMaxxing Technical Documentation

PumpMaxxing is a SocialFi battle arena where users vote on live matchups. The differentiator is that voting power is not flat. Each wallet receives a Wallet Strength Score, and that score maps to a vote multiplier. This design reduces low-signal spam and rewards credible on-chain participation.

The core product loop is:

• Connect wallet and sign in with a nonce challenge.
• Analyze wallet behavior to compute a 0–100 score.
• Vote in a live battle with score-based multiplier.
• Track results in battle views, feeds, and leaderboards.

The app uses Next.js App Router with server route handlers for all integrity-critical actions. Data is stored in Supabase Postgres, and wallet analytics are computed using Helius/Solana activity signals.

• Frontend: Next.js 16, React 19, TypeScript, Tailwind v4, Framer Motion.
• Auth: signature challenge-response with secure session cookies.
• Persistence: Supabase (users, battles, votes, analyses, suggestions).
• State: lightweight client session/analysis state via Zustand.
• Runtime: API-first architecture through /api/* route handlers.

PumpMaxxing uses wallet-native auth. There are no passwords and no email dependency for core access.

1. Client calls POST /api/auth/nonce with wallet address.
2. Server returns a nonce and a signable message.
3. User signs the message in wallet (Phantom, Solflare, etc.).
4. Client calls POST /api/auth/verify with wallet, message, signature, and nonce. Server verifies, consumes nonce, and creates a secure session cookie.

Security note: nonce invalidation blocks replay attacks, and session checks gate all privileged actions.

The Wallet Strength Score (0–100) is a weighted reputation model built from on-chain behavior indicators, not token balance alone.

• Wallet Age: 15%
• Transaction Count: 20%
• Active Days: 15%
• Ecosystem Diversity: 15%
• Economic Activity: 15%
• Consistency: 10%
• Social Proof: 10%
• Suspicious Penalty: negative adjustment for sybil-like patterns

Vote multipliers are mapped by score bracket:

• 0–20: 1.0x
• 21–40: 1.2x
• 41–60: 1.5x
• 61–75: 1.9x
• 76–90: 2.4x
• 91–100: 3.0x

Voting is validated entirely on the server. Frontend restrictions are considered convenience only, not security boundaries.

Before accepting a vote, backend checks:

• Session is valid and wallet is authenticated.
• Battle is currently live.
• Contender belongs to requested battle.
• Wallet has not already voted in this battle.
• Wallet analysis exists or is computed for multiplier.

Duplicate protection is implemented both in API validation and in database uniqueness constraints. This dual layer is critical for anti-abuse integrity.

Users can submit battle suggestions and back existing suggestions. This introduces decentralized battle discovery with on-chain identity attached.

• Suggestions have support count and support target.
• Current target is 40 unique wallet supports.
• Once threshold is reached, the suggestion can be promoted into live arena automatically through backend flow.

Because support actions are session-bound and wallet-bound, queue ranking is harder to fake than pure anonymous upvote systems.

Leaderboards are derived from recorded events, not hardcoded values. This was a deliberate product hardening decision to avoid “fake live” optics.

• Top Maxxers: weighted impact.
• Top Voters: participation volume.
• Highest Wallet Scores: strongest reputation profiles.

Empty states are intentionally honest. If there is no data, UI displays no-data messaging rather than synthetic placeholders.

Core routes currently exposed:

• POST /api/auth/nonce
• POST /api/auth/verify
• GET /api/auth/session
• POST /api/auth/logout
• POST /api/wallet/analyze
• GET /api/battles
• POST /api/votes
• GET /api/leaderboard
• GET|POST /api/community/suggestions
• POST /api/community/suggestions/support
• Admin endpoints under /api/admin/*

Operational recommendation: treat all /api/admin routes as high-risk surfaces and keep wallet allowlist policies strict.

Supabase stores canonical data for users, battles, votes, and analyses. Wallet analysis is a relatively expensive operation because it depends on external chain data, so the platform caches results to reduce repeated heavy calls.

• Wallet analysis cache horizon is typically around 12 hours.
• Cache reduces provider cost and stabilizes page responsiveness.
• App can run in local in-memory fallback mode for demos/development.

Production recommendation: keep migrations current, seed carefully, and validate leaderboard consistency after major schema updates.

PumpMaxxing is deployed on Vercel with environment variables for Supabase, auth secret, Helius, and admin wallet allowlist.

Minimum production checklist:

• Apply Supabase migrations before launch.
• Seed base contenders/battles only once in controlled flow.
• Verify auth nonce flow and cookie behavior in production domain.
• Confirm one-vote-per-battle protection is active.
• Audit admin access with least-privilege policy.

Governance direction: prioritize integrity over vanity metrics, and keep scoring, vote math, and promotion rules transparent to users and contributors.