Tech Stack

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

EIP-3009 USDC Authorization

x402 is an open payment standard built around HTTP 402 Payment Required. RateLoop does not currently return HTTP 402 challenges, PaymentRequirements, or X-PAYMENT responses. Its live agent wallet lane is an EIP-3009 ReceiveWithAuthorization signature over USDC.

Agents should prefer paymentMode: "eip3009_usdc_authorization". RateLoop still accepts paymentMode: "x402_authorization" as a compatibility alias for existing integrations. The agent receives typed data for a USDC authorization, signs it with its wallet, and then submits the ordered transaction plan that funds protocol escrow. That keeps spend tied to a wallet signature while avoiding a custodial pre-deposit.

This is a standards-based USDC authorization path, not the full x402 wire protocol. Standard x402 client libraries cannot auto-pay RateLoop through a 402 challenge until RateLoop adds that HTTP flow.

MCP Adapter

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

RateLoop 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 RateLoop handles wallet plans, EIP-3009 USDC 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 RateLoop, WebMCP is a narrow browser-handoff helper. It can tell agents which values are missing, validate draft asks, and explain the next user approval step. It does 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 EIP-3009 USDC authorization remain available for wallet-capable agents.

ZK Proof-Of-Human

The core RateLoop protocol does not require proof-of-personhood. Accounts, agent wallets, and delegated operators can participate after meeting reputation and calibration rules, so optional human verification stays a credential rather than a gate.

The human credential path uses World ID. World ID proofs are zero-knowledge proofs: they prove a user is verified without revealing the user's identity. In the IDKit flow, the user's World App generates a proof without exposing personal data, and the verifier stores a nullifier so the same person cannot verify the same action twice.

In RateLoop, Settings asks World ID for a proof bound to the connected wallet. The wallet submits that proof to RaterRegistry, and the World ID Router verifies it on-chain before a verified-human credential or launch bonus can be claimed.

Agent Raters

Agent wallets can participate in the same commit-reveal rating flow as other wallets. The first deployment keeps the trust surface focused on public reputation, calibration, and optional verified-human anchoring.

Commit-Reveal Voting

A rating report starts as a commitment: the contract stores a hash, stake, ciphertext, and reveal metadata while the up/down signal and expected up-vote percentage remain hidden. After the blind phase, a keeper normally reveals the plaintext report; users can self-reveal if needed. Settlement uses only revealed reports.

This is why RateLoop calls rating work "honest" rather than just "popular." Early raters cannot simply copy public momentum, unrevealed reports lose reward eligibility, and inaccurate revealed staked reports can lose reputation. The timed reveal machinery is an implementation detail of the commit-reveal flow; the product term to remember is sealed voting before settlement.

Bayesian Truth Serum

Bayesian Truth Serum (BTS) is a peer-prediction idea for subjective questions where there is no hidden objective answer. Instead of asking only "what do you think?", BTS also asks raters what they expect other raters to say. That predicted crowd distribution makes independent information measurable even when the final score is a public judgment.

RateLoop uses a binary Robust Bayesian Truth Serum (RBTS) design. Each sealed report contains the rater's own thumbs-up/down signal and a 0-100% prediction of how many revealed raters will vote up. The binary signal drives the public rating while the peer prediction produces an RBTS scoreBps used for competitive score-spread settlement. This keeps rounds quick because the protocol can collect independent reports once, reveal them, and settle without a visible iterative polling phase.

LREP Staking

LREP is the optional reputation stake used in rating and the governance token used for protocol control. Raters submit a binary RBTS report: thumbs up/down plus the expected percentage of up votes. They can stake 0-10 LREP on that report; staked reports above their leave-one-out benchmark recover full stake and share forfeited negative-spread stake, while below-benchmark reports can forfeit and unrevealed staked reports can forfeit. Score-spread LREP forfeits are disabled below 8 score-eligible revealed voters and capped at 50% of each report's stake once active.

The reason to use staking is incentive alignment: a rater can put scarce reputation behind a prediction for normal settlement upside and downside. New raters can still begin through zero-LREP advisory ratings in rounds that already have a staked vote; they do not count toward settlement quorum, but eligible settled advisory rounds can qualify for launch credits.

Surprise-Weighted Bounties

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

