DarkCallPrivate, verifiable sealed-bid auctions on ZcashLocal demo · isolated regtest
ZECATHON 2026 · Private Markets
No bid is ever opened. The price is still proven. Settled on Zcash.
Proving the price shouldn't require anyone to rebuild the bid book, not even the prover. DarkCall proves it without opening a single bid: not at the close, not to any single operator, not even to generate the zero-knowledge proof. One shielded transaction pays the seller and refunds every bidder exactly as proven, and checking it needs no published viewing key.
SplitREP3Multi-party computation
Each bidder's client splits the bid into secret shares for the operators. No operator can read one.
ProvecoNoirMulti-party ZK proving
The operators jointly prove the price. No one holds the bid book.
PayHalo2Proof-bound settlement
Four refunds, the seller and the fee: each amount and recipient proven, in one shielded transaction.
Beyond the auction terms, only the clearing price and the units sold are public: not the bid book, not how many bid at any other price (no demand curve), and not who was paid how much. By the auction rule the price equals the highest losing bid or the reserve, so that one amount is implied. In this demo each bidder's own client runs as a local service; operators receive only secret shares of each bid and proofs, never a bid.
The problem
Why a sealed auction is hard to verify
Bidders want their ceilings kept secret. Everyone else wants proof that the price and the payouts are right. Usually one of the two gives way.
01Checking the price usually opens the bids
Commit–reveal auctions and viewing-key audits prove the result by making every bid amount readable after the close.
02Whoever proves it sees every bid
A zero-knowledge proof can keep the bids from the public, but its prover, or an operator who decrypts them after the close, still reads the whole book.
03A proven price doesn't move the money
The payout is a separate transaction. Unless each refund and the seller's payment are proven too, the result and the money can disagree.
DarkCall answers all three. Bids become secret shares (REP3), the operators generate the proof together from those shares (coNoir), and every payout gets its own proof (Halo2), in one shielded Zcash transaction.
How it works
How can a sealed auction be publicly verified?
A bid is a willingness to pay. Say a newsletter sells three sponsor slots every month. If a sponsor's ceiling leaks after the close, next month's floor is set from it, and rival sponsors learn each other's budgets. In four stages, DarkCall turns private bids into a provably correct Zcash payment.
01 · SealCommit and split each bidCommitment · REP3 secret shares · client ZK proof🧑🏻Each bidder's own client
02 · FundLock deposits on ZcashShielded deposits · 2-of-3 FROST escrow · signed accepted book🧑🏻Bidders deposit · 🖥️all three operators sign
03 · ProveClear without openingMulti-party ZK proving · REP3 MPC + coNoir🖥️All three operators, together
04 · SettlePay exactly as provenHalo2 binding for 4 refunds, seller and fee · FROST · one shielded transaction🖥️Any two operators sign with FROST
🌐Public
✓ auction terms✓ clearing price✓ units sold✓ the proofs✓ one shielded transaction
Never published
✕ the bid book✕ any winner's maximum bid✕ demand at any other price✕ each refund✕ who paid which deposit✕ any viewing key
The operators learn who won and each refund, never the bid book. When only one bid loses, as in this demo, knowing the winners tells them that bid was the price.
Auditable without revealing
Why should an audit reveal the bids?
Blind auctions keep the bids secret but ask everyone to trust the result. Reveal-to-audit designs win the check back by opening the bids. Zero-knowledge designs with one prover check the price without publishing the bids, but that prover reads them all. DarkCall keeps the bids secret and still lets anyone check: no bid reveal, no published viewing key, no operator reconstructs the bid book.
Trusted blind auction
Sealed bidsThe seller clearssees every bidAnnounces a price
Bids stay hidden from the public, but the price and the escrow rest on trusting whoever runs it. No one else can check the result.
Commit–reveal or viewing-key audit
Sealed bidsOpen themreveal, or publish a keyRecompute
Auditability comes from making the bids readable after the close. Every bid amount becomes public.
Auditability comes from proofs, not from access to the bids. Verifying needs no bid and no viewing key.
The auction ends. The bidding strategy stays private.
Two bid books for the same three sponsor slots, reserve 20:
Bid book A
77614321
Sponsors would have paid far more
Bid book B
22222221
Barely above the price
Public result of bothPrice 21 · 3 of 3 soldThe same price, winners and refunds. Each book has its own commitments and proofs, and neither public check reveals the winners' maximum bids or the full demand curve.
A commit–reveal or viewing-key audit shows everyone which book it was, and next month's floor moves to match. DarkCall's public proofs tell a verifier the same thing for either book, price 21 and three sold, and no single operator learns which book it was.
Who needs a viewing key?
🌐Anyone verifyingNo viewing key
Checks the price and every payout from public proofs, signatures and the transaction. Decrypts no bid and no refund.
🔑Each bidderIts own key, kept
Opens only its own encrypted receipt, and never hands the key to anyone, verifiers included.
🖥️The three operatorsThe escrow's viewing key
Needed to admit deposits; it shows fixed-size deposits, never a bid. They learn winners and refunds, and none of them alone can rebuild the bid book (REP3). Knowing the winners, they can tell whose bid the price is when only one bid lost.
No viewing key is ever published. In this demo every party runs on one host, so each key staying on its owner's own device is the deployment model, not something this run shows.
Why multi-party ZK proving instead of a single prover?
Take the demo auction: four bidders seal maximum bids of 77, 61, 43 and 21 zatoshi for three units, so the price is 21. A zero-knowledge proof convinces everyone that 21 is right without showing the bids. The question is who has to see the bids to make that proof.
The verifier sees only the public result, not the bids. But the single prover must know every bid to generate the proof.
DarkCall · multi-party ZK proving (coNoir over REP3)
🖥️Operator A holds shares 13🖥️Operator B holds shares 21🖥️Operator C holds shares 32One joint proof
Three independent operators, A, B and C, run the auction. Each bid is split into three secret shares, 123; each operator holds two of them, and one share alone reveals nothing. The three operators compute the witness and the proof together from those shares. No single operator ever holds the complete bid book.
Assumes at most one semi-honest operator (REP3); two colluding operators could reconstruct the bids.
Threshold signatures don't prove the clearing price.
FROST spreads control over the funds. Publishing a viewing key makes the escrow auditable by disclosure. Both are useful, but neither proves a private clearing computation while the bids stay sealed. DarkCall goes further: multi-party ZK proves the clearing result without reconstructing the bid book, and Halo2 binds that result to the actual shielded payouts.
FROST distributes signing authority.ZK proves clearing over accepted bids.Multi-party ZK does it without opening them.
Multi-party ZK proving × Halo2 output binding
Proving the price is half the problem. Proving the payment is the other half.
A correct auction means nothing if the money goes somewhere else. DarkCall proves both the clearing result and that every payout in a verified settlement matches it. Two colluding signers could still move the escrow, but such a payout fails public verification.
Multi-party ZK · coNoir · BN254Prove the private resultClearing price and six private payout rows, committed with Poseidon2
Halo2 · PallasProve each payout matches4 refunds, seller and fee: each amount and recipient equals one native note commitment
Native Zcash · NU7One shielded transactionThe escrow's four Ironwood spends signed 2-of-3 with FROST; all six payouts proof-bound
Across two curves. The auction proof lives on BN254, while Zcash's shielded notes are commitments on Pallas, so the auction proof cannot speak about them directly. Each Halo2 proof recomputes one row's BN254 Poseidon2 commitment inside a Pallas circuit and shows that it holds the same amount and recipient as one native note commitment.
What checks what. The Zcash network validates the native transaction. DarkCall's public verifier checks the auction proof, the six output bindings and the accepted book's signatures against operator keys obtained independently of the bundle, with no secrets. All three operators sign the accepted book; any two of the three FROST signers authorize the settlement, and honest signers do so only after every proof checks out.
Why Poseidon2. In an earlier experiment, coNoir's joint proof of the six-row plan took 1,655 s with SHA-256 row commitments and 8.2 s with field-native Poseidon2. Both figures cover that proving step only, not the six Halo2 proofs.
Follow one auction
Four bids. Three winners. One shielded settlement.
The faint numbers under each seal are the demo's bids and payouts, shown only here; the protocol never publishes them. Point at a seal, or tap it, to read one.
🧑🏻Bidders · each bidder's client seals its bid and splits it into three secret shares, 123, sent to the operators. One share alone reveals nothing; only all three rebuild the bid
🧑🏻Ticket 0177
1233 secret shares
🧑🏻Ticket 0261
1233 secret shares
🧑🏻Ticket 0343
1233 secret shares
🧑🏻Ticket 0421
1233 secret shares
🖥️Operators and escrow · each operator receives two of every bid's three secret shares, never all three; the deposits sit in a 2-of-3 escrow
🖥️Operator A holds shares 13
T0113
T0213
T0313
T0413
Never all three shares of any bid
🖥️Operator B holds shares 21
T0121
T0221
T0321
T0421
Never all three shares of any bid
🖥️Operator C holds shares 32
T0132
T0232
T0332
T0432
Never all three shares of any bid
🔒Shielded 2-of-3 escrow4 × 15,100 zatoshiIts key was made jointly (DKG) for 2-of-3 FROST: no operator ever holds it whole, and any two must sign together to pay out. Each deposit: 100 budget + 15,000 processing fee (demo values).
2 · Fund · all three operatorsCheck every deposit, then sign the accepted bookThe same bid proofs and secret shares are checked again before anyone signs.
3 · Prove · all three operatorsClear on the secret shares and prove it jointlyREP3 MPC computes the price; coNoir turns the same computation into one proof. No operator sees a bid.
4 · Settle · any two of the threeBind every payout, then sign with FROSTHalo2 proofs tie each output to the result; then two operators each add a signature share, giving one ordinary Zcash signature.
⚙️Clearing and settlement · the price is computed on the secret shares (MPC), then paid in one shielded transaction
Computed on secret sharesPrice 21 · 3 of 3 soldcoNoir proof ✓ · no bid list rebuilt
One shielded transaction · six outputs
Refund · Ticket 0179Halo2 ✓ note
Refund · Ticket 0279Halo2 ✓ note
Refund · Ticket 0379Halo2 ✓ note
Refund · Ticket 04100Halo2 ✓ note
Seller · payment63Halo2 ✓ note
Operator · fee30,000Halo2 ✓ note
Plus a 30,000 zatoshi network fee, public on chain. Six outputs + fee = 4 × 15,100.🖥️🖥️Signed 2-of-3 with FROST by two operators; on chain it is an ordinary shielded transaction.
👀Who sees what · the public checks the proofs but sees no bid, winner or refund; each bidder opens only its own receipt
🌐Anyone seesPrice 21 · 3 sold · proofs ✓No secret and no viewing key needed to verifyNever sees✕ any bid✕ who won✕ any refund✕ who was paid
🔑Ticket 01's private receiptWon · refund 79Decrypted from its own memo with its own key, which it keepsCannot open✕ any other ticket's receipt
A closer look at the protocol
1
Bid commitment
🧑🏻Each bidder's own client · 🖥️each operator checks
Why can't a bid be changed later?
The bidder's client commits to a maximum bid and splits it into REP3 secret shares, one pair per operator. A Noir proof shows that the commitment and the shares hold the same bid, within the budget. Each operator checks it and signs a receipt.
Stays private the bid · Proven commitment and secret shares agree
2
Funding and admission
🧑🏻Bidders deposit · 🖥️all three operators sign the book
Who accepted which bids?
Each ticket deposits its budget plus fee into a shielded 2-of-3 FROST escrow made by DKG. The operators decrypt the deposits, re-verify the same proofs and secret shares, and after the close all three sign the root of the accepted book.
Stays private who funded which ticket · Signed the accepted book
3
Confidential clearing
🖥️All three operators, together
How is the price computed without seeing the bids?
The operators run the auction as REP3 multi-party computation on the secret shares: one uniform price, the winners and every refund. From the same shares they jointly generate the zero-knowledge proof by multi-party ZK proving with coNoir, so even the proving step never gathers the bids in one place. The proof shows the price follows the rules over exactly the committed bids; no bid list is reconstructed.
Stays private the bid book · Proven price and units sold · Note by the auction rule the price equals the highest losing bid or the reserve
4
Private outcome delivery
🖥️Operators to the settlement step · 🧑🏻each bidder reads only its own
Why aren't refunds and winners published?
Winner flags and refunds leave the MPC as blinded commitments and go only to the settlement step; the public sees the price and the number sold, never the list of results.
Stays private who won and each refund · Public price and units sold
5
Proof-bound Zcash settlement
🖥️Operators prove each payout · any two sign with FROST
How can anyone check the payout matches the result?
A settlement proof turns the same committed bids into six payment rows: four refunds, the seller and the operator fee. Six Halo2 proofs bind each row's amount and recipient to a native note commitment, and each refund note carries that bidder's encrypted receipt memo. The escrow's four Ironwood spends are signed 2-of-3 with FROST, with keys made by a DKG, so no escrow master key ever exists. Honest signers sign only after every proof checks out; colluding signers could still move funds, but not as a verifiable settlement.
Stays private amounts and recipients · Proven every output matches the result
6
Public verification
🌐Anyone · 🔑each bidder, for its own receipt
What can anyone check without seeing a bid?
The clearing proof, the six output bindings, the signed accepted book and the native Zcash proofs and signatures, from a public bundle with no secrets. Each bidder verifies a receipt proof, then decrypts only their own memo with their own viewing key.
Needs no secrets about 20–30 seconds on a laptop
Under the hood
Exactly what is computed, and what is proven
Three proof systems, each with one job. These are the relations the code checks.
1 · REP3 secret sharing
No operator holds a bid
Each bid x and its salt s are split into three field elements, two of them fresh random values. Every share is held by two operators, so any one operator sees only two uniformly random numbers.
# in the BN254 scalar field
x = x₁ + x₂ + x₃
A holds (x₁, x₃)
B holds (x₂, x₁)
C holds (x₃, x₂)
The bidder's client proves in bid_input (4,580 gates) that the commitment and the pairs it sends hold the same bid, so each operator checks its pair without learning x:
# the bid commitment, public in the book
c = Poseidon2(ctx, id, x, s)
# the pair operator i receives
cᵢ = Poseidon2(ctx, id, i, xᵢ, xᵢ₋₁, sᵢ, sᵢ₋₁)
# the shares add up, within the budget
x₁ + x₂ + x₃ = x ≤ budget
s₁ + s₂ + s₃ = s
2 · coNoir · multi-party ZK proving
The proof is generated on shares
The three operators run the Noir circuits as REP3 multi-party computation. The witness is computed on shares, and coNoir turns it into one UltraHonk proof that Barretenberg's verifier checks like any other. Three circuits: clearing auction4 (10,247 gates), winner flags delivery_flags4 (11,894) and the settlement plan settlement_poseidon4 (24,016). The settlement proof has 232 public fields:
Fixed in public
auction conditions, four ticket ids, units, reserve, budget, processing fee, the four bid commitments, the accepted root the operators signed, six receiver commitments, six action indices
Proven outputs
clearing price, units sold, a commitment to the private payout plan, and six row hashes h₁…h₆, one per payout
3 · Halo2 output binding
Each payout matches one proven row
A payout row is 224 bytes: conditions, accepted root, ticket, role, action index, recipient (gd, pkd), amount and salt. For each of the six rows, one Halo2 proof on Pallas (K = 17) shows, for the same private row and note opening:
# the row hash the coNoir proof output
Poseidon2_BN254(rowᵢ) = hᵢ
# the note at action aᵢ of the Zcash transaction
NoteCommit(g_d, pk_d, v, ρ, rseed) = cmxᵢ
Its public inputs are the eight words of hᵢ, the note commitment cmxᵢ and its action index aᵢ. BN254 arithmetic is emulated inside the Pallas field, which is why one binding is a 217-row circuit.
Signing. The escrow key is a 2-of-3 FROST key on RedPallas from a DKG, so no master key exists. Honest signers authorize the four Ironwood spends only after checking the coNoir proofs, the six bindings and the accepted book's three signatures.
Noir
1.0.0-rc.2
coNoir, REP3 (TACEO co-snarks)
467a2abb
Barretenberg, UltraHonk
87aa5283
halo2_proofs · halo2_gadgets
0.3.5 · 0.5.0
librustzcash (NU7)
9c5705f5
Orchard native fork
42015f15
RedDSA FROST fork
ed49e9ca
Zebra (NU7 regtest)
7.0.0-rc.0
Privacy
What each party sees
Every observer, from the public to the operators, and what each one learns. The full trust model is at the end of the page.
Observer
Learns
Does not learn
Anyone checking the auction
The terms, the clearing price, the units sold, the bid commitments, the proofs and the settlement transaction. By the auction rule the price is the highest losing bid or the reserve, so that one amount follows.
Any other bid, any winner's maximum, who won, any refund or payout, or how many bid at any other price.
Anyone watching Zcash
The shielded deposit and settlement transactions, with their fees and timing. The settlement has six outputs.
Amounts, senders, recipients, or which output pays whom.
Each bidder
Its own bid, and its own result and refund, decrypted from its own memo with its own key.
Other bids, or other bidders' results.
Any one operator
Two of the three secret shares of every bid, which reveal nothing on their own; who won, each refund, and which deposit is whose. When only one bid loses, knowing the winners tells it that bid was the price.
The bids, beyond what the price implies.
Two colluding operators
Every bid, by combining their shares: the stated REP3 limit. Together they could also sign a different payout, which then fails public verification.
Nothing more is kept from them.
This demo's host
Everything: here every role runs on one machine, each bidder's client included. A deployment puts each operator and each bidder's client on its own machine.
—
Recovery
What if something goes wrong?
What happens under the stated assumptions, and where each case is shown.
If this happens
Outcome
Shown
One operator stops before settlement
Clearing needs all three, so the auction cannot settle. The other two refund every deposit, 10,100 of 15,100 zatoshi each (the rest is the network fee), signing 2-of-3 with FROST without the stopped operator's key share.
Nobody can sign. The deposits wait in escrow until they return.
Limit
Two colluding operators sign a different payout
Not prevented. It fails public verification, so it cannot pass as this auction's settlement.
Limit
The operators drop an accepted bid
That bidder holds all three operators' signed acceptance and sees its ticket missing; outsiders cannot tell.
Limit
Proven on public Zcash testnet
It ran end to end on testnet.
On October 19 this auction was created, funded, cleared and settled in this UI on standard public Zcash testnet (NU7). It is the auction in the video and under "See a settled auction".
be1157c8…a1c8ad67Block 4,518,315 · 2 confirmations · settled in 19 min
Public check
102 sNo secrets · tampered proof refused
Also on testnet, Oct 21: a single-unit auction. Four new sealed bids (the same demo amounts) for one unit: price 61, one sold, settled in one shielded transaction 1d85d98f…82db, with the same circuits and proofs (record). One to three units now settle.
Zcash validated these native transactions; DarkCall's public verifier checked the auction proof, the six output bindings and the signed accepted book. Transaction links open ZecBlock, a third-party testnet explorer. The run read chain data from one lightwalletd provider (testnet.zec.rocks). Full record.
Evidence
Claims you can check
Each record is committed with the code and states its own commands and limits.
So do audits by a published viewing key or by bids revealed after the close: the bid information becomes readable. That matters wherever the same buyers come back: monthly sponsor slots, where this month's ceilings would set next month's floor, or a treasury selling blocks of a holding to funds, where each bid is a fund's valuation. DarkCall proves the price without opening any, then pays out in shielded ZEC.
Property
DarkCall
Open on-chain auction
Commit–reveal or published viewing key
Operator decrypts after the close, then proves (timelock or key committee)
Bids hidden from the public
Yes, never opened
No
Only until the close
Yes
Bids hidden from whoever runs it
Yes, from any single operator
No
No
No, it decrypts them after the close
Anyone can check the price
Yes, by zero-knowledge proof
Yes
Yes, by opening every bid amount
Yes, by its proof
Payments and refunds stay private
Yes, one shielded transaction
No
Possible, if paid shielded
Possible, if it pays shielded
Anyone can verify payouts match the result
Yes, six output proofs
Yes, by contract
By contract, or audited afterwards
Only if the payouts are proven too
Audit without revealing bids or keys
Yes, proofs only
No, nothing is hidden
No, opens the bids or publishes a key
For the price; the operator reads every bid
0.6 sto seal a bid with its zero-knowledge proof
9 sto clear four sealed bids by MPC, proof included
19 minto settle on testnet: every output proven, signed and confirmed
~30 sfor anyone to verify a settlement, no secrets needed (a machine's first check ~2 min)
Trust model: what DarkCall does not prove
Bid secrecy holds against at most one semi-honest operator (REP3). Two colluding operators can reconstruct the bids. This is not malicious-secure MPC.
Custody is 2-of-3 FROST from a DKG. Two colluding signers can move escrowed funds, and bidders have no unilateral refund. Clearing needs all three operators; if one stops before settlement, the other two refund every deposit, less a 5,000 zatoshi share of the network fee, signed 2-of-3 with FROST (shown on regtest). If two stop, the deposits wait in escrow. A colluding payout fails public verification but is not prevented.
The three operators hold the escrow's viewing key, which admitting deposits needs: it shows them fixed-size deposits, not bids, and they learn winners and refunds. No viewing key is published, and public verification needs none.
The public price is the highest losing bid, or the reserve, so one bid value can follow from it; the operators, who know the winners, can tell whose it is when only one bid lost.
Public verification trusts the auction's operator admission keys, which a verifier must obtain independently of the bundle. Funding is certified by those operators' signatures, not proven in zero knowledge, and the bundle alone does not prove chain inclusion.
The public check proves the result over the operators' signed book; it cannot show that every funded bid made it in. Each bidder holds all three operators' signed acceptance and checks that its own ticket is in the book, so dropping an accepted bid is visible to that bidder, not to outsiders.
In this demo every party runs on one host: each bidder's client (which sees its own typed bid) and all three operators, and one test wallet funds all four tickets.
Common designs compared, not specific projects. Other ZK and MPC auction designs also keep bids private; DarkCall's focus is combining multi-party ZK proving with proof-bound, native shielded settlement on Zcash. Timings from one 16 GiB laptop; testnet coins only.
Try it yourself
Check the settled auction, or run your own.
Your auctionDemo bids
1Create
2Bid
3Fund
4Clear
5Result
6Settle
Create your auction.
You play the seller and all four bidders: create the auction, seal four bids, then fund, clear and settle it on Zcash. Each step says what to do next. About 20 minutes on the local regtest.
0 / 4 sealed
Bids and receipts
Works in another browser on this computer.
Signed pre-check
Step 3 · FundIsolated regtest
Lock the deposits.
Every sealed ticket gets a real shielded deposit of budget plus fee, paid from one local test wallet. The operators decrypt the deposits, re-check the same bid proofs and secret shares, and sign the closed book again over the same root. About 2 minutes.
Deposit and admit4 shielded deposits · same proofs and 12 secret-share pairs (each operator's two shares of each bid) re-checked · book signed over the same root
Deposit transaction
—
Chain admission
—
If one operator stops, the other two refund everyone.
Clearing needs all three operators. If one stops before the auction settles, the other two return every deposit: one shielded transaction, its four escrow spends signed 2-of-3 with FROST, each to that ticket's certified refund address, less a 5,000 zatoshi share of the network fee. The stopped operator's key share is never needed. If two stop, the deposits wait in escrow.
A and B sign the refundFour Ironwood spends · 2-of-3 FROST · C's journal and key share never opened
Broadcast and checkTwo confirmations · every refund wallet and the empty escrow checked
Refund transaction
—
Each ticket
—
Step 4 · ClearFresh proof
Discover the price.
Clearing price—zatoshi per unit
Units sold—of 3
Every winner pays the same price. Three operators computed it on secret shares, and no bid was reconstructed.
No deposit yet · funding comes after the close
Still sealed.
Open the result of a ticket you sealed here.
Try to cheat
Change one byte of the proof and watch it fail.
Clearing details
The bidder's client on this computer sees demo inputs; operators get only secret shares of the bids. Three semi-honest REP3 parties run on this computer; privacy assumes at most one is corrupt. The ticket capability lives only in this page's memory, so reloading loses it. It is not a production login.
Step 6 · SettleIsolated regtest
Pay it out, privately.
One shielded transaction pays the seller and every refund from the funded escrow, and every output is bound to the proven result. About 10 minutes on this Mac.
MPC deliveryA fresh REP3 run on the same secret shares; the price must match
Bind every outputSix Halo2 proofs tie each amount to its recipient
Sign and confirmAuction proof · 2-of-3 FROST · Zebra · six wallets
Public checkA verifier replays the public bundle, with no secrets
🌐Everyone
The clearing price, the units sold, and one shielded transaction with its proofs. Nothing about demand at any other price.
🧑🏻Each bidder
Only their own result and refund, from their own encrypted memo.
🖥️The operators
Who won and the refunds. Each one holds only secret shares of the bids.
🙈Never published
✕ who bid what✕ any winning bid✕ demand at other prices
The price is the highest losing bid.
Settlement transaction
—
Deposit transaction
—
Same sealed book
—
Outcome
—
Your receipt is encrypted.
Only your viewing key can open your memo in this transaction.
Try to cheat
Corrupt the receipt proof. Your key is never read.
About this demo
Sealing a bid gives an instant signed pre-check of its proof and secret shares. Fund on Zcash then makes a real deposit for every sealed ticket on an isolated NU7 regtest: budget plus 15,000 zatoshi each, from one local test wallet. The operators admit the deposits under a chain-funded certificate over the same accepted root. Only then does REP3 clear the book, and Settle on Zcash pays out in one shielded transaction. Each bidder's client runs on this computer: it sees its own typed bid and creates the proof and the secret shares; operators receive only secret shares and proofs.
Four tickets are required. After the cutoff, three operators sign the accepted book and run the same secret shares through REP3. The fixed proof and signed root are verified before any ticket's result is opened. Everything runs on one host; the MPC is semi-honest, and privacy assumes at most one corrupt party.
Amounts are demo-sized on purpose. Bids stay within a 100-zatoshi budget, and the fixed 15,000-zatoshi processing fee per ticket pays the settlement's 30,000-zatoshi network fee and a 30,000-zatoshi operator fee output. This is a cryptographic end-to-end demo, not a pricing proposal.
The opening capability stays in page memory, so reloading loses access. Before Settle, your result is checked against the clearing proof on this computer; after Settle, it is decrypted from your ticket's own native shielded memo. This is not production authentication or in-browser proving.
No time to wait?
See a settled auction.
An auction that was created and settled in this UI earlier. Open its bidders' receipts, verify it in about 20 seconds, or try to cheat it. It does not settle these demo bids.
A settled auction
Private payments, publicly verified.
A real auction, created and settled in this UI. Try these three in any order:
1 · Open a private result. Act as any bidder; only that bidder's key opens the receipt.
2 · Verify the settlement. The public check, with no secrets; about 20 seconds.
3 · Try to cheat. Change an accepted bid, the price or a payout proof, and see which check refuses it.
Loading the recorded demo…
The auctionRecorded
Four sealed bids, three units
Think of a newsletter selling three sponsor slots this month. No operator ever rebuilds the bid book; only the clearing price is published.
Clearing price—zatoshi per unit
Units sold—/ 3units
01sealed
02sealed
03sealed
04sealed
Every winner paid the same price. The maximum bids stayed secret-shared.
1 · What stays private
Who sees the result?
Act as any of the four bidders. Each receipt opens only with that bidder's own key.
Still sealed.
Open your encrypted receipt to see your result.
What gets verified
The fixed auction and receipt proofs
The native Zcash transaction
Your own ticket and refund, decrypted with your key
Each opening reads only that bidder's viewing key. All demo identities live on this computer, and choosing a bidder is not a login.
2 · Verify the whole settlement
One transaction. Every output checked.
Check that the shielded Zcash transaction matches the auction outcome, without seeing the bids.
Six output bindings · auction proof · native authorization · signed book
Inspect the proof trail The public data behind each claim
Rather not trust this server? On your own machine, scripts/docker_verify.sh builds every pinned tool from source in a clean Linux container and verifies this same bundle with no network: about 20 minutes and 15 GB of disk the first time. How to run it.
3 · Try to cheat
Can a dishonest operator get away with it?
Pick one change. DarkCall makes it to a copy of this settlement and runs the same verifiers on it. Nothing is simulated.
A refused change cannot pass as this auction's settlement. Not shown here: two colluding operators can sign a different transaction from the escrow. Its outputs would not match the payout proofs, so it could not pass this check, but the funds would still have moved.
Recorded clearing; own receipt unopened. Settlement not reverified in this session.
Public check
Not run in this page session.
Trust model and limits
Bid secrecy assumes at most one semi-honest REP3 party is corrupt. Two colluding parties can reconstruct bids.
Custody is 2-of-3. Two signers can move funds, and users cannot force a unilateral refund. If one operator stops before settlement, the other two can refund every deposit; if two stop, the deposits wait.
The three operators hold the escrow's viewing key (it shows fixed-size deposits, not bids) and learn refunds and who won. Public outcomes can allow inference. No viewing key is published; verifying needs none.
Every party of the recorded auction ran on one host; see the chain note below. No malicious-MPC or production-custody claim.
Accepted-book signatures attest funding; they are not a public ZK funding proof. The admission authority is configured and trusted separately.
The public check proves the result over the operators' signed book; it cannot show that every funded bid made it in. Each bidder holds all three operators' signed acceptance and checks that its own ticket is in the book, so dropping an accepted bid is visible to that bidder, not to outsiders.
Item delivery, network anonymity and Sybil resistance are outside this prototype.
No chain inclusion proof in the public bundle.
Recorded settlement; separate offline rehearsal with synthetic funding.