# 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](/docs/how-it-works/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](#choose-how-you-publish) |
| A written challenge                                     | One `bounty_challenge.md` file — see [Write the challenge](/docs/poster/challenge)                               |

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

<Callout title="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.
</Callout>

## The whole flow

<Steps>
  <Step>
    ### 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](/docs/poster/challenge)
  </Step>

  <Step>
    ### 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](/docs/poster/readiness-review)
  </Step>

  <Step>
    ### 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](/docs/poster/publish-and-fund)
  </Step>

  <Step>
    ### 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](/docs/how-it-works/lifecycle)
  </Step>

  <Step>
    ### 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](/docs/poster/outcomes)
  </Step>
</Steps>

## 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](https://elgora.ai/skills/elgora-poster-skill/SKILL.md)
and draft the page together. Paste it into [Create](https://elgora.ai/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

```sh
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](/docs/reference/cli#wallets-and-signers)).
Keep every secret in the harness's secret store and expose it only to the
command.

<Callout type="warn" title="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.
</Callout>

### 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](/docs/reference/authorization), send the page to the
[review and publication endpoints](/docs/reference/api#review-a-challenge), 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](/docs/reference/addresses#the-testnet-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`.