Delivering the winning work

How exactly one Submission reaches the funding Poster, the custody trade-off that makes it convenient, and what limits the exposure.

An awarded bounty is only finished when the Poster who paid for it can actually read the winning work — and at the moment ElgoraHub names a winner, that work is still sealed ciphertext. Nobody has handed the Poster anything yet.

Closing that gap takes one indirection. A Guardian on the bounty's pinned roster takes a Submission's content key and wraps it — re-encrypts it — to the deployment's published delivery public key; Elgora stores that wrap, along with a record of which Guardian produced it, for which Submission, and when. When the Poster later comes to collect, the server opens the stored wrap with the matching delivery private key and immediately rewraps the content key to a single-use key the Poster's browser generated for that one request. The raw content key exists only inside that one server-side step; the Poster's browser unwraps it locally and decrypts the files there.

A Guardian may wrap a candidate Submission's key before anyone knows which Submission wins, so a stored wrap is not a claim about the outcome — finalized ElgoraHub state alone decides whether anything may be released, and for which Submission. In practice a Guardian waits and wraps a single key, for the winner its roster agreed on — which is why a public delivery/status check exists: Guardians poll it to see whether the winning Submission's key still needs delivering, and operators watch it on freshly awarded bounties.

The constraint set

Release is permitted only when finalized contract state says awarded, and only for the exact Submission that state names.
The recipient must be the funding Poster's wallet, proved by signature.
No caller can select a different or losing Submission.
The server never returns a raw stored key or a plaintext artifact.
No written Verdict, database row, or Elgora record can authorize a release that ElgoraHub state does not.

The gate reads ElgoraHub's state from Elgora's indexed copy of its event log, and only trusts the outcome and the named Submission once the block that recorded them is at or behind the chain's proven-finalized tip. ElgoraHub still owns the outcome; the index is just how the API reads it.

What is checked, and when

When a Guardian stores a wrap

The API verifies the Guardian is on that bounty's pinned roster, and that the Solver and Submission are a pair ElgoraHub currently records — narrowed to the exact finalized winner once the bounty is awarded. It then proves the wrap actually opens with the deployment's own delivery key before storing it.

That last check is worth noting: a broken wrap fails immediately, attributable to the Guardian who sent it, rather than surfacing months later as an unexplained failure for a Poster. It only ever touches the small wrapped key, never the Submission ciphertext, and the opened key is discarded at once.

When the Poster asks for the key

The Poster signs the request with the funding wallet. Before opening anything, the server re-reads finalized contract state — awarded, and this exact Submission — and confirms the signer is that bounty's funding Poster.

Because the Poster's key is generated per request, there is no key for a Poster to preserve, back up, or lose between funding a bounty and collecting the work months later. That convenience is the entire reason for the design — and it has a price.

The delivery key

For the Poster's browser key to stay single-use, something has to hold the winning content key in between — so a Guardian wraps it to a key the deployment holds, and the deployment rewraps it on retrieval. The alternative, a Poster-held key that has to survive the whole bounty lifetime, trades that for a class of permanent, unrecoverable delivery failures.

The delivery key is a standalone secret with no other power: no signing authority, no settlement authority, and no ability to move funds, change a Verdict, or read anything a Guardian did not wrap for it. Browser clients never receive it.

Every stored wrap records a delivery_key_id — a short hash of the delivery public key it was wrapped to, and the same value GET /api/deployment/delivery-key publishes. It is how a wrap says which keypair can open it, and it changes automatically if that keypair is ever rotated.

Wrapped keys that can no longer serve a finalized winner are cleared: on awarded, every losing Submission's; on no_valid_submission and timed_out, all of them. What is kept is the attestation — which Guardian wrapped a key, for which bounty, Solver, and Submission, and when.

If a wrap is missing

Anyone can check, without authenticating:

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

It answers {"exists": true} or {"exists": false} for exactly that Submission. It never reveals the key or which Guardian stored it. The submission_commitment query parameter is required.

If no wrap exists for the winning Submission, any roster Guardian can supply one with a single command. It is idempotent — re-running it, or running it after another Guardian already did, is harmless — so there is nothing to "repair", only a key to deliver. The contract still gates it: the pair must be the one it currently records, or the finalized winner. Local state and written Verdicts authorize nothing.

That is Guardian-side work. As a Poster, if status says false on an awarded bounty, ask the deployment operator or a roster Guardian to run it.

What the Poster receives

The exact artifact files the winning Solver sealed — the same names, media types, and bytes. Nothing is transformed, and nothing is re-served afterwards once the key material for that bounty has been cleared, so treat the retrieval as the moment you take custody of the work.