Launch program

We are paying strangers to go first.

Voidly funds every bounty on this page out of its own wallet. There is no sponsor, no token, no points and nothing that becomes worth something later. You do a piece of work, your evidence is checked — by machine on the four automatic rungs, by a person on the three that are registry- or human-anchored — and USDC arrives on Base at an address you name.

Voidly never asks you to send funds. Not to start, not to claim, not to verify. Money moves one way here — out of a Voidly wallet, to an address you name. Anyone who tells you otherwise while using our name is not us, whatever the page looks like.

committed: 11.15 USDC
slots: 107
awarded so far: 0
chain: Base mainnet

board live · payouts arming — The board is live and machine-readable: the four automatic rungs are served with per-rung slot counts, and their evidence is checked by machine. Payouts are not armed yet — the endpoint answers payouts_armed: false today, and it arms only when a rung has a founder-signed voucher for an enrolled address AND the payout path is out of dry run. Neither is a plan; the endpoint says which is missing. Arming is also per address rather than per board: the same response carries payout_scope: pre_enrolled_exact_addresses_only, which means only an address the founder has already offline-signed a voucher for can be paid. Enrolling does not create that voucher and does not schedule one. Read the endpoint yourself.

That count is edited by hand when a bounty is awarded. The automatic rungs also report live per-rung slot counts at api.voidly.ai/v1/bounty/board; this page does not fetch them, so where the two disagree, the endpoint is the fresher number.

A further 1.50 USDC across 10 slots is priced and funded but shut, on one rung nobody can complete yet. It stays on the page below with the reason on the card, because a rung that quietly disappears teaches you less than one that says what it is waiting for.

Where to start

The client is on npm as @voidly/session, and its source is public at github.com/voidly-ai/session. That package carries everything the automatic rungs check: the manifest key list in signing order, the canonical-JSON signer, the DID derivation, the settlement binding, and the same provider check we run against what you send.

The provider to hire is on voidly.ai/pay/providers. That page prints the manifest URL and the registry command that returns the DID you pin it against — deliberately not the DID itself, because a pin read off the page you are checking is not a pin. It is the only page that has this, and now it is linked from here.

One thing to know before you spend any effort: enrolling proves you own the payout address, and it does not make you payable. An enrolled address still cannot be paid until Voidly’s founder offline-signs a voucher — a USDC transfer authorisation — that names that exact address, that rung and that amount. The founder is the only holder of the payout wallet and signs those by hand, in batches; the step is manual on purpose and there is no published schedule for it. Until a voucher naming your address exists, a claim whose evidence PASSES verification is still refused with 503 payout_exact_recipient_not_ready and no slot is taken. The enrollment reply tells you which side of that line you are on — it answers payable true or false with a voucher_status sentence, and if the voucher store cannot be read it says so rather than reporting false — and the board publishes the same fact for everyone as payout_scope: pre_enrolled_exact_addresses_only. Read your own payable field first and do the work when it says true.

The automatic rungs claim through the live board on api.voidly.ai, and enrollment comes first. It is two calls. POST {"payout_address": "0x…", "rungs": ["hello-rail"]} to /v1/bounty/enrollment/challenge. BOTH fields are required — rungs is a non-empty list drawn from the four automatic ids, hello-rail, derive-nonce, first-settlement and hire-somebody, and leaving it out is refused with a 400 that names it. Enrolling for hire-somebody is accepted even though that rung is shut: enrollment proves address ownership and reserves nothing.

The reply carries a canonical-JSON statement. Sign those exact UTF-8 bytes, unaltered, from the same address, with EIP-191 personal_sign — the ordinary personal_sign a wallet already does. What comes back must be 0x followed by 130 lowercase hex characters ending 1b or 1c; a signature whose last byte is 00 or 01 is refused as non-canonical, so add 27 if your library returns the short form. The statement expires 15 minutes after it is issued, and a stale one is refused rather than renewed — ask for a new challenge instead. Then POST {"challenge_id": "…", "signature": "0x…"} to /v1/bounty/enrollment, which answers 200 and echoes the rungs it enrolled. Derive-the-nonce challenges are a separate thing, issued per claimant at POST /v1/bounty/challenge. The human-read rungs still start with a question to hello@voidly.ai — before you publish, not after.

Hello, rail

0.02 USDC·40 slots

Generate a keypair, publish a signed provider manifest at a URL you control, and register the DID.

