Size should not be a penalty.

Automated market makers solved the cold-start problem for long-tail tokens and, in doing so, made one number the price of everything: reserve depth. A constant-product pool quotes a marginal price, not a clearing price. Trade small and the difference is noise. Trade size and the difference becomes the dominant cost of the transaction, larger than fees, larger than spread, often larger than a week of the position's carry.

OTCDEX is an on-chain over-the-counter venue for Solana tokens. A holder posts an ask: a mint, a size, a price, an expiry. The tokens move into a program-owned vault. A buyer fills any slice of that order and, in a single transaction, quote goes to the seller, tokens go to the buyer, and the venue fee goes to the treasury. No pool is touched, so nothing is dragged along a curve and no reserve is depleted.

The idea did not come from a design document. It came from a tape. During the $CATE flash crash, a single holder sold a block worth roughly 1.4% of supply into a pool holding roughly 4% of the market cap. The seller had no intention of moving the market: they had one position and one exit. The pool priced every token they sold further down the curve, and the print landed about 45% below where the resting interest actually was.

What happened next is the part that matters. The candle became the news. Holders who had never seen the seller's wallet read the chart as insider distribution and sold into the same thin book. The mechanical cost of routing size through a pool manufactured the fear that then justified itself. Within hours, the token traded back most of the way up, which is the clearest possible evidence that the crash was liquidity structure and not information.

A constant-product pool holds reserves R of the token and Q of the quote asset, and preserves R × Q. Selling X tokens returns quote equal to Q × X / (R + X). Divide by the spot price Q / R and the average fill you actually receive is:

fill / spot  =  R / (R + X)
loss         =  X / (R + X)        (fraction of value given up)
value lost   =  spot * X^2 / (R + X)

The second line is the whole argument. Loss is a function of your size relative to the pool, and it grows without bound. Sell an amount equal to a quarter of the token reserve and you hand over 20% of the value before fees. Sell half the reserve and you hand over a third. There is no routing trick that removes this term, because it is not a fee: it is the definition of the curve.

Take a liquid, well-known memecoin rather than a thin one, so the comparison is generous to the pool. A holder wants to sell $250,000 of Fartcoin. Aggregated routes show a few million dollars of usable two-sided depth near spot, which sounds like plenty until the order is priced along the curve.

The pool route is not merely more expensive. It is uncertain: the seller learns the true cost after the transaction lands. On OTCDEX the seller sets the number, the buyer accepts the number, and the only variable left is whether someone takes the other side.

Set a size and a pool depth. The calculator applies the same constant-product arithmetic as above, then shows the same trade settled at an agreed price with the venue fee applied.

An order is a small account owned by the program: mint, quote mint, remaining size, price, expiry, maker, and an optional price authority. Funding it moves the maker's side into a vault the program controls. From that moment the maker cannot spend those tokens elsewhere, and neither can anyone else.

Both directions exist. An ask escrows tokens and waits for quote. A bid escrows quote and waits for tokens, which lets a buyer advertise real, funded demand rather than an intention. When an ask and a bid cross, the fill settles at the resting order's price, so whoever posted first is never worse off than they asked for. When the crossing price is better than the taker asked for, the improvement is surfaced explicitly in fill history: you asked 1.00, you got 1.11.

A market-tracked order stores no price. It stores its maker's offset, such as 2% under market, and reads the AMM pool inside the transaction that settles the fill. Nothing is written when the market moves, no stored number can go stale, and no keeper maintains it. The order executes at the pool's marginal price without walking up its curve, so its advantage over the same pool grows with trade size.

Both sides resolve through the same formula and neither references the other. A tracked ask and a tracked bid on one token, both at zero offset, quote the identical pool price, so the book shows no spread at all. What remains between the two is the protocol fee: 0.15% on each side of a fill.

Every tracked order requires a bound, capped at 25% from the maker's reference price: a floor the seller will not sell below, a ceiling the buyer will not pay above. That bound is the maker's protection because the venue reads the pool exactly as it finds it, and a pool can move inside one block. A pool is accepted only when its owning program, account length, and discriminator exactly match. An upstream layout change therefore pauses tracked fills instead of risking a wrong price.

Fixed-price orders may still delegate updates to a price authority within a signed band. Market-tracked orders do not use that mechanism on either side.

Blocks rarely rest as one order. The swap screen takes a budget, walks the resting asks from cheapest upward, and returns the exact token amount, blended price, and number of transactions before anything is signed. Because every leg is a discrete fill at a posted price, the blended number is arithmetic rather than a prediction.

If a sweep needs more instructions than fit in one transaction, it is batched and the progress of each batch is reported. A batch that fails leaves the orders it did not touch exactly as they were.

The venue charges 0.30% per fill at the current rate, 0.15% per side. The fee is a config value the admin can change, it is visible in the preview before signing, and it is the only cost the venue imposes: there is no spread, no maker rebate, no priority tier.

Removing price impact does not remove counterparty risk in the asset itself. Every listing is checked against mint-level facts and the result is shown on the order, not buried:

$OTC is the venue token: six decimals, fixed maximum supply, with mint and freeze authorities revoked at launch. Revenue allocation is the mechanism described in section 10. There is no fee discount, no staking lock, and no governance theatre attached to it.

Live supply, burn history and treasury flow are published on the token page rather than in this document, because they change daily and a paper should not pretend otherwise.

Equities never asked institutions to route blocks through the visible book. Upstairs desks, crossing networks and negotiated prints exist because moving size through a continuous market is a tax on the mover and noise for everyone else. Crypto skipped that layer and went straight to a single pooled venue for every trade at every size.

We think the missing layer is not a private club. It is a public program: anyone can post, anyone can fill, prices are visible, custody belongs to the maker until the instant of settlement, and the arithmetic is printed on the screen. Small trades belong in a pool. Blocks belong here.

Trade size. Skip the price impact.

OTCDEX is live on mainnet and labelled beta. The program is open source and covered by a reproducible build; audits and coverage are tracked publicly on the roadmap. Per-order value limits and expiry bounds are enforced both in the interface and in the program while the venue matures.

Nothing here is investment advice. Smart contracts can contain defects, memecoins can go to zero for reasons that have nothing to do with execution quality, and an escrowed order that nobody fills simply expires and returns to you. Size your trades accordingly.