{"slug": "how-sarva-keeps-the-same-gpu-multipler-on-the-cost-side-and-the-earn-side-the", "title": "How Sarva keeps the same GPU multipler on the cost side and the earn side without the ledger drifting", "summary": "Sarva, a hub-and-spoke compute grid, has implemented a ledger system that ensures cost and earn multipliers remain consistent without drifting. The system uses a quality score based on GPU tier and a per-user region rate, with the cost locked at job submission using the submitter's region and the earn calculated at completion using the node's region. This design prevents precision loss and allows reconstruction of any disputes via audit logs.", "body_md": "Sarva is a hub-and-spoke compute grid — a FastAPI backend, a Next.js 14 dashboard, and a Python node agent that runs on contributor machines. This post is not about the hub-and-spoke pattern (that one is well-trodden). It's about the one piece of business logic I was most worried about getting right: the moment a job is assigned, how do you decide what it *costs* the submitter, what the node *earns*, and how do you make sure the audit log captures enough state to reconstruct any disagreement after the fact.\n\nI am writing this after the third time I rewrote `submit_job`\n\nand `complete_job`\n\n. The first two versions diverged — they used different `gr()`\n\nlookups, different rounding, and a \"credit\" abstraction that quietly lost precision. This is the version that has been live on Railway for the last few weeks, and it is the one I am willing to defend.\n\nThere are two multiplier functions, both tiny:\n\n```\nGPU_MULT = {\n    \"rtx-4090\": 3.0, \"rtx-5090\": 3.0, \"rtx-3090\": 2.5,\n    \"rtx-4070\": 2.5, \"rtx-3060\": 2.0, \"rtx-2070\": 2.0,\n    \"gtx-1080ti\": 1.5, \"gtx-1080\": 1.5, \"gtx-1660\": 1.3, \"cpu\": 0.8\n}\nGEO_RATE = {\"in\": 0.7, \"india\": 0.7, \"us\": 1.0, \"uk\": 1.0, \"eu\": 0.95}\nPLATFORM_FEE = 0.20\n\ndef qs(g: str) -> float: return GPU_MULT.get(g.lower(), 1.0)\ndef gr(r: str) -> float: return GEO_RATE.get(r.lower(), 1.0)\n```\n\n`qs()`\n\nis the **node's** quality score — set once at registration, never changes. `gr()`\n\nis a **per-user** region rate. Both functions are called on the cost side *and* the earn side. The catch is *whose* `gr()`\n\nyou use on each side, and that asymmetry is intentional.\n\n``` python\n@app.post(\"/jobs/submit\")\ndef submit_job(type: str, submitter_id: str, script: str = None,\n               slices: int = 1, priority: int = 0,\n               db: Session = Depends(get_db)):\n    user = db.query(User).filter(User.id == submitter_id).first()\n    if not user:\n        raise HTTPException(status_code=404, detail=\"User not found\")\n    gpu_cost = {\"ml\": 2.5, \"gaming\": 3.0, \"compute\": 1.0}.get(type.lower(), 1.0)\n    cost = slices * gpu_cost * gr(user.region)        # ← submitter's region\n    final_cost = 0.0 if user.tier == UserTier.GOD else cost\n    if user.tier != UserTier.GOD and user.balance < final_cost:\n        raise HTTPException(status_code=400,\n            detail=f\"Insufficient credits. Need {final_cost}, have {user.balance}\")\n    job = Job(id=job_id, type=type, status=JobStatus.PENDING,\n              submitter_id=submitter_id, script=script,\n              slices=slices, credits_cost=final_cost, priority=priority)\n    db.add(job)\n    if user.tier != UserTier.GOD:\n        user.balance -= final_cost\n        user.spent_total += final_cost\n        tx = Transaction(... type=\"spend\", amount=-final_cost, ...)\n        db.add(tx)\n    audit(db, \"job_submitted\", {\"job_id\": job_id, \"type\": type, \"submitter_id\": submitter_id})\n    db.commit()\n```\n\nTwo things to notice:\n\n`gr(user.region)`\n\nis the `Job.credits_cost`\n\nis locked at submission time. If the node that eventually runs the job is in a different region, that does \n\n``` python\n@app.post(\"/jobs/{job_id}/complete\")\ndef complete_job(job_id: str, result_cid: str = None, error: str = None,\n                 db: Session = Depends(get_db)):\n    job = db.query(Job).filter(Job.id == job_id).first()\n    # ... mark COMPLETED / FAILED ...\n    if job.assigned_node_id:\n        node = db.query(Node).filter(Node.id == job.assigned_node_id).first()\n        if node:\n            node.status = NodeStatus.ONLINE\n            if job.credits_cost > 0 and not error:\n                earn_mult = qs(node.gpu_tier) * gr(node.region)   # ← node's region\n                earned = job.credits_cost * earn_mult * (1 - PLATFORM_FEE)\n                owner = db.query(User).filter(User.id == node.owner_id).first()\n                if owner:\n                    owner.balance += earned\n                    owner.earned_total += earned\n                    tx = Transaction(..., type=\"earn\", amount=earned,\n                                     job_id=job_id, ...)\n                    db.add(tx)\n    audit(db, \"job_completed\", {\"job_id\": job_id, \"error\": error})\n    db.commit()\n```\n\n`gr(node.region)`\n\nhere is the *node's* region, not the submitter's. A node in India running a job submitted by a US user gets 0.7x — the cheaper-region rate flows through to the earner. This is symmetric in spirit (cheap power → cheap earn), but the two `gr()`\n\ncalls are in different functions, hours apart in real time, and called with different arguments. That asymmetry used to be a source of bugs. I eventually settled on the rule: \"use the subject's region, always.\"\n\n`PLATFORM_FEE = 0.20`\n\nis taken *off the top of the earn*, not added to the cost. So the 20% comes from what the node would have earned, not from the submitter's pocket. This is the part where a lot of decentralized-compute projects get the framing wrong: \"we take 20% from the worker\" sounds bad; \"the worker keeps 80% of whatever the submitter paid\" sounds fine. They are the same number. The latter framing is what we ship.\n\nThe credit math is small enough to hold in your head. The reason I sleep at night is `audit(db, ...)`\n\n. Every state-changing operation writes a row to `audit_logs`\n\nwith a `type`\n\nand a `data`\n\nJSON blob:\n\n``` python\ndef audit(db: Session, log_type: str, data: dict):\n    log = AuditLog(id=uuid.uuid4().hex[:12], type=log_type, data=data)\n    db.add(log)\n```\n\nThe events I currently log: `user_registered`\n\n, `node_registered`\n\n, `job_submitted`\n\n, `job_assigned`\n\n, `job_completed`\n\n, `topup`\n\n, `cashout`\n\n. The `data`\n\nblob is *whatever I have at the time of the call* — it is not normalized. That is a deliberate choice. The alternative is a clean event schema, but clean event schemas are how you end up with `event_v2`\n\nand a migration that nobody wants to run. The JSON blob is messy but it is *complete*: if a node owner and the platform disagree about whether a job ran, the audit log has the `job_id`\n\n, the `node_id`\n\n, the `error`\n\nfield, and the timestamp. I can replay the credit math from the audit log and the immutable `transactions`\n\ntable to figure out who owes whom what.\n\nThere is a `/logs`\n\nendpoint that returns the most recent 50 entries. It is the first thing I check when somebody opens a ticket.\n\n`gr()`\n\nsnapshot on the Job row.`Job`\n\ntable stores `credits_cost`\n\n(locked), but not the `gr()`\n\nvalue at submission time. If we ever change the `GEO_RATE`\n\ndict and a dispute arises, the audit log + transactions table is enough to reconstruct — but it is annoying, not instant. I am 70% convinced this is fine and 30% convinced I should add a `cost_gr_snapshot`\n\ncolumn to the Job row tomorrow.`users.balance`\n\nis the source of truth, but I do not yet have a job that walks every user's transactions and asserts `balance == sum(tx.amount)`\n\n. I run this query by hand once a week. It is fine for a few hundred users. It is not fine at 10,000.`MIN_DISK_GB`\n\nenforcement on assignment.`diskFreeGb`\n\nat registration but the orchestrator does not check it before handing out a job. This is on the list.`final_cost = 0.0 if user.tier == UserTier.GOD else cost`\n\nlets the `god`\n\nuser submit anything for free. That is intentional for dev, but it is `god`\n\nuser ID in production would be a small catastrophe. I am aware.The pricing formula is the single thing I would want a second pair of eyes on. Specifically:\n\n`PLATFORM_FEE`\n\nbe a flat 20%, or should it scale with `slices`\n\n(lower for short jobs, higher for long ones) so that the platform has a stronger incentive to keep cheap jobs flowing?Sarva is open source at [github.com/AmSach/sarva](https://github.com/AmSach/sarva) — the monorepo is `/backend`\n\n(FastAPI + Postgres), `/frontend`\n\n(Next.js 14), and `/node`\n\n(Python agent). The backend is live on Railway, the dashboard is on Vercel, and the node agent is a single-file Python script you can run on any machine with `HUB_URL`\n\nand `AUTH_TOKEN`\n\nset.\n\nIf you have shipped a two-sided credit ledger before, I'd genuinely like to know whether the audit-blob approach scales or whether I am about to regret it. Comments welcome.\n\nTags: python, fastapi, opensource, distributed", "url": "https://wpnews.pro/news/how-sarva-keeps-the-same-gpu-multipler-on-the-cost-side-and-the-earn-side-the", "canonical_source": "https://dev.to/aman_sachan_126d19c4a2773/how-sarva-keeps-the-same-gpu-multipler-on-the-cost-side-and-the-earn-side-without-the-ledger-1b1c", "published_at": "2026-06-20 01:37:09+00:00", "updated_at": "2026-06-20 02:36:42.406901+00:00", "lang": "en", "topics": ["ai-infrastructure", "developer-tools"], "entities": ["Sarva", "FastAPI", "Next.js", "Railway"], "alternates": {"html": "https://wpnews.pro/news/how-sarva-keeps-the-same-gpu-multipler-on-the-cost-side-and-the-earn-side-the", "markdown": "https://wpnews.pro/news/how-sarva-keeps-the-same-gpu-multipler-on-the-cost-side-and-the-earn-side-the.md", "text": "https://wpnews.pro/news/how-sarva-keeps-the-same-gpu-multipler-on-the-cost-side-and-the-earn-side-the.txt", "jsonld": "https://wpnews.pro/news/how-sarva-keeps-the-same-gpu-multipler-on-the-cost-side-and-the-earn-side-the.jsonld"}}