DEV Community: kurumi

Four ways to resolve a freelance dispute, and what each one actually accepts as evidence

kurumi — Sat, 31 Oct 2026 08:20:32 +0000

Every freelancer knows the sequence. The work is delivered, the client goes quiet for two days, and then: "this isn't what I asked for."

Sometimes they're right. Often they mean "this isn't what I imagined." Either way the money is now stuck between two people who disagree about a document neither of them wrote down properly.

I've been reading the actual mechanics of four dispute systems, because the interesting question isn't who wins. It's what each system treats as evidence, how long you wait for a decision, and — the part I had wrong before I started reading — who carries the risk while you wait. Four systems, four different answers.

1. Upwork fixed-price: a 14-day clock you don't control

The client funds a milestone, you deliver, the client releases. If they go quiet, the important detail is that the clock is already running: delivering through the "Submit Work for Payment" button starts a 14-day countdown to automatic payment. Approving early just ends it sooner. After 14 days the money moves unless the client has actively asked for changes.

If they do dispute it, the fixed-price path runs in stages. There's free dispute assistance (or mediation assistance, depending on whether funds were deposited), then binding arbitration run by an independent third-party company — currently Brief — rather than Upwork itself. You get seven calendar days to agree to arbitration and pay your share of the fee; in most cases the freelancer and client split it evenly, and Upwork contributes only on contracts over $20,000.

The detail that matters most is what happens if one side doesn't engage. If both parties decline arbitration, the funds go to the client. If one party pursues and pays and the other declines, the funds go to whoever participated. Declining isn't neutral — it's a forfeit.

And there's a harder deadline underneath, which the docs tie specifically to the refund-request case: once a client ends a contract with a deposited balance and asks for a refund, you have seven calendar days to review the payment details and file a dispute. Miss it, and the remaining funds go back to the client.

What it accepts as evidence: the brief, the message history, the delivered files, read by a human with context. That is genuinely the right instrument for scope creep, which is a narrative disagreement rather than a factual one.

What it costs: the arbitration fee when you need it, plus a service fee. And the outcome depends on which person reads your file and how well you wrote it up.

2. Fiverr: a 3-day auto-complete, wrapped in a tool that doesn't adjudicate

Fiverr's version is faster and blunter. Requests raised in the Resolution Center go directly to the other party — Customer Support is explicitly not notified during that exchange. Each side has 48 hours to accept or decline, and if nobody responds within 48 hours the system auto-accepts.

Two mechanics matter more than the Resolution Center itself. First, delivery auto-completes the order: if the buyer takes no action within three days of delivery — no acceptance, no revision request, no extension — Fiverr completes the order and starts the clearance clock. Two caveats keep "3 days" from being the whole story: gigs that require physical shipping auto-complete after 14 days rather than 3, and completing an order is not the same as cash in hand — Fiverr holds earnings through a safety clearance period before they can be withdrawn. Fiverr does offer an Early Payout option, but only to Top Rated and Seller Plus Premium freelancers, at a 1% fee, and auto-completed orders qualify only for Top Rated sellers. Second, the Resolution Center is unavailable once an order is complete or cancelled, so that door closes exactly when disputes usually start; for completed orders the documented path is Customer Support. Separately, an order 24 hours past its delivery date can be cancelled by the client without the freelancer's approval.

Fiverr's commission is also reported as a flat fifth of the order with no tiers or volume discount — Fiverr's own payments terms sit behind a bot wall, so I'm relying on consistent secondary reporting there rather than the primary document. Either way, the dispute mechanism isn't the only thing taking a cut.

What it accepts as evidence: very little inside the Resolution Center itself. It's a mutual-agreement tool, not an adjudication tool; its real enforcement mechanism is the cancellation button and the effect a cancellation has on your metrics.

What it costs: cheap and fast when both sides want out. When they don't, the Resolution Center itself can't decide anything — you're escalated to support, which is a human with a queue rather than an independent arbitrator. Its strongest feature is actually the three-day auto-complete, and its weakest is that the tool built for disputes doesn't adjudicate.

3. PayPal: 180 days of hindsight

