> For the complete documentation index, see [llms.txt](https://docs.robinmesh.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.robinmesh.com/core-concepts/on-chain-settlement.md). # On-Chain Settlement A single inference job on RobinMesh puts at least two transactions on Robinhood Chain: an escrow lock when the job is submitted and a payment release once completion is verified. Both sit in public view on the Blockscout explorer at `robinhoodchain.blockscout.com`. What follows is the full settlement picture: which contracts do what, how an escrow moves through its lifecycle, how payouts split, and how disputes get resolved. *** ## Why Robinhood Chain 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 RobinMesh | | ----------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | Block time | \~100ms | 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 RobinMesh sponsors gas via ERC-4337, neither users nor workers ever hold ETH | | Throughput | High-throughput Arbitrum Orbit stack | With at least 2 transactions per job, on-chain volume has to stay a rounding error at scale, never a bottleneck | | Native USDG | ERC-20 | USDG (Paxos Global Dollar) is native to Robinhood Chain, so nothing needs bridging | | EVM compatibility | Solidity + Ethereum security | Contracts built and audited with mature tooling (Foundry, ethers.js, viem), settling on Ethereum and inheriting its security | 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. Robinhood Chain, being an Ethereum Layer 2, holds fees to fractions of a cent while still settling back to Ethereum. *** ## Smart contracts The contracts are Solidity, built with Foundry, fully open-source, and audited before any Mainnet 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` contract 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: * Ethereum address * Staked $RMESH 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 contract 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 a signature from the worker's registered key. 4. With everything valid, compute the payout split from the worker's current stake tier. 5. Release the escrow, sending USDG 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 Alchemy indexer. ### `staking` Runs $RMESH staking for both workers and passive stakers. $RMESH itself is an ERC-20 token on Robinhood Chain. 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` contract 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 contract upgrades. It activates once the beta ends. Voting power is proportional to each $RMESH holder's staked balance. *** ## Payout distribution At settlement, the escrowed USDG 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 $RMESH in the `staking` contract at the moment the settlement transaction executes. USDG piles up in the protocol treasury, and every week the treasury contract: * Spends 50% of the accumulated fees buying back $RMESH on Uniswap, then burns what it bought * Sends the other 50% to $RMESH stakers, pro-rata by staked balance Each buyback and each burn is an ordinary public transaction on Robinhood Chain, and the RobinMesh 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` contract, passing: * The job ID * The SHA-256 hash you computed locally over the output stream you received The contract 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 RobinMesh Safe multisig examines the dispute and rules on it. A worker found to have posted a fraudulent proof loses 5% of their staked $RMESH to a burn, and the user gets their credits back. **After the beta:** Disputes move to a DAO committee that $RMESH 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 Robinhood Chain transaction you can inspect. Four ways in: **Blockscout** at `robinhoodchain.blockscout.com`: look up any transaction hash, or browse the `job_escrow` contract address. **Alchemy API**: query the `worker_registry` contract for any worker address and pull their complete on-chain earnings history, job count, and reputation score. **RobinMesh Explorer** at `robinmesh.com/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-robinmesh-job-id` and `x-robinmesh-tx-hash`, 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.robinmesh.com/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.