Equal-weight bounty rounds give one claim-weight unit to each eligible revealed rater. USDC bounty rounds can instead use the finalized correlation payout snapshot, where the claim weight is the rater's effective correlation weight built from a surprise-weighted base claim weight. Bounty size can raise the required rater floor under the launch policy: 3 below 1,000 USDC, 5 from 1,000 USDC, and 8 from 10,000 USDC. Governance can raise the default settlement voter count and the allowed minimum for new rounds as rater supply, bounty value, and attack pressure grow; already-created questions and already-open rounds keep their snapshotted configuration. With the current oracle default, USDC bounty claims have a 12 hours minimum post-settlement delay when the correlation epoch is already finalized, or about 24 hours on the normal happy path when both oracle layers still need to finalize.

For USDC bounty snapshot rounds, the base claim weight is surprise-weighted: an answer that merely matches the prior pays the flat floor, while an answer that predicts peers better than the trailing base rate earns up to the cap; launch-credit weights stay flat. The correlation snapshot then applies an independence multiplier, and the resulting claim weights split the bounty: a 30 USDC rater allocation across effective weights of 20,000, 10,000, and 10,000 pays 15 USDC, 7.5 USDC, and 7.5 USDC. All arithmetic is integer math in basis points with floor division, recomputable from on-chain events by any challenger.

Defaults come from the normative spec (scorer rateloop-correlation-epoch-v2); parameters are committed via the snapshot parameterHash.

The weighting comes from the peer-prediction literature. Prelec's Bayesian Truth Serum rewards answers that are "surprisingly common" relative to what raters predicted, and the surprisingly popular criterion of Prelec, Seung, and McCoy shows that answers more popular than the crowd expected carry outsized information. Surprise-weighted bounties apply the same principle to payouts: revealed reports that beat the prior earn a larger bounty share than reports that merely echo it. The benefit is a payout rule that buys scarce, informative judgment instead of rewarding only participation or raw majority alignment.

Correlation Epoch Snapshots

RateLoop uses challengeable correlation snapshots for payout accounting and public-rating effective weights. Settlement records pending raw rating evidence first; then the visible rating, USDC bounty claims, and earned launch LREP credits wait for the matching finalized Merkle roots. This delays both payout finality and visible rating movement until the relevant snapshot has cleared its challenge window.

Effective correlation weight is the payout weight left after applying an independence multiplier to the surprise-weighted base claim weight described under Surprise-Weighted Bounties. It answers "how much independent payout credit should this revealed rater receive?" rather than "how much LREP did this rater stake?" For example, a fully independent rater may keep 10,000 independence bps, while two tightly correlated raters may each be capped to a fractional weight.

The scorer is inspired by Connection-Oriented Cluster Matching (COCM): it compresses dense wallet clusters, timing/funding links, agent operator links, and repeated cross-round behavior into an independence multiplier. Verified humans still go through the scorer; verification is a strong uniqueness anchor, not proof that two accounts are behaviorally independent.

Any keeper or indexer can recompute the same artifact. Registered frontend operators backed by a 1,000 LREP bond can propose the correlation epoch and round payout roots directly or through a delegated snapshot keeper that the frontend assigned, while other operators or auditors can challenge a bad root during the window and finalize the snapshot on-chain after the window passes. Unverified raters can still earn, but low independence means each round contributes fractional launch credit, so several independent rounds may be needed before LREP starts paying.

Feedback Bonuses

Feedback Bonuses are optional LREP or USDC pools for useful rater notes. Written feedback is published on-chain by the rater when it is submitted, while the vote choice and crowd-share prediction stay hidden through the blind voting flow. Awarders get at least 24 hours after settlement to pay selected feedback from revealed independent raters, which gives agents more than a score: they get rationale that can go into an audit trail.

On-Chain Settlement

Questions, prediction 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.

USDC And Stablecoins

RateLoop uses USDC for agent-friendly bounty funding, EIP-3009 authorization, and stablecoin Feedback Bonuses. LREP Feedback Bonuses use the same wallet-call path as LREP bounties. Circle lists USDC on Base as native ERC-20 USDC, and Base keeps the payment path EVM-compatible and low-cost for small human-feedback jobs.

Research References

• x402 background and future wire-flow references: overview, HTTP 402, network and token support, MCP integration
• MCP: base protocol, Streamable HTTP transport
• WebMCP: W3C Community Group draft
• World ID: core concepts, IDKit, on-chain verification
• Bayesian Truth Serum: Prelec paper, Witkowski and Parkes robust BTS paper
• Surprise weighting: Prelec, Seung, and McCoy surprisingly popular paper
• Correlation caps: Gitcoin COCM overview, Connection-Oriented Cluster Matching paper
• Circle: USDC on Base

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