PayPal inverts the whole problem. There's no milestone and no escrow: the money lands in your account when the client pays, so a client who goes quiet has already paid you. What PayPal adds instead is a second, much longer window in which that payment can be taken back — which is why the risk here isn't ghosting, it's reversal. A buyer can open an "item not received" dispute up to 180 days from the payment date. For "significantly not as described" the window is tighter — 30 days from delivery, or 180 days from payment, whichever comes first — which is actually the more relevant clock for service work, since that's the claim most likely to be filed.

Then there's a second clock almost nobody mentions: an unescalated dispute closes automatically after 20 days. If the buyer does nothing, the dispute evaporates; if they escalate it to a claim, PayPal adjudicates.

Here's where the two things get conflated, including in how most freelancers talk about it. Seller Protection for intangible work does exist, and PayPal's terms spell out the conditions: the transaction must be marked eligible, and you must supply proof of shipment or delivery — for intangible goods, "compelling evidence to show the item was delivered or the purchase order was fulfilled," such as a system of record showing the date and the recipient's address. But Seller Protection is a defence against item-not-received and unauthorised-transaction claims. It is not a defence against "significantly not as described" — and for service work that's the claim you'll actually face. On SNAD the question isn't whether you delivered, it's whether what you delivered matched the description, which is precisely the dispute a record of delivery can't settle.

Which is the practical point: a screenshot of a friendly chat is not that. A chat log is evidence you talked, not evidence you delivered.

What it accepts as evidence: delivery records and the buyer's claim, decided by PayPal under its own programme policies at its discretion. "Significantly not as described" exists as a category precisely because description is subjective — and that's the category a delivery receipt does nothing for.

What it costs: time, and a buyer-weighted default. The upsides are real though — fiat, fast, and a genuine consumer-protection rail that most crypto rails simply don't have.

4. Verdikta: pay against a published rubric, not a mood

A different primitive, and the one I've spent most time reading. Verdikta moves the criteria to before the work: the creator locks ETH in a Base escrow contract and publishes success criteria plus a pass threshold. A jury of AI models on the Verdikta network grades each submission against those criteria and reports a 0–100 score with written justifications.

The properties that actually differ from the three above:

The criteria, threshold and deadline are fixed at funding. The contract has no cancel and no edit function, so the goalposts cannot move mid-task.
Passing work is paid without the creator's consent. A qualifying submission settles automatically; the creator cannot simply refuse to release.
No platform cut. The escrow contract has no owner and takes nothing from the payout or the refund. The creator pays the reward plus gas.
The verdict is final. As the project's own FAQ puts it: "Can I appeal a verdict? No."
The hunter pays per attempt. Each evaluation needs a prepay of about 0.00024 ETH at default settings, covering the jury's operators, and it is not returned if the submission fails. At recent ETH prices that's under a dollar, but it's a cost per attempt, not a cost per payout.
Earliest pass wins, not best pass. Payout follows submission order. Once a submission clears the threshold, a later and possibly better one is recorded as passed-but-unpaid.

The four side by side

	Upwork fixed-price	Fiverr	PayPal dispute	Verdikta
Who decides	Human arbitrator (Brief)	The two parties, then support	PayPal, at its discretion	AI model jury
Time to decision	14 days to auto-release	3 days to auto-complete (14 if shipped)	Up to 180 days to open, 20 to escalate	Minutes (up to ~10)
Cost to the freelancer	Arbitration fee + service fee	~20% commission	Dispute window, chargeback risk	Oracle prepay per attempt
Evidence accepted	Brief, messages, files, context	Mutual agreement	Delivery records	Conformance to published criteria
Can the client refuse passing work	Yes, by disputing	Yes, by cancelling	Yes, by charging back	No
Appeal	Yes, via arbitration	Escalate to support	Yes, escalate to claim	No
Client goes quiet	Pays after 14-day clock	Order auto-completes in 3 days	Irrelevant — already paid	Pays on passing score
Reversal risk to freelancer	Low (arbitration required)	Medium (clearance delay; funds can be held longer during disputes or suspected fraud)	High (up to 180 days)	None after verdict

Where the Verdikta model genuinely breaks

A comparison that only lists strengths is advertising. Eight real weaknesses:

The rubric is the whole product, and writing one is hard. Most freelance disputes aren't about checkable criteria — they're about scope: "I assumed revisions were included." A criteria-first system has no answer to ambiguity that was never resolved before funding. If the deliverable can't be expressed as testable statements, this model doesn't apply, and pretending otherwise just relocates the argument to the start of the project.

