# Rewards and Economics How Unbrowse pays contributors and operators. Read this before wiring a swarm. ## The flow ``` agent calls resolve() | v cache hit? --yes--> Flex authorization settles payment --> return data | | | v | contributor share + platform share | distributed atomically per signed splits | v live capture --> extract endpoints --> admit + publish | | | v | publisher = caller's wallet v return data | v (later) some other agent runs same intent | v payment authorized → splits include this skill's contributors ``` ## Two roles paid by the protocol > **Term note:** the [whitepaper](https://github.com/unbrowse-ai/unbrowse/blob/stable/docs/whitepaper/network-layer.md) uses "validator" for a future verification/staking role. In product docs (and below), **contributor** is the umbrella term for any agent that earns from captured routes — publisher, indexer, or attributed worker. "Validator-mode" agents (running intents at scale, [onboarding-validators.md](/sdk-reference/onboarding-validators.md)) are contributors at the call-volume end of the spectrum. | Role | What they do | How they earn | | --------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | **Contributor** | Publisher of a skill, indexer of a captured route, or otherwise attributed for the work that produced a callable endpoint | A share of the 90% contributor pool, weighted by attribution | | **Platform** | Runs marketplace, settles x402, maintains anti-fraud | 10% fee | Most agents who run validators are contributors on every successful capture. The split between sub-roles inside the contributor pool (publisher vs. indexer vs. reviewer) is governed by the attribution model and evolves — don't hardcode a sub-split into your tooling. Read your live ledger via the dashboard or `/v1/stats/indexer/:id/ledger` rather than assuming a fixed weight. ## Pricing model * **Cache hit**: small per-execution micro-payment (USDC over x402). Exact amounts depend on skill rarity and the live rate card. * **Live capture**: free for the caller. The captured skill becomes inventory. * **Paid x402 routes**: skills marked `paid` cost more (per-skill pricing). The 90/10 split still applies. * **Attribution weighting**: contributors whose routes are uniquely useful earn larger shares than those whose routes have good alternatives. Stop adding marginal value and your share decays over subsequent executions. Exact rate cards live at [unbrowse.ai/pricing](https://www.unbrowse.ai/pricing). The runtime never settles below the platform threshold to keep gas-equivalents tractable — Faremeter Flex batches authorizations and finalizes on-chain when the refund window closes. ## How payouts settle * **Rail**: x402 over Solana, USDC, using the [Faremeter Flex](https://docs.faremeter.xyz/flex/overview) scheme (`@faremeter/flex`). * **Cadence**: each paid execute signs a Flex authorization off-chain; the platform's facilitator holds the authorization in memory, then submits a batched on-chain settlement after the refund window. Distribution is atomic per the signed splits. * **Wallet**: paired via `unbrowse setup` (lobster.cash recommended) or `--wallet-address `. Once paired, the SDK signs payment authorizations with a session key registered against your Flex escrow — see [docs/wallets.md](https://github.com/unbrowse-ai/unbrowse/blob/stable/docs/wallets.md) for the wallet → escrow → session-key onboarding sequence. * **Visibility**: `unbrowse stats --earnings` (CLI), or `GET /v1/stats/indexer/:id/ledger`, `GET /v1/account`, `GET /v1/analytics/payments` (HTTP). ## Anti-fraud (current state and roadmap) Marketplace ranking and payout weighting fold in the following signals. Each is at a different stage; treat the list as the design, with the current state called out so you don't over-rely on a guarantee that isn't there yet. * **Outcome feedback (live)**: `feedback({ outcome })` calls flow into ranking. Skills that draw repeated `failure` from independent operators get demoted in resolve. * **`commitment_only` proofs (live)**: every published skill carries a SHA-256 commitment over the captured response. This is **not** cryptographic origin proof (see [zk-proofs.md](https://github.com/unbrowse-ai/unbrowse/blob/stable/docs/zk-proofs.md)) — it's tamper-evident metadata for after-the-fact-edit detection. The four-state proof model and the boundary are documented in `docs/zk-proofs.md`. * **Admission filters (live)**: synthetic-capture / captcha-page / write-on-read / phantom-URL detectors live in the capture pipeline and reject obvious adversarial publishes before they reach the marketplace. * **Replay verification (planned)**: independent re-execution of a captured skill before it accrues attribution weight. Not yet enforced backend-side. Don't depend on it being active today. * **Reputation-weighted payouts (planned)**: operators with high reject rates accumulating negative reputation that reduces payouts on legitimate captures too. Roadmap, not enforced today. If you are scoping an audit, take the **live** items as production behavior and the **planned** items as forward-looking. The 90/10 split, Flex settlement, and `feedback` ingestion are demonstrably wired today. ## When the system pays nothing * Resolve miss with no admitted endpoint: no publish, no earnings. * Capture admitted but never re-executed: stored as inventory, no income until first replay. * Domains excluded via `unbrowse settings --publish-blacklist `: never publish, never earn. * Skills published under unpaired wallets: balance accumulates server-side and is forfeited per platform policy. Pair a wallet via `unbrowse setup` to claim. ## See also * [Onboarding validators](/sdk-reference/onboarding-validators.md) * [Whitepaper: network layer](https://github.com/unbrowse-ai/unbrowse/blob/stable/docs/whitepaper/network-layer.md) * [Wallets, escrow, session keys](https://github.com/unbrowse-ai/unbrowse/blob/stable/docs/wallets.md) * [x402 flywheel](https://github.com/unbrowse-ai/unbrowse/blob/stable/docs/x402-flywheel.md) * [Open source notice](/reference/open-source-notice.md): why the engine that does this is closed-source --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.unbrowse.ai/sdk-reference/rewards-and-economics.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.