• The problem
• The insight: per-bid locktimes within current NUT-11
• How this gives early refunds
• How this prevents retractions
• Self-rebidding is capital-efficient
• Benefits
• Settlement policy versioning
• Open questions
• Conclusion

Moving-bound auctions: early refunds without oracle key custody

By: c03rad0r @Chiefmonkey

Date: 2026-05-24

§The problem

The v1 path-oracle auction (settlement_policy: cashu_p2pk_path_oracle_v1) has a UX gap:

Losing bidders wait for the full locktime (max_end_at + settlement_grace, typically 1-3 hours) to reclaim their ecash, even if the seller settles within seconds.

A bidder who bid 24 hours before the auction ends waits just as long as a bidder who bid 5 minutes before. This also makes rebidding capital-inefficient: a bidder who raises their own bid has both old and new amounts locked simultaneously.

SatsAndSports proposed two solutions using a coordinator (Carol) who holds a Cashu signing key per auction:

• SIG_ALL: bidder pre-signs two swap transactions (pay seller / refund bidder), coordinator picks which to co-sign. Instant refund for losers.
• SIG_INPUTs: coordinator signs message hashes blind, never sees the token. Instant refund for losers, better privacy.

Both work. Both require:

• Coordinator holding a Cashu signing key (new trust assumption)
• NUT-11 M-of-N multisig support from mints
• Seller needing coordinator’s signature for settlement (reduced autonomy vs v1)

§The insight: per-bid locktimes within current NUT-11

Instead of a single uniform locktime for all bids, each bid gets its own locktime. The oracle (same path oracle as v1, no new role) computes the locktime when issuing a derivation path:

locktime = max(current_effective_end + settlement_grace, now + minimum_bid_duration)

The auction’s effective end becomes:

effective_end_at = highest_bid_locktime - settlement_grace

The bound is “moving” — it shifts forward with each new bid.

§How this gives early refunds

Each bid’s locktime is based on when it was placed + the current auction state. When a bid is outbid, its locktime is typically minutes away, not hours.

Example: auction with end_at = 12:00, settlement_grace = 10 min, minimum_bid_duration = 5 min

• 10:00 Alice bids 1000 sats, locktime = 12:10
• 10:30 Bob bids 1500 sats, locktime = 12:15 (effective_end shifts to 12:05)
• 11:00 Carol bids 2000 sats, locktime = 12:20 (effective_end shifts to 12:10)

Bob was outbid at 11:00. His locktime is 12:15. He waits 1h15m from his bid time. In v1, Bob would wait until max_end_at + grace (potentially much later).

Alice’s first bid (locktime 12:10) is superseded at 10:30 and refunds at 12:10 — she already has her rebid active with a later locktime. Old bids recycle within minimum_bid_duration of being superseded.

With minimum_bid_duration = 5 min, losers wait at most 5 minutes for refund. Not instant (like coordinator co-sign), but dramatically faster than v1’s hours.

§How this prevents retractions

The winning bidder’s proofs are locked to the seller’s HD-derived child key (1-of-1 P2PK). The bidder holds no spending key — only a refund key that activates at locktime. The locktime is enforced by the mint. The bidder simply cannot retract. Same mechanism as v1. No oracle key in the lock needed.

§Self-rebidding is capital-efficient

When Alice rebids, she locks the new amount with a new (later) locktime. Her old bid’s locktime is shorter (it was assigned earlier). The old bid refunds at its locktime — typically within minimum_bid_duration of being superseded. Capital overlap is brief, not hours-long.

§Benefits

Preserved from v1:

• Oracle holds NO Cashu key material (derivation paths only)
• Seller claims independently after path reveal
• Basic NUT-11 compatibility (1-of-1 P2PK + locktime + refund, nothing more)
• Safe failure: oracle offline → all bids refund at their locktimes
• Bidder-side path verification unchanged (§5.6)

New vs v1:

• Loser refunds in minutes instead of hours
• Capital-efficient rebidding (old bids recycle fast)
• No hard max_end_at required (supports open-ended auctions)
• Anti-snipe built into the moving bound
• No new trust assumptions, no new parties, no new mint requirements

Tradeoff vs coordinator model:

• Refunds are fast (minutes), not instant (coordinator co-sign is instant)
• Rebidding has brief capital overlap, not zero
• For auctions running hours or days, the difference is negligible

§Settlement policy versioning

Introduced as cashu_p2pk_path_oracle_v2 alongside existing v1. Same auction kind (30408), bid kind (1023), settlement kind (1024), path registry (30410). Only the oracle’s request_path locktime calculation and effective_end_at derivation differ. Both policies coexist on relays. Old auctions settle under v1 forever.

§Open questions

• Default minimum_bid_duration (5 min? 10 min? per-auction seller parameter?)
• Is “minutes not instant” acceptable? For hours-long auctions, likely yes.
• Should there be an absolute maximum auction duration (e.g., 7 days)?
• How does the bid floor curve interact with the moving effective_end?

§Conclusion

Moving-bound per-bid locktimes give you fast loser refunds and capital-efficient rebidding while preserving every unique advantage of the path-oracle architecture. No coordinator keys. No multisig. No new trust assumptions. No mint changes.

The tradeoff is speed: minutes instead of instant. For a marketplace where auctions run for hours or days, this is the right tradeoff.