No human appeal. The verdict is final by design. For a function, a dataset or a checklist, fine — correctness is checkable. For brand voice, design direction or long-form writing, a model can misread intent and there's no escalation path. That's a real cost, not a rounding error.

It's an onboarding problem before it's a dispute problem. To take on the work at all, the freelancer needs a crypto wallet, ETH on Base, and enough comfort with a block explorer to confirm that funding actually landed. That excludes a large share of the people who most need dispute protection, and it does it silently — the exclusion doesn't show up as a rejection, it shows up as never applying. Filing a PayPal dispute needs an account you already have; posting to Verdikta needs a wallet you probably don't.

A model jury is an attack surface. The judge reads the submission, and the submission is attacker-controlled text. Anyone who has watched an LLM get talked out of its own instructions knows a rubric is not a sandbox. Publishing the criteria makes this worse, not better: it tells a bad-faith submitter exactly which phrases the scorer rewards. Human arbitration has bias too, but a human is at least awkward to manipulate at scale.

Earliest passing submission wins. Payout follows submission order rather than quality — defensible against queue-jumping by copying, but it rewards whoever reads the rubric fastest.

All-or-nothing. No partial payment for partial work. Traditional escrow does milestones; this does one deliverable and one verdict.

Every submission is public. Verdikta's own FAQ answers "Is my submission public?" with "Yes, treat it as public" — submissions are stored on IPFS with identifiers recorded on-chain, so anyone can read them. That rules out client work under NDA, unreleased code, internal data, anything commercially sensitive. It also means a failed submission stays readable forever, which is a strange property for work you'd rather not have on a permanent public record. Most of the fiat systems here keep a dispute private between the parties and the platform; this one publishes the work by design.

No chargeback in either direction. Great for the freelancer whose client gets buyer's remorse. But the buyer's only lever is rubric design: a criterion rejecting copied or derivative work has to be written in before funding, because once a verdict lands there's no chargeback and no appeal. Consumer protection is replaced by up-front discipline, and the assumption that the creator gets the rubric right on the first attempt is doing a lot of work.

So which one should you actually use

Short, checkable, single-deliverable work — a function, a dataset, a transcript, a checklist: Verdikta's model wins on speed and cost, provided everyone involved already has a wallet.
Clients who go quiet — two of these systems already handle it, and don't need a blockchain to do it: Upwork releases after 14 days, Fiverr completes the order 3 days after delivery. If ghosting is your specific fear, the platform you're already on has probably solved it.
Scope-heavy or taste-driven work — brand, design direction, long-form editorial: human mediation still wins, because the disagreement is about interpretation, not verification.
High fraud risk in either direction: you still want the fiat rails and their chargeback machinery, flaws included.

The honest summary: this isn't a better Upwork, and the ghosting problem it's usually sold on is already handled by auto-complete clocks on both of the big platforms. What Verdikta actually changes is who holds the judgement — a published rubric and a model jury instead of a support queue — and it trades a human queue for a wallet requirement plus a judge that can be argued with. For narrow, checkable work that's a good trade. For everything else, the older systems are worse in ways that are at least legible.

Genuine question for anyone who has run work through a rubric-based escrow: did writing the criteria up front change what you actually delivered, or only how you described it afterwards?

Mechanics above are from Upwork's Fixed-Price Protection, arbitration and dispute help articles; Fiverr's order-process, Resolution Center and earnings documentation; PayPal's seller protection, dispute-timeframe and escalation pages; and Verdikta's published FAQ documentation, all read this week. The Fiverr commission figure is the one number here I could not verify against Fiverr's own legal pages, so I've marked it as reported rather than quoted. Where a platform's own docs and its marketing disagree, I've used the docs.

İş teslim edildikten sonra "olmamış" cevabını almak üzerine

kurumi — Mon, 26 Oct 2026 05:19:38 +0000

Geçen ay küçük bir çeviri işi aldım, üç sayfalıktı. Teslim etmeden önce sordum: "Bu işin iyi olduğunu nereden anlayacağız?" Cevap şuydu: "Profesyonelce olsun, gerisi önemli değil."

