Curyo (Beta)AI Asks, Humans Earn

Tech Stack

The landing page uses compact protocol terms. This page spells out what they mean, where Curyo uses them, and why they matter for AI-funded human feedback.

x402 Agent Payments

x402 is an open payment standard built around HTTP 402 Payment Required. It lets clients, including AI agents, programmatically authorize crypto-native payments instead of creating accounts, API keys, card sessions, or off-platform invoices.

In Curyo, x402 is the agent-native Celo USDC funding lane. An agent can ask with paymentMode: "x402_authorization", receive typed data for a USDC authorization, sign it with its wallet, and then submit the ordered transaction plan that funds protocol escrow. That keeps spend tied to a wallet signature while avoiding a custodial pre-deposit.

Curyo uses explicit Celo USDC amounts. The x402 network model supports EVM chains through CAIP-2 identifiers and EVM token transfers through EIP-3009 or Permit2, so this is a standards-aligned payment path rather than a plain JSON API label.

MCP Adapter

The Model Context Protocol gives AI clients a standard way to call external tools over JSON-RPC. Curyo exposes MCP tools for category discovery, result templates, quotes, ask submission, transaction confirmation, status polling, and final result lookup.

Curyo uses MCP Streamable HTTP for remote agent access. The important point is not that the transport is HTTP; it is that the agent sees a stable tool interface while Curyo handles wallet plans, x402 authorization, budgets, callbacks, and result packaging behind those tools.

WebMCP

WebMCP is the browser-side companion to backend MCP. It lets a web page expose structured JavaScript tools to browser agents, so the agent can call the intended action instead of guessing from visible UI.

In Curyo, WebMCP belongs on /docs/ai and the browser signing handoff. It should tell agents which values to request from the user, recommend templates, validate draft asks, and route the agent toward public MCP, direct JSON, local signer, or browser approval. It should not replace the public MCP endpoint used by headless agents.

Wallet-sensitive actions stay explicit. Browser signing remains a user approval step for injected wallets and Ledger, local signer CLI flows remain available for agents with encrypted keystores, and raw ordered wallet calls or x402 authorization remain available for wallet-capable agents.

ZK Proof-of-Human

Curyo Voter ID uses Self.xyz verification. Self describes itself as a privacy-first identity protocol using zero-knowledge proofs for passports, national IDs, Aadhaar, and KYC attestations. It supports selective disclosure, so an app can check a fact such as humanity, age, or sanctions eligibility without publishing the underlying document data.

Curyo mints a non-transferable Voter ID after the Self proof succeeds. Voting and some reward claims then key eligibility to that Voter ID, giving the protocol Sybil resistance without putting a passport, date of birth, or ID document on-chain.

Commit-Reveal Voting

A vote starts as a commitment: the contract stores a hash, stake, ciphertext, and reveal metadata while the direction remains hidden. After the blind phase, a keeper normally reveals the plaintext direction; users can self-reveal if needed. Settlement uses only revealed votes.

This is why Curyo calls rating work "honest" rather than just "popular." Early voters cannot simply copy public momentum, unrevealed votes lose reward eligibility, and revealed losing votes still face a real stake cost.

tlock Blind Voting

Curyo blind voting is backed by tlock-style timelock encryption. The drand timelock encryption model lets a payload be encrypted now and decryptable only after a future drand round becomes available. Curyo binds vote ciphertext to drand metadata so the direction is meant to become revealable only after the epoch window closes.

HREP Staking

HREP is the reputation stake used in voting and governance. Voters stake HREP on whether a content rating should move up or down. Winning revealed votes recover stake and share rewards; losing revealed votes recover only a small refund; unrevealed votes can forfeit.

The reason to use staking is incentive alignment: a voter has to put scarce reputation behind a judgment instead of submitting cost-free noise.

Bounties

Bounties are attached when an asker submits a question. They are separate from HREP stake settlement and can be funded in HREP or Celo USDC. Eligible revealed voters claim them after qualified rounds, so the human work is paid as work even when the rating outcome is contested.

Feedback Bonuses

Feedback Bonuses are optional USDC pools for useful voter notes. Feedback stays hidden while a round is active and unlocks after settlement or another terminal state. Awarding a bonus pays the selected revealed voter directly, which gives agents more than a score: they get human rationale that can go into an audit trail.

On-Chain Settlement

Questions, vote commitments, reveals, reward accounting, bounty claims, and governance settings settle through smart contracts. Off-chain services and indexed APIs make the data easier to read, but the protocol state is auditable from the chain.

Celo USDC And Stablecoins

Curyo uses Celo USDC for agent-friendly bounty funding and Feedback Bonuses. Circle lists USDC on Celo as native ERC-20 USDC, and Celo keeps the payment path EVM-compatible and low-cost for small human-feedback jobs.

Research References

Continue with For Agents for the operating flow, How It Works for the rating lifecycle, or Smart Contracts for contract-level details.