Seller-relay re-locks: guaranteed fast refunds without oracle key custody
- The problem
- Why per-bid short locktimes alone don’t work
- The seller-relay re-lock mechanism
- What the oracle holds (key material analysis)
- What the seller holds
- What the bidder holds
- Liveness requirement analysis
- Game-theoretic analysis
- Benefits
- Open questions
Seller-relay re-locks: guaranteed fast refunds without oracle key custody
By: c03rad0r nostr:npub1a3um269aaf3u5e5ee64fa883d107ef9e558472c4eb9aaaefa459d
Date: 2026-05-24
The problem
In v1 path-oracle auctions, losing bidders wait for the full locktime (max_end_at + settlement_grace, typically 1-3 hours) to reclaim their ecash.
The moving-bound design (per-bid locktimes) helps when bidding is active but degrades to v1-equivalent latency when bidding is sparse. Two bidders who bid once each at 10:00 and 10:05 will both wait until their respective locktimes — which could be hours away.
The coordinator proposals from SatsAndSports give instant refunds but require the coordinator to hold a Cashu signing key and the seller to need the coordinator’s signature at settlement.
We want:
- Guaranteed fast refunds for losers (not best-effort)
- Oracle holds NO Cashu key material (only derivation paths)
- Seller claims independently after path reveal
- Basic NUT-11 mint compatibility (no multisig)
- Bid retraction prevented by the protocol, not by trust
Why per-bid short locktimes alone don’t work
If every bid starts with a short locktime (e.g., now + 5 minutes), losers get fast refunds. But the standing (highest) bidder’s locktime also expires in 5 minutes. If nobody extends it, the standing bid evaporates and the auction has no valid commitment.
The standing bidder can’t extend their own locktime because the proofs are locked to the seller’s HD-derived child key (1-of-1 P2PK). Only the seller can spend them (after the oracle reveals the path). The bidder doesn’t hold the child privkey and can’t re-lock.
The seller-relay re-lock mechanism
Every bid starts with a SHORT locktime. The oracle periodically re-locks the standing bid by coordinating with the seller. Losers’ short locktimes expire and they reclaim. Fast refund is guaranteed.
Bid flow
- Bidder requests path from oracle. Oracle issues path_A, child_pubkey_A, locktime = now + minimum_bid_duration (e.g., 5 min).
- Bidder locks proofs 1-of-1 to child_pubkey_A. Same v1 lock profile.
- Bidder publishes bid event + submits token to oracle (same as v1).
Re-lock flow (standing bid only)
When the standing bid’s locktime approaches:
- Oracle issues a NEW path_B, child_pubkey_B, locktime = now + minimum_bid_duration.
- Oracle EARLY-REVEALS path_A to the seller (before auction ends).
- Seller’s daemon derives child_privkey_A from the revealed path_A.
- Seller’s daemon swaps the old proofs (locked to child_pubkey_A) to new proofs locked to child_pubkey_B with the new locktime.
- Oracle does NOT reveal path_B. It stays secret until settlement.
- The old proofs are consumed (spent at the mint). The new proofs replace them.
The standing bid is now re-locked with a fresh short locktime. Repeat as needed.
Settlement (same as v1)
- Oracle reveals the final derivation path for the winning bid.
- Seller derives child privkey, claims the proofs. Done.
Refund for losers
Losing bidders never get re-locked. Their locktime = bid_time + minimum_bid_duration. They reclaim via refund key when it expires. Guaranteed within minimum_bid_duration, regardless of bidding activity or liveness of any other party.
Seller offline fallback
If the seller’s daemon doesn’t respond to a re-lock request:
- The standing bid’s locktime expires.
- The standing bidder reclaims via refund key. Their funds are safe.
- The auction continues with the next-highest bid.
- This is equivalent to “seller failed to maintain the standing bid.”
- The bidder does NOT lose funds. They get everything back.
Worst case for the standing bidder: wait until locktime (minutes, not hours). Worst case for the seller: auction settles at a lower price or with no winner.
What the oracle holds (key material analysis)
The oracle holds:
- Derivation paths for all bids (same as v1)
- Encrypted bid tokens (same as v1)
The oracle does NOT hold:
- Any Cashu signing key
- Any child privkey
- Any xpriv material
- Any bidder privkey
The oracle’s role is purely informational: it assigns paths, tracks which bid is standing, and reveals paths at the appropriate times. Even a fully compromised oracle cannot steal funds. It can only:
- Refuse to issue new paths (DoS, same as v1)
- Reveal paths to the seller prematurely (enables early seller claim — but only for the standing bid, which the seller would win at settlement anyway)
- Fail to coordinate re-locks (standing bids evaporate, auction degrades)
None of these produce fund theft. The oracle’s trust profile is identical to v1.
What the seller holds
- xpriv for deriving child privkeys from revealed paths (same as v1)
- The re-lock daemon must be online during the auction to respond to re-lock requests
The seller does NOT hold:
- Any bidder’s privkey or refund key
- Any oracle signing key
- Any ability to spend non-standing bids
The seller can only spend proofs that have been re-locked to them (the standing bid’s current child pubkey). They cannot spend losing bidders’ proofs because those proofs are locked to different child pubkeys whose paths have NOT been revealed to the seller.
What the bidder holds
- Their own refund privkey (same as v1)
- The derivation path they were granted (for audit, same as v1)
The bidder does NOT hold:
- Any child privkey (seller’s key)
- Any spending key for the locked proofs before locktime
The bidder trusts only:
- The mint (to honor proofs, same as any Cashu user)
- The oracle (to not reveal paths to the seller prematurely — same as v1)
- NOT the seller for refund. The bidder’s refund is enforced by the mint’s locktime mechanism. If the seller goes offline, the bidder waits for locktime and reclaims. No seller cooperation needed.
Liveness requirement analysis
| Party | Must be online when | Consequence of going offline |
|---|---|---|
| Oracle | Always (same as v1) | No new paths issued, no re-locks. All bids refund at locktime. Same as v1. |
| Seller’s daemon | During auction (new) | Standing bids evaporate as locktimes expire. Auction degrades to next-highest. No fund loss. |
| Bidder | Only to place bid (same as v1) | If standing bidder goes offline, their bid’s locktime eventually expires. They reclaim. No fund loss. |
The seller’s liveness is a NEW requirement vs v1. In v1, the seller only needs to be online at settlement time (after auction ends). In the seller-relay design, the seller must also be online during the auction to maintain the standing bid.
However:
- The seller is already running a marketplace (Plebeian Market). A lightweight daemon is a natural extension.
- The consequence of seller offline is graceful degradation, not fund loss. The auction continues with the next-highest bid.
- The seller is economically incentivized to stay online: offline means their auction sells for less (or not at all).
Game-theoretic analysis
Bidder strategies
- Honest bid: lock value, hope to win. If outbid, reclaim within minutes. Rational. No downside vs v1 (faster refund).
- Spam bid: lock value with no intent to win. Funds are locked for minimum_bid_duration. Same cost as v1 but shorter lockup. Oracle rate-limiting applies (same as v1).
- Bid retraction: impossible. Proofs locked to seller’s child key. Bidder has no spending key. Same as v1.
- Refund griefing: bidder cannot prevent or delay their own refund. The mint enforces locktime. No counterparty risk.
Seller strategies
- Honest: run daemon, maintain standing bids, settle at auction end. Rational. Maximizes sale price.
- Go offline: standing bids evaporate. Auction degrades. Seller gets lower price or no sale. Self-harming. No fund theft possible.
- Premature claim: seller could spend re-locked proofs before auction ends. But those proofs are for the standing bid — the bid the seller would win at settlement anyway. Claiming early doesn’t give the seller more money. It does end the auction prematurely, which the oracle can detect and flag. Social/economic disincentive (reputation damage, platform ban).
Oracle strategies
- Honest: issue paths, coordinate re-locks, reveal at settlement. Same trust assumption as v1.
- Refuse re-locks: standing bids evaporate. Auction degrades. Same DoS risk as v1. No fund theft.
- Reveal paths early: enables seller to claim standing bid early. Same risk as v1 (oracle could reveal path before settlement). Mitigated by same v1 mechanisms (bidder audit of path registry).
- Fabricate paths: bidder verifies child_pubkey derivation (§5.6). Same protection as v1.
Collusion scenarios
- Seller + Oracle: could prematurely claim the standing bid. But the standing bid is the one the seller would win anyway. No extra theft. Could claim a losing bid? No — the oracle has NOT revealed the losing bid’s path to the seller. Only the standing bid’s path is early-revealed for re-lock.
- Seller + Bidder: bidder could let their standing bid expire on purpose. But then they get their own money back. No theft of other bidders’ funds.
- Oracle + Bidder: oracle could refuse to re-lock a standing bid from a competing bidder. The competing bid evaporates. This is a DoS vector, same as v1. No fund theft.
Benefits
Preserved from v1:
- Oracle holds NO Cashu key material
- Seller claims independently after final path reveal
- Basic NUT-11 compatibility (1-of-1 P2PK + locktime + refund)
- Bid retraction prevented (bidder has no spending key)
- Safe failure: all bids refund at their locktimes
- Bidder-side path verification (§5.6)
New vs v1:
- Guaranteed fast refunds for losers (within minimum_bid_duration, not hours)
- Refund speed independent of bidding activity or liveness of other bidders
- Supports open-ended auctions (no hard max_end_at)
- Anti-snipe built into the re-lock cycle (standing bid keeps extending)
- No new entities, no coordinator keys, no multisig, no new trust assumptions
Tradeoffs vs v1:
- Seller must run a lightweight daemon during the auction (new liveness requirement)
- Standing bidder’s proofs are re-locked by the seller — bidder temporarily loses visibility of their funds during re-lock transitions
- Oracle must track re-lock state (slightly more complex than v1)
Open questions
- How does the seller’s daemon authenticate re-lock requests from the oracle?
- Should re-lock be a new ContextVM tool (request_relock) or an extension of request_path?
- What is the optimal minimum_bid_duration? Shorter = faster refunds but more frequent re-locks (more seller daemon activity, more mint swaps).
- Should there be a maximum number of re-locks per bid to prevent seller exhaustion?
- How does the bid floor curve interact with re-lock timing?
Highlights (2)
The coordinator proposals from SatsAndSports give instant refunds but requirethe coordinator to hold a Cashu signing key and the seller to need thecoordinator's signature at settlement.
The coordinator proposals from SatsAndSports give instant refunds but require the coordinator to hold a Cashu signing key and the seller to need the coordinator's signature at settlement.
Write a comment