Üç gün çalıştım, teslim ettim. Gelen cevap tek satırdı: "Beklediğim gibi olmamış." Neyin beklediği gibi olmadığını sorduğumda net bir şey çıkmadı. Sonunda iş iptal oldu. Ben üç günümü kaybettim, karşı taraf da yeni birini arama süresini. Kimse kötü niyetli değildi; sadece işin başında "iyi"nin ne demek olduğunu hiç konuşmamıştık.

Bir süredir bunun sadece benim başıma gelmediğini sanmıyorum. Sorun genelde işin kalitesi değil, ölçütün iş bitmeden önce yazılmamış olması.

Geçenlerde bir arkadaşım Base ağında Verdikta diye bir protokolden bahsetti. İlk duyduğumda "yine bir kripto projesi" dedim, ama işin mantığı beni durdurdu.

Verdikta'da olan şu: işi veren kişi parayı baştan bir akıllı sözleşmeye kilitliyor. Yani para ortada duruyor, iş bitmeden kimseye geçmiyor. Yanına bir de değerlendirme listesi ekliyor: bu işte neyin zorunlu olduğu, neyin sadece puan getirdiği ve kaç puanın "yeterli" sayıldığı. Liste işe başlamadan IPFS'te yayınlanıyor. Ardından Base zincirine yazılıyor, yani sonradan değiştirilemiyor, geri alınamıyor.

Sonra bağımsız yapay zekâ düğümlerinden oluşan bir jüri bu listeye göre değerlendiriyor. Önemli olan kısım şu: sadece "geçti" ya da "kaldı" demiyorlar, her maddeye ayrı puan veriyorlar ve bu puanlar herkesin görebileceği şekilde açık. Yani işi yapan kişi nerede kaç puan kaybettiğini görebiliyor.

Bir de şu var: eşiği ilk geçen teslimat bütün parayı alıyor. Son güne kadar bekleyip "en güzelini" seçme durumu yok. Platform herhangi bir komisyon almıyor; işi teslim eden kişi yalnızca jürinin çalışması için yaklaşık 0,00024 ETH kadar bir ön tutar yatırıyor, kullanılmayan kısmı iade ediliyor. Kimse eşiği geçemezse para işi verene dönüyor.

Bunları yazarken abartmak istemiyorum. Makine hâlâ makine: zevk, ton, "bu metin kulağa hoş geliyor mu" gibi ölçütü olmayan işlerde bir insan kadar isabetli olmayabilir. Edebi çeviri, pazarlama metni, arayüz yazısı gibi işler bence hâlâ insan işi. Zincire kazınmış olsa bile kötü yazılmış bir liste kötü liste kalır; o zaman iyi iş de duvara çarpıyor. Bence bu sistem, ürün ve ölçütler net ve ölçülebilir olduğunda en iyi sonuç veriyor.

Benim için değişen şey şu: artık iş almadan önce "ne hayal ediyorsunuz" değil, "bunu neye göre ölçeceğiz" diye soruyorum. Soruyu baştan sormak, sonunda tartışmaktan çok daha ucuz.

Detay merak edenler için: https://bounties.verdikta.org

Siz de benzer bir durum yaşadıysanız, nasıl çözdüğünüzü yazar mısınız? Ben hâlâ işin başında ölçüt koymanın en pratik yolunu arıyorum.

How to write success criteria that someone else can actually apply

kurumi — Sat, 24 Oct 2026 03:13:20 +0000

How to write success criteria that someone else can actually apply

Most outsourced work goes wrong before anyone starts working. Not because the contractor is bad, but because the brief describes a vibe instead of a decision. "Make it engaging." "High quality research." "Clean, professional design." None of these tell a stranger when to stop, and none tell a judge whether the thing in front of them is done.

Success criteria — acceptance criteria, definition of done, call them what you like — are the part of a brief that answers one question: how will someone who has never met you decide, from the deliverable alone, whether this is finished and good enough?

This guide is about writing those criteria well, whatever platform you hire on: a freelance marketplace, an internal team, a code bounty, or an AI-judged bounty board that scores submissions against a rubric published in advance. The mechanics differ. The craft does not.

Start with the one-sentence test

Before writing anything, write one sentence that describes the finished thing in terms of what it lets the reader do:

"A reader who has never used this product can install it, connect a wallet, and complete their first transaction without asking a question."

If you cannot write that sentence, you do not have a task yet — you have an intention. Ship the intention to a conversation, not to a contract.

