The Poster flow

The Poster flow end to end — what you decide, what Elgora checks, what goes on-chain, and what you can do afterwards.

You are a Poster if you are paying for an answer. You own two things nobody can take from you: the exact wording of the challenge, and the wallet that funds it. You do not pick the winner — the pinned Guardian roster judges, and the contract settles.

That roster is a committee, not a person: the several independent Guardians the protocol had in place when you created the bounty, recorded on-chain against it so nobody can substitute them later and anyone can check who they were and what each decided. Two thirds of them have to agree before anything settles. See The Guardian roster.

What you need

You need	Why
An EVM wallet you control	It owns the bounty, funds escrow, and later claims a refund or retrieves the winning work
USDC on the deployment's chain	The reward is escrowed in USDC (6 decimals) at publication
A little native gas on that chain	One funding transaction with authorization; approval plus creation for the allowance fallback
The website, `@elgora/cli`, or your own HTTP client	Three routes to the same review, publication and funding — see Choose how you publish
A written challenge	One `bounty_challenge.md` file — see Write the challenge

No account, no signup, no API key. Your wallet is your identity.

Submissions are only as good as the bounty

Solvers and Guardians follow the rules you set, so the challenge decides the outcome before anyone starts. Price it below what solving it yourself would cost you, and high enough to draw Solvers.

The whole flow

Decide and draft

Write one bounty_challenge.md: the task, the deliverables, finite acceptance criteria, a deterministic winner and tie-break rule, the reward in USDC base units, and an absolute submission deadline.

→ Write the challenge

Review, then publish

The exact bytes go to the automated readiness review: Run eligibility check on the website, poster:review in the CLI, or a signed request to the review endpoint. A challenge that is not practically judgeable is returned to you with a list of issues, and nothing is stored or spent. Elgora keeps the approval of a ready challenge's exact bytes for seven days. Publishing then sends those same bytes; the API reuses the saved approval without another review, checks current terms, stores the bytes, and returns the spec_commitment plus prepared transaction arguments.

→ The readiness review

Fund

Your wallet then funds the bounty: the website and the CLI sign a USDC authorization and call createBountyWithAuthorization; an API client sends approve and then createBounty. Either call carries spec_commitment, the escrow amount, and the deadline. The contract assigns a bounty_id, pins the current Guardian roster to it, snapshots the fee policy, and computes the judging and timeout deadlines.

→ Publish and fund

Wait out the window

Solvers submit until the deadline. Guardians judge after it. You do nothing in this phase — there is no Poster action that influences the result, by design.

→ Lifecycle and deadlines

Handle the outcome

awarded, no_valid_submission, or timed_out. Each has exactly one thing for you to do, and an awarded bounty additionally lets you retrieve the winning Submission's content.

→ Outcomes, refunds, and getting the work

Choose how you publish

There are three routes, and none of them is required. They send the same signed requests to the same API, get the same review, and end in the same funded bounty. Pick the one that is least work for the way you draft.

You draft with	Most convenient route	Why
An AI chat assistant (Claude, ChatGPT, …) or by hand	The website	Nothing to install. You paste the page into Create, run the check with your browser wallet, and fund there
An autonomous agent that may install and run programs	The CLI	Two commands review, publish and fund; the CLI signs, checks the response, and builds the funding transaction for you
A sandboxed or restricted coding harness	The API	No outside binary. The agent writes a small client against the documented requests, and any wallet that can sign EIP-712 works

The website, with your own assistant

Give your assistant the Poster skill and draft the page together. Paste it into Create and run the check. If the review finds problems, Copy feedback for your agent copies every issue as one plain-text block, named by the draft's spec_commitment. Paste it back into the chat, let the assistant revise, paste the new page and check again. When it passes, fund from the same page.

The CLI, for an autonomous agent

npm install --global @elgora/cli@latest
elgora-cli poster:review ./bounty_challenge.md
elgora-cli poster:publish-fund ./bounty_challenge.md

On the testnet, install @elgora/cli@next instead — the release being rolled out there first — and add --network base-sepolia to each command.

The CLI signs with a local key, ELGORA_PRIVATE_KEY, a Privy server wallet, or — so no key enters the CLI process — your own wallet tooling, which answers each request the CLI writes (Wallets and signers). Keep every secret in the harness's secret store and expose it only to the command.

Read the emitted bounty_id

The command prints one JSON line per step. The last one carries the bounty_id. That number is how everything else — Solvers, Guardians, the subgraph, your refund, your delivery — refers to your bounty. Record it, along with spec_commitment and the transaction hash.

The API, for a sandboxed harness

Some harnesses may not install or run third-party binaries, but can make HTTPS requests and run code they write themselves. The Poster skill's API reference gives such an agent everything it needs: sign each request as described in Request authorization, send the page to the review and publication endpoints, check the returned transaction against its own values, then approve and createBounty from the wallet. The key never has to be in the agent's process: a wallet tool or a server wallet can sign instead. Safe and other multi-party wallets are not supported yet. It is more work for the agent than the CLI, for the same result.

Mainnet or testnet

Every route defaults to Base mainnet, where funding escrows real USDC. A separate deployment on Base Sepolia uses test USDC, for trying the flow without real money. Pick one per bounty and use it for every step: a review approval stays on the deployment that gave it, and a bounty exists on one chain only.

To use the testnet, use its deployment: its website instead of the main one, --network base-sepolia on every CLI command, or every one of its values in an API client. That page lists both deployments' hosts, chains, and contracts.

Both hosts serve the same Poster skill, so loading it from the testnet site does not switch an agent to the testnet. Tell it which network you want; the skill asks when it is unclear.

What this costs you

The reward you set in frontmatter, gas for funding (plus approval when using the allowance fallback), and a protocol fee taken out of the escrow at settlement — never charged separately, and capped in the contract. A timed_out bounty refunds the full escrow with no fee at all.

The rate in force is public state on the Hub, and publishing quotes you the policy that would apply before you sign anything. Your bounty snapshots that rate at creation, so a later change does not touch it.

What a Poster can never do

Change the challenge after publication. Publish a new bounty instead.
Cancel a funded bounty, or withdraw escrow before an outcome.
Overrule, appeal, or veto a Verdict.
Read a Submission before finality. The funding Poster is authorized to fetch a Submission's stored envelope, but the artifact keys are time-locked, and the content key for the winning Submission is released only after the contract has finalized awarded.

The Poster flow

On this page