How Hearth works

​

What Hearth is not

• Not a centralized order book hosted by a company
• Not the same as swapXFG (cross-chain atomic swaps)
• Not DIGM

​

Orderbook model (v12+)

1. Orders are transactions. A limit order is created by a TransactionExtraLimitDeposit (SELL_XFG deposits XFG, BUY_XFG deposits HEAT into the pending buckets). Nothing exists in a gossip mempool — every resting order is backed by committed funds.
2. Execution at block time, against the pool, at the live spot price. Each block the protocol fills resting orders whose limit is crossed by the current pool spot price (ammGetSpotPrice = HEAT/XFG × COIN):
   • SELL_XFG fills if target ≤ spot; the pool buys the XFG and credits HEAT proceeds.
   • BUY_XFG fills if target ≥ spot; the pool sells XFG and debits the HEAT budget.
3. Partial fills and proceeds. Fills consume part of the deposit; the proceeds (proceedsXfg / proceedsHeat) are claimable later with the remaining deposit via a TransactionExtraLimitWithdraw (also the auto-return path for expired orders).
4. Expiry is height-based (expiration blocks). Expired orders keep their deposit + proceeds claimable.
5. Taker pays the 1% fee by receiving the fee-adjusted output; the fee value leaves LP reserves into the HEAT-denominated CD accumulator.
6. No unbacked orders, no gossip, no user-vs-user matching. The pool is the sole counterparty — this removes the wash-trade / unbacked-order manipulation classes entirely.

​

Fee (live code)

gross = user_notional
paid  = gross × (10000 − 100) / 10000      // taker receives fee-adjusted output
fee   = gross − paid                        // 70% → CD accumulator, 30% → maker rebate

​

Roles

​

Privacy

​

Related

• Provide liquidity
• Fee earning
• Mint HEAT
• swapXFG