What ComputeFi does, what it does not do, and how to run it safely.

Renters create a job, specify an optional Hugging Face model ID or model URL, attach a small input file if needed, and choose a SOL budget. Their connected wallet sends that SOL to the server escrow address. The server verifies the on-chain transfer before saving the job. Available workers heartbeat to the board every three seconds. The oldest open job is assigned to an idle worker. A configured native worker runs its local executor, submits a completion proof, and receives a ledger credit for 97.5% of the job budget. The worker can then claim that SOL from escrow.

Every important state change is stored: job details, payment signature, assignment, progress lifecycle, completion proof, worker heartbeat, credit, payout, and payout signature. MongoDB is required for production. The local JSON fallback is only for a single development process.

• Worker presence, names, GPU/CPU detection, assignment, stale-worker recovery, and a live job board.
• Wallet-funded SOL transfers to escrow and server-side transaction verification.
• Database ledger credits and outbound SOL claims from the escrow server wallet.
• Native execution through a local operator-supplied executable. That executable receives the assigned job in the COMPUTEFI_JOB environment variable and exits successfully only after it has finished the work.
• Lifecycle progress: 0% waiting, 5% assigned, and 100% completed. This is board state, not a model-token progress meter.

Browser sharing does not run Hugging Face inference yet. It reports a real WebGPU adapter and creates a worker heartbeat, but no browser model runtime is bundled. Similarly, the downloadable PC worker does not download arbitrary models or execute arbitrary renter text. It only invokes the executable configured by the machine owner. That boundary is intentional: model URLs, files, and renter prompts are untrusted input.

The transaction display is real only after real activity happens. Before a wallet funds a job, a native executor completes it, and a worker claims, “No transactions” is the correct state. A UI message alone is never proof of a payment; use the signature and a Solana explorer as the source of truth.

1. Connect a Solana wallet on Rent.
2. Describe an explicit, bounded task. Good examples: image batch rendering, embeddings for a fixed document set, an approved transcription batch, or a fixed inference prompt list.
3. Paste an approved Hugging Face ID or direct model link. Your native executor decides which sources it accepts.
4. Attach an input file only when it is small (at most 1 MB) and necessary.
5. Enter a SOL amount and approve the transaction. The job is created only after the server sees the escrow transfer.

Useful real-world rent cases include batch image generation, Blender or 3D asset rendering, video transcoding, embeddings, OCR, approved LLM batch inference, scientific parameter sweeps, and data transformations. Each requires a purpose-built executor; the board does not provide those tools by itself.

For the easy Windows path, use Windows quick start from Earn, double-click the downloaded launcher, provide the receiving Solana address, and keep the worker window open. Node.js 18+ is required. The launcher downloads the current worker from this site and joins the board.

For actual work, configure COMPUTEFI_EXECUTOR to an executable owned by the worker operator. The runner receives JSON in COMPUTEFI_JOB, validates the requested model and job format, does the work, prints a short completion proof, and exits with code zero. Do not pass raw renter text to a shell. Use allow-lists, resource limits, an isolated working directory, model hash checks, and an explicit timeout.

Escrow is a server-controlled hot wallet in the current implementation. It must have ESCROW_SECRET_KEY, configured only as a server environment variable, plus enough SOL for transaction fees. Renters transfer into it; workers are paid out of it. The server verifies destination and amount before creating a job. The worker ledger is not the blockchain: it is an internal record of a verified completed job. Claiming sends a real Solana transfer and saves its signature.

This is not trustless escrow. Before public mainnet usage, add an audited Solana program or multisig custody, signed completion receipts, dispute and refund windows, authentication/rate limiting, monitoring, automatic reconciliation against chain data, and independent security review.

Progress currently represents reliable lifecycle events, not guessed compute completion. A generic worker cannot know that an arbitrary model is “42% done.” To show true progress, the local executor must report structured milestones through a future authenticated progress endpoint.

Multiple workers should only share a job when it can be split safely: render frames, independent prompts, document chunks, or parameter ranges. The pool must be divided by completed shards, not by simply assigning the same model request to many machines. The current scheduler intentionally assigns one worker per job. Parallel worker pools require shard definitions, shard-specific inputs and proofs, retry rules, aggregation, and proportional settlement. Those are planned architecture work, not a switch we should enable prematurely.

• Set production MongoDB, RPC, site URL, and escrow key in the correct Vercel environment; redeploy after every change.
• Visit /api/escrow; it must return an address, not an error.
• Use devnet first. Fund a devnet job, run a harmless allow-listed executor, verify assignment, completion, credit, and claim.
• Review the Mongo job and ledger records and verify every signature in a Solana explorer.
• Set alerts for failed claims, missing heartbeats, low escrow fee balance, and RPC errors.