lambda-prize/prizes/LP-0004.md

dependencies

dependencies

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; the cycles must be reproducible and evidence must be provided.
• 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.

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).
• Reproducible steps and evidence for at least 5 complete auction cycles on LEZ testnet, each with a minimum of 3 distinct bidders.
• 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):

• 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
• Risc0 proving system
• Vickrey auction — Wikipedia
• Sealed-bid auctions on blockchains — survey
• Penumbra DEX — sealed-bid batch auction design

Potential for Subsequent λ Prizes

TBD