Marketplace

Not everyone who earns a voucher wants to run a job. The marketplace lets holders sell capacity to people who do.

It is a central-limit-order-book design: orders are signed off-chain, rest off-chain, and settle on-chain when filled.

Signed limit orders

A maker signs an EIP-712 order and posts it to the book. Signing costs nothing and touches no contract.

Order {
  maker        address    // signer
  side         uint8      // 0 = sell vouchers, 1 = buy vouchers
  voucherId    uint256    // packed (version, skuId, expiryBucket)
  quantity     uint256    // total units offered
  price        uint256    // price per unit, in the quote asset
  quoteToken   address    // settlement currency
  expiry       uint64     // order expiry, distinct from voucher expiry
  nonce        uint256
}

Two expiries appear here and they are unrelated. Order.expiry is how long the quote stands. The voucher's expiry is baked into voucherId. A one-hour quote on a voucher with three months of life is perfectly ordinary.

A taker submits the order plus a signature to fillOrder. The contract recovers the signer, checks the order is live, and moves both legs atomically: vouchers from maker to taker, quote asset from taker to maker, protocol fee to the treasury. Either both legs move or the transaction reverts.

Because orders live off-chain, quoting is free and cancelling is cheap. A maker cancels by invalidating the nonce on-chain, or simply by letting Order.expiry lapse, which costs nothing at all. Market makers can requote continuously without paying gas per quote.

Partial fills

Vouchers trade in lots that rarely match. A staker may hold 4,000 H100-hours; a buyer may want 40.

The contract tracks cumulative fills per order hash:

filled[orderHash] += takeQuantity
require(filled[orderHash] <= order.quantity)

One signed order can therefore be hit many times by many takers until it is exhausted, expires, or is cancelled. The maker signs once. Fills are first-come and settled in block order; a taker who arrives after the order is exhausted reverts rather than partially filling at a stale price.

Why an order book and not an AMM

The obvious alternative is a constant-function pool per voucher class. It is the wrong shape here, for two reasons.

Vouchers decay toward expiry

A voucher's fair value falls as its expiry bucket approaches, and hits zero when it passes. That is not volatility, it is a deterministic, one-directional drift with a known terminal value.

An AMM liquidity provider holds inventory. Holding voucher inventory across time means holding an asset whose value is guaranteed to decline toward zero. In options language the LP is short theta: they are exposed to time decay, and nothing in an AMM pays them for it. An options seller is short theta too, but collects a premium up front as compensation. An AMM LP collects only swap fees, which depend on volume, not on the passage of time.

So the LP's position is: certain decay, uncertain compensation. Rational LPs will not supply, or will supply only at spreads wide enough that the pool offers nothing over a book.

An order book has no resting inventory requirement. A maker quotes a price for right now and can move it every second as expiry approaches. The decay is priced continuously by whoever is willing to price it, rather than absorbed silently by a passive pool.

Liquidity would fragment anyway

Every (SKU, expiry bucket) pair is its own asset. Three SKUs across a year of weekly buckets is over a hundred distinct markets. An AMM needs a funded pool for each, and depth divided a hundred ways is depth in nothing. A book concentrates liquidity in the classes that people actually trade and costs nothing to leave open in the ones they do not, an empty book is an empty file, while an empty pool is capital nobody can use.

Add that most classes will be thin and episodic, and continuous passive pricing is simply the wrong tool. Books handle thin markets by having no bid until someone posts one. That is honest.

Fees

The taker pays a fee in basis points of notional, routed to the protocol treasury. This is one of the protocol's two revenue lines; see Token.

The rate is TBD. Whether makers are charged at all is also undetermined; the intent is a taker-side fee so that quoting stays free.

Settlement asset

Which quote assets are accepted is a governed parameter and is TBD. The contract is written against an arbitrary ERC20 quote token so the set can be extended without redeploying.

What the marketplace does not do

• It does not custody vouchers. Vouchers stay in the maker's wallet until a fill executes.
• It does not guarantee a bid. If nobody wants a voucher class, it does not trade, and it will expire in your wallet with no refund. See Vouchers.
• It does not price anything. There is no oracle and no reference price. What a voucher is worth is whatever the book says at that moment.

The marketplace is not deployed. Everything above describes intended behaviour.