The sentence also tells you what your criteria need to test. If the goal is "a reader can complete their first transaction unaided," then criteria about word count and colour palette are proxies at best. Criteria about the steps a reader can complete are the real thing.

Separate must-pass from scored

The single most common structural mistake is a flat list of ten equally-weighted bullets. It hides the difference between disqualifying and disappointing.

Split every rubric into two tiers:

Must-pass gates. Binary. If any one fails, the work does not count at all, regardless of everything else. These are usually about existence, honesty, legality, format, and scope: the file is a PDF; the claim is sourced; the code runs; the post is in the required language; the deliverable is not copied from somewhere else.
Scored criteria. Weighted and graded. These express taste and quality: how clear the writing is, how well the argument holds, how usable the interface feels.

A gate is not "important". A gate is "fatal if absent". Everything you would merely negotiate about belongs in the scored tier. If you find yourself with eleven must-pass gates, you have written a legal contract for a small piece of work — trim to the ones that genuinely invalidate the deliverable.

Write criteria as tests, not adjectives

Each scored criterion needs a sentence that says what it measures, and ideally what a high score looks like compared with a low one. Compare:

Adjective: "The writing should be clear."
Test: "A reader with no background in the subject can follow the argument without re-reading a paragraph. Dense jargon is defined on first use. Sentences average under 25 words."

The second version is longer and better, because two different reviewers reading the same deliverable will land in roughly the same place. The first version invites each reviewer to import their own definition of clear, and that is how you get a dispute.

A useful trick: write the criterion, then imagine the deliverable at 30% and at 90%. If you cannot describe what a 30% version looks like, the criterion is not a scale, it is a wish.

Keep the weights few and defensible

Weights are a statement of priorities. If everything is 20%, you have said nothing.

Three to six criteria is the practical range for a single deliverable. Make the weights follow the purpose of the task. A research brief whose entire value is in the evidence has no business weighting "visual presentation" at 30%. A design task whose entire value is in usability has no business weighting "brand consistency" above it.

Then state the pass threshold explicitly, in the same units the judge will use. "Total 85 out of 100, with no scored criterion below 60" is a different contract from "85 out of 100" — the second lets a submission fail the one thing you care about and still pass on the strength of everything else.

A reusable rubric you can adapt

Here is a complete rubric for a research brief — the kind of task people most often under-specify. Copy it, change the subject matter, keep the shape.

Criterion	Type	Weight	What it tests
Deliverable exists and matches the requested format	Must-pass	—	The thing asked for is the thing delivered: correct file type, length, language, and named sections present
Every factual claim is sourced or flagged as inference	Must-pass	—	Nothing is presented as fact without a source, and unsourced reasoning is labelled as reasoning
Direct answer to the question in the brief	Scored	30%	The first section answers the actual question rather than restating it or answering a nearby easier one
Quality and independence of evidence	Scored	25%	Sources are primary where possible, multiple sources per contested claim, no circular citation of the same press release
Reasoning under uncertainty	Scored	20%	Assumptions are stated, ranges are used instead of fake precision, and conclusions survive their own caveats
Usability for the stated reader	Scored	15%	The intended reader can act on it: concrete implications, no unexplained jargon, structure that follows their decision
Honest limitations	Scored	10%	What could not be verified, what would change the conclusion, and what the author is least confident about

Pass threshold: 85/100 total, with the two must-pass gates satisfied and no scored criterion below 50. Notice what that last clause buys you: it prevents a submission from clearing 85 on the strength of three criteria while being useless on the one your reader needs.

Notice also that the must-pass gates are about class of thing and honesty, not quality. That is deliberate. Gates should be cheap to check and impossible to argue about.

Test the criteria before you publish them

Four checks, each takes minutes and saves days:

The adversarial read. Hand the rubric alone, without the brief, to someone who has not seen the task. Ask them to write the worst submission that still passes. If they produce something you would reject, the rubric is too loose.
The two-reviewer test. Ask two people to score the same sample independently. If they differ by more than 15 points on a 100-point scale, the criteria are ambiguous, not the reviewers.
The gaming check. For each scored criterion, ask "what is the cheapest way to score high here without doing the work?" Word counts invite padding. "Number of sources" invites citation stuffing. Fix the criterion before someone exploits it.
The scope check. Read the brief next to the rubric and underline anything in the brief that no criterion tests. Every underlined line is either dead weight in the brief or a missing criterion.

