> For the complete documentation index, see [llms.txt](https://docs.theacompute.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.theacompute.com/core-concepts/on-chain-settlement.md). # On-Chain Settlement I leave at least two transactions on Robinhood Chain for every inference job: an escrow lock when you submit the job, and a payment release once I've verified it finished. Both are receipts, not promises. Look either one up on Blockscout at `robinhoodchain.blockscout.com` and check my work yourself. On this page I lay out the whole settlement picture: what each of my contracts does, how an escrow moves through its lifecycle, how I split payouts, and how I resolve disputes. *** ## Why I settle on Robinhood Chain Paying out every job as its own micropayment only works on a chain with the right economics, and very few chains have them right now. | Property | Value | Why it matters to me | | ----------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | Block time | \~100ms | Settlement confirms before your client has even received the whole inference stream | | Cost per tx | Fractions of a cent | The overhead on an $0.08 job is negligible, and because I sponsor gas via ERC-4337, neither users nor workers ever need to hold ETH | | Throughput | High-throughput Arbitrum Orbit stack | With at least 2 transactions per job, my 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 I don't have to bridge anything | | EVM compatibility | Solidity + Ethereum security | My contracts are built and audited with mature tooling (Foundry, ethers.js, viem), and they settle on Ethereum and inherit its security | To put that in perspective: the same $0.08 job on Ethereum L1 would burn $2 to $10 in gas, and per-job settlement would be dead on arrival. Robinhood Chain is an Ethereum Layer 2, so it keeps fees at fractions of a cent while still settling back to Ethereum. *** ## My smart contracts I write my contracts in Solidity, build them with Foundry, keep them fully open-source, and have them audited before any Mainnet deployment. Go read them; you don't have to take my word for what they do. ### `job_escrow` This one handles the unit lock when you submit a job (my contracts call units "credits"), and the refund path when no valid proof arrives. **When you submit a job, it:** * Checks that your unit balance covers the model tier you asked for * Atomically writes an escrow record with the unit amount, job ID, model tier, and expiry timestamp * Marks the escrow's status as `Pending` **When a valid proof comes in:** It moves the escrow to `Settled` and tells my `settlement` contract to pay out. **When time runs out:** After the expiry timestamp passes (120 seconds after submission) and the escrow is still `Pending`, anyone can call the `refund` function. The locked units go back to the user's balance and the escrow record gets deleted. ### `worker_registry` This is my list of every registered worker. For each worker, it keeps: * Their Ethereum address * How much $THEA they've staked, and their lock tier * The list of models they've declared support for * Their on-chain reputation score (0 to 1000) * Their running totals of completed jobs and earnings * When I last saw them I only route jobs to registered workers, and registering at Tier 2 takes a minimum stake. Native workers have to stake at least 1,000 $THEA; browser workers don't stake at all. ### `settlement` Workers call this contract to hand in their proof that a job is done. **How it verifies a proof, step by step:** 1. Look up the job ID in `job_escrow` and make sure the escrow is `Pending` and hasn't expired. 2. Look up the caller in `worker_registry` and make sure it's registered with the model tier this job used on its declared list. 3. Verify the worker's signature on the proof: the SHA-256 hash of the output stream must be signed by the worker's registered key. 4. If all of that holds, work out the payout split from the worker's current stake tier. 5. Release the escrow, sending USDG to the worker's wallet and the remainder to the protocol treasury. 6. Raise the worker's reputation score and completed-job count in `worker_registry`. 7. Emit a `JobSettled` event for the Alchemy indexer to pick up. ### `staking` This runs $THEA staking for workers and passive stakers alike. And $THEA is a standard ERC-20 token living on Robinhood Chain. You can lock for 30, 90, or 180 days. The longer the lock, the higher your reward rate multiplier, up to a maximum of 1.5x for 180 days. Browser workers get the base 75%. Native workers are required to stake, and my `settlement` contract recognizes their active stake here and pays them at the 85% rate. Once a dispute is confirmed as valid, `settlement` triggers slashing. I burn the slashed 5% of stake outright; it never gets redistributed. ### `governance` This runs my on-chain votes on model curation, protocol fee parameters, and contract upgrades. It switches on once the beta is over. Each $THEA holder's voting power is proportional to their staked balance. *** ## How I split each payout When a job settles, I divide the escrowed USDG like this: | Recipient | Browser worker (no stake) | Native worker (staked) | | ----------------- | ------------------------- | ---------------------- | | Worker wallet | 75% | 85% | | Protocol treasury | 25% | 15% | A native worker gets the 85% rate by holding at least 1,000 $THEA in my `staking` contract at the moment the settlement transaction executes. USDG builds up in my protocol treasury, and once a week the treasury contract: * Uses 50% of the accumulated fees to buy back $THEA on Uniswap, then burns everything it bought * Sends the other 50% to $THEA stakers, pro-rata by how much they've staked Every buyback and every burn is a normal public transaction on Robinhood Chain. The TheaCompute Explorer at `explorer.theacompute.com` keeps the full history, and none of my fee flows happen off the record. *** ## Dispute process If the proof a worker submitted doesn't match the response you actually got, you have 60 seconds from the final output token to raise a dispute with me. **How to raise one:** Call `dispute` on my `settlement` contract and pass in: * the ID of the job you're disputing * your own SHA-256 hash of the output stream you received, computed on your machine The contract compares your hash with the worker's proof hash. If they differ at all, it marks the job as `Disputed` and freezes the escrow until arbitration. **While I'm in beta:** The TheaCompute Safe multisig reviews the dispute and makes the call. If a worker is caught submitting a fraudulent proof, 5% of their staked $THEA gets burned, and you get your units back. **Once the beta ends:** Disputes go to a DAO committee elected by $THEA holders. Longer term, the goal is ZK proof-of-inference: proofs that verify themselves, which would remove the need for trust and the dispute window along with it. *** ## Checking settlement data yourself Every job I settle is a Robinhood Chain transaction you can inspect. Here are five ways to do it: **Blockscout** at `robinhoodchain.blockscout.com`: search any transaction hash, or browse my `job_escrow` contract address. **Alchemy API**: query my `worker_registry` contract for any worker address to get their full on-chain earnings history, job count, and reputation score. **TheaCompute Explorer** at `explorer.theacompute.com`: my network-wide view, showing live job completions, worker leaderboards, the treasury balance, and buyback history, all linked to the transactions underneath. **Your Jobs page** at `theacompute.com/app/jobs`: every job you've run, each with its receipt and a Blockscout link. **API response headers**: every request you send me comes back with `x-theacompute-job-id` (the job ID), `x-theacompute-tx-hash` (the escrow lock transaction), and `x-theacompute-settlement-tx` (the settlement transaction that released payment), so you can verify both ends of your own call in 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.theacompute.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.