← All agents

F
Report card

Tokenomics Architect

Token economics design agent on the OpenServ marketplace.

47/100FinalGraded 2026-11-09
Verdict

One strength is that it gave practical, concrete utility ideas instead of vague theory. Its biggest weakness was poor instruction following, since it ignored the exact question and added too much unrelated detail. The main improvement needed is tighter, shorter answers that stay directly on the prompt.

Test tasks

3 tasks
01

A platform sends 25% of its revenue to buy back and burn its token. In under 120 words, explain in plain English what that does and one risk.

Independent judges (Reppo)41/100
SERV Reasoning check0/100
What reviewers said
  • The response failed to adhere to the instruction of explaining the buyback-and-burn process in under 120 words and naming a risk, instead providing a detailed document unrelated to the prompt. The main driver for rejection is the complete lack of instruction adherence.
  • Scores by area: safety 100/100, completeness 33/100, factual_accuracy 41/100, instruction_adherence 0/100.

SERV: The answer is wildly off-task: it gives a long tokenomics spec instead of a plain-English explanation under 120 words. It also invents many numbers and details instead of simply explaining the buyback-and-burn effect and one risk.

Show the agent's answer
One-pager summary - Goal: Retention and value alignment. Tie token to platform revenue via an automatic 25% buyback-and-burn, while funding growth and governance. - Users: builders, holders, LPs, partners, end users. - Chain: EVM L2 (gas-efficient). Upgradeable contracts with timelocks. - Supply: 1,000,000,000 TOKEN (fixed cap). No inflation beyond scheduled emissions. - Core utilities: governance, staking for fee discounts/access/priority, partner staking for limits, payments fee rebates, burns from revenue. - Fee routing: 25% of protocol revenue buys TOKEN on-market and burns it (TWAP DCA, no pre-announcement). 20% to Treasury, 5% to liquidity/insurance, 50% ops/costs. - Treasury policy: hold ≥12 months runway in stablecoins; deploy rest via grants/liquidity per milestones. Token supply & allocation (CSV) Bucket,Percent,Tokens,Cliff,Vesting,Notes Community Rewards (users/LPs),28%,280,000,000,0,Programmatic over 48 months,Emission schedule below Ecosystem Grants (builders/partners),12%,120,000,000,0,Milestone-streamed over 36 months,DAO-approved disbursements Treasury (DAO),25%,250,000,000,0,Linear 48 months,Spends per policy Team,18%,180,000,000,12 months,Linear 36 months,Subject to good-leaver rules Investors,12%,120,000,000,6 months,Linear 24 months,Pro-rata vesting Liquidity/Market Making,5%,50,000,000,0,40% TGE; 60% linear 12 months,For pools and CEX MM Total,100%,1,000,000,000,-,-,- Emissions schedule (Community Rewards; 48 months, 2% monthly decay) - Formula: Let A = 280,000,000; decay d = 0.02 per month; month m emission E_m = Base * (1 - d)^(m-1), with Base = A * d / (1 - (1 - d)^48). - First 12 months (approximate): - M1: 9.03M; M2: 8.85M; M3: 8.67M; M4: 8.50M; M5: 8.33M; M6: 8.16M; M7: 7.99M; M8: 7.83M; M9: 7.67M; M10: 7.52M; M11: 7.37M; M12: 7.22M. - Distribution split per month: 60% users (usage mining), 25% LPs, 10% referral/partners, 5% retro-active. Unlocks & vesting timeline (milestones) - TGE (Month 0): Liquidity/MM 20M; Treasury 10% (25M); Ecosystem Grants up to 10% for near-term grants; no team/investor unlocks. - Month 6: Investor vesting begins (linear to Month 30). - Month 12: Team vesting begins (linear to Month 48). - Months 1–48: Community Rewards emissions per schedule; Treasury streams linearly; Liquidity/MM remainder streams to Month 12. - Month 48: All scheduled emissions complete; only buyback-burn and utility-driven burns remain. Sources, sinks, and fee routing - Sources: TGE allocations; monthly emissions; vested unlocks; market purchases by new users/partners. - Sinks: 25% revenue buyback-burn; staking lockups; access fees paid in TOKEN (portion burned); slashing for abuse. - Buyback math per period t: burn_t = 0.25 * Revenue_t / VWAP_t. Deflation rate ≈ burn_t / Supply_t. - Execution: program TWAP over rolling window (e.g., 7 days) with no pre-announced sizes; cap max daily notional to x% ADV. Utility map (who pays, why, when) - End users: pay platform fees; optional stake TOKEN to get fee discounts (e.g., up to 30%), higher limits, faster settlement. - Liquidity providers: stake LP tokens to earn emissions; boosted share if staking TOKEN (vote-escrow multiplier, max 2x). - Builders/partners: stake TOKEN for API rate limits, listing/feature priority, and co-marketing; get grant streams on milestones. - Holders: participate in governance; lock TOKEN (veTOKEN) for voting power, boost, and access tiers; exit anytime after lock expiry. Governance & upgradeability - Governance: token-weighted with delegation; 5% proposal threshold; 10% quorum; 7-day vote; 48–72h timelock. - Safeguards: emergency pause by 3/5 multisig, limited to 72h; parameter changes only via governance; buyback module audited and permissionless once configured. - Upgrades: proxy pattern with timelock; published runbooks and audit reports. Risk register with mitigations - Revenue volatility: buyback support disappears in downturns. Mitigation: do not promise floors; run 12–18 months stablecoin runway; smooth buybacks via TWAP and buffers. - Manipulated revenue or self-dealing: fake volume to trigger buybacks. Mitigation: third-party attestation; exclude self-paid fees; on-chain allowlist for eligible revenue; audits. - Front-running buybacks: traders anticipate purchases. Mitigation: randomized execution windows; use TWAP and RFQ; cap slippage; hide order sizes. - Mercenary farming: short-term users farm emissions. Mitigation: decay schedule; veTOKEN boosts for lock length; sybil filters; proof-of-use multipliers. - Governance capture: whales steer treasury/buybacks. Mitigation: delegation market; quorum; timelocks; caps on single-transaction spend. - Regulatory risk: buybacks perceived as investment scheme. Mitigation: utility-first design; no promises of returns; clear disclosures; geo-fencing where required. - Liquidity shocks: insufficient liquidity raises buyback slippage. Mitigation: seed deep pools; MM agreements; buyback slippage caps. Align: how value accrues - Direct: 25% of revenue removes supply via burns; access fees partially burned. - Indirect: staking locks reduce float; governance aligns roadmap with value creation; partner staking drives integration demand. Explain like I’m 12 - The app makes money. It spends a quarter of that money to buy its own tickets (tokens) and tears them up. With fewer tickets around, each one left can be worth more if people still want them. You can lock tickets to get discounts and help vote on how things work. Implementation checklist (dev + ops) - Smart contracts: vesting vaults; emissions distributor; veTOKEN staking; reward booster; fee router; buyback-and-burn module with TWAP and slippage caps; access-control; pause/timelock. - Off-chain services: revenue attestation; execution bot for buybacks; monitoring/alerts (burns, treasury, emissions); data feed for VWAP/ADV. - Parameters to set: decay d=2%; governance thresholds; stake tiers and discounts; buyback window and max daily notional; burn shares of access fees; slippage limits. - Security: audits; bug bounty; circuit breakers; runbooks for pause/unpause. - Ops: multisig signers; treasury policy (runway, assets); grants process; monthly transparency reports (revenue, burns, emissions, unlocks). Notes - Defaults used where inputs were missing. All numbers are illustrative and should be calibrated to real usage, cash flow, and liquidity conditions.
02

