How it works
A simple path from spare capacity to verifiable reward.
Three stages that keep the user in control and make participation auditable.
01 — Browser node
A lightweight container runs in the browser. It uses only spare CPU, GPU, and optional bandwidth. No installer, no background service, no hidden bridge.
02 — Verified job runtime
Job requests are validated, sandboxed, and rate-limited by the worker runtime. Execution stays in the browser, not on a remote server. Results leave only as verified outputs.
03 — Rewarded participation
Completed jobs are submitted to the network. Rewards accrue to a non-custodial wallet. The node operator can pause or withdraw anytime.
Trust
Built to be auditable from the first click.
One set of core guarantees, supported everywhere.
No secrets
The worker code is open-source and reproducible. No hidden endpoints, no black-box bridges.
Non-custodial
Rewards go to a wallet you control. Withdraw directly. No intermediary custody.
Browser-native
Work runs inside the page. No installer, no background service, no remote execution.
Verified
Jobs are validated before acceptance and outputs are auditable. Reputation tracks honest participation.
Model
The network model — embedded rules, not afterthoughts.
A single rule set that keeps throughput honest, allocation efficient, and onboarding open.
Publisher sets the reward split
The publisher controls the exact percentage of reward split — 1 % to 100 %. The split is visible in the publisher dashboard and in client reward breakdowns.
Tasker pays for output
Billing is outcome-based: the tasker pays for resources consumed by output only. Browser nodes are paid per completed job, not per session.
Publisher and Client are separate roles, one identity can be both
Roles are distinct by design, and a single authenticated identity can hold both at the same time for the same placement or campaign.
Permissionless integration
Embed the widget, set any fee split, and onboard publishers without account approval. The iframe URL is the only integration surface.
Example
Earn Idle — the first validated client.
Contribute resources, complete jobs, earn rewards. Everything runs in the browser.
What the client actually does
- Runs inside the browser container, no download needed
- Executes the verified inference worker on-device
- Uses WebGPU with WASM fallback for broad support
- Pays out per job completed to a non-custodial rewards wallet
- Identity can act as both client and publisher when needed
Components
What makes up the Earn Idle container instance.
Job polling loop — Polls `/api/inference/job` for assigned work
Transformers.js runtime — `@huggingface/transformers` loaded from CDN at runtime
Model — `Llama-3.2-1B-Instruct` Q4 ONNX via WASM
Result submission — Output, tokens, and timing posted back to `/api/inference/result`
Payout tracking — Per-job USDC payout returned by the API; node earnings update per completed job
Settlement — Tasker pays for resources consumed by output only; browser node is paid per job
Permissionless integration — Embed the widget, choose any reward split, and launch without account approval
Browser capabilities
What the browser container can do.
These are the rentable services the container makes available.
Inference
Run verified AI inference jobs on-device using WebGPU with WASM fallback.
CPU / WebAssembly compute
Execute general-purpose compute tasks using spare CPU cycles inside a sandboxed WebAssembly runtime.
GPU / WebGPU + WebGL
Leverage the GPU for parallel workloads. Automatically falls back to WebGL when WebGPU is unavailable.
Bandwidth / routing
Relay or proxy small amounts of network traffic. Useful for distributed routing and connectivity checks.
Memory / caching
Store temporary data for the network. Clean, sandboxed memory that is released after each job.
Temporary storage
Hold short-lived files or intermediate results needed for the current job only. No persistent device access.
Roles
How you participate.
Welcome / Trust
Step 1
Secure widget runtime with granular consent. Share CPU, GPU, and bandwidth when you choose.
Sign in & Create Wallet
Step 2
Choose a login method to continue. A non-custodial rewards wallet is created at onboarding. You control the key.
Resource Consent
Step 3
Choose which resources to share and set your limits: CPU, GPU, bandwidth. Adjust anytime.
Verify Wallet
Step 4
Sign a message with your wallet to verify ownership and keep the reward pool honest.
Active Session
Step 5
See live earnings, session time, reputation, and completed tasks in one panel.
Withdraw / Payouts
Step 6
Withdraw rewards to your non-custodial wallet anytime. No custodial accounts, no hidden fees.
Client iframe example
Drop this into your page to load the client widget.
Earn from placements while users contribute resources in-browser. One account can own both roles.
Get Started
Step 1
Add organization name, website URL, login options, then create account or continue.
Domain Verification
Step 2
Add a TXT record to verify your domain. Once verified, the placement is eligible for rewards.
Publisher Wallet
Step 3
Create a secure wallet for payouts. You own the key. Passkey plus backup recovery.
Create Placement
Step 4
Define page placement, allowed domain/path, resource limits, and reward split.
Embed Code
Step 5
Copy the script and iframe snippet. Add to verified pages and start monetizing placements.
Publisher Rewards Dashboard
Step 6
Monitor verified pages, active sessions, earnings, and payout history. See the chosen reward split at a glance.
Publisher reward split
The publisher chooses any percentage of the reward split. The split stays visible on the dashboard and in client reward breakdowns.
Rules for integration
- Integration is permissionless: embed the iframe, set the publisher fee split, and drive traffic without account approval.
- The publisher chooses any percentage of the reward split, and that split stays visible in the publisher dashboard and client reward breakdown.
- Publisher and Client are distinct roles. One identity can be both at once.
- Matched resources change per tasker based on current browser resources, capacity, bid, and capability fingerprint.
- The tasker pays for resources consumed by output.
- Browser nodes are paid per job, not per session.
- The widget URL is the only integration surface. No CLI, build, or API token is required to register a placement or change fee split.
Tasker flow
From discovery to settlement — Idle first.
The tasker views available resources, makes a request, and pays for output. The browser node is paid per completed job.
Tasker views available resources
Browse browser-compute inventory with capability chips and per-slot pricing. Idle is listed first as the reference resource.
Tasker makes a request
Select a resource such as GPU inference, choose model and size, and set a max price.
Tasker pays for resources
Pre-authorize payout for the requested output before the job starts.
Idle runs the job
The browser node executes inside the user's tab, streams status, and submits the result.
Settlement
The tasker is charged for output only. The node is paid per completed job.