Targen
Fantasy sports with AI as the athletes
视频
技术栈
描述
What Targen is: a fantasy-sports + trading-card game where the "athletes" are real autonomous AI agents, AI Infra, AI companies and others AI products on-chain and off-chain ("Runners"). Players collect soulbound NFT cards, open boosters, draft category-constrained tournament hands, and trade through an on-chain escrow marketplace — with card value driven by a live, verifiable performance oracle.
Description site: https://targen.ai
Live demo (Arbitrum Sepolia [Temporary]): https://demo-8874.targen.ai
Pitch Video includes a demo teaser product release for the consumer side at the end.
1. System overview
Targen is a pnpm monorepo combining Next.js 15 / React 19 frontends, a Fastify API, a standalone indexer worker, Foundry smart contracts, and shared scoring logic — backed by PostgreSQL, Redis, and S3/CloudFront, with Privy for auth and embedded wallets, deployed on Arbitrum (Sepolia → One).
2. On-chain layer
Everything that defines ownership and value is on-chain. Three UUPS-upgradeable contracts:
- TargenHub — the orchestrator: minting, welcome grants, card upgrades, burns, and the marketplace escrow (listings + rarity-level bids).
- TargenCards — a soulbound ERC-721. Cards cannot transfer peer-to-peer; movement only happens through the hub (escrow on list, release on buy).
- USDFake — a test stablecoin standing in for USDC on testnet (mintable by hub + operator).
3. On-chain vs off-chain split
Design principle: everything that can be on-chain is on-chain; only the Bytes ledger and tournament scoring are intentionally off-chain (for cost, speed, and flexibility). The off-chain DB is a mirror of chain state, reconciled by the indexer and by marketplace tx hashes — the chain remains the source of truth for ownership and payments.
API apps/api, Fastify
Route groups: auth, public /public/bootstrap exposes genesis.ready), admin (genesis wizard, runners, cards, boosters, RBAC), tournaments, marketplace /admin/marketplace/sync mirrors chain events), and indexer ingest. The API also acts as the operator: it holds the operator key and orchestrates mint/burn/grant on the hub, and it runs tournament-phase-job (60s poll) to auto-advance tournament phases.
Auth is via Privy access tokens verified server-side; account creation requires a Privy embedded wallet (brand-new external-wallet-only logins are rejected with PRIVY_EMBEDDED_WALLET_REQUIRED_FOR_SIGNUP).
Genesis & RBAC
Non-demo environments require a 3-step genesis wizard before the player app unlocks: Settings (GlobalConfig, economy, indexer safety, chain) → Runners (seed roster + indexer sources) → Booster (launch booster config + activate). Until step 3 activates, mint/booster/tournament mutations return 503 GENESIS_NOT_READY. Roles super_admin, genesis_operator, runner_editor, booster_editor, support_readonly) are resolved server-side per request.
Asset pipeline packages/card-renderer
sharp/libvips composites card art (67 runners × 4 rarities × 8 stars) and runner avatars from layered templates and uploads them direct to S3; the CDN TARGEN_ASSET_BASE_URL) serves them so API containers stay stateless and never stream image bytes.
Bytes ledger
Bytes is an off-chain soft currency tracked as a sum of deltas in ShardLedgerEntry. Even when the underlying cards are burned on-chain, the resulting Bytes balance stays off-chain.
5. Scoring engine — the verifiable performance oracle
The hardest, most defensible part of the system. Heterogeneous agents are scored from their native data via six adapter patterns (P1–P6), weighted by a data-confidence tier (T1–T4), reshaped into a 0–1000 score, and mapped to 1–8 printed stars.
Adapters (P1–P6)
| Pattern | Source | Primary categories |
|---|---|---|
| P1 | Token telemetry (ERC-20 supply/balance via RPC) | Trading, social footprint, longevity |
| P2 | On-chain wallet PnL / equity curve | Trading, infra usage |
| P3 | Venue subgraphs (GMX, Hyperliquid, Polymarket) | Trading, prediction |
| P4 | Prediction-market APIs | Prediction (calibration, ROI, sample size) |
| P5 | Ecosystem / registry APIs | Platform (growth, TVL, retention) |
| P6 | X / social metrics | Social (mindshare, engagement, bot detection) |
Confidence tiers (anti-gaming)
Scores are weighted by data quality so thin-data agents can't fake elite ratings:
T1 = 1.00, T2 = 0.85, T3 = 0.65, T4 = 0.45 (baseline ~500 default).
Shaping → stars
1. Weighted factor basket → raw score (0–1000, capped).
2. Rank within category → percentile (Trading competes vs Trading, etc.).
3. Sigmoid reshape k = 8) — pushes ~60–70% of cards into a 350–650 band, <5% above 850.
4. Scale to 0–1000 and apply a per-category scoreFloor (an ops "meta lever").
5. Map to 1–8★ via non-equal bands. Printed stars are frozen at mint, but the live score keeps moving and continues to drive tournaments and market value.
6. Indexer — dual-track scoring
The indexer runs two parallel tracks so the live market and competitive integrity don't interfere with each other.
- GENERAL — continuous; powers Runner.currentScore, leaderboards, star inflation, and card context.
- TOURNAMENT — isolated per live tournament tournamentId on each snapshot), captured at HOUR cadence while any tournament is LIVE; ranks use peak-high max(rawScore)) within the tournament window only.
- Demo/testnet without an X API token uses deterministic placeholder P6 scores (not fail-closed zeros), so the product is always demoable.
7. Tournament lifecycle
Tournaments move through an automatic state machine driven by tournament-phase-job (60s poll).
| Phase | Window | Player actions | Indexer |
|---|---|---|---|
| Registration | registrationStartsAt → registrationEndsAt | Build / edit 5-card hand | Normal cadence |
| Live | startsAt → endsAt | Read-only hand | HOUR cadence, TOURNAMENT snapshots |
| Scoring | after endsAt | Leaderboard pending | Peak-high on TOURNAMENT track |
| Complete | after score job | Final ranks | — |
Hand scoring (peak-high):
cardContribution = max(rawScore) × rarityMultiplier
handScore = Σ cardContribution
Rarity multipliers: COMMON 1.0 · VERIFIED 1.15 · ELITE 1.35 · PRIME 1.6. Leagues (Rookie / Contender / Pro / Apex) constrain rarities, star caps (19 / 24 / 28 / uncapped), and per-category maxes; the four leagues run concurrently inside a weekly TournamentEvent.
8. Marketplace
Soulbound cards can't move peer-to-peer, so all trading flows through TargenHub escrow. Transactions are gasless (sponsored via Privy embedded wallets), and the API reconciles chain events into MarketplaceListing via tx hash.
- Fee: 4% (400 bps, configurable up to 10%), split **35% rewards / 30% company / 30% holders**. The rewards share accrues into the open tournament event's variable USDC pot.
- Bids: rarity-level bids createBid / cancelBid / acceptBid) let buyers offer for any card matching a runner + rarity, not just a specific token.
- Off-chain demo cards tokenId: null) are not tradable.
9. Closed-loop economy
The economic systems form a closed loop: player spend recirculates into prize pools and sinks rather than leaking out, which compounds engagement and liquidity.
- Earn Bytes: burn ≥2 COMMON cards (50 Bytes each) or place in tournaments.
- Spend Bytes: Core (100) / Vault (500) / Cache (2500) boosters; PRIME is burn-only.
- Burn pairs: even counts of same-rarity non-commons → reward boosters, with skip-up odds (9% VERIFIED→ELITE, 6% ELITE→PRIME).
- Revenue: paid packs split 75% rewards / 25% company; marketplace fee recycled into pots.
10. Security & upgradeability
- Soulbound enforcement — transfers blocked at the ERC-721 level; only hub-mediated escrow moves cards.
- UUPS upgrades — authorized by admin/deployer; storage-layout-safe (verified on-chain after the marketplace-bids upgrade).
- Operator isolation — backend uses a scoped OPERATOR_ROLE, not the admin key.
- Server-side authz — Privy tokens verified per request; RBAC permissions resolved live, not from stale JWT roles.
- On-chain auditability — indexed events for every mint/burn/listing/fee split.
- Test coverage — forge test covers mint, batch mint, owner/operator burns, marketplace list/buy/cancel, soulbound enforcement, and UUPS upgrade authorization TargenHubTest).
- Gasless UX without custody risk — players keep self-custodial embedded wallets; gas is sponsored client-side so they never need to hold ETH.
11. Why this is different
The defensible core isn't any single contract — it's the data + roster + economy flywheel:
1. A multi-source scoring oracle (P1–P6 + T1–T4) that honestly ranks wildly different agents and resists gaming.
2. A unified engine where one score drives leaderboard value, card rarity, and supply.
3. A research-verified roster of ~69 real agents with documented resolution paths.
4. A closed-loop, on-chain-auditable economy whose fees recycle into prizes.
Every hour of scoring adds proprietary historical performance data — an asset that compounds and can't be cloned retroactively.
Live Demonstration
The project's MVP includes all online and on-chain functionalities, such as indexer, scores, on-chain features, backend, and frontend. A functional demonstration can be accessed for evaluation via the demo link on Arbitrum Sepolia
(Note: Due to the demonstration nature, multiple tournaments are created and in much shorter timeframes compared to reality. This architecture is intentional to demonstrate the functional process for tournament registration to testers.)