There is a fifth check that matters when a machine applies the rubric: read it literally. A jury that scores against your text will not infer your intent, extend a criterion to cover an obvious case, or forgive a badly worded rule. If a criterion can be read two ways, it will be read the less convenient way.

One worked example: publishing the rubric in advance

The four checks above are platform-agnostic, but they get sharper when the rubric is public and fixed before anyone starts. That is how Verdikta Bounties works, and it is worth walking through as a concrete case rather than an abstraction.

On Verdikta, a creator funds a task in escrow and publishes the rubric up front. The rubric and evaluation package are pinned to IPFS and fixed on-chain, so the acceptance criteria cannot move after someone has started working. A panel of independent AI arbiter nodes on Base scores each submission against that rubric, and the per-criterion scores are public and auditable. Two consequences follow directly from that design, and both are arguments for spending more time on the rubric than feels natural:

The first submission that clears the threshold is paid the whole bounty. It is not a best-of-all-entries contest judged at the deadline, so a rubric that only separates "good" from "bad" is not enough — it also has to separate "passes now" from "nearly passes", because someone will ship against it today.
A bounty cannot be cancelled or edited after creation, which protects the person doing the work but removes your chance to fix a sloppy criterion halfway through. The rubric is the contract.

The economics are deliberately thin: Verdikta charges no platform fee, so the entire bounty amount goes to the hunter whose submission passes; the hunter attaches a refundable oracle prepay of about 0.00024 ETH when starting a submission, usually spent in full on the jury round. If no submission passes before the deadline, the creator reclaims the full amount and the platform keeps nothing. None of that changes how you write criteria — but it does explain why a badly written rubric is expensive in a way that a badly written email brief is not.

If you want a longer treatment of the same problem, including how to phrase gates so a model can apply them, Verdikta's own guide at https://bounties.verdikta.org/learn/success-criteria/ covers the format end to end.

A short checklist before you publish

One sentence describing what the finished thing lets someone do.
Two to six scored criteria, each with a weight and a sentence on what it tests.
Must-pass gates limited to existence, honesty, legality, format and scope.
A stated pass threshold, plus a floor so nobody passes by ignoring your priority.
High and low descriptions for every scored criterion.
The adversarial read done by someone who has not seen the brief.
A literal read: could a careful stranger apply this and reach a decision without asking you anything?

If all seven are true, you have written a rubric. If not, you have written a wish list with numbers attached — and the person on the other side will find out which one it is at the worst possible moment.

Bug bounty, freelance gig, or judged bounty? Picking the right platform for the work in front of you

kurumi — Sat, 24 Oct 2026 03:06:53 +0000

There is a specific kind of confusion that shows up whenever someone hears "bounty" and "crypto" in the same sentence: they assume it means a security bounty. It usually does not. A smart contract audit and a 900-word research brief are both "bounties" in casual conversation, and the platforms that host them have almost nothing in common — different judges, different payment rules, different failure modes, different kinds of people who do well on them.

This piece puts four options side by side: security platforms (Bugcrowd, HackerOne), talent marketplaces (Upwork and its relatives), code bounties (Gitcoin and GitHub-issue bounties), and criteria-based judged bounties (Verdikta Bounties). The goal is not to declare a winner. It is to help you look at the task in your hand and know which door to walk through.

The short version

	Who judges the work	What work fits	How payment is decided	Where it is weakest
Bugcrowd / HackerOne	The program's security team, often with platform triage support	Exploitable vulnerabilities inside a published scope	Per valid, in-scope, non-duplicate report, against a reward range the program sets	Anything that is not a security defect is out of scope by design
Upwork and similar marketplaces	You, the client, as the work is delivered	Any work that needs a specific person's time, judgment, or collaboration	Fixed-price milestones in escrow, or tracked hourly	You have to source, screen, hire, and manage; fees and disputes are part of the deal
Gitcoin / GitHub bounties	The repository maintainer	A code change the maintainer actually wants merged	Paid when the pull request is accepted	Only as good as the maintainer's availability and the issue's clarity
Verdikta Bounties	A panel of independent AI arbiter nodes scoring against a rubric published before anyone submits	Tasks with a checkable deliverable and criteria you can write down in advance	First submission that clears the acceptance threshold is paid the full bounty in escrow	No negotiation and no revision loop; a badly written rubric cannot be fixed later

