DEV Community: Papa

Sportwarren - Rec Football Gets Its Intelligence Layer

Papa — Mon, 08 Jun 2026 06:59:20 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

SportWarren is a tactical command center for recreational football — the 5-a-side, 6-a-side, Sunday league kind that hundreds of millions of people play every week and that has, until now, left absolutely no trace.

You play every week. You score goals. You build chemistry with the same five people over years. And then the final whistle goes and none of it happened. No stats, no record, no reputation. Rec players are invisible.

SportWarren fixes that. Set your formation, put your squad on the pitch, share a challenge link to the group chat — and every matchday becomes verified stats, XP, and permanent squad history. Six attributes per player (pace, shooting, passing, dribbling, defending, physical) that actually evolve with every game. AI coaches that give you tactical banter and real analysis. Group verification via Telegram or WhatsApp so results are confirmed by the people who were there.

But the piece that makes this more than a stats tracker — and the piece that was entirely missing from the hackathon prototype — is the agentic commerce layer. There are two payable units baked into SportWarren now, both settled via x402 and USDC on GOAT Network's Bitcoin-secured infrastructure:

AI scouting reports (0.005 USDC) — an agent analyses your squad's attributes, form, and tactical tendencies and returns a structured breakdown
Match verification attestations (0.10 USDC) — once a result clears group confirmation via Telegram or WhatsApp, an agent produces a signed on-chain attestation of the verified outcome

The social layer is the integrity layer in SportWarren — group verification is what separates real stats from self-reported ones — and turning that verification into a purchasable on-chain attestation makes the commerce primitive inseparable from the core product mechanic. You're not paying for a feature. You're paying to make your match permanently true.

That's the Kite AI Agentic Commerce track in a sentence: rec football as an entry point into agent-native payments. Unglamorous use case, real economic primitives.

Built in collaboration with @udirobert · Find me on Farcaster · Lens

Demo

🔗 Live app: sportwarren.com
📦 Repo: github.com/udirobert/sportwarren
📱 Telegram bot: t.me/sportwarrenbot

The Comeback Story

The honest state of SportWarren before the Kite AI hackathon: everything was scattered. The tactics board existed but the challenge flow was broken. The player cards rendered but XP didn't update correctly after matches. The group verification system — the mechanic that makes stats trustworthy, not self-reported — was stubbed out. And the AI layer was a collection of disconnected pieces that didn't form a coherent loop.

Most critically: there was no agentic commerce layer at all. The verification system existed in fragments but wasn't connected to any on-chain settlement. The AI analysis ran and returned results into a void — no identity, no payment, no record.

The Kite AI Global Hackathon — and the support from GOAT Network's builder grants program — gave this a forcing function. Kite's agentic commerce track is specifically designed for agents that discover, pay, and manage via x402 and programmable constraints settled on-chain. The natural fit turned out to be verification: a squad logs a result, the group confirms it, and an agent produces a signed attestation someone pays for. That loop didn't exist before. Here's what actually got built and fixed:

The core loop stabilised. Formation setup → challenge link → opponent counter-pick → simulation → result logging → group verification. All five steps now work end-to-end without broken states or dead ends.

XP and player progression wired up correctly. Six attributes now actually update after every logged match. The progression curve — slower at higher levels, volatile early — is tuned to feel like a real career arc rather than a grind.

Group verification shipped. Squadmates can now confirm or dispute a logged result via Telegram or WhatsApp, with a 6-hour TTL, configurable confirmation thresholds, and silence-as-consent handling. This is what separates SportWarren from self-reported stat apps: the social layer is the integrity layer.

The simulation engine built out. The tactical AI runs opponent formations against each other using Monte Carlo probabilities, and delivers a readable breakdown — not just a scoreline but an explanation of why a 4-1 lost to a 1-2-1.

x402 payment integration on GOAT Network. Two payable endpoints now live: AI scouting reports at 0.005 USDC and match verification attestations at 0.10 USDC, both settled via x402 protocol through GOAT Network's facilitator. The economics are deliberately micro — this is about proving the primitive works at the right layer of the product, not extracting revenue.

Kite AI agent passport + ERC-8004 identity registered. The agent has its own verifiable on-chain identity, making it a first-class participant in the agentic economy rather than a backend function with a webhook.

