> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rondo.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Use Rondo

> Choose the right side of the live book, size a fill, and understand every state that can disable settlement.

This guide follows the current Orders interface. It separates the words used by the book from the
token you are personally selling, because that is the most common source of a reversed trade.

## Before you trade

<Steps>
  <Step title="Use a wallet on Kaia">
    Connect Kaia Wallet or MetaMask to **Kaia mainnet (chain id 8217)**. Keep a small amount of
    KAIA for gas.
  </Step>

  <Step title="Hold the token you will pay">
    First choose **JPYC / USDT**, **IDRX / USDT**, or **IDRP / USDT** in the app rail. Selling the
    regional base token requires that exact Kaia token; selling USDT requires Kaia USDT. The in-app
    **Guide** works out a funding route, while **Get tokens** and **Bridge** provide the relevant
    acquisition and Ethereum-to-Kaia routes.
  </Step>

  <Step title="Open Orders">
    Orders is the default application page. A first-time prompt can take you through the interactive
    guide before you trade with real funds.
  </Step>
</Steps>

## 1. Open the side you want to receive

The book labels describe what the **maker offers**, not what you are selling:

| You want to…                 | Open this filter       | You pay             | You receive             |
| ---------------------------- | ---------------------- | ------------------- | ----------------------- |
| Sell the selected base token | **USDT offered**       | JPYC, IDRX, or IDRP | USDT                    |
| Sell USDT                    | **Base token offered** | USDT                | The selected base token |

By default, Live orders hides rows whose taker edge is zero or negative. Enable **Show
non-profitable** only when you deliberately want to see the whole book.

<Info>
  **Your edge** is your net result against the Orakl reference after the protocol fee. Positive is
  favourable to you as the taker; negative is worse than the oracle-equivalent trade. [See the exact
  formula](/protocol/edge).
</Info>

## 2. Build the settlement ticket

<Steps>
  <Step title="Select Take on an order">
    Compare the offered amount, wanted amount, price, edge and expiry. A **PEG** tag means the row
    reprices from Orakl's five-minute reference on every fill; without it, the posted ratio is fixed.
  </Step>

  <Step title="Enter You pay">
    The current interface takes the amount leaving your wallet. It derives how much gross escrow
    can be released, confirms the quote against `previewFill`, and shows the exact **You receive**
    amount after the protocol fee.

    The contract itself still takes `sellAmountOut` — gross output from escrow — as its fill-size
    argument. That implementation detail is important for integrations, but it is not what a user
    types into the Rondo ticket.
  </Step>

  <Step title="Resolve a minimum-size warning">
    When an order still has at least the configured minimum remaining, a partial fill must release
    at least that minimum of the **offered token**. The ticket shows the corresponding minimum
    payment and keeps Fill order disabled until the size is valid.

    Use **Take the minimum** or **Take it all**; both insert an exact, contract-valid amount.
  </Step>

  <Step title="Choose slippage for PEG orders">
    A PEG quote may move before the transaction is included. The 0.1% / 0.5% / 1% setting defines
    `maxAmountIn`, the most the contract may pull. Fixed orders use the exact quoted payment because
    their rate cannot move.
  </Step>

  <Step title="Approve, then fill">
    The first trade for a payment token may require an ERC-20 approval. For PEG orders the app
    approves the payment ceiling, not only the current quote, so an ordinary oracle tick does not
    leave the allowance a few units short. Review the wallet request, then sign Fill order.
  </Step>
</Steps>

### How the minimum-fill rule actually works

The rule applies to **the amount released in this fill**, not to the remainder it leaves behind:

* Taking the full remainder is always allowed.
* While `sellRemaining ≥ minOrderAmount`, a partial fill must have `sellAmountOut ≥ minOrderAmount`.
* Once an order's remainder is already below the current minimum, smaller partial fills are allowed;
  raising the configured minimum cannot freeze an existing small remainder into all-or-nothing.

This is why the UI presents a minimum payment rather than asking you to calculate gross output or
the protocol fee yourself. [Read the contract guard order](/protocol/filling#partial-fills-and-the-minimum).

## 3. Post an order

Making is permissioned. If your wallet does not hold `MAKER_ROLE`, the **Make an order** navigation
item and Orders action tell you to contact the team instead of opening a transaction that would
revert.

Once registered, choose which pricing model matches your intent:

<CardGroup cols={2}>
  <Card title="Fixed price" icon="lock">
    Enter what you offer and what you want. Use −0.3%, Oracle, +0.3%, or a custom offset within the
    current band. The ratio never moves after posting.
  </Card>

  <Card title="Oracle-pegged" icon="wave-square">
    Enter what you offer, the taker's premium, and a 1% / 2% / 5% price-floor tolerance. Every fill
    reprices, and the order pauses if the settled rate falls through the floor.
  </Card>
</CardGroup>

<Warning>
  The PEG premium is the taker's result **after** the protocol fee. The maker therefore funds both
  the premium and the fee. At a 30 bps fee, a 25 bps taker premium costs the maker about 55 bps.
  [Follow the full example](/protocol/pricing#premium-and-fee-—-who-actually-pays).
</Warning>

After posting, **Your open orders** for that market shows escrow, remaining quantity, received-to-date, expected
future proceeds, and the average realised rate for partially filled PEG orders. Cancelling returns
the unused escrow to the maker.

## What each app page is for

| Page                        | Purpose                                                                                        |
| --------------------------- | ---------------------------------------------------------------------------------------------- |
| **Orders**                  | Live book, profitability filters, and settlement ticket                                        |
| **Guide**                   | Funding route plus an interactive walkthrough of the real Orders layout                        |
| **Make an order**           | Maker-only order creation and open-order management                                            |
| **Get tokens** · **Bridge** | Acquire assets or move USDT between Ethereum and Kaia                                          |
| **Earn yield**              | Review the JPYC-market idle-USDT route; IDRX and IDRP currently have no configured yield route |
| **History**                 | Past fills reconstructed from contract logs                                                    |

## Order alerts

The Telegram bot posts newly discovered orders whose taker edge clears its configured threshold.
It is a notification channel, not a quote source: reopen Rondo and review the live ticket before
signing.

<Card title="Rondo Order Alert" icon="telegram" href="https://t.me/RondoOrderAlert" cta="Open Telegram" arrow>
  Receive notifications when an order beats the oracle after fees.
</Card>