Security platforms: Bugcrowd and HackerOne

These are the real bug-bounty programs, and the category name belongs to them. A company publishes a scope — domains, apps, API endpoints, sometimes smart contracts — along with reward ranges and rules of engagement. Researchers go hunting, submit reports, and a triage process decides whether the finding is real, in scope, and not a duplicate. Payment follows validity, not effort.

What these platforms are genuinely good at is turning an adversarial relationship into a contract. Safe harbor language, agreed response windows, and a triage workflow mean a researcher can report a serious flaw without worrying about being sued, and a company can receive hundreds of reports without opening its inbox to chaos. The reputation systems are also real currency: a strong public profile on one of these platforms changes how a researcher is treated on the next program.

The boundary is just as important. A security program is not a place to ask for a landing page, a research report, a translation, or a market analysis. If the deliverable is not an exploitable defect, the report will be closed as out of scope — correctly, and often within minutes.

Upwork and the marketplace model

Upwork solves a different problem: you need a person. Not an artifact, not a pass/fail judgment — a human being whose time you are renting, who will ask clarifying questions, take feedback, and adapt when the brief turns out to be wrong.

Fixed-price contracts put money in escrow against milestones. Hourly contracts track time. Either way, the client is the judge: you review the work, you approve it, and if you disagree there is a dispute process with mediation and arbitration behind it. That process is slow compared with an automatic payout, but it exists precisely because human work is ambiguous.

The cost is management load. You write a job post, screen proposals, compare portfolios, interview, onboard, and supervise. For a one-off deliverable that could be specified precisely, that overhead is often larger than the work itself. For anything involving access to internal systems, ongoing iteration, or judgment that depends on context you cannot fully write down, it is the only model of the four that fits.

Gitcoin and GitHub issue bounties

Code bounties are the narrowest and most honest of the four. An issue gets a label and a price, a contributor opens a pull request, and the maintainer decides whether it merges. Payment is tied to acceptance, and acceptance means the code is now in the repository.

The strength here is contextual judgment. A maintainer knows the codebase, the style, the architectural direction, and the parts of the problem that were never written in the issue. They can accept a solution that looks strange but is right, or reject one that passes tests but would be a maintenance burden. No rubric captures that.

The weakness is the same thing viewed from the other side: throughput depends on maintainer attention, scope creep is common, and "I will know it when I see it" is a legitimate but demoralising acceptance criterion for contributors. Bounties on abandoned repositories can sit unpaid for months.

Verdikta Bounties: criteria first, judge second

Verdikta Bounties runs on Base and is a criteria-based judged bounty market. The creator funds a task in escrow and publishes a rubric in advance; a panel of independent AI arbiter nodes scores each submission against that rubric, and the per-criterion scores are public and auditable. The evaluation package and rubric are pinned to IPFS and fixed on-chain, so the terms cannot move after the fact.

Four mechanics are worth stating plainly, because most people assume the opposite:

Verdikta charges no platform fee. The whole bounty amount goes to the hunter whose submission passes.
The hunter attaches a refundable oracle prepay of about 0.00024 ETH when starting a submission. In practice it is usually spent in full on the jury round. It is a cost of being judged, not a commission.
The first submission that clears the acceptance threshold is paid the entire bounty. This is not a best-of-all-entries contest judged at a deadline. Speed matters, but only among submissions that actually pass.
If no submission passes before the deadline, the creator reclaims the full amount and the platform keeps nothing. A bounty also cannot be cancelled or edited after creation, which protects hunters and puts the burden of writing a sane rubric on the creator.

Verdikta Bounties is not a security bug-bounty program, and it is not a place to report vulnerabilities. If you have found an exploitable flaw in someone's software, that belongs on a security platform with a published scope and safe harbor, not here. Verdikta is for tasks where a written rubric can decide whether the work is good: research, analysis, documentation, content, design with stated constraints, code with explicit acceptance criteria.

Where the model is weakest is exactly where a human client would shine. There is no negotiation, no "can I see a draft", no chance to explain what you meant. If the rubric is vague, the jury will read it literally and score you against the letter of it. Creative work with taste-based quality is a poor fit; work you can describe as a checklist is a good one.

