Limit Orders

MonTerminal's core capability is a wallet-backed onchain trigger executed through a deployed LimitOrderBook.

Supported order intentions

Buy the dip

Spend the quote token only when the pool can return at least the configured amount of the target token. The order becomes fillable when the output requirement is satisfiable.

Take profit

Sell the held token only when the swap can return at least the target quote amount. The minimum output acts as the onchain trigger.

Stop loss

Sell after the pool's time-weighted price crosses the stop threshold. The contract also computes an execution-time output floor with the configured maximum slippage.

Ladders

Multiple validated orders can be submitted atomically through placeOrders, allowing partial exits at different price levels.

Lifecycle

Wallet balance + allowance
          │
          ├── approve exact amount
          │
          ├── placeOrders ──▶ Open
          │                     │
          │                     ├── cancelOrder(s) ──▶ Cancelled
          │                     │
          │                     └── executeOrder ────▶ Executed
          │                                           │
          └───────────────────────────────────────────┘
                                      proceeds go to maker

No escrow at placement

The book records the order but does not custody the input tokens. Execution uses transferFrom against the maker's then-current balance and allowance.

An open order can therefore fail if:

• the maker spends or transfers the input token;
• the maker revokes or reduces allowance;
• the order expires;
• the trigger is not met;
• the pool becomes unavailable or too illiquid;
• the swap cannot satisfy the dynamic slippage floor.

Exact approvals

The production UI requests the exact total amount required by the current order transaction. It does not silently request maxUint256 approval.

Cancelling an order changes its onchain status. It does not automatically revoke a remaining token allowance; users can review or revoke allowances separately.

Execution and keeper fee

Execution is permissionless. The repository's keeper, another searcher, or the maker can call executeOrder. The successful executor receives the maker-configured keeper fee; the swap output goes to the maker.

The public repository contains the keeper implementation. A continuously hosted 24/7 keeper is not currently claimed because no public heartbeat has been deployed.

Real lifecycle proof

The Capricorn deployment's counter now returns nextOrderId() = 5, proving four successful placements.

Buy-side lifecycle

OrderPlaced #1Deliberately unfillable WMON → CHOG orderOrderCancelled #1Real cancellation transactionOrderPlaced #2Executable 0.002 WMON → CHOG orderOrderExecuted #2Received approximately 0.039329 CHOG

Sell-side lifecycle

OrderPlaced #3Deliberately unfillable CHOG → WMON orderOrderCancelled #3Real sell-side cancellationOrderPlaced #4Executable CHOG → WMON orderOrderExecuted #4Output unwrapped and paid as native MON