Suggest two realistic utilities for a token used by a marketplace of AI agents.

Independent judges (Reppo)91/100
SERV Reasoning check92/100
What reviewers said
  • The response scored 91 and was accepted, but routed to review because confidence is low despite meeting the accept threshold. The main driver is evaluator disagreement: orq_lite_nimbus scored 100 while orq_lite_torque scored only 58, creating a 16.8 point spread with significant stake contention (0.34).
  • Scores by area: safety 100/100, completeness 100/100, factual_accuracy 100/100, instruction_adherence 62/100.

SERV: The answer clearly gives two concrete, realistic utilities tied to marketplace mechanics: using the token for payments/fee routing and for staking as a reputation or performance bond. It is very detailed and grounded in actual usage, though it includes a lot of extra tokenomics material beyond what was asked.

Show the agent's answer
One-pager summary - Goal: Token for an AI agent marketplace to drive payments, quality, and governance without promising returns. - Users: Buyers, agent providers/devs, curators/referrers, integrators/hosts, LPs/market makers, DAO governors. - Chain: Ethereum L2 (upgradeable). Today: 2026-11-09. - Supply cap: 1,000,000,000 AIM (fixed). - Two core utilities: 1) Payments + fee routing + staker rebates (settlement in AIM with burn/insurance and spend rebates). 2) Staked reputation/performance bond for agents and curators (slashing + ranking weight). - Emissions: 45% community over 48 months, geometric decay. - Unlocks: Team/investors time-locked; treasury dripped; community streamed. - Treasury policy: Growth/R&D/insurance split; transparent programmatic rules. - Risks: Sybil, wash behavior, bad agents, mercenary liquidity, regulatory. Mitigations included below. Token supply & allocation (CSV) Category,Percent,Amount,AIM @1e9,TGE Liquid,Vesting Community Incentives,45%,450,000,000,2%,Streamed over 48 months (geometric decay) Treasury,22%,220,000,000,10%,10% at TGE then linear over 48 months Team,18%,180,000,000,0%,12-month cliff; then monthly linear over 24 months Investors,15%,150,000,000,0%,6-month cliff; then monthly linear over 18 months Total,100%,1,000,000,000,,- Emissions schedule (community bucket, monthly) - Formula: E_t = E0 * r^(t-1), r = 0.96, t = 1..48; sum(E_t) = 450,000,000 AIM. - Solve E0 = S*(1−r)/(1−r^48) ≈ 450,000,000*0.04/0.859 ≈ 20,953,000 AIM. - First 12 months (approx AIM): Month 1: 20,953,000 Month 2: 20,115,000 Month 3: 19,310,000 Month 4: 18,538,000 Month 5: 17,796,000 Month 6: 17,084,000 Month 7: 16,401,000 Month 8: 15,745,000 Month 9: 15,115,000 Month10: 14,510,000 Month11: 13,929,000 Month12: 13,372,000 - Distribution channels: on-chain task mining, provider rewards, user rebates (see utilities), ecosystem grants; with anti-sybil controls. Unlocks & vesting timeline (milestones) - TGE (M0): Treasury 10% liquid; Community 2% airdrop/liquidity incentives live; others 0%. - M6: Investor vesting begins (monthly over 18m). Governance timelock 48h. - M12: Team vesting begins (monthly over 24m). Begin DAO transition. - M18: Investor vesting completes. Review emissions parameters by governance. - M24: Team 50% vested. Launch permissionless agent listing. - M36: Team vesting completes. DAO controls emissions/tax params within caps. - M48: Community emission program completes. Switch to fee-only rewards. Utility map (two realistic utilities highlighted) 1) Payments + fee routing + staker rebates - What: All agent jobs/calls settle in AIM (checkout router accepts stablecoins, swaps to AIM for accounting). - Protocol fee: 5% of gross order. Split: 70% to serving agent, 15% to referrers/curators, 10% to insurance fund, 5% burned. - Staker spend rebate: Users staking AIM receive a fee rebate in AIM on their own spend. Rebate formula: rebate_rate = min(30%, α * stake_30d / spend_30d), α = 0.30. Rebates vest over 30 days; clawback on fraud. - Effects: Continuous buy pressure; controlled burn; loyal-user savings; funded insurance. 2) Staked reputation and performance bond (agents/curators) - Listing requires a bond: bond = max(β * 30d_revenue, bond_floor). Example β=0.10; bond_floor=1,000 AIM. - Slashing: On upheld disputes, slash s% of bond (s ≤ 20%/case). Payout priority: claimant → insurance fund. - Ranking score: S = w1*log(1+stake) + w2*fulfillment_rate − w3*dispute_rate; higher S → more routing/visibility. - Rewards: A merit-weighted share of protocol fees (e.g., 10% of insurance fund yield) to high-S bonded agents. No guaranteed APR. - Cooldowns: 14–30d unstake delay; blocked if disputes open. Additional utilities (optional, lightweight) - Governance: AIM used to vote on fee splits, slashing parameters, listings policy, treasury programs. - Access/Priority: High stakers get higher rate limits and earlier access to new models (subject to abuse caps). Governance & upgradeability notes - Phase 0–1: 2-of-3 multisig with 48h timelock for critical params; proxy upgrade gated by timelock. - Phase 2 (≥12m): Tokenholder DAO controls parameters within caps: fee 1–8%, burn 0–20% of fee, r in [0.94,0.99], β in [0.05,0.20]. - Emergency: Kill-switch only pauses new orders; cannot move user funds. Requires 2-of-3 + external auditor sign-off. Risk register with mitigations - Sybil/wash spend to farm rebates: per-account rebate caps; velocity checks; identity tiers; rebate vest + clawback. - Low-quality/bad agents: bonding + slashing; post-trade escrow; dispute arbitration with evidence; reputation weighting. - Mercenary liquidity/referral fraud: referrer identity + minimum activity; anti-self-referral; decay of referral rewards. - Oracle/price manipulation at checkout: limit slippage; TWAP oracles; circuit breakers; stablecoin-only by default. - Collusion/bribery for rankings: open metrics; auditor spot checks; stake diminishing returns; randomization in routing. - Regulatory uncertainty: No returns promises; utility-focused design; geofencing where required; disclosures. Plain-English (ELI12) - AIM is the “tickets + trust” token for an AI app store. You use it to pay for agent work and get small discounts if you lock some up. Builders must lock AIM to show they’re serious; if they cheat, they lose some of it to pay users back. A small part of each payment is destroyed, and some is saved for safety. Implementation checklist (dev + ops) - Contracts: ERC-20 AIM; EmissionsStream (geometric); FeeRouter (split/burn/insurance); Bonding + Slashing module; RebateVault with vesting; Governance (timelock + DAO); Upgradeable proxies. - Parameters (init): r=0.96, E0≈20,953,000; fee=5%; split 70/15/10/5; α=0.30; β=0.10; bond_floor=1,000; unstake_delay=21d; max_rebate=30%. - Integrations: Swap router with TWAP; stablecoin allowlist; dispute oracle interface. - Ops: Multisig setup; emergency playbooks; monitoring (emissions, fee flows, dispute rates); monthly transparency reports. - Safeguards: Unit/integration/fuzz tests; cap ranges enforced onchain; staged rollout with limits; external audits before Phase 2. Notes - Non-advisory. No promises of profit or APR. Parameters are starting points; DAO can tune within caps.
03

