A robotics skill and a Portuguese localisation are the same object to us. Both get an objective, a reward pool, an eligibility rule, a deadline, a completion check and a payout trigger. Once those six fields are filled in, the domain stops carrying weight. Work sorts on one axis: can someone state in advance what done looks like. - A disclosed vulnerability. The maintainer confirms the report, the fix lands, the reward moves. Clean. - On-chain trading challenges. The ledger does the reviewing, so nobody has to arbitrate. - An AI training dataset. Checkable, but only if the row count, the labelling standard and the rejection rule are written down before collection starts. - Technical documentation. "Better docs" has no end state. "Every public method in the SDK reference ships with an example that runs" has one, and a reviewer can run it. The field worth arguing over is who runs the check, and that name belongs on the form next to the deadline.

Selection is where most funding programmes fail, and it fails on the wrong artifact. An organisation opens a bounty, gets forty applications, and every one of them is a document. Documents are what get scored, so whoever writes well beats whoever ships well. The reviewer rarely finds out, because by the time the work lands or does not, the decision is two months old. The workaround is references. Someone who closed a hard protocol integration last quarter has to find a person there willing to vouch for them in a DM, and hope the reviewer weights it. Good contributors end up gated behind who they happen to know. We think the durable asset belongs to the contributor: the record itself. How many missions they closed, in which domains, what share of what they claimed got paid out, how fast they answered, what they earned. Each of those is a fact produced by work already checked and settled. It has to sit on-chain. A record in our database is our opinion of a contributor, and it dies with the platform. Carry an eighteen-month history out of one DAO's ecosystem into a company that has never heard of you, and it reads the same. Our own objection to this: a track record is exactly as good as the completion criteria under each entry. A hundred closed missions judged on vague criteria are a hundred entries with nothing behind them. Proposal-writing stops being the qualifying skill, and the reviewer's side changes as much as the contributor's. Reading forty pitches for tone becomes filtering on fields. Response time is the one we keep arguing about internally: measured from when the mission opens or from the contributor's first message, and whether someone who reads a scope for three days then answers precisely should rank below someone who claims it in an hour and stalls

The verification argument splits in three, and programmes tend to win the first part and stop there. 1. Payment is the solved part. Once a condition reads as met the payout fires, and nobody spends months chasing a status report on funds that already left. 2. The definition is where the actual work sits. Which contract, on which chain, merged by whom, passing which tests: get those four answers on paper and two people can disagree hard about the quality of the work and still land on the same answer about whether it is finished. A scope that skips them leaves the reviewer arbitrating on instinct. 3. Judgement is not solved and we will not pretend it is. A completion check for a disclosed vulnerability reads nothing like one for a translated set of docs, and either can be written badly. What we do enforce is that the sentence exists: every mission we publish carries it as a required field, and an empty one is visible to anyone reading the brief before they start work.

Ask ten funders what their bounty is for and nine will describe a direction of travel. The finish line is missing, and that gap surfaces long before anyone gets to argue about verification. Our form asks for it on line one: what has to exist before this counts as done. Drafts stall there for days. That week is the cheapest part, because the alternative is finding out in month four.

Worth stating up front, since it shapes what we build at Mission: the failure mode in grant programmes is drift. Fraud is rare and loud. Drift is quiet, well intentioned, and it is where the budget goes. You can watch it in a follow-up thread 📩. Ops sends a fourth check-in on a tranche that went out in March, gets a warm reply about a demo next month, files it, and repeats that across a dozen open grants ⏳. Nobody there is behaving badly, which is what makes it stubborn. Funds moved on the strength of a written case, so there is no agreed moment when the work counts as finished and none when it counts as over. So the row stays open. Next cycle's cohort gets funded beside it, the tracker gains a line, and the only thing forcing a decision is the annual report 🧾.

How much of posting a bounty is actually naming the reward? Almost none of it. The number is the field anyone can fill. The work is the line under it: what counts as done, who checks it, what a tie resolves to. Write that loose and you get six submissions that each half-qualify and an argument nobody can settle fairly, so the pool pays out to no one. Leave it out and the organiser just decides after the fact, which is the grants problem wearing a bounty's clothes. Naming the reward takes a minute. Writing the check that releases it is the whole job.

The claim that gets the most pushback from us: the work itself does not matter. A disclosed vulnerability and a robotics skill arrive in the same form, with the same three fields waiting to be filled. Objective, completion check, payout trigger. That is the shape of every mission, and swapping the kind of work only changes what fills those fields: - A disclosed vuln: reproduce the exploit on a clean clone, a maintainer confirms the advisory, the pool releases. - A robotics skill: a policy that clears an agreed success rate over a fixed run of trials, the reviewer signs off, the pool releases. - An AI training dataset: labelled examples inside a stated error bound, a held-out audit passes, the pool releases. - An on-chain trading challenge: hit the target return on a tracked wallet, read straight from the chain, the pool releases. The form cannot tell whether it is holding a Solidity advisory or a Spanish tutorial.

