Multi-asset rotation

Leave it
open.

One bounded rotation, resting on chain. Filled from the books, or by one signed maker package, within the same limits you approved. Or still waiting, with the reason.

Specified design. No v3 registry, settlement, Bounds, keeper or client is deployed.

SheafOrder —admitting
≤
spend WMON
at most X
≥
receive USDC
at least Y
≥
receive AUSD
at least Z
minOut not met
bookschecking
packageno quote
funds stay in your wallet · not reservedblock —
FILLEDfillSource=quote · limits unchanged
simulated · placeholder amounts · not a live order

What you sign

Outcomes

At least this much of each asset out. At most this much in. Per asset — one blended price cannot say it.

Either path

The signed legs are the book sequence. A maker package must meet the same per-asset bounds without executing them.

Not reserved

A resting order holds nothing. Funds stay in your wallet, and several orders may advertise the same balance.

Admit · rest · revalidate · settle

It waits on chain.
It moves once.

1pre-flight, advisory
2admit
3rest
4revalidate
5re-check · pull · fill · assert
6receipt
no funds movemoves value in full · a refusal is a receipt, nothing moves · an execution failure reverts whole

Two ways to finish it

Books, or one signed package.

The two paths are checked independently. Thin books never close the package path, and a package never relaxes what you signed.

Book pathevery leg, in the signed order
Package pathone complete signed package, or none
Your per-asset limitsthe same on both
Partial or mixed fillsnot supported
Best pricenot promised
Where it restsSheaf's registry, not Kuru's book
Makerteam-operated · disclosed
Who can settleanyone, inside your consent
WAITING_FOR_LIMITSwhich path, which leg, and the observation behind it
INSUFFICIENT_DEPTH · PRICE_DRIFTreasons it is still waiting, not states
BOOK_HOLDbook observations disagree: the book path waits, the package path does not
NEEDS_FUNDINGwhich asset — and whose
MONITOR_UNAVAILABLElast successful check. the order is still live
PENDINGadmit, cancel, revise or fill: a submission reference, unresolved until chain evidence — never inferred from elapsed time
EXPIREDderived from block height; a cleanup receipt only if one exists
CANCELLEDrequested → pending → effective

Waiting is a state

Never a
bare no.

Thin depth and price drift are reasons an order is still open, not the end of it. Every wait carries the one thing that would change it, and its last successful check. Cancelling is a chain state, not a button press: it costs gas, and a fill ordered first wins.

marketsMON_USDC · MON_AUSD · AUSD_USDC
legsat most three, in the signed order
per assetminOut · maxIn, signed
recipientyou · fixed on chain
budgetgross input per asset · base units · per policy period
acceptQuotesbooks_only · auto_accept_complete_package
admit · revise · cancelyou only
expirya block number · exclusive

Sheaf Bounds

Bound once.
Checked at the money.

Both paths re-read your authorization, revision and remaining budget in the same breath as the transfer. A maker's valuation never decides what your budget spent.

authorityRef and conditionHash are reserved zero: delegated authority is deferred and the optional trigger predicate is cut from this scope

No session, no wallet

Close the tab.
Read it later.

An order that settles hours later has to reach you somehow. It is a link: chain id, settlement address, order id. A fresh browser reads the limits you signed, the current revision, each path's own status and the receipt — straight from chain. Reconnect to cancel or revise; anyone else can read it, or quote it as a maker.

/o/<chain id>/<settlement address>/<orderId>
no stored session · no notifications · unknown id, wrong deployment and an unreachable node each say so · the bounds on the link are public · route shape illustrative
One order.
Two ways to finish it.
View an examplenot available — no completed order exists yet
Try on testnetnot available — nothing is deployed

Status: in build. No v3 order registry, settlement contract, Bounds implementation, maker quote path, keeper or web client exists. Everything above describes the specified design, not shipped software; the ticket is a simulated reference with placeholder amounts, not a live order.

Not claimed: novelty, demand, adoption, users, a timing or block-speed advantage, prize eligibility or competitor absence. No loss-prevention or fill-rate figure is published here. Prior art overlaps directly: Bebop's JamOrder supports multi-token limit orders with indefinite expiry, per-asset amounts and maker or solver settlement; ComposableCoW covers conditional order generation, validation and watch-towers; EIP-5792 wallet batches are atomic when requested and supported.

Monad testnet only, controlled liquidity, and a team-operated maker and keeper under one disclosed operator. Native MON is not an outcome token: the intended route authorizes WMON at the wallet boundary and unwraps and rewraps inside the venue adapter — that route is not implemented or proven. Funds are wallet-direct across a transaction, not within one: output transits the Sheaf contract. The registered Gate 1 depth protocol has produced no verdict, and a qualifying negative result ends this project.