Sources
Written up in November 2026 from the lab’s 2024 technical material on the pool framework that HOT and the liquid staking marketplace run on. Section 2 of the HOT whitepaper summarises the framework under the name Sovereign Pools.
An exchange contract answers a fixed list of questions. What price does a trade get? What fee does it pay? Who may trade, deposit or withdraw? Where do the reserves sit between trades? What does the pool record for others to read? A typical automated market maker answers all of them in one contract. Changing one answer means forking the contract and auditing all of it again.
In 2024 we built a pool framework that gives each question to a separate module. This note describes the split, the order in which the modules are called, and the two markets built on it since.
What is fixed and what is replaceable
| Module | Decides | If absent |
|---|---|---|
| Liquidity module | The price and amount for each swap, and how deposits are represented | Required |
| Swap fee module | The fee for each swap | A constant fee set at deployment |
| Verifier module | Who may swap, deposit or withdraw | Anyone may |
| Oracle module | What the pool records after each swap, such as a time-weighted price | Nothing is recorded |
| Vault | Where reserves are held, and whether other pools share them | The pool holds its own |
A pool can also have a manager, which assembles the modules, and a gauge for incentive programmes. The core keeps what should be the same in every design: token transfers, reserve accounting, a lock against re-entry, and the sequence of a swap.
The sequence of a swap
- The pool locks itself and checks the request.
- The verifier module, if set, approves or rejects the caller. It may hand data on to the pricing step.
- The swap fee module, if set, returns a fee rate.
- The liquidity module returns a quote: how much it will take in and pay out.
- The pool checks the quote against its reserves and the trader’s limits.
- Tokens come in, the pool’s accounts are updated, and the oracle module records the trade.
- Tokens go out, the fee and liquidity modules receive a closing callback if they asked for one, and the pool unlocks.
Decisions the split forces
The fee is set before the fill is known. The fee module is asked at step three, and the liquidity module decides at step four how much of the order it will fill. The fee is therefore a rate. The pool first sets aside the largest fee the order could owe, then charges the rate on the amount filled, rounded up in the pool’s favour. The rate is capped so that the fee can never exceed half of what the trader pays in.
The verifier can talk to the pricing module. Whatever data the verifier returns is passed to the liquidity module, which lets one pool give different execution to different callers while the pricing code does no authentication of its own.
Rebasing tokens need a different kind of accounting. Tokens such as stETH change every holder’s balance without a transfer. A pool marked as holding one treats its live token balance as its reserve and tolerates rounding errors of a few of the token’s smallest units on transfers. The cost is that anyone can change the reserves by sending tokens to the pool, so a pricing module for a rebasing token has to stay correct under arbitrary changes in balance.
The manager’s powers are part of the design. The liquidity module can be set once. The fee module can be replaced, at most once every three days. The manager role can be given up, which makes the pool immutable.
Two markets on one core
HOT implements the liquidity module and the swap fee module in one contract, because its fee depends on the time of its last price update. A verifier module restricts signed quotes to authorised solvers, and an oracle check bounds the prices a quote may carry.
The liquid staking marketplace has a liquidity module that reads the redemption rate from the staking protocol and prices at it. Its fee module is a schedule of steps keyed to reserves. Two smaller modules attach to it. One files and claims withdrawals through the staking protocol’s queue. The other lends idle reserves.
The two share custody, accounting and the swap sequence. Everything that distinguishes them lives in modules.
What modularity costs
The interfaces become the place where things go wrong. Each module can be audited alone, but each combination has to be tested together, because a fee module that is safe with one pricing module may be unsafe with another. Calls between contracts cost gas that a single contract would not spend. And a pool is only as fixed as its replaceable parts: where a module can be changed, users are trusting whoever can change it as well as the code. The marketplace keeps its core immutable and puts the modules that can change behind a timelock of three to seven days.