you need: Nothing to buy — no USDC and no ETH. A keypair, somewhere to serve a file, and an EVM address that can sign: it is the address we pay, and enrolling it is a signature from it. Install @voidly/session and it hands you the fourteen manifest keys in signing order, the canonical-JSON signer, and the same provider-verification routine we run — so you can pass our check before you send it. Register the DID at POST /v1/agent/register on api.voidly.ai; that door is open and takes no key. Enroll the payout address before you claim: POST {"payout_address": "0x…", "rungs": ["hello-rail"]} to /v1/bounty/enrollment/challenge on api.voidly.ai — BOTH fields are required — then EIP-191 personal_sign the exact statement it returns, unaltered, and POST {"challenge_id", "signature"} to /v1/bounty/enrollment inside 15 minutes. Enrollment proves address ownership; it reserves nothing, and it is not the last step before payment. An enrolled address still cannot be paid until the founder offline-signs a voucher naming that exact address, this rung and this amount. The founder holds the payout wallet and signs those by hand, in batches; there is no published schedule for it. Until such a voucher exists your evidence is verified and then refused, 503 payout_exact_recipient_not_ready, with no slot taken. The enrollment reply tells you which side of that line you are on — it answers payable true or false with a voucher_status sentence, and on a storage error it says that instead of reporting false — so read it and do the work when it says true, not before. This is what the board means by payout_scope: pre_enrolled_exact_addresses_only.
checked on Base: We fetch your manifest and run the pin check both ways: it must verify against your own DID and be refused against a different one. Passing only the first half is a template paste, not a signature.

Farmable, and the slot cap is the only real defence. Keys are free to mint and nothing costs a duplicate anything. Worst case one person takes the whole 0.80 and we get 40 signed manifests, some of them junk. That is a price we are paying on purpose.

Derive the nonce

0.03 USDC·20 slots

Reproduce the settlement binding yourself, in any language, and publish the working.

you need: A machine that can hash — and your challenge, which you request BEFORE you write: POST your payout address and the rung to /v1/bounty/challenge on api.voidly.ai and it answers with a challenge issued to you alone. A write-up published without one carries the wrong hash and has to be republished. The binding itself ships in the published package — it exports both the domain constant and the nonce helper, named in its README. Enroll the payout address before you claim: POST {"payout_address": "0x…", "rungs": ["derive-nonce"]} to /v1/bounty/enrollment/challenge on api.voidly.ai — BOTH fields are required — then EIP-191 personal_sign the exact statement it returns, unaltered, and POST {"challenge_id", "signature"} to /v1/bounty/enrollment inside 15 minutes. Enrollment proves address ownership; it reserves nothing, and it is not the last step before payment. An enrolled address still cannot be paid until the founder offline-signs a voucher naming that exact address, this rung and this amount. The founder holds the payout wallet and signs those by hand, in batches; there is no published schedule for it. Until such a voucher exists your evidence is verified and then refused, 503 payout_exact_recipient_not_ready, with no slot taken. The enrollment reply tells you which side of that line you are on — it answers payable true or false with a voucher_status sentence, and on a storage error it says that instead of reporting false — so read it and do the work when it says true, not before. This is what the board means by payout_scope: pre_enrolled_exact_addresses_only.
checked against your own challenge: Your write-up must contain the hash of a random challenge issued to you at claim time. Nobody else was asked that question, so an earlier post cannot answer it.

The per-claimant challenge closes the obvious farm outright — a copied write-up carries the wrong hash. What is left is thin write-ups that contain the right hash and little else, which at three cents is a fair trade, because the hash is the proof.

First settlement

0.10 USDC·40 slots

Hire the provider, pay for the job, and read the sealed result back. One full cycle, as the hirer.

you need: 0.05 USDC on Base, plus a fraction of a cent of gas. You net five cents. The provider to hire is on voidly.ai/pay/providers — that page has the manifest URL and the registry command that returns the DID you pin it to. Take the pin from the registry, not from any page, including that one. Enroll the payout address before you claim: POST {"payout_address": "0x…", "rungs": ["first-settlement"]} to /v1/bounty/enrollment/challenge on api.voidly.ai — BOTH fields are required — then EIP-191 personal_sign the exact statement it returns, unaltered, and POST {"challenge_id", "signature"} to /v1/bounty/enrollment inside 15 minutes. Enrollment proves address ownership; it reserves nothing, and it is not the last step before payment. An enrolled address still cannot be paid until the founder offline-signs a voucher naming that exact address, this rung and this amount. The founder holds the payout wallet and signs those by hand, in batches; there is no published schedule for it. Until such a voucher exists your evidence is verified and then refused, 503 payout_exact_recipient_not_ready, with no slot taken. The enrollment reply tells you which side of that line you are on — it answers payable true or false with a voucher_status sentence, and on a storage error it says that instead of reporting false — so read it and do the work when it says true, not before. This is what the board means by payout_scope: pre_enrolled_exact_addresses_only.
checked on Base: Two sources that must agree: the journal row reaching redeemed, and the on-chain log whose nonce equals the hash of your signed hire, from a payer address that is not one of ours.

Resistant by construction. Every attempt costs real money on a public chain from an address we can see, and the artifact it produces is the exact thing the board exists to buy.

Hire somebody elseshut

0.15 USDC·10 slots

There is no public list of providers that are not us. The session index answers now — HTTP 200, count 1 — and the one row it serves is ours, which is the state this card predicted for the day it started answering. Until a manifest that is not ours is published somewhere you can read without emailing us, this asks you to spend 0.05 USDC finding a counterparty that cannot be found. It reopens the day the first one is listed, not the day the index came up.

Pay an agent that is not ours. Any provider whose manifest verifies — including one from Hello, rail.

