> For the complete documentation index, see [llms.txt](https://docs.solventus.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solventus.org/core-concepts/on-chain-settlement.md). # On-Chain Settlement A single inference job on Solventus puts at least two transactions on Solana: an escrow lock when the job is submitted and a payment release once completion is verified. Both sit in public view on the Solscan explorer at `solscan.io`. What follows is the full settlement picture: which programs do what, how an escrow moves through its lifecycle, how payouts split, and how disputes get resolved. *** ## Why Solana Per-job micropayments only pencil out on a chain with the right economics, and few chains have them today. | Property | Value | Why it matters for Solventus | | ----------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Block time | \~400ms | The settlement confirms before the client has even received the full inference stream | | Cost per tx | Fractions of a cent | Overhead on an $0.08 job is negligible, and since Solventus sponsors network fees through its fee payer, neither users nor workers ever hold SOL | | Throughput | Thousands of transactions per second | With at least 2 transactions per job, on-chain volume has to stay a rounding error at scale, never a bottleneck | | Native USDC | SPL token | USDC (issued by Circle) is native to Solana, so nothing needs bridging | | Maturity | Rust + Anchor tooling | Programs built and audited with mature tooling (Anchor, @solana/web3.js, @solana/kit), settling on Solana's own base layer with native finality | For comparison, putting that same $0.08 job on Ethereum L1 would burn $2 to $10 in gas, which kills per-job settlement outright at these prices. Solana, being its own high-throughput base layer, holds fees to fractions of a cent with native finality and no bridges involved. *** ## Programs The programs are Rust, built with Anchor, fully open-source, and audited before any mainnet-beta deployment. ### `job_escrow` Owns the credit lock at submission time and the refund path when no valid proof shows up. **At job submission it:** * Confirms the user's credit balance covers the requested model tier * Atomically writes an escrow record holding the credit amount, job ID, model tier, and expiry timestamp * Sets the escrow's status to `Pending` **On a valid proof:** Moves the escrow to `Settled` and signals the `settlement` program to pay out. **On timeout:** Once the expiry timestamp passes (120 seconds after submission) with the escrow still `Pending`, anyone may call the `refund` function. The locked credits go back to the user's balance and the escrow record is deleted. ### `worker_registry` The roster of every registered worker. Per worker, it stores: * Solana address * Staked $SOLVENTUS amount and lock tier * Declared model support list * On-chain reputation score (0 to 1000) * Cumulative completed jobs and earnings * Last seen timestamp Only registered workers receive job routing, and Tier 2 registration requires a minimum stake. ### `settlement` The program workers call to submit their proof of completion. **Its verification sequence:** 1. Find the job ID in `job_escrow` and confirm the escrow is `Pending` and unexpired. 2. Find the caller in `worker_registry` and confirm it is registered with the model tier this job used declared. 3. Check the proof signature: the SHA-256 hash of the output stream has to carry an Ed25519 signature from the worker's registered key, verified via the Ed25519 precompile. 4. With everything valid, compute the payout split from the worker's current stake tier. 5. Release the escrow, sending USDC to the worker's wallet and the rest to the protocol treasury. 6. Bump the worker's reputation score and completed-job count in `worker_registry`. 7. Emit a `JobSettled` event for the Helius indexer. ### `staking` Runs $SOLVENTUS staking for both workers and passive stakers. $SOLVENTUS itself is an SPL token on Solana. Three lock durations are offered: 30, 90, and 180 days. The longer the lock, the higher the reward rate multiplier, topping out at 1.5x for 180 days. The `settlement` program recognizes any worker with an active stake here and pays them at the 85% rate rather than the base 75%. When a dispute is confirmed valid, `settlement` triggers slashing. The slashed 5% of stake is burned outright, never redistributed. ### `governance` Runs the on-chain votes covering model curation, protocol fee parameters, and program upgrades, built on SPL Governance (Realms). It activates once the beta ends. Voting power is proportional to each $SOLVENTUS holder's staked balance. *** ## Payout distribution At settlement, the escrowed USDC splits like this: | Recipient | Unstaked worker | Staked worker | | ----------------- | --------------- | ------------- | | Worker wallet | 75% | 85% | | Protocol treasury | 25% | 15% | The 85% rate applies to any worker holding at least 1,000 $SOLVENTUS in the `staking` program at the moment the settlement transaction executes. USDC piles up in the protocol treasury, and every week the treasury program: * Spends 50% of the accumulated fees buying back $SOLVENTUS on Orca and Raydium, routed by Jupiter, then burns what it bought * Sends the other 50% to $SOLVENTUS stakers, pro-rata by staked balance Each buyback and each burn is an ordinary public transaction on Solana, and the Solventus Explorer keeps the complete history. *** ## Dispute process If the proof a worker submitted does not match the response you actually received, you have 60 seconds from the final output token to raise a dispute. **Raising one:** Call `dispute` on the `settlement` program, passing: * The job ID * The SHA-256 hash you computed locally over the output stream you received The program checks your hash against the worker's proof hash. Any difference flags the job as `Disputed` and freezes the escrow until arbitration. **During the beta:** The Solventus Squads multisig examines the dispute and rules on it. A worker found to have posted a fraudulent proof loses 5% of their staked $SOLVENTUS to a burn, and the user gets their credits back. **After the beta:** Disputes move to a DAO committee that $SOLVENTUS holders elect. Further out, the goal is ZK proof-of-inference: proofs that verify themselves, which removes the trust requirement and the dispute window with it. *** ## Reading settlement data Every settled job is a Solana transaction you can inspect. Four ways in: **Solscan** at `solscan.io`: look up any transaction signature, or browse the `job_escrow` program address. **Helius API**: query the `worker_registry` program for any worker address and pull their complete on-chain earnings history, job count, and reputation score. **Solventus Explorer** at `solventus.org/explorer`: the network-wide view, with live job completions, worker leaderboards, the treasury balance, and buyback history, all linked to the underlying transactions. **API response headers**: every request you make comes back with `x-solventus-job-id` and `x-solventus-escrow-tx`, so verifying the settlement for your own call takes seconds. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.solventus.org/core-concepts/on-chain-settlement.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.