A reference is a favour, and favours run on who you already know. The good contributor with ten finished projects has no clean way to hand a stranger proof of it. They ask a former client to vouch. The organisation has the mirror problem: it reads a proposal and guesses whether whoever wrote it well is also the one who ships. Those are separate skills, and the document measures the first. We think the record is what matters most over time. Every mission a contributor finishes leaves a trail: the objective taken on, whether the completion check passed, what the pool paid, how long they sat between claiming and submitting. Stack enough and a shape appears. Success rate across accepted missions, earnings anyone can verify on-chain, response time read off the timestamps, the areas where the finished work clusters. That trail lives on-chain and the contributor owns it. When they move from one DAO to the next, the history moves with them, no permission and no introduction required. The next organisation does not chase down a former client for a quiet word. It reads the wallet. What the organisation evaluates shifts with it: a history of outcomes sits where a paragraph of intentions used to, and the applicant who writes well no longer passes automatically for the one who ships. You stop hiring the proposal and start hiring the history. The dependency we keep circling back to: a record is only as trustworthy as the checks that wrote each line. When a completion criterion was loose enough that a weak submission still cleared it, that pass sits in the history looking identical to a hard-won one. So the field reading 42 missions completed is really a claim about 42 completion checks, each as strict or as loose as its poster made it, and the record carries them forward without marking which was which

Most defences of up-front grant funding brace for fraud. Fraud is the rare case. The failure that actually drains the money is drift, a project meant in full sincerity that never arrives. 1. Drift is the good-faith failure. The applicant meant every word, drew the pool in month one, then priorities moved and the milestones stopped landing. By the time anyone clocks it, a clawback costs more in lawyer hours and goodwill than the grant was worth, so it gets left and the line item rots on the books. 2. Tie the payout to a verified outcome and that same drift costs the treasury nothing. On Mission the completion check goes unmet, the deadline lapses, and the reward pool is still in escrow exactly where the poster staked it. There is nothing to recover, because nothing was ever released. 3. And the contributor who genuinely tried is treated like it. No demand email, no public write-off, no awkward call about spent money. Their attempt closes, the pool reopens, and the next person takes a run at the same objective.

Gig work reprices you after the hours are already spent. Scope creeps, the deadline slides, and whoever's paying gets to decide what 'done' meant. A mission fixes it in public first: the objective, the reward pool, who's eligible, the deadline, the completion check. You read what winning pays before you commit a minute.

Mission changes one thing: the order in which money and proof happen. A grant clears because a proposal reads well. Cash is out the door 💸, and what you funded is now a promise somebody has to chase. Six months on, a programme lead is drafting a fourth check-in email 📨 to a channel that went quiet by week three, no clean way to call it done or dead. We write the completion check first and publish it, then fund the pool behind it. Objective, verification method, and who signs off are all fixed and visible before a contributor spends an hour. The pool releases the second the check passes ✅. If it never passes, the funds stay where they were staked. Nobody drafts a chase email, because the criterion that pays out was on the page before the money went in.

Reputation in this market runs one way. An organisation opens a contributor's history, counts completed work, and decides. The contributor gets a website and whatever they pick up from people who worked there. Published missions leave a trail too. Every objective we wrote is still readable, dated before the first submission, and so is the day the reward left the pool. Where a submission landed half inside the criterion, the record shows whether we settled it in a week or let it sit. A contributor should price us off that. Open the last mission we published, find the sentence naming who resolves an ambiguous submission, and check whether that name was there before the work started.

Which person on your grants team ends up owning the spreadsheet? -> the reminder redrafted five times so the fifth one still reads as friendly -> the decision to log a half-finished repo as on track, because the alternative starts a fight -> the meeting where four people ask how it is going and none of them can answer -> the arithmetic on how much is left, done privately, well before anyone says it out loud That labour exists because the money moved before the outcome did, and it lands on whoever has least standing to refuse it. Mission does not delete it. Writing a completion test that holds up before the pool is funded is its own hard afternoon, and it still tends to land on whoever owned the spreadsheet.

A robotics grasp skill and a page of launch copy sit at opposite ends of everything published here. The catalogue looks scattered until you find the single property holding it together. We drew the scope wide on purpose. A grasp skill, a labelled training set, an interface pushed into a language nobody on the team reads, a vulnerability routed to the maintainer, docs for an SDK that shipped without any, a protocol integration, a tutorial, marketing assets, a signup target, an on-chain trading challenge. No two of those want the same person. They share exactly one property: completion can be settled by someone other than the claimant. The maintainer reproduces the bug and says so. A native speaker reads the string file and marks the lines that are wrong. Our counter clears the stated number before the deadline. The split runs along who holds the verdict. On one side, work you can hand to a checker. On the other, work whose only test is whether a client feels good about it. "Sharpen our positioning" has no ending. "Three explainer threads, every claim traceable to the docs" has one. That cuts against us too. A mission we cannot phrase as a check is one we should be telling an organisation to hold, and valuable work sits on the wrong side of that line today. Which leaves the part we keep circling. When a deliverable is real but only an expert can judge whether it is any good, who gets to be that expert, and who pays for those hours?

