The single pool

Every coin has exactly one market, and the entire float is in it.

Why one

A coin split across several venues has no price. Trackers pick one of them, usually the wrong one, and show a number nobody could actually trade at. Holders read a market cap that does not survive contact with a sell.

TerminalPad removes the option. There is one pool, on Rhea Finance's DCL — the concentrated-liquidity AMM of NEAR (dclv2.ref-labs.near). A price you read is the price the whole float sits behind, because there is nowhere else for it to be. It also removes a class of failure fragmented launches never escape: liquidity that has to be managed between venues, rebalanced, topped up, and that fails exactly when volume arrives. There is nothing to manage here.

One position, and what that means

The position holds the coin, spread from the opening price toward ever cheaper prices — in practice, all the way down — plus the USDC the creator's seed paid, sitting just above the price. No other dollars are deposited at launch, which is why launching needs no capital beyond the $1 seed — and that seed is a purchase, not a deposit.

As buyers arrive they walk the price up, and the USDC they pay in accumulates in the position. The position is the coin's order book and its treasury at the same time: what buyers put in is what sellers can take out, and there is no third place for it to go.

The 1% tier, and why not more

Rhea DCL's fee tiers are fixed in its contract: 0.01%, 0.04%, 0.2% and 1% (fee values 100, 400, 2000 and 10000; anything else is refused). 1% is the maximum and the one every coin uses (POOL_FEE = 10000, point delta 200), the same economics as the 1% tier the Avalanche version used. Of that 1%, Rhea keeps 20% as its protocol fee (protocol_fee_rate 2000, read on 2026-09-25) and the position earns the rest.

The one way to charge more would be a transfer tax on the token, which makes swaps through the standard route fail and gets the coin flagged by every scanner — it would cost the one property we care most about, that any bot can trade the coin. We did not take it.

The opening price

Rhea DCL states prices in points: the price at point p is 1.0001^p raw token_y per raw token_x, in smallest units. The coin is always token_y and USDC always token_x, so a point is "raw coins per raw USDC", and the gap between an 18-decimal coin and 6-decimal USDC is part of the price, not a rounding detail — a factor of a trillion:

point(P) = log_1.0001( 10^18 / (P · 10^6) )

with P the coin's price in dollars. A $0.00001 coin sits at point ≈ 391,573. The launch rounds that to the tier's 200-point grid toward a cheaper coin, and that is the top of the position's range. The range runs from there down 799,800 points — DCL refuses a position 800,000 points wide or more — which is a factor of about e^80 in price: "the last tick", in practice.

The creator's seed is then priced into the pool's opening state: the launch computes where a buy of that size would leave the price, creates the pool at that point, and puts the seed's USDC above the price and the rest of the coin below it, in the one position. No swap happens before the position exists, so nobody can trade ahead of the creator.

Two more things are done before any coin is added:

• The pool is created before the coin exists. The coin's account id is drawn from the block's randomness at launch, so nobody can know it earlier, and its pools are created in the launchpad's first step. Nobody can create a coin's pool first.
• The price is checked before the add. An empty DCL pool's price can be moved by anyone, for free. So the launchpad reads the pool first, moves it back to the computed point if needed (with a dust amount it gets back), and adds with minimums just under its amounts: if someone moves the price again in between, the add fails and is resumed, rather than opening the coin at someone else's price.

Why the coin is always token_y. Rhea DCL orders a pool's two tokens by account id. USDC's id on NEAR is a hex string beginning 17208628…, which sorts before every named account; coin ids always start with a letter; tracker ids always start with a digit (5xnvda.…). So USDC < tracker < coin, always: the coin is the second token in its USDC pool and in its tracker pool alike, and every chart prices it the same way up before and after the bond. On Avalanche this took mining addresses; on NEAR the names do it.

Depth where it is used

A tracker's own USDC reference pool (Rhea's 0.04% tier, the nearest to the 0.05% the Avalanche version used) does not spread its capital across all possible prices. Most of it — 70% — sits in a core band of ±200 points, about ±2%, around the tracker's NAV, with the rest in a floor position as wide as DCL allows (just under 800,000 points) underneath and above, so no single trade can push the price off the book. Both are centred on NAV, not on the pool's last price: centring on a drifted price would bless the drift. Anyone can trigger a re-centre once NAV has moved about 1.25% (125 points) from the last centre.

The gain is not marginal. For a band bounded by Pa and Pb, capital efficiency against a full-range position is:

E = 1 / ( 1 − (Pa/Pb)^(1/4) )

A ±2% band is worth roughly fifty times the same money spread across the whole curve; a ±10% band, about eleven times. That is what makes serious depth affordable exactly where trades actually happen — and why a bonded coin's USDC side is deeper than its own pool was.

Why keep a wide part at all: in tests run for an earlier deployment (not on NEAR), a tight band alone absorbed a few buys cleanly and then emptied, and the tracker's pool price ran away. The floor is what sits under that cliff.

The reference pools are the protocol's own liquidity: the protocol seeds them, and their owner can withdraw what they hold. They carry no user deposits.