maker_pool
The maker_pool is the custody layer. Each maker has their own pool contract — deployed on demand by maker_pool_factory at registration — that holds only that maker's inventory and moves tokens during their swaps. It has no pricing logic; it simply executes what quote_verifier tells it to.
Why one pool per maker
Isolating inventory per maker means one maker's balance can never be spent settling another maker's quote. The factory deploys each pool with a deterministic salt (sha256(maker.to_xdr())) so the same address is computed in both simulation and execution.
Why makers pre-fund their pool
Atomic settlement requires the pool to already hold the output tokens at the moment of execution. There is no credit, no flash loan, no JIT — the pool is a real pre-funded balance sheet. This design means every accepted quote is guaranteed settleable.
Access control
execute_swap is the most sensitive function — it moves real tokens. It requires require_auth() from the registered quote_verifier address. No other contract or user can call it directly.
Functions
| Function | Caller | Description |
|---|---|---|
| deposit(token, amount) | Maker | Transfers amount from maker wallet into the pool (2-TX: approve + deposit) |
| withdraw(token, amount) | Maker | Transfers amount from the pool back to the maker wallet |
| execute_swap(quote) | quote_verifier only | Moves amount_in from taker→pool, amount_out from pool→taker. Atomic — reverts if either transfer fails. |
| get_balances() | Anyone | Returns the pool USDC + EURC balances in stroops |
Factory address: CBDD5WBPCX6GSF4XIP6CAKAM3TCU6R73CW7QNYUTXXT3OAGEPFFACOI4 — individual pool addresses are per-maker and shown on the /maker dashboard.
Persistent TTL: every deposit/withdraw bumps all storage entries so the pool doesn't expire (Soroban persistent-storage TTL).