The project went from a scattered prototype with broken flows to a working app with a genuine on-chain commerce layer. Rec football as a trojan horse for agent-native payments.

My Experience with GitHub Copilot

I used Copilot heavily on SportWarren — both inline autocomplete and Copilot Chat, often switching between them mid-session depending on what the problem needed. Alongside other AI tools in the repo (the codebase reflects a multi-tool workflow), Copilot was the constant thread.

Inline autocomplete earned its keep most on the repetitive but precision-sensitive work: building out the player attribute system, writing the XP calculation logic for different match outcomes, scaffolding the Telegram bot handlers. These are tasks where the pattern is clear but the details matter — getting the attribute deltas wrong would make the progression feel fake — and Copilot's suggestions were consistently close enough that reviewing them was faster than writing from scratch.

Copilot Chat was where the more interesting collaboration happened. The x402 integration on GOAT Network was genuinely new territory — x402 is a young protocol and there's limited prior art to draw from. Walking through the payment flow architecture in Chat, getting hypotheses about where the 402-challenge/response cycle should sit relative to the verification workflow, and debugging EIP-3009 permit handling were all places where Chat provided real signal rather than just plausible-sounding boilerplate.

The other place it proved its worth was verification system design. Group verification sounds simple but has real edge cases: what happens when one player disputes a result the other four confirmed? What's the timeout window? How do you handle silence? Copilot Chat was useful for thinking through the state machine before writing it — catching the cases I'd glossed over before they became bugs.

Between both modes, Copilot was present across most of the meaningful decisions in this build — not leading them, but keeping pace.

Supported by GOAT Network builder grants — Bitcoin-secured infrastructure for the agentic economy.

Find me on Farcaster and Lens — always building at the intersection of AI, emerging markets, and on-chain infrastructure.

OnPoint - curator first AI fashion studio

Papa — Mon, 08 Jun 2026 06:58:35 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

OnPoint is a curator-first AI fashion studio — a multiplatform ecosystem for personalized styling, fashion discovery, and digital ownership.

The pitch in one line: stylists hand customers a branded try-on → polaroid → share → buy loop, and every session generates live retail intelligence on the back end.

The problem OnPoint solves exists at the intersection of two broken experiences. For shoppers, fashion discovery is noisy and impersonal — you scroll endlessly, get generic recommendations, and can't tell if something will work on you before you buy. For retailers and stylists, the data they need (what's missing from the catalog, what competitors are pricing, what customers are actually reaching for) is either locked behind expensive tools or never collected at all.

OnPoint closes both gaps at once. Shoppers get a real-time AI styling session — point a camera at an outfit, get instant coaching overlays, discover matched products, and buy. Stylists and curators get the same flow turned into live GTM intelligence: when a shopper tries on a jersey and the catalog has no match, the agent fires an external_search action. The Python FastAPI bridge (via Browser Use Cloud and Bright Data) searches the open web, extracts competitor pricing, and returns a structured product list — name, price, source URL, image — surfaced as an "Agent Discovery" card. That's the GTM intelligence: not a dashboard, but a structured signal a curator can act on immediately.

The platform also has a meaningful on-chain layer. Each agent has an ERC-8004 identity (Agent ID 9177), an agent wallet on Celo, and session data is stored verifiably via IPFS/Filecoin through Lighthouse.

The stack: Next.js frontend on Netlify, Express API and Python FastAPI agent bridge on Hetzner, multi-chain support across Celo, Base, Ethereum, and Polygon, with AI routing across Venice AI, Google Gemini Live, OpenAI, and AI/ML API.

Demo

🔗 Live app: beonpoint.netlify.app

🔗 Source: github.com/thisyearnofear/onpoint

🔗 Agent identity: 8004scan.io/agents/celo/9177

Key flows to try:

Upload a photo or use your camera for live AR styling feedback
Watch the agent search the open web when the catalog doesn't have a match
Check the retail intelligence panel for product gap and competitor pricing signals
Connect a wallet (RainbowKit) and explore the on-chain agent identity layer

The Comeback Story

OnPoint started as several hackathon projects running in parallel. The core try-on and styling loop worked, but each vertical — Bright Data web intelligence, Auth0 Token Vault, the Celo agent wallet, IPFS storage — had been built and deployed independently. The real finish-up work wasn't adding features; it was making the pieces coherent enough to trust in production.