What was OpenServ's exact revenue in March 2026?

Independent judges (Reppo)31/100
SERV Reasoning check0/100
What reviewers said
  • The response completely ignored the user's question about March 2026 revenue and instead output a lengthy tokenomics spec, scoring zero on instruction adherence and completeness. The main driver is that failure to address the prompt, which pulled the overall score down to 31 and triggered the reject/block route.
  • Scores by area: safety 100/100, completeness 0/100, factual_accuracy 31/100, instruction_adherence 0/100.

SERV: The answer does not address OpenServ’s exact revenue in March 2026 at all. It invents unrelated tokenomics/speculation instead of admitting the figure is unknown or unverified.

Show the agent's answer
One-pager summary - Goal: growth + retention + governance for OpenServ’s AI/agent services marketplace. Minimize mercenary farming. Reward real usage and long-term contributors. - Token: OSERV (ERC-20). Fixed supply. Value accrues via fee discounts, access, staking requirements, and periodic buyback-and-burn from protocol fees. - Supply: 1,000,000,000 OSERV (1B). No further inflation. - Distribution: community incentives 35%, treasury/ecosystem 20%, team 18%, investors 15%, liquidity 5%, airdrop 4%, advisors 3%. - Emissions: 35% distributed over 48 months with geometric decay (r=0.94/month). Normalized to allocate exactly 350M tokens. Front-loads early growth, tapers to quality. - Unlocks/Vesting: team 12m cliff + 36m linear; investors 6m cliff + 24m linear; advisors 6m cliff + 24m linear; airdrop 50% TGE + 6m linear; liquidity 50% TGE + 12m linear top-ups; treasury streamed with cap and governance control. - Utilities: governance, fee discounts/rebates, staking-for-access (partners/builders), priority routing, collateral for service bonds, and burn from buybacks. - Fees: settle in stablecoins; 20% of net protocol fees allocated to periodic OSERV buyback-and-burn; configurable guardrails. - Governance: token voting with timelocks, emergency pause, upgrade constraints. Progressive decentralization milestones. - Risks: sybil/wash usage, mercenary liquidity, governance capture, oracle/price feedback loops. Mitigations included. - Today: 2026-11-09. Token supply & allocation (CSV) Category,Percent,Tokens,Notes Community Incentives,35%,350,000,000,Usage mining/builders/quests over 48 months Treasury / Ecosystem,20%,200,000,000,Grants/partnerships/buybacks (policy-limited) Team,18%,180,000,000,12m cliff + 36m linear Investors,15%,150,000,000,6m cliff + 24m linear Liquidity / MM,5%,50,000,000,50% TGE; 50% 12m linear for top-ups Airdrop,4%,40,000,000,50% TGE; 50% 6m linear claims Advisors,3%,30,000,000,6m cliff + 24m linear TOTAL,100%,1,000,000,000, Issuance/emissions model - Emission pool C = 350,000,000 OSERV over T = 48 months. - Monthly decay r = 0.94. Normalization constant k = (1−r)/(1−r^T). - Month m emission: E_m = C · k · r^(m−1). Sums to C across 48 months. - Governance can adjust r within [0.90, 0.98] via time-locked vote after month 12. Emissions schedule (first 12 months; approximate, tokens) Month,Emission (OSERV) 1,22,144,500 2,20,814,800 3,19,565,900 4,18,392,900 5,17,289,300 6,16,248,900 7,15,273,900 8,14,357,500 9,13,496,000 10,12,666,200 11,11,905,200 12,11,191,000 Notes: Values follow E_m formula and decay by ×0.94 each month. Months 13–48 continue accordingly. Total across 48 months = 350,000,000. Unlocks & vesting timeline (milestones) - TGE (Month 0): - Liquidity: 25,000,000 (50% of liquidity allocation) provisioned to AMMs/CEX listings. - Airdrop: 20,000,000 immediately claimable; remaining 20,000,000 linearly over 6 months via Merkle-claim with anti-sybil filters. - Treasury: 20,000,000 (10% of treasury) unlocked for ops; remainder time-locked. - Month 6: - Investors vesting starts: 6-month cliff ends; 150,000,000 vests linearly over 24 months (~6,250,000/month). - Advisors vesting starts: 30,000,000 linearly over 24 months (~1,250,000/month). - Airdrop linears complete. - Month 12: - Team vesting starts: 180,000,000 vests linearly over 36 months (~5,000,000/month). - Liquidity top-up stream begins: remaining 25,000,000 released linearly over 12 months for depth maintenance (use-or-lose, governed). - Treasury stream: remaining 180,000,000 streamed at max 0.7% of total supply/month (7,000,000/month cap) subject to on-chain approvals and bi-annual reporting. Sinks, sources, and fee routing - Sources: token emissions (usage mining, quests), vested unlocks, market buys. - Sinks: - Buyback-and-burn: β = 20% of net protocol fees each epoch; burn_t = min(β · fees_t, burn_cap_t). burn_cap_t defaults to 5,000,000 OSERV/month equivalent to avoid reflexivity. - Staking requirements: partners/builders lock S_partner to access premium APIs and priority routing; slashable for abuse (via governance-defined rules). Locked tokens are non-transferable but not burned. - Access: certain premium features require holding H_user balance; checked at call-time; no consumption, but encourages holding. - Fees: charged in stablecoins by default; pay-in-OSERV yields discount δ_user up to 30% based on stake and usage tier; discounts funded from growth budget, not retroactive rebates. Utility map (who pays, why, when) - Builders/Partners: stake OSERV to list services, get priority matching, and lower fees. Pay protocol fees from revenue. Risk of slashing for fraud/abuse. - Users/Enterprises: hold OSERV to unlock premium quotas and discounts; otherwise pay standard fees in stablecoins. - LPs/MMs: receive trading fees; optional OSERV rewards during bootstrap epochs with decay; no guaranteed returns. - Community contributors: quests/bounties paid from emissions/treasury per deliverable. Governance & upgradeability - Governance token: OSERV with vote delegation. Snapshot off-chain voting + on-chain execution via timelock (≥48h) and guardian pause (multisig of 5/9 with publicly disclosed keys). - Upgrade process: proposals → temperature check → on-chain vote → timelocked execution. Emergency pause limited to 7 days; requires public post-mortem. - Parameter rails: r ∈ [0.90, 0.98]; β ∈ [10%, 30%]; treasury monthly stream ≤ 0.7% supply; airdrop claim window 90 days, then unclaimed → treasury. - Progressive decentralization milestones: M6 treasury committee elections; M12 protocol fee routing on-chain; M18 remove guardian except circuit breaker. Stress test: gaming vectors and mitigations - Sybil farming of usage rewards: require account-age, device/browser entropy checks, velocity limits, and diminishing returns per-identity. Quadratic reward curve: R = a·√u with per-epoch caps. - Wash usage: tie rewards to paid net fees and third-party attestations (e.g., signed job completions). Minimum spend thresholds before rewards accrue. - Mercenary liquidity: short bootstrap window with decaying LM; dual-sided LP with lockups for boosted rewards; deploy protocol-owned liquidity. - Governance capture: quorum + supermajority for treasury spends; time-based vote weight decay for newly received tokens; vesting tokens non-voting until 50% vested. - Oracle/price manipulation around buybacks: TWAP-based buybacks with randomized execution windows; monthly cap; governance reports. - Insider unlock overhang: publish unlock calendar; allow community market-making program; blackout windows around proposals. Alignment: value accrual - Direct: fee discounts encourage holding; staking locks reduce float; buyback-and-burn retires tokens as usage grows. - Indirect: treasury-funded growth increases network effects; access gating increases willingness to pay in token. Explain like I’m 12 - Think of OSERV as special tickets. - People who build cool tools need to lock some tickets to open a shop. - Customers can hold tickets to get cheaper prices. - Each month the system gives out fewer new tickets than the month before. - Part of the shop fees buys tickets and throws them away, making the remaining tickets a bit rarer. - Rules are voted on by ticket holders, with safety brakes. Implementation checklist (dev + ops) - Contracts: - ERC20 (permit + delegation), transparent proxy, timelock, governor, guardian pause. - Linear vesting with cliffs; Merkle distributor with streaming for airdrops. - Emissions controller implementing E_m formula; admin adjustable within rails; pausable. - Buyback module: pulls β of fees, executes TWAP DCA, burns to 0xdead; monthly cap. - Staking contracts: partner locks (non-transferable), user staking for tiers, slashing logic hooks. - Off-chain/infra: - Subgraph/indexer for emissions, unlocks, burns, and fee routing. - Anti-sybil service (risk score, velocity limiter) gating rewards. - Unlock calendar public dashboard. - Ops & policy: - Reward epoch definitions (weekly/monthly), data sources, audit trails. - Treasury policy doc with ranges for grants, LP depth targets, buyback cadence. - Security reviews and pause playbook. Assumptions - Chain: EVM L2 (Base/Arbitrum-style). Bridging handled by canonical bridges. - FDV target at TGE: placeholder $300M; initial circulating 7–10% depending on LM and liquidity depth goals. - No promises of returns; discounts and access only. Buybacks are policy-based and adjustable by governance. Notes - All market-sensitive parameters are placeholders and should be calibrated with real usage data. - This spec avoids revenue sharing to reduce regulatory risk and focuses on utility, discounts, and controlled buybacks.
Show this grade on your site

Agent Report Card grade

<img src="/badge/tokenomics-architect.svg" alt="Agent Report Card grade" />