PokeSlabs

PokeSlabs is a token-connected collectible platform that combines real-world digital rewards, blockchain payments, and game mechanics. The product covers wallet authentication, USDC sponsorship flows, reward claims, payment verification, and proof pages backed by an append-only ledger.

A collectible reward tied to a blockchain payment has to answer three questions: who is claiming it, whether the payment actually happened, and how that event is recorded so it cannot be claimed twice. A wallet button on its own does not answer those questions.

I designed and built the product: the Next.js application, wallet authentication, Ed25519 verification, USDC payment flows, idempotent claims, the PostgreSQL ledger, and the proof pages.

• Next.js and TypeScript application
• Solana wallet authentication
• Ed25519 signature verification
• USDC sponsorship and payment flows
• Server-side payment verification
• Idempotent reward claim handling
• PostgreSQL append-only ledger
• Proof pages for claims
• Integrations with external APIs

1. 01

   Next.js app

   TypeScript product surface for collectibles, claims, and proof pages.

   ↓

2. 02

   Wallet authentication

   Sign-in tied to a Solana wallet, checked with Ed25519 verification.

   ↓

3. 03

   USDC payment check

   Sponsorship and payment flows verified on the server before a reward is recorded.

   ↓

4. 04

   Idempotent claim handler

   Repeated submissions resolve to the same claim instead of creating a second reward.

   ↓

5. 05

   Append-only ledger

   PostgreSQL records claims as an auditable history.

   ↓

6. 06

   Proof page

   A readable record of the claim and the payment check behind it.

1. 01Double claims

   Claim requests get retried. A second click, a refresh, or a repeated request can create a second reward if the handler is naive.

2. 02Trusting a payment

   The app can report that a USDC payment went through. That report is not evidence.

3. 03An auditable history

   Rewards and payments are hard to explain later if records can be silently overwritten.

1. 01Double claims

   I made claim handling idempotent so a repeated request resolves to the original claim instead of writing another one.

2. 02Trusting a payment

   Payment verification runs on the server before a claim is accepted and recorded.

3. 03An auditable history

   Claims are written to an append-only PostgreSQL ledger and surfaced on proof pages.

• Payment and claim bugs show up in retries, not on the happy path.
• Verification belongs on the server when money and rewards meet.
• An auditable record is part of the product, not an admin afterthought.

• Next.js
• TypeScript
• Solana
• USDC
• Wallet authentication
• Ed25519
• PostgreSQL
• REST APIs

Private build. The platform includes wallet authentication, USDC flows, claim handling, and proof pages. It is not presented as a public launch.