Competitive pools have a cost worth naming. Five people write the tutorial, one submission is accepted, four contributors worked for nothing. We think that trade is honest when the objective wants variety and one attempt costs an evening: marketing assets, a translation, a trading challenge scored on rank. It gets ugly once the work runs for weeks. - Competitive pool: cheap for us to publish, expensive for whoever loses. Post the pool, the deadline and how many are already in. - Milestone mission: scope allocated before anyone starts, paid per verified step. Someone owns the sequencing, which is why it gets skipped. - Team mission: one submission, several contributors, the split fixed while everyone is still friendly. - Recurring campaign: the same objective on a cadence, so the four who lost this round know when the next one opens.

How do you prove you can do the work when nobody in the room has met you? Today the answer is a favour: asking a maintainer you helped last winter to vouch in a Discord, hoping she replies before the shortlist closes. That reference lives in someone else's inbox, which is how good people stay gated behind who they know. Every mission you complete writes to a record you own. Completed count, earnings, success rate, response time when scope is questioned, the areas you keep returning to. It moves with you to the next organisation. You prove it by holding your own receipts.

Airdrop farming is the nearest thing to us on the shelf, and it is the exact model we exclude. Pretending the resemblance is invented is why people squint at this whole category. Paid engagement rewards activity: a wallet touched a contract, an account quoted a post, a counter moved. A mission rewards an object that a named person on the organisation's side has to open, read and accept. Refusing to blur that costs us, and here is the bill: - Anyone running twenty farming campaigns a week has nothing to hand in here, so the funnel narrows. - Every published mission needs a human at the other end willing to say yes or no to a submission, which caps how fast objectives go out. - Participation counts stay small, since we can only count people who submitted something. What survives is duller and it is the number we want: completed missions, each with something behind it that a person actually opened, like a dataset that got labelled or a bug that got fixed.

The reward number is the easy part. Most missions get drafted budget first, criterion last, in ten minutes, by someone who knows what they meant. Say the objective the way it comes up in a call: improve the onboarding docs for our SDK. Everyone nods. Nobody in that room can resolve it. Improved against what, judged by whom, done when? Now phrase it as a check: a stranger reads it, looks at a submission, answers yes or no without messaging you. Usually that means naming four things: the artifact, where it lands, the state it must be in, the event that shows it happened. "A quickstart page in the docs repo that takes a new developer from empty folder to first successful call, merged to main." Ugly sentence. Also hard to argue with. Same move on work that resists pinning down. Translation: which pages, which glossary terms stay in English, who signs off. Vulnerability disclosure: reproduction against a named commit, severity on a linked scale, payout on confirmed repro. Then the part publishers skip. Something will land in the grey zone, and who decides that belongs in the mission before anyone starts. Name the resolver: a person, a seat or a small panel, and the days they have to answer. Settling that in writing is the publisher's job, done before submissions open. Heavy process for a modest pool, someone always says. Fair, up to a point. What it really costs is learning at drafting time that the objective is still a wish, which lands softer than the same discovery three weeks in, with finished work in front of you. So the check gets written first, priced second: it is what the pool buys. Last pass before publishing, read the criterion aloud to someone who missed the scoping call, and watch for the moment they stop and ask what we mean here by production ready.

We do not publish a mission until six fields are filled in: what the objective is, who can take it, how much sits in the pool, when it closes, what counts as done, and what releases payment. Those six lines are the contract. Most bounties in the wild run with two of them blank, and the blanks are where the argument starts. 1. Objective and the done test. Written apart, they drift. "Run a community campaign" is an intention, and whoever accepts it invents the standard afterwards. 2. Reward pool. Unfunded, a contributor is pricing your goodwill, and the strong ones decline to bid. 3. Eligibility and deadline. Leave the first open and you read submissions from people never in scope. With no date on it, nothing closes and it dies by attrition. 4. Payout trigger. Blank, acceptance becomes a conversation, and a human is back in the loop the moment the work is done and the contributor is waiting.

Fraud is the least of our problems. Programmes die like this: the deliverable becomes a status update, the update becomes a line in Discord, and by Q4 nobody opens it. Everyone stays on good terms. No month is wrong enough to stop it. What it never had was an ending, which every mission names: the result, and the day it counts as met.