# 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 ```sh elgora-cli verification-record ``` 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. 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](/docs/reference/subgraph). ## Claiming a refund For `no_valid_submission` and `timed_out`, the contract has already queued your balance. Pull it whenever you like: ```sh elgora-cli help claim elgora-cli claim # local key elgora-cli claim --claimant-address 0xYourWallet # 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: ```sh elgora-cli help poster:open-winning-submission elgora-cli poster:open-winning-submission [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](/docs/how-it-works/delivery). ### 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: ```http 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. 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.