Here's the specific problem that forced the biggest change: the agent heartbeat was running on Vercel serverless functions with a 60-second execution cap. The platform promised "agent works while you sleep," but the infrastructure couldn't sustain it. Cold starts (~8s) made the heartbeat unreliable, and the stateful loops needed for the Dead Man's Switch simply couldn't run on serverless. The fix — documented in ADR 0001 — was moving stateful agent execution to Hetzner. That required extracting agent-core into a shared package both runtimes could import, which touched every agent endpoint. After the migration, heartbeat latency dropped from cold-start territory to under 100ms on the persistent worker. The autonomous executor now handles nonce management via Redis atomic INCR — no more nonce-dance crashes on retry.

The fraud detection layer is what makes the "agent spends your money" pitch credible. The Dead Man's Switch monitors heartbeat health — miss 3 consecutive check-ins and the agent freezes autonomously. Transactions above $500 require multi-signature approval. Every suspicious pattern (velocity spikes, unusual amounts, rapid large transfers) increments a 0–100 anomaly score that triggers an automatic freeze at 75. Velocity checks cap at 20 transactions per hour. This isn't safety theater — it's the trust infrastructure that lets a shopper hand the agent real spending authority.

The curator primitive came from field feedback. A stylist selling football jerseys needed a toolkit for her customers, not a crypto wallet. ADR 0002 formalized the decision: what a Curator is, what data lives where, what stays out of scope. Writing the ADR clarified that the agent layer should be infrastructure (behind /lab) rather than the hero feature — the curator's brand and storefront stay front and center.

Auth0 Token Vault brought external API credentials (Calendar, Slack, and others) under proper management via RFC 8693 Token Exchange. The agent can now act on behalf of users without those users handing raw API keys to a third party.

Farcaster miniapp frame — the app now launches directly from the Farcaster social layer, which is a meaningful distribution channel for the Web3-adjacent audience OnPoint is built for.

What I'd do differently: I'd have extracted agent-core earlier. The Phase 2 extraction in ADR 0001 was necessary but disruptive — a deployment change became a refactor. I'd also have been more conservative about the chrome extension. It shipped but hasn't been maintained; better to have left it as a future phase than carry the dead code.

My Experience with GitHub Copilot

OnPoint spans more languages and runtimes than most projects its size — TypeScript for the Next.js frontend and Express API, Python for the FastAPI agent bridge, Solidity for on-chain contracts, and shell scripts for deployment. Switching contexts across all of these in a single session is where Copilot earned the most.

The fraud detection tests were a good example. Mocking Redis across 14 scenarios — high velocity, unusual amounts, Dead Man's Switch triggers, multi-sig lifecycle, alert resolution — required thinking through edge cases that hadn't come up in the happy path: what happens when an agent has no prior heartbeat? What about zero-value transactions? Copilot was good at generating the boilerplate mock structure once I'd defined the first two or three cases, which meant I spent my time thinking about the scenarios rather than the scaffolding. The test file became documentation.

Cross-language consistency — when wiring the Python bridge to the TypeScript API, Copilot helped keep interface contracts consistent. It would suggest Python function signatures that mirrored the TypeScript types I'd defined, which caught a handful of mismatches before they became runtime errors.

ADR drafting — this was a surprise. When writing the Architecture Decision Records, Copilot's inline suggestions helped maintain the consistent structure (Context → Decision → Consequences) and often anticipated trade-offs I was about to articulate. The commit references, the "Out of Scope" sections, the migration phases — Copilot helped maintain that discipline across multiple documents without me having to paste a template each time.

Multi-chain wallet integration — RainbowKit + Wagmi + multi-chain configuration has a lot of repetitive ceremony. Copilot handled the per-chain config objects and provider setup cleanly, letting me focus on the ERC-8004 agent identity integration, which was the genuinely novel part.

The honest caveat: the hardest decisions — the Hetzner migration, the curator primitive model, the fraud detection thresholds — Copilot didn't make. Those required working through the product and the trade-offs. What it did was compress the distance between decision and working code, which for a project with this much surface area made a real difference.

Find me on Farcaster and Lens — always building at the intersection of AI, emerging markets, and on-chain infrastructure.