SkyhookThe Contracts

Bespoke Haggling versus Standing Tickets

Skyhook Bridge counterparties agree on a price in one of two modes, which differ mainly in who sets the price and how firmly. In bespoke mode the requester writes her terms into the request and anyone may fill it, so the market works like an open outcry auction. In standing mode a liquidity provider commits inventory once and then prices individual trades by signing short-lived tickets, whose amounts the contract enforces through the signature rather than by computing a price. Both modes settle through the same lifecycle and the same finality machinery, so the assurances a swap receives don’t depend on how it was priced.

Bespoke mode

In bespoke mode Alice states the amount, her tolerance and the expiry directly in her request blob, in plain view. Anyone can then fill the request. There is no provider signature on the price, no menu of quotes and no required relationship between the parties, and the request stands as an open offer until it is filled, cancelled or expires.

The margin is set by toleranceBps, the largest discount below her stated amount that Alice will accept, in basis points; 200 basis points is 2%. Liquidity providers run automated fillers that watch the oracle exchange rate and fill as soon as filling is more profitable than waiting. The spread therefore goes to the fastest capable filler. Because nothing needs to be negotiated, the mode handles unusual amounts, odd expiries and one-off arrangements without special treatment.

Bespoke pricing with toleranceBpsInteractive
Floor: the least ZEC a fill may pay
Escrowed ETH, valued in ZEC at the market rate
Provider's margin if filling at the floor

The ETH locked is the request's howMuchEth. The floor is the requested amount less the tolerance (200 bps is 2%). Any party may fill at or above the floor. A liquidity provider's automated filler watches the market rate off-chain and fills once doing so beats waiting, so the margin goes to the fastest capable filler; the contract itself never computes a price. The starting rate is Coinbase's spot price when this site was built.

Standing mode

Standing mode reverses who sets the price. A liquidity provider selling ETH locks it once in a standing order, a single transaction that creates a durable on-chain commitment. Standing orders exist only on the Ethereum side: Zcash has no way to set one up, and ZEC providers don’t need one, since they lock nothing. From then on the provider signs per-quote tickets off-chain. Each ticket states the ZEC amount to pay, the taker it is issued to, the amount out and an expiry: three numbers and a deadline under one signature.

The signature is the price. The spread between the quoted amounts is the provider’s entire fee, and it is enforced cryptographically rather than by contract arithmetic: the contract checks each ticket’s authentication, accounting and deadline, but never computes a price. From the deadline, the contract extrapolates the ideal expiryHeight for the Zcash payment, so a payment that misses its window can never be mined late. A ticket can optionally add a buffer, a period between the expiryHeight and the deadline, which gives the recipient time to respond to the swap, or lets MEV bots watch for the payment’s transaction ID and submit the first proof while it waits for finality. Tickets have three layers of protection:

  • each ticket can be used only once, which rules out replays;
  • each ticket names its taker, so a front-runner would have to present someone else’s non-transferable authorization;
  • each ticket is short-lived, which limits the exposure from a compromised quoting key to minutes, and per-key spend caps limit even that.

Takers can make partial fills, taking only part of a standing order, with the escrow tracking the remainder down to the zat (the smallest unit of ZEC). An optional MEV buffer, funded by the taker, pays watchers to complete fills, so that a fill never stalls waiting for attention. How tickets are authenticated is discussed further in Ticket Authentication.

Choosing a mode

BespokeStanding
Who pricesRequester, through blob termsProvider, through signed tickets
Who may fillAny partyThe taker named on each ticket
Where the margin isTolerance cap plus oracle-watching fillersQuoted spread under signature
Best forUnusual sizes, one-off dealsRepeated, quotable flow

Bespoke mode suits requesters who would rather state terms than shop for quotes, and trades that don’t fit a standard size. Standing mode suits repeated flow and automated liquidity: providers control their pricing without sending a transaction for every quote.

See also