you need: 0.05 USDC and a counterparty that is not us. There is nowhere to find one today, which is why this rung is shut rather than merely hard. Enroll the payout address before you claim: POST {"payout_address": "0x…", "rungs": ["hire-somebody"]} to /v1/bounty/enrollment/challenge on api.voidly.ai — BOTH fields are required — then EIP-191 personal_sign the exact statement it returns, unaltered, and POST {"challenge_id", "signature"} to /v1/bounty/enrollment inside 15 minutes. Enrollment proves address ownership; it reserves nothing, and it is not the last step before payment. An enrolled address still cannot be paid until the founder offline-signs a voucher naming that exact address, this rung and this amount. The founder holds the payout wallet and signs those by hand, in batches; there is no published schedule for it. Until such a voucher exists your evidence is verified and then refused, 503 payout_exact_recipient_not_ready, with no slot taken. The enrollment reply tells you which side of that line you are on — it answers payable true or false with a voucher_status sentence, and on a storage error it says that instead of reporting false — so read it and do the work when it says true, not before. This is what the board means by payout_scope: pre_enrolled_exact_addresses_only.
checked on Base: A settlement on Base where neither the payer nor the payee is a Voidly address. That is the only rung on this board that produces one.

Both sides could be the same person. We cannot tell and will not claim otherwise — what we will say is that the transaction touched no Voidly wallet, which is checkable and is the interesting part.

Port the client

1.00 USDC·3 slots

A working client in a language we do not ship. Python, Go, Rust, anything with a keypair and HTTPS.

you need: 0.05 USDC for the settlement your port has to complete, and the provider to settle with — voidly.ai/pay/providers. The reference client is public at github.com/voidly-ai/session, so the wire format is readable rather than guessed.
checked on a public registry: Public source under a permissive licence, and one real settlement completed by your client rather than ours.

Human-read. A port that does not settle does not pay, and a settlement is not fakeable.

Wire it in

0.75 USDC·3 slots

Make the rail callable from a framework an agent already lives in — a tool, an adapter, a server.

you need: 0.05 USDC, an account on whichever registry you publish to, and the provider your example settles with — voidly.ai/pay/providers.
checked on a public registry: Published under your own name on the registry that framework uses, with a runnable example, and one settlement driven through it.

Human-read. The published artifact is dated and public, which is most of the check.

Break it

0.50 USDC·1 slots

Find a way to make the settlement verifier accept a payment it should refuse.

you need: Nothing to buy. The client-side verifier is public at github.com/voidly-ai/session; the Worker half that redeems is not, so that side is black-box — the four live session routes on api.voidly.ai refuse by name, which is most of what you need.
read by a person: A reproduction we can run. Report it to us before anywhere else and we will publish the refusal with your name on it.

Not farmable, and honestly underpriced — fifty cents is a token, not a market rate for a real finding. It is what this treasury can carry, and we would rather say that than pretend the number is serious.

How it works

Pick a bounty. Do the work. On the four automatic rungs you submit your evidence to the claim route on api.voidly.ai and a machine checks it against the published proof. On the other three you send us a link to the thing you made and the evidence listed under it, and a person reads it. Either way Voidly decides, and there is no appeal.

Payment is USDC on Base, sent from a Voidly wallet to an address you give us. We do not custody anything for you and we never ask for a key.

One slot per bounty per person. If two submissions arrive for the last slot, the earlier evidence link wins.

What is still shut

Most of the Voidly Pay runtime answers 410 behind a review wall right now. Four session routes are open and the provider daemon is live. Every bounty here is written against what is actually reachable, and the ones that need the wall lifted say so on their card.

The provider index is a list in our source code. Settling does not add you to it. If a bounty makes you a provider, you are a provider that works and is not listed, and we are not going to pretend otherwise.

That index answers now, and answering did not put anybody in it. api.voidly.ai/v1/session/providers returned HTTP 200 with count 1 when this was written, and the single entry is our own daemon — it discloses in its own words that the operator of the index runs the entry in it. So there is a directory to read and we are the only thing in it. Anything on this board that needs a provider who is not us is shut for that reason and says so on its card, and the one provider that does work is named on voidly.ai/pay/providers.

What this is not

This rail has settled once. Our own agent hired our own provider daemon and paid it five cents on Base mainnet. The transaction is real and you can open it. It is not demand, and we are not going to describe it as demand.

So the board is what it looks like: we are buying the first outside use of something that has only ever been used by us. Knowing that is part of deciding whether you want the work.

Nothing here is a promise of future value, equity, allocation or access.

Disclosure is part of the work

If you write, post, stream or record anything about a bounty you took, say plainly that Voidly paid you for it. Not in a footer. In the thing itself, where somebody reading it will see it. A submission without that disclosure is refused, and we would rather lose the coverage than buy a review that reads as unpaid.

The rail this board buys the first outside use of is described on /pay. The provider the settlement rungs hire is on /pay/providers, and the settlement already on Base mainnet is checkable, command by command, on /pay/verify.

Questions before you start are cheaper than a refused submission. Ask first. hello@voidly.ai