Voidpay Bounties — the next public proof

Checking canonical board

Voidly never asks you to send funds. Check availability for your exact address and selected bounty before starting.

reading the canonical board in this browser

Wallet connection

Connect your wallet.

Use Robinhood Wallet or another WalletConnect wallet.

Connecting does not sign a message or move funds. Check the live board and your own payout eligibility before starting paid work.

Read payout requirements

Loading wallet connection…

Using Robinhood Wallet?

Choose WalletConnect and search for Robinhood Wallet. On a computer, scan the QR code with Robinhood Wallet, or choose OPEN, then All Wallets to search.

If you arrived from Telegram or another app, use its menu to open this page in your browser.

The genesis slate

Choose what you can prove.

Listed work is shown first. Readiness is separate and address-specific. Open the proof, prerequisites and limits before choosing a contract.

01Machine routeAuthored · listed

Hello, rail

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

Proof, prerequisites, limits

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. Check payout_mode and your selected rung in payout_readiness. In voucher mode the founder offline-signs a voucher naming that exact address, this rung and this amount, by hand with no published schedule; enrollment does not create that voucher. In allowance mode derive-nonce can pay automatically after verified work when readiness for your address is true. Unknown or stale readiness means check again before starting. Readiness does not reserve a slot or funds.
What proves it: 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.
Farm posture: 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.

Per accepted claim: 0.02 USDC
Authored slots: 40 slots
Verification: Machine checks the signed manifest and DID

02Machine routeAuthored · listed

Derive the nonce

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

Check my address and start

Proof, prerequisites, limits

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. Check payout_mode and your selected rung in payout_readiness. In voucher mode the founder offline-signs a voucher naming that exact address, this rung and this amount, by hand with no published schedule; enrollment does not create that voucher. In allowance mode derive-nonce can pay automatically after verified work when readiness for your address is true. Unknown or stale readiness means check again before starting. Readiness does not reserve a slot or funds.
What proves it: 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.
Farm posture: 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.

Per accepted claim: 0.03 USDC
Authored slots: 20 slots
Verification: Machine checked against your challenge

03Machine routeAuthored · listed

First settlement

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

Proof, prerequisites, limits

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. Check payout_mode and your selected rung in payout_readiness. In voucher mode the founder offline-signs a voucher naming that exact address, this rung and this amount, by hand with no published schedule; enrollment does not create that voucher. In allowance mode derive-nonce can pay automatically after verified work when readiness for your address is true. Unknown or stale readiness means check again before starting. Readiness does not reserve a slot or funds.
What proves it: 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.
Farm posture: 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.

Per accepted claim: 0.10 USDC
Authored slots: 40 slots
Verification: Machine checked on Base

05Person reviewedAuthored · listed

Port the client

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

Proof, prerequisites, limits

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.
What proves it: Public source under a permissive licence, and one real settlement completed by your client rather than ours.
Farm posture: Human-read. A port that does not settle does not pay, and a settlement is not fakeable.

Per accepted claim: 1.00 USDC
Authored slots: 3 slots
Verification: Person checked on a public registry

06Person reviewedAuthored · listed

Wire it in

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

Proof, prerequisites, limits

You need: 0.05 USDC, an account on whichever registry you publish to, and the provider your example settles with — voidly.ai/pay/providers.
What proves it: Published under your own name on the registry that framework uses, with a runnable example, and one settlement driven through it.
Farm posture: Human-read. The published artifact is dated and public, which is most of the check.

Per accepted claim: 0.75 USDC
Authored slots: 3 slots
Verification: Person checked on a public registry

07Person reviewedAuthored · listed

Break it

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

Proof, prerequisites, limits

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.
What proves it: A reproduction we can run. Report it to us before anywhere else and we will publish the refusal with your name on it.
Farm posture: 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.

Per accepted claim: 0.50 USDC
Authored slots: 1 slot
Verification: Read and decided by a person

04Machine routeAuthored · shut

Hire somebody else

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

Shut — do not begin work on this contract. The reopening condition is below.

Proof, prerequisites, limits

Why it is shut: 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.
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. Check payout_mode and your selected rung in payout_readiness. In voucher mode the founder offline-signs a voucher naming that exact address, this rung and this amount, by hand with no published schedule; enrollment does not create that voucher. In allowance mode derive-nonce can pay automatically after verified work when readiness for your address is true. Unknown or stale readiness means check again before starting. Readiness does not reserve a slot or funds.
What proves it: 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.
Farm posture: 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.

Per accepted claim: 0.15 USDC
Authored slots: 10 slots
Verification: Machine checked on Base

Loading the address check…

The clearing path

Qualify before you execute.

01
Choose
Pick the contract and read the exact proof rule.
02
Qualify
Check readiness for your exact address and selected bounty.
03
Execute
Produce the artifact without changing the agreed target.
04
Submit
Send the named evidence to the machine route or human reviewer.

Read the exact enrollment and starting protocol

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.

Check payout_mode and the selected rung in your own payout_readiness response before work. Enrollment proves address ownership; it is not the last step. In voucher mode the founder offline-signs a voucher naming that exact address, rung and amount, by hand with no published schedule; enrollment does not create that voucher. In allowance mode derive-nonce can pay automatically after its proof passes. Unknown or stale readiness means check again before starting. A readiness check reserves no funds.

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.

Terms that travel with the work

Proof without theater.

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.

The automatic route deduplicates by rung, payout address and evidence claim key; it cannot prove that two addresses belong to two different people. The final slot is reserved atomically, so concurrent accepted claims cannot both take it.

What is still shut

Most of the Voidpay 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.

Try free Proofs ↗Sessions Provider index Verify receipt

1.50 USDC across 10 slots are funded but shut, and remain visible with the reason.

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

Make the next proof.

Hello, rail

Connect your wallet.

Choose what you can prove.

Hello, rail

Derive the nonce

First settlement

Port the client

Wire it in

Break it

Hire somebody else

Qualify before you execute.

Choose

Qualify

Execute

Submit

Proof without theater.

Disclosure is part of the work