Skip to main content
sealForge runs auditable sealed-bid auctions on Zcash: the clearing price is public, the bidders aren’t. A bid is one shielded payment to a per-auction escrow address. Its encrypted memo carries a salted commitment and a refund address. The escrow is a 2-of-3 FROST key generated by three trustees. After the auction closes, the organiser publishes the result and the escrow’s incoming viewing key (UIVK). Anyone can then recompute the result from the chain. Refunds and the payout are 2-of-3 threshold spends of the escrow, built as PCZTs.

Status

One row per component. Labels are defined in the docs index. No component has run on mainnet.

The three guarantees

Stated as what is hidden, from whom, and when. Each links to where it’s enforced.
  1. Bidders are hidden from chain observers during the auction and after it. A bid is a shielded Ironwood payment. The published UIVK decrypts incoming notes (amounts and memos), not senders. The refund address in each memo becomes readable after publish, so the bid flow asks for a fresh address per bid. See 2.1 Roles and 3 Zcash integration.
  2. Bid amounts are hidden from chain observers during the auction. In sealed-reveal mode the price is also hidden from the coordinator and trustees until the reveal window, though they see deposit sizes, which bound the price from above. In deposit mode the coordinator and trustees see amounts as bids arrive. After publish, every amount is public. See 2.4 Commitments and 5 Security.
  3. Anyone can recompute the result from the chain with only the published UIVK and a lightwallet server they choose. The auditor reclassifies every payment with the same sealforge_core::selection code the coordinator ran, then recomputes clearing and the Merkle root and compares every field. See 6 Verification.

What it doesn’t guarantee

  • Bidder behaviour at the exit. A bidder who moves all refund notes out at once recreates their refund amount (2.7 Refund privacy).
  • Source-chain privacy for ShieldRamp. Not built. EVM-side deposits are public.
  • Coordinator and organiser liveness. Refunds need the organiser to publish, the coordinator to build transactions, and two trustees to sign. Any of them can delay (5 Security).
  • Protection against a malicious coordinator at refund time. Trustees sign the sighash the coordinator gives them without seeing the transaction, so they can’t detect a spend that pays the wrong place. One rogue trustee can’t move funds; a rogue coordinator plus two trustees signing as instructed can. Closing this is a mainnet gate (5 Security).
  • Operator blindness in deposit mode (5 Security).

Ninety seconds

  1. Open a finished testnet auction: <https://sealforge.udokaam.dev/a/KE5DFF4PDA>.
  2. Open its audit page, <https://sealforge.udokaam.dev/audit/KE5DFF4PDA>, and press Rescan the chain in my browser. Your browser fetches the blocks over gRPC-web from a lightwallet server you choose, decrypts them with the published UIVK in WebAssembly, and recomputes the result.
  3. Or from a terminal: sealforge-audit --published https://sealforge.udokaam.dev/api/auctions/KE5DFF4PDA/result --endpoint https://testnet.zec.rocks:443 (see 6 Verification).