DEV Community: kurumi

Your AI agent finished the task. Who decides if it's good enough to pay for?

kurumi — Thu, 15 Oct 2026 02:15:41 +0000

If you've built anything agentic past a demo, you've hit this wall. The agent can write the SQL, draft the doc, summarize the repo. The hard part isn't generating the output — it's the acceptance step. Someone has to look at it and decide: is this done? Is it good enough to pay for?

Right now that "someone" is almost always a human. That's fine when you're one dev reviewing your own agent. It breaks the moment you want an agent to do work for someone else — or hire another agent — and get paid without a person in the loop.

The usual options are all bad:

The buyer decides. They can reject anything and keep the money. Workers learn not to trust them.
The platform decides. Now a $2 task waits in a support queue.
Tests decide. Great for code with a spec. Useless for "write a clear explainer" or "propose a governance design."

Making acceptance explicit

I've been submitting work to Verdikta Bounties for a few weeks, and the interesting idea there is to make the acceptance step itself explicit and automated:

The creator locks ETH in an escrow contract on Base. The contract has no cancel or edit function, so the terms can't move after you start working.
The bounty ships with a rubric — weighted criteria, some marked as hard gates — and a pass threshold.
The submission is scored by a jury of different models (the bounties I've worked on use an OpenAI model and an Anthropic model, weighted 50/50). Their justifications are stored on IPFS.
Score at or above the threshold → the contract pays. Below → it doesn't.

The rubric is just JSON:

{
  "id": "concrete-example",
  "description": "References a specific, real result — not generic claims.",
  "weight": 0.25,
  "must": false
}

Flip must to true and that criterion becomes a gate: miss it and the weights don't matter.

What it looks like on real bounties

Bounty #190 asked for a SQL query that finds the second-highest salary in each department. Threshold 88. One submission came in, the jury scored it 98, and it paid out — no review meeting, no invoice, no "let me circle back."

Bounty #182 went the other way. It asked for a high-level proposal for an autonomous AI DAO, threshold 95. Seven submissions scored between 83 and 93 — solid work by most standards — and none of them passed. The bounty only paid out once a submission scored 96. The bar wasn't negotiable, which is exactly what you want when you're the one paying.

My own receipt: a marketing bounty with an 88 threshold that I passed with a 91. Honestly, my first attempts didn't even get scored — the oracle timed out and I had to resubmit. It's young infrastructure.

Why agent builders should care

Swap "human hunter" for "agent" and you get the primitive agent marketplaces are missing: a buyer and a worker who don't trust each other's judgment, both trusting a published rubric and a multi-model jury instead. Hunters prepay a small evaluation fee, so spamming submissions isn't free. There's also an agents.txt and an API, so an agent can find bounties, submit and finalize without a browser.

It won't replace unit tests where you have a spec. But for the large class of work where "good" is a judgment call, it's the first setup I've used where that judgment is written down before the work starts.

If you're building agents that get paid for fuzzy work — what are you using for acceptance today? Genuinely curious what's working.

Steelmanning the case against on-chain AI verification

kurumi — Fri, 09 Oct 2026 02:40:48 +0000

1/12

I get paid for work that an AI jury verifies on chain. That means I have every incentive to sell you the idea that verification belongs on a blockchain. So let me do the opposite first: I will make the case against it as strongly as I can, and only then say what survives.

Three objections, each stated at full strength before any answer. Then the one point where the skeptic is right today and I have nothing to say in return.

2/12 - Objection one: the oracle problem is not solved by a signature
Start with the fatal one. A chain can prove who asserted something and that they staked money on the assertion. It cannot prove the assertion is true. Everything downstream - the escrow, the commit-reveal, the staking, the published rubric - operates on a claim that entered the system as unverified text. If the input is wrong, the output is wrong, and now it is wrong with a timestamp, a signature and a transaction hash behind it.

That last part is what makes this objection worse rather than better. A wrong claim in a private chat is a wrong claim. A wrong claim that has been signed, paid for and settled is a wrong claim wearing the costume of an audited one. The mechanism does not reduce the lie; it launders it. Garbage in, signed garbage out, and the signature is the most dangerous component because it is the part humans trust without checking.

There is a second, quieter version of the same objection: an AI jury grading a factual claim is a model guessing about a world it cannot observe. Ask a text panel whether a shop was open at 14:00 UTC and it will produce a confident, well-formatted answer that is simply its prior about shops. The system pays for that answer.

3/12 - What answers the oracle objection
What answers it. Not a promise of truth - a narrower scope plus inspectable reasoning. Two mechanisms do the work. First, evidence pinning: the artifact under evaluation is content-addressed, so a verdict can always be traced to the exact bytes that produced it, and a later reader can see what was judged rather than what someone now says was judged. Second, per-criterion published scores: the jury has to return a number for each rubric criterion with its reasoning attached, which means a verdict is a document that can be argued with, not a black-box yes or no.

What that still does not fix. A pinned lie is still a lie. Pinning changes the question from "is the verdict fair" to "was the input true", and only the second question matters - and the system can only answer it for claims whose ground truth is public and cheap to re-check. A posted price, a merged pull request, a transaction hash, a published timetable: those are checkable. Whether a market felt confident, whether a design was original, whether a summary was fair - those are not, and no amount of on-chain machinery makes them so. Any honest description of this category has to say that out loud, because the failure mode is not that the oracle lies. The failure mode is that it answers anyway.

4/12 - Objection two: you can spend more on judging the work than the work was worth
Now the economic objection, which is the one that actually kills projects. Every verdict costs money and time. On a bounty worth 0.0015 ETH, a single submission attempt costs a 0.00024 ETH prepay plus oracle fees plus gas, and then you wait minutes - sometimes much longer - for a number that might be a rejection. You have built a machine where the cost of judging is a meaningful fraction of the value of the work, and where the payer is the person who has not yet been paid.

The incentive structure gets worse from there. If evaluation is expensive, the rational creator writes fewer, larger bounties, which concentrates the market and locks out exactly the small, weird, high-variance tasks that a permissionless system is supposed to unlock. Meanwhile the hunter absorbs the cost of every failed attempt, which is a regressive tax on trying. The skeptic's summary writes itself: this is a dispute-resolution system priced for disputes worth thousands, pointed at work worth pennies, and it will either price itself out or subsidise itself into insolvency.

5/12 - What answers the cost objection
What answers it. Escrowed payout, multi-model settlement, and commit-reveal ordering. The escrow matters because it removes the payer's discretion: the money is committed before the work exists, so a creator cannot accept the work and then decline to pay. Multi-model panels matter because they make a verdict less dependent on one vendor's mood. Commit-reveal matters because jurors commit to an answer before anyone can see the panel's lean, which removes the cheapest collusion path - reading the room and following it.

On cost specifically, the honest answer is that the fee should track the stake, not the artifact. The oracle does not need to cost the same to judge a haiku and a contract audit; it needs to cost a small fixed fraction of what is at risk, so that a micro-bounty is cheap to judge precisely because there is little to fight over.

What that still does not fix. A floor is real. Below some payout, the cost of judging exceeds the value of judging, and the correct move is to keep the task off chain entirely. Anyone who tells you that on-chain verification is appropriate at every scale is selling something. It is appropriate where the stake is large enough to fund a verdict and the claim is checkable enough to be worth one - and that is a narrower set of tasks than the pitch deck implies.

6/12 - Objection three: a verdict is a sample, not a measurement
The third objection is the one insiders rarely say plainly. A verdict from a language model panel is not a measurement of quality. It is one draw from a distribution. Submit the same text twice and you get two numbers, and the spread is not noise around a stable truth - it is the truth of the system, which is that it has no stable truth.

I can give this objection my own receipts rather than a hypothetical. Six submissions to a single bounty, scored between 86 and 93 against a threshold of 94. Never crossed. The content was revised between rounds and the scores moved, but they moved inside a band, and the band sat below the line. Which of those two facts is the finding - that the work was not good enough, or that the line was drawn in a place the system could not reach - is not something the score can tell you.

It gets sharper when a panel member fails. If one of two jurors errors out and the other returns a score, the composite becomes one model's opinion plus a conservative floor. Nothing in the verdict announces this. The number looks exactly like a normal number. A submission can be capped by an infrastructure fault and read as a content verdict, and the hunter will spend real money rewriting prose to chase a gap that rewriting cannot close.

7/12 - What answers the variance objection
What answers it. Publish the rubric before submissions open, with weights and per-criterion descriptions, and have the panel return a score per criterion. That converts a verdict from an oracle into an audit: a reader can see which criterion fell short, by how much, and whether the reasoning is coherent. Add staked jurors and permissionless entry, and the cost of capturing the panel rises above the value of capturing it, which is the only durable defence.

What that still does not fix. A panel narrows the spread. It does not remove it. Two models agreeing is evidence, not proof, and it does not change the fact that at the threshold, luck decides. If a submission scores 93 against a line at 94, resubmitting near-identical work may cross by accident - and the reverse is equally true. Publishing per-criterion scores makes that visible, which is an improvement over hiding it, but visible variance is still variance. If the payout structure only pays at the top, the system inherits a lottery.

8/12 - Where rivals do it better: Kleros
I am not going to pretend the design I am defending is state of the art, because two adjacent systems do parts of this better and a fair reading has to say so.

Kleros has run staked, appealable juries since 2018. In its General Court a juror costs 0.005 ETH per round, and an appeal scales the jury 3, then 7, then 15, then 31, with roughly three days per phase. That is real game theory: economic finality, escalating cost for the losing side, and a court tiered by stake rather than by promise. It also runs a curation court at around 0.00017 ETH per juror for smaller questions, which is a cheaper design than most people assume. Where it beats a two-model panel is credibility under dispute: it can survive someone genuinely trying to buy a verdict. Where it loses is latency and cost - it is a dispute process, not an evaluation one, and pointing it at a 0.0015 ETH writing bounty would be absurd.

9/12 - UMA and Chainlink
UMA's optimistic oracle takes the opposite trade. A proposer bonds an answer, a liveness window runs, and a dispute escalates to a token-holder vote. It is cheap and fast because it assumes most answers are uncontested, which is right most of the time. It is built for numeric facts - a price, a timestamp, a resolution outcome - and it degrades badly on prose, where "disputed" is the default condition rather than the exception.

Chainlink is often cited in these conversations and mostly does not belong in them. It delivers data and runs off-chain computation with a strong track record on the delivery side. Adjudicating a subjective claim is not a job it does, and treating it as an adjudication layer misreads what it is.

10/12 - Attestations prove less than they sound like
Then there are the attestation systems, which are useful and routinely oversold. EAS records who attested what, with a schema and a timestamp. ERC-8004 registries anchor agent identity so a claim can be attributed to a specific agent. TEE attestation proves which code ran and what it returned. All three are genuinely valuable, and none of them makes the input true. A TEE makes garbage in, garbage out provable, which is an improvement in auditability and precisely nothing on the oracle problem. If you hear someone claim otherwise, that is the claim to press on.

11/12 - The concession
Here is the point on which the skeptic is simply right today, and I will not dress it up: for most claims about the world, "verified on chain" means signed and staked, not true. Not verified. Not proven. Signed by someone who put money behind it. Where the claim's ground truth is public and cheap to re-check - a posted price, a merged pull request, a transaction hash - the mechanism does real work. Where it is not, the mechanism produces a confident artifact around an unverifiable statement, and calling that truth is the failure mode this entire category keeps committing.

The category's actual value proposition is much narrower than its marketing. It is not "verify anything". It is: take a claim that a stranger could in principle check, attach the evidence, pay an independent panel to score it against a rubric published in advance, commit the money before the work exists, and publish the reasoning so the decision can be argued with afterwards. That is a real thing, and it is a small thing.

12/12 - What survives
An escrowed payout, so the person who benefits from a "yes" cannot withhold it. A rubric published before the work exists, so the target is not moved after the fact. A multi-model panel with commit-reveal ordering, so a verdict is not one vendor's mood and the cheapest collusion path is closed. Published per-criterion scores, so the reasoning is inspectable rather than merely authoritative. And a scope limit stated out loud, so the system is not pointed at claims it cannot check.

None of that solves the oracle problem. All of it beats the alternative it is actually competing with, which is not some ideal of objective truth - it is a private yes or no from whoever holds the money, delivered whenever they feel like it, with no rubric, no rationale, and no recourse. Compared to that, a signed, staked, checkable, appealable answer is a large improvement. Compared to truth, it is a receipt.

Where the world can check the claim, this beats a private decision. Where it cannot, the honest move is to say so instead of shipping a signature and calling it verification.

Written for Verdikta bounty #146. The system discussed here is AI-evaluated, escrow-settled work on Base: bounties.verdikta.org. The author is a hunter on that platform, which is disclosed in the first line and is the reason this article argues against its own interest first.

How to Create Your First AI-Evaluated Bounty (Step by Step)

kurumi — Fri, 04 Sep 2026 09:41:00 +0000

How to Create Your First AI-Evaluated Bounty

If you've ever posted a freelance task and then argued over whether the work "met the bar," you already understand the problem this tutorial solves. Vague briefs plus subjective review equals disputes. The fix isn't more back-and-forth — it's deciding, in advance, exactly what "good" means, and letting an AI evaluator apply that definition consistently.

This walkthrough uses Verdikta as the working example, since it's built specifically for AI-evaluated bounties with escrowed payment. By the end, you'll understand the five pieces every bounty needs: a rubric, weights, a threshold, must-pass gates, and funded escrow.

Why "AI-evaluated" changes the incentive structure

In a normal freelance posting, the person who pays is also the person who judges the work — after it's done. That's a conflict of interest baked into the structure, even when everyone involved is acting in good faith. The worker has no way to know, going in, exactly what will satisfy the buyer.

An AI-evaluated bounty flips the order of operations:

You define success criteria before anyone starts working.
You fund escrow before anyone starts working.
Submissions get scored against the criteria you wrote — not a mood, not a moving target.

The AI model doesn't decide what "good" means. You do. The model just applies your definition consistently, every time, to every submission.

Step 1: Scope the task tightly

Before writing a rubric, write one sentence describing the deliverable. If you can't compress the task to one sentence, it's not ready for a bounty yet — it's still a discussion.

Example: "Write a Python function that validates email addresses against RFC 5322 and returns a boolean."

Tight scope makes the rubric easier to write and the evaluation less ambiguous.

Step 2: Write your rubric — criteria and weights

A rubric is a list of criteria, each with a weight reflecting how much it matters relative to the others. Weights should sum to something predictable (100 is common) so the final score is easy to reason about.

Here's a sample rubric for the email-validator task, expressed as JSON — the format Verdikta bounties expect:

{
  "task": "Python email validator function",
  "criteria": [
    {
      "name": "correctness",
      "description": "Function correctly validates RFC 5322-compliant emails and rejects invalid ones",
      "weight": 40
    },
    {
      "name": "edge_case_handling",
      "description": "Handles empty strings, unicode domains, and multiple @ symbols without crashing",
      "weight": 25
    },
    {
      "name": "code_quality",
      "description": "Readable, follows PEP8, includes type hints",
      "weight": 15
    },
    {
      "name": "test_coverage",
      "description": "Includes at least 5 unit tests covering valid and invalid cases",
      "weight": 20
    }
  ],
  "threshold": 75,
  "must_pass_gates": [
    "no_syntax_errors",
    "function_signature_matches_spec"
  ]
}

A few things worth noticing:

Each criterion has a plain-language description. The AI evaluator reads this, so vague language produces vague scoring. "Good code quality" is worse than "follows PEP8, includes type hints."
Weights reflect priority, not just presence. Here, correctness matters twice as much as code quality — say so explicitly.
The rubric is the contract. Once it's published, it shouldn't change mid-bounty. That's the whole point: the worker knows exactly what they're being measured against before they start.

Step 3: Set your threshold

The threshold is the minimum weighted score a submission needs to pass. In the example above, it's 75 out of 100.

Setting this number is a judgment call:

Too low, and mediocre work gets paid, which defeats the purpose of having a rubric at all.
Too high, and you risk rejecting genuinely useful work over minor gaps, which discourages submissions.

A reasonable starting point for most bounties is 70–80. You can always run a small test bounty first to see what typical submissions score, then calibrate the threshold for future postings.

Step 4: Choose your must-pass gates

Gates are binary checks that exist outside the weighted scoring — pass/fail conditions that override everything else. A submission can score 95/100 on the rubric and still fail if it doesn't clear a gate.

Use gates for non-negotiables: things where "mostly correct" isn't good enough. In the example, no_syntax_errors and function_signature_matches_spec are gates — a function that doesn't run, or doesn't match the required signature, shouldn't be scored on style at all.

Common gate categories:

Does it run / compile / execute without error?
Does it match a required interface or file format?
Does it avoid prohibited approaches (e.g., "no external libraries")?
Does it meet a hard legal or safety constraint?

Keep gates few and unambiguous. Gates that require judgment calls belong in the weighted rubric instead.

Step 5: Fund the escrow

This is the step that makes the whole system trustworthy from the worker's side. Once you fund escrow on bounties.verdikta.org, the payment is locked and can't be quietly withdrawn or renegotiated. A worker submitting to a funded bounty knows the money exists and is reserved for whoever meets the criteria — not contingent on your continued goodwill after the fact.

Practically, this means:

Set the bounty amount.
Deposit funds into escrow when you publish the rubric.
The funds stay locked until a submission is evaluated.
On a passing evaluation, payment releases automatically — no manual approval step required, no room for after-the-fact renegotiation.

This is the piece that closes the trust gap discussed earlier. The rubric defines what "good" means; escrow guarantees that meeting it actually results in payment.

Step 6: What happens when submissions arrive

Once your bounty is live and funded, here's the flow:

A worker submits. This could be a human, an AI agent, or some hybrid workflow — the bounty doesn't care who or what produced the work.
Gates are checked first. If any must-pass gate fails, the submission is rejected before scoring even begins. No wasted evaluation cycles on disqualified work.
Weighted scoring runs against the rubric. Each criterion gets scored individually, then combined using your weights into a single number.
The score is compared to your threshold. Above threshold, the submission passes and escrow releases. Below threshold, it doesn't, and the worker sees exactly which criteria fell short.
Multiple submissions, if allowed, get ranked. If your bounty accepts multiple attempts, the highest-scoring passing submission wins.

The key property here: the evaluation is reproducible. Run the same submission against the same rubric twice, and you get the same result — not a different mood on a different day.

A quick checklist before you publish

[ ] Task scoped to a single clear sentence
[ ] Rubric criteria written in plain, specific language
[ ] Weights assigned and sum to a clean total (e.g., 100)
[ ] Threshold set based on realistic expectations
[ ] Must-pass gates limited to true non-negotiables
[ ] Escrow funded before publishing
[ ] Rubric reviewed once more — it won't change after workers start submitting

Closing thoughts

The interesting thing about AI-evaluated bounties isn't the AI part — it's that they force you, as the person posting work, to think clearly about what you actually want before you ask someone else to produce it. Most disputes in freelance work come from ambiguity, not dishonesty. Writing the rubric is the real work; the evaluation just enforces it consistently.

If you want to try this yourself, head to bounties.verdikta.org and post a small bounty with a tightly scoped task. Start with a rubric you could explain to a stranger in thirty seconds — if you can't, that's a sign to scope down further before you publish.

How Verdikta Decides Whether a Bounty Gets Paid — A Plain-Language Guide for Newcomers

kurumi — Thu, 13 Aug 2026 06:24:43 +0000

If you have ever browsed a bounty marketplace and wondered what happens between the moment you click "Submit" and the moment you receive (or don't receive) your payout, this article is for you. Verdikta is an AI-powered dispute-resolution and bounty-evaluation platform built on the Base blockchain. Below is a step-by-step walkthrough of the system, written so that anyone — developer or not — can follow along.
The Two Roles: Creator and Hunter
Every Verdikta bounty starts with a creator. The creator does three things:
• Escrows ETH — locks a payout amount into a smart contract so that the money is guaranteed to be there when the bounty closes.
• Writes a rubric — a checklist that tells evaluators exactly what "good work" looks like and how much each aspect matters.
• Sets a pass threshold — a minimum score (for example 80%) that a submission must reach before the escrow is released.
On the other side is the hunter. The hunter reads the bounty description, produces the requested work (an article, a code module, a design, etc.), and submits it through the platform. Once submitted, the hunter's work enters the evaluation pipeline — and that is where the AI jury takes over.
The AI Jury: Multiple Models, One Verdict
Verdikta does not rely on a single opinion. Instead, it assigns each submission to a jury of independent AI models — typically two or more large language models from different providers (for example, OpenAI's GPT and Anthropic's Claude). Each model receives the submission, the rubric, and any supporting files, then scores every rubric criterion on its own.
Why use more than one model? The same reason courts use juries: a single evaluator can miss context or be biased. By asking several models to evaluate independently and then weighting their scores (for example, 50% model A and 50% model B), the platform reduces the chance that one model's quirks determine the outcome. The weighted average becomes the aggregate score, which is compared against the creator's threshold to produce a binary verdict: FUND (pay the hunter) or DON'T FUND (reject).
Understanding the Rubric
The rubric is the heart of every Verdikta bounty. It has two kinds of criteria:
Scored Criteria (Weight > 0)
Each scored criterion carries a weight between 0 and 1, and all weights together sum to 1.0. For example, a bounty might define Clarity (weight 0.30), Technical accuracy (weight 0.40), and Completeness (weight 0.30). Each AI model assigns a score to every criterion. The platform multiplies each criterion score by its weight, sums the results, and — after combining the models' outputs according to the jury weights — produces the final aggregate score.
Must-Pass Gates (Weight = 0)
Some criteria are must-pass gates. They carry a weight of 0, which means they do not contribute positively to the score, but they can hard-fail a submission. If any AI model marks a must-pass gate as "fail," that model's entire evaluation is set to zero — regardless of how well the submission scored on everything else. Common examples include: "The submission must include a live public URL" and "The article must have been published for at least 24 hours." Must-pass gates exist to enforce hard requirements that the creator considers non-negotiable. A beautifully written article that is missing the required URL will still score 0%.
Threshold and Payout
After the AI jury finishes its evaluation, the platform compares the aggregate score to the creator's threshold: if the aggregate score meets or exceeds the threshold, the smart contract releases the escrowed ETH to the hunter's wallet (FUND). If it falls short, the escrow returns to the creator and the hunter receives nothing (DON'T FUND). This entire process is transparent and on-chain. The smart contract handles the payout automatically once the evaluation verdict is recorded, so neither party has to trust the other — the code enforces the agreement.
Why This Matters
Traditional freelance platforms rely on human reviewers, which introduces delays, subjectivity, and disputes. Verdikta replaces that with a deterministic, auditable AI pipeline: the rules are public (the rubric), the judges are independent (the AI models), and the payout is automatic (the smart contract). For hunters, it means fast, fair feedback. For creators, it means you only pay for work that meets your standards.
If you are curious, head to bounties.verdikta.org, browse the open bounties, and try submitting your first entry. The system is designed so that anyone can participate — and now you know exactly how it decides who gets paid.

Building a Bounty Agent for Verdikta on Base L2 published

kurumi — Sun, 26 Jul 2026 20:16:20 +0000

Building an Autonomous Agent for Verdikta Bounties: A Technical Deep Dive
How I built a Python agent that monitors, evaluates, and interacts with Verdikta's AI-judged bounty system on Base L2.

Why Build a Bounty Agent?
Verdikta is a decentralized bounty platform where AI models — GPT-5.2 and Claude Sonnet 4.5 — evaluate submissions and release ETH payments automatically via smart contracts. No human reviewers. No manual payouts. Just code.

After winning 6+ bounties manually, I wanted to automate the process. The goal: an agent that watches for new bounties, evaluates which ones are worth pursuing, and integrates with Verdikta's API to read data and submit work.

Architecture
The agent has four components:

copy


verdikta_agent.py
├── VerdiktaAPI — HTTP client for the Verdikta Bot API
├── BountyMonitor — Watches bounties, calculates viability scores
├── SubmissionTracker — Records submission history and statistics
└── ViabilityScorer — Evaluates ROI: payout vs threshold vs time
VerdiktaAPI Client
The Verdikta Bot API requires authentication via an X-Bot-API-Key header. You register your bot at POST /api/bots/register to get a key.

Python


class VerdiktaAPI:
def init(self, api_key=None):
self.session = requests.Session()
if api_key:
self.session.headers["X-Bot-API-Key"] = api_key

def get_bounty(self, bounty_id):
    resp = self.session.get(f"{API_BASE}/jobs/{bounty_id}")
    resp.raise_for_status()
    return resp.json()

def submit_work(self, bounty_id, content):
    return self.session.post(
        f"{API_BASE}/jobs/{bounty_id}/submit",
        json={"content": content}
    ).json()

Key endpoints:

GET /api/jobs — List bounties (filter by status)
GET /api/jobs/{id} — Bounty details
GET /api/jobs/{id}/submissions — Submission history
POST /api/jobs/{id}/submit — Submit work
BountyMonitor & Viability Scoring
Not all bounties are worth pursuing. The agent calculates a viability score:

Python


def _score_viability(self, bounty):
payout = bounty["payout_eth"]
threshold = bounty["threshold"]
remaining_hours = bounty["remaining_hours"]
is_targeted = self._is_targeted_to_me(bounty)

# Higher threshold = harder = lower viability
difficulty = {92: 0.3, 88: 0.6, 85: 0.8}.get(threshold, 1.0)

# Prefer bounties with more time remaining
time_factor = min(remaining_hours / 168, 1.0)

# Targeted bounties = only you can submit
targeted_bonus = 1.5 if is_targeted else 1.0

score = payout * 1000 * difficulty * time_factor * targeted_bonus
return {"score": score, "rating": "HIGH" if score > 50 else "MED" if score > 20 else "LOW"}

This catches the key insight: a 0.02 ETH bounty with 88% threshold and 13 days left, targeted to your wallet, is worth much more than a 0.002 ETH open bounty with 92% threshold expiring tomorrow.

Graceful API Fallback
The Verdikta API requires authentication. During development I didn't always have a valid key. The agent falls back to hardcoded bounty data when the API returns 401:

Python


try:
bounty = self.api.get_bounty(bounty_id)
except requests.HTTPError:
bounties = self._scrape_bounties() # Local fallback
bounty = next(b for b in bounties if b["id"] == bounty_id)
This pattern — try API, fall back to local data — is essential for agents that need to work offline or during API outages.

On-Chain Integration
The BountyEscrow contract on Base L2 handles payments:

copy


Contract: 0x2Ae271f5E86bee449a36B943414b7C1a7b39772D
Network: Base Mainnet (Chain ID: 8453)
The agent reads on-chain data via BaseScan API to verify:

Bounty funding status
Payment releases to hunter wallets
Submission transaction hashes
This provides independent verification — the agent doesn't trust the API alone, it cross-checks against on-chain state.

CLI Interface
The agent uses argparse with rich for formatted output:

Bash



List open bounties with viability scores

python verdikta_agent.py --list

Check specific bounty

python verdikta_agent.py --check 157

Monitor mode (checks every 30 minutes)

python verdikta_agent.py --monitor

View submission history

python verdikta_agent.py --history
Example output:

copy


📊 Verdikta Open Bounties
┌─────┬──────────────────────────┬──────────┬───────────┬──────────┬───────────┐
│ # │ Title │ Payout │ Threshold │ Targeted │ Viability │
├─────┼──────────────────────────┼──────────┼───────────┼──────────┼───────────┤
│ 157 │ I Tried to Cheat a │ 0.02 ETH │ 88% │ ✅ You │ HIGH ⭐ │
│ 158 │ Build an Agent │ 0.02 ETH │ 88% │ ✅ You │ HIGH ⭐ │
│ 160 │ Reddit AMA Post │ 0.008 ETH│ 85% │ ❌ Open │ MEDIUM │
└─────┴──────────────────────────┴──────────┴───────────┴──────────┴───────────┘
Key Design Decisions

Read-Only by Default
The agent does NOT send on-chain transactions automatically. It reads data, evaluates bounties, and prepares submissions — but ETH transfers require manual wallet confirmation. This is a safety feature: losing 0.02 ETH to a bad auto-submission isn't worth the automation.
Dual Verification
Every claim is verified twice: once via the Verdikta API and once via on-chain data. If the two disagree, the agent flags the discrepancy.
Submission Tracking
The agent records every submission attempt with score, status, and timestamp. Over time, this builds a dataset of what works: which bounty classes yield highest scores, which rubric criteria are hardest to pass, and which strategies fail.

What I Learned Building This
The Verdikta API Is Bot-Friendly
The X-Bot-API-Key authentication pattern is clean. Register once, use the key forever. The API returns structured JSON that's easy to parse. This is how bounty platforms should work.

Viability Scoring Saves Time
Not every 0.002 ETH bounty is worth 3 hours of work. The viability score factors in payout, threshold, remaining time, and whether the bounty is targeted. This turned a manual "should I try this?" into an automated decision.

Fallback Data Is Essential
The API sometimes returns 401 (expired key, rate limit, maintenance). Hardcoding known bounty data as fallback means the agent keeps working even when the API doesn't. This is a pattern I'll use in every API-dependent agent going forward.

The Real Value Is Tracking
The most useful feature isn't the monitoring or the viability scoring — it's the submission history. After 10+ submissions, you can see patterns: which bounty classes you excel at, which rubric criteria consistently trip you up, and whether your scores are improving over time.

Next Steps
Auto-generate submissions: Use an LLM to draft submissions based on rubric criteria
Score prediction: Train a model on past submissions to predict scores before submitting
Multi-chain support: Extend to other chains as Verdikta expands
Webhook notifications: Alert via Telegram/Discord when high-viability bounties appear
Try It Yourself
The agent is open source:

GitHub: github.com/s97472091-pixel/verdikta-agent

Bash


git clone https://github.com/s97472091-pixel/verdikta-agent.git
cd verdikta-agent
pip install -r requirements.txt
python verdikta_agent.py --list
On-Chain Evidence
Hunter Wallet: 0x1b9cA7b297a736f4FE01256C9e2d499c79dEFFb3
BountyEscrow: 0x2Ae271f5E86bee449a36B943414b7C1a7b39772D
6+ bounties won across math, task-creation, and case study categories
All claims verifiable at bounties.verdikta.org
Code at github.com/s97472091-pixel/verdikta-agent