# LP-0004: Sealed-Bid Auction Using Shielded Balances [DRAFT]

**`Status: Draft - pending LEZ timelock feature`**
**`Logos Circle: N/A`**
## Overview

On-chain auctions are broken by transparency: every bid is visible to subsequent bidders, enabling last-second sniping, bid-matching, and strategic withholding. The result is that on-chain auctions fail to discover true market prices and systematically disadvantage honest participants.

Logos' shielded account model makes hidden balances a native primitive. This prize demonstrates the power of that model with a sealed-bid auction on LEZ — one where participants commit bids without revealing their amounts, no bidder can see competitors' maximum offers, and the winner is determined and assets transferred entirely on-chain without a trusted auctioneer.

## Motivation

Sealed-bid auctions (Vickrey, first-price, or hybrid formats) are theoretically optimal for price discovery, but they have been impractical on transparent blockchains: bids must be hidden until reveal, which requires either trusted off-chain components or complex commit-reveal schemes vulnerable to non-reveal griefing.

Logos' shielded execution model changes this. Hidden balances mean a bid can be a real on-chain transfer — not a commitment to a future transfer — that the contract holds in escrow without any observer knowing its value. There is no reveal phase and no griefing vector. This prize demonstrates that privacy-preserving shielded state is not just a financial feature but an infrastructure primitive that enables new classes of applications.

A competitive prize is the right mechanism because the design space is large: auction format (Vickrey vs. first-price), how the contract reads shielded escrow balances, tie-breaking, refund mechanics, and front-running resistance all have multiple valid solutions.

## Success Criteria

### Functionality

- [ ] Bidders can submit bids as shielded transfers to the auction program without the bid amount being visible to other participants or on-chain observers.
- [ ] The auction program determines the winner entirely on-chain, without a trusted auctioneer or off-chain reveal phase.
- [ ] Losing bidders receive full refunds to their shielded accounts without the refund amount being linkable to their original bid.
- [ ] At no point during or after the auction can a passive observer determine any losing bidder's maximum offer.
- [ ] A reference integration is delivered: a working demo of a complete auction lifecycle (open → bid → close → winner determined → refunds issued) on LEZ testnet.
- [ ] At least 5 complete auction cycles are run on LEZ testnet, each with a minimum of 3 distinct bidders, at least 3 of those auctions organised by parties outside the submitting team.
- [ ] Full documentation and a clean public repository are delivered.

### Usability

- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program.
- [ ] Provide a Logos Basecamp app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp).
- [ ] Provide an IDL for the LEZ program, using the [SPEL framework](https://github.com/logos-co/spel).

### Reliability

- [ ] The auction handles concurrent bids from multiple bidders without state corruption.
- [ ] Refunds are issued atomically — a refund failure does not leave a bidder unable to recover funds after timelock expiry.
- [ ] The auction state is consistent across sequencer restarts: in-progress auctions resume correctly.

### Performance

- [ ] Document the compute unit (CU) cost of bid submission, winner determination, and refund issuance on LEZ devnet/testnet. Note: LEZ's per-transaction compute budget may change during testnet.

### Supportability

- [ ] The program is deployed and tested on LEZ devnet/testnet.
- [ ] End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI.
- [ ] CI must be green on the default branch.
- [ ] A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and Basecamp app.
- [ ] A reproducible end-to-end demo script is provided and works against a real local sequencer with `RISC0_DEV_MODE=0`.
- [ ] A recorded video demo of the end-to-end flow is included in the submission; the recording must show terminal output (including proof generation) to confirm `RISC0_DEV_MODE=0` was active.

## Scope

### In Scope

- A LEZ auction program (Rust) implementing the full lifecycle: auction creation, shielded bid submission, winner determination, and refunds.
- A client-side SDK or CLI for submitting bids from shielded accounts.
- At least one auction format implemented: first-price sealed-bid or Vickrey (second-price). The submission must document the chosen format and justify the choice.
- A reference integration on LEZ testnet demonstrating a complete auction lifecycle.
- Documentation covering: auction format, how shielded balances are used for bid escrow, winner determination logic, refund mechanics, and known limitations.

### Out of Scope

- Hiding the identity of the winner (the winning bid transfer is out of scope for privacy; focus is on hiding bid amounts during the auction).
- English (ascending) or Dutch (descending) open-cry auction formats.
- Multi-asset or NFT auctions — fungible token bids only.
- A polished consumer UI — a working demo is sufficient.
- Ongoing maintenance or security audits beyond initial delivery.

## Prize Structure

- **Total Prize:** $TBD
- **Effort:** Large

## Eligibility

Open to any individual or team. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT or Apache-2.0.

## Submission Requirements

- Public repository with LEZ program code and client-side tooling under MIT or Apache-2.0.
- Program deployed on LEZ testnet with a verified program ID.
- End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates a full auction lifecycle with at least three bidders using shielded accounts. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
- Write-up covering: auction format and rationale, how shielded balances are used for escrow, winner determination and refund mechanics, security assumptions (e.g. miner/sequencer front-running), known limitations, and integration instructions.
- Gas cost benchmarks for bid submission, winner determination, and refund issuance.

## Evaluation Process

Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies all criteria wins.

Evaluators will independently clone the repository and run the demo script from a clean environment; the script must succeed without modification. Evaluators may also ask technical follow-up questions to verify authorship and understanding of the implementation.

The following policies apply to all prizes (see [evaluation policies](../README.md#evaluation-policies)):

- **Submissions:** each builder (or team) is allowed a maximum of **3 submissions** per prize, with at most **one submission/review per week**.
- **Feedback:** initial evaluation feedback is limited to a pass/fail indication against the success criteria.

## Resources

- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/)
- [Risc0 proving system](https://dev.risczero.com/)
- [Vickrey auction — Wikipedia](https://en.wikipedia.org/wiki/Vickrey_auction)
- [Sealed-bid auctions on blockchains — survey](https://eprint.iacr.org/2021/1113)
- [Penumbra DEX — sealed-bid batch auction design](https://protocol.penumbra.zone/main/dex.html)

## Potential for Subsequent λPrizes

TBD