Outcomes and getting the work

The three ways a bounty can end, how to claim in each, and how the funding Poster retrieves the winning Submission.

After the submission deadline, Guardians judge and the contract settles. There are exactly three final states, and each gives you one action.

Final state	What happened	Your action
`awarded`	Two thirds of the pinned roster named the same winning Solver and Submission	Nothing to claim — the reward is reserved for the winner. Retrieve the winning work
`no_valid_submission`	Two thirds agreed no Submission met your criteria	Claim your refund: the full escrow if nobody submitted, otherwise minus the Guardian fee; no treasury fee is charged
`timed_out`	Nothing settled before the timeout	Claim the full escrow back, no fees taken

You cannot influence which one happens, and none of them can be revisited. Settlement is final.

Checking where your bounty stands

elgora-cli verification-record <bounty_id>

A plain, unauthenticated GET. For a finalized bounty it returns an advisory VerificationRecord: the final status, the winner if any, every Guardian's recorded Verdict and whether it supported the settled outcome, the amounts and recipients the outcome authorizes, the spec_commitment, and the settlement transaction. For a bounty that has not finalized yet it tells you so.

It is evidence, not a receipt

A VerificationRecord summarizes chain state. It is not proof of payment, it does not create an entitlement, and it never overrides ElgoraHub. When they disagree, the chain is right.

For live state before finality, read the bounty from the API or the subgraph — see The subgraph.

Claiming a refund

For no_valid_submission and timed_out, the contract has already queued your balance. Pull it whenever you like:

elgora-cli help claim
elgora-cli claim <bounty_id>                                  # local key
elgora-cli claim --claimant-address 0xYourWallet <bounty_id>  # external wallet

The command reads finalized state, checks you are the Poster of record, checks there is a non-zero balance queued to you, and then either sends claim or — with --claimant-address — simulates it and prints the exact transaction for your own wallet to send.

Queued balances never expire. Only the address they are owed to can claim them; no operator, Guardian, or Poster can redirect, sweep, or cancel one.

Retrieving the winning Submission

For an awarded bounty, the funding Poster — and only the funding Poster — may retrieve the winning Submission's content. Not a losing one, not a different Solver's, not a Submission from another bounty.

Use the web app or the CLI with the same funding wallet. In the web app, choose Open winning solution on the bounty page. From a terminal:

elgora-cli help poster:open-winning-submission
elgora-cli poster:open-winning-submission <bounty_id> [output_dir]

Both clients generate a fresh key pair locally for this retrieval.

What happens under the hood:

Your local client generates a one-time key pair

It exists for this one request. Nothing is stored, and there is no key for you to keep safe between now and whenever you come back.

You sign the retrieval request

The signature proves you control the funding wallet. The server independently reads finalized ElgoraHub state: the bounty must be awarded, and the Submission served must be the exact one the contract named. Neither a written Verdict nor any Elgora record can authorize this.

The server rewraps the content key to your one-time key

It unwraps the key a Guardian previously wrapped to the deployment, and immediately rewraps it to the public key your client just made. The raw content key never leaves that single server-side step, and you never receive a stored key or a plaintext artifact from the server.

Your local client decrypts

It unwraps with its private half and decrypts the artifact bundle locally.

The details, including the custody trade-off this design accepts, are on Delivering the winning work.

If delivery is not available yet

Delivery depends on a Guardian having wrapped the winning Submission's key for this deployment. That normally happens during judging, before anyone knows which Submission wins. You can check without authenticating:

GET /api/bounties/{bounty_id}/delivery/status?submission_commitment=0x…

It answers {"exists": true|false} for exactly that Submission — never the key itself, and never which Guardian stored it. The submission_commitment query parameter is required; without it the route returns 400.

If it says false on an awarded bounty, a Guardian can repair it with a single idempotent command that re-wraps the key for that exact Solver and Submission — the contract, not any off-chain record, decides whether that is still allowed. That is Guardian-side work; as a Poster, ask the deployment operator or a roster Guardian to run it.

Only the winner's key is kept

Key material that can never serve a finalized winner is cleared: on awarded, every losing Submission's wrapped key; on no_valid_submission and timed_out, all of them. The attestation that a Guardian wrapped a key is retained; the key itself is not. The winning Submission's wrap is what survives, so there is no deadline on your retrieval — but it is also the one piece of key material still in the deployment's reach, which is why the design bounds everything else.

What you get

The exact artifact files the winning Solver submitted, as they sealed them — names, media types, and bytes. What you may then do with them is a matter of whatever licence or terms your challenge stated. Elgora does not impose one, and does not keep a copy you can be re-served from once the key material is gone.

Outcomes and getting the work

On this page