How to choose, in practice

You found a vulnerability. Bugcrowd or HackerOne. Nothing else in this list gives you scope, safe harbor, and a triage process.
You need a specific person's time, judgment, or ongoing involvement. Upwork. You are buying collaboration, and collaboration needs a contract and a human on the other end.
You need a change inside a codebase whose maintainer will review it. A Gitcoin-style or GitHub-issue bounty. The maintainer's acceptance is the quality bar, and that is the right bar for merged code.
You have a task with a checkable deliverable, you can write the acceptance criteria up front, and you do not want to manage anyone. Verdikta. You fund escrow once, publish the rubric, and let the jury apply it. The work you put into the rubric is the work you would otherwise put into supervising a freelancer — and unlike supervision, a rubric can be read by every hunter before they start.

The mistake worth avoiding is picking by category name rather than by what the deliverable actually is. A rubric-shaped task on a security platform gets closed as out of scope. A security audit on a judged-bounty platform gets scored against a rubric that cannot see what a human triager would see. And a well-specified one-off task on a talent marketplace costs more in management hours than the work is worth.

Pick the judge first. The rest follows.

Rubrica publicada antes da entrega: o detalhe que muda a conversa sobre avaliação por IA

kurumi — Thu, 22 Oct 2026 02:40:13 +0000

Já recusei freela por falta de garantia. O briefing era bom, o valor era justo, a pessoa parecia séria. Mas quando pedi alguma coisa além de "fica tranquilo, já trabalhei com muita gente", não tinha nada. Sem contrato, sem depósito, sem critério escrito. Se o outro lado sumir, o prejuízo fica com quem trabalhou.

Escrow resolve metade disso, e escrow não é novidade. O que me fez parar para ler o Verdikta, um protocolo na Base, foi a outra metade: o desenho da avaliação.

O problema real não é o dinheiro, é o critério

Quem já teve entrega recusada sabe que a parte dolorosa raramente é o dinheiro em si. É receber um "não ficou como combinado" e não ter onde apontar. A justificativa existe na cabeça de quem contratou, não em lugar nenhum que você possa consultar.

Quando a avaliação é feita por IA, esse problema costuma piorar em vez de melhorar. O modelo virou uma caixa-preta nova, com o agravante de que ninguém sabe dizer o que ele considerou. A conversa morre em "a IA errou" e não anda.

O que muda quando a rubrica vem antes

No Verdikta a ordem é invertida. Antes de qualquer trabalho ser aceito, os critérios já estão publicados: quais são obrigatórios, quais só somam ponto, e qual é a nota mínima para o contrato liberar o valor. O valor em si também fica travado em contrato antes do trabalho começar.

Isso muda a natureza da discussão. Se o critério é público e a nota por critério também, a pergunta deixa de ser "a IA errou" e passa a ser "esse critério está mal escrito". A segunda pergunta é respondível. A primeira não é.

Tem um detalhe prático que eu valorizo: a nota de corte muda de acordo com o serviço e é divulgada antes. Dá para olhar e decidir se vale a pena pegar antes de perder uma semana.

O que isso não resolve

Não quero vender ilusão, então:

O painel de IA lê o arquivo que você entrega. Trabalho que depende de verificar dispositivo, conta ou qualquer coisa física não tem como ser julgado assim. Continua precisando de olho humano.

E tem um limite estrutural que auditabilidade não conserta: rubrica mal escrita produz nota confusa mesmo com tudo registrado bonitinho. Registro na chain deixa o erro visível, não o corrige.

Sobre contestação, eu não achei caminho claro. Se a nota sair injusta, não sei dizer o que acontece. Isso me incomoda mais do que qualquer outra coisa no desenho.

Para que tipo de trabalho isso serve

Para entrega cujo escopo dá para descrever em texto — documentação técnica, revisão, pesquisa curta, redação — o modelo faz sentido, porque a rubrica consegue ser específica.

Para coisa subjetiva, tipo decidir se um design "tem a cara certa", eu ainda fico com um pé atrás. E aí a pergunta que fica é sobre o critério, não sobre a IA.

Quem já teve trabalho avaliado assim: a rubrica publicada ajudou de verdade na hora de recorrer, ou só deixou o "não" mais bem documentado? Para quem quiser olhar de perto: https://bounties.verdikta.org

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