The target and fixed walls
The formula chooses the wall’s location; fees determine its size. A wall is an LP position funded with available ETH at defined ticks.
Chosen specification, implementation in progress. The new rule uses the market at time T. Older documents about a single monotonic wall, the E/C placement formula or an all-time high no longer define the requested policy.
The formula at time T
Let M(T) be the reference capitalization at placement time and B the launch base, expressed in the same unit:
The coefficient retraces 60% of the gap between the current market and the base. It therefore retains 40% of that gap above the base. With B = 7 000:
| Market at placement | Calculation | Target for new funds |
|---|---|---|
| 30 000 | 30 000 − 23 000 × 0.6 | 16 200 |
| 100 000 | 100 000 − 93 000 × 0.6 | 44 200 |
| Return to 60 000 | 60 000 − 53 000 × 0.6 | 28 200 |
The third calculation starts from 60 000, even if the market previously reached 100 000. There is no global ratchet based on the all-time high. Time T is when raiseFloor() executes and funds are placed, not the time of each sale that funded the reserve.
Change the market level
The example below keeps two older levels at 16.2k and 44.2k, then calculates the target for new funds. All values use the same capitalization unit. This level diagram simulates neither absorption, balances nor a transaction.
Only new funds follow the current target. Older levels remain fixed; the ETH still available at each level must be read separately.
Each older wall keeps its ticks
Once funding is placed, its ETH remains allocated to the corresponding position. A rising or falling market does not move those older funds to the new target.
- New funding can create a position at the current target, or deepen a compatible position at the same level according to the chosen geometry.
- A sale can consume part of a wall’s ETH.
- Absorbed CUBIT is isolated for burning; the wall’s remainder stays attached to its ticks.
- ETH not redeployed because of rounding remains allocated to that wall. It cannot be freely reused at another level.
Historical identifiers remain permanent. The implementation in preparation indexes ticks to traverse walls touched by a sale. This processing and the preservation of each position still require validation in the new version.
ETH actually placed
The contract places available money in the LP position corresponding to the target. Sales can consume this ETH: each wall’s reserve is finite. A wall can be funded without waiting for coverage of the entire supply.
From capitalization to ticks
The normative reference interprets 7k as USD 7 000 FDV, on a constant basis of 21 million tokens. The USD/ETH conversion must be recorded once before deployment. The initial ETH price is then fixed; it does not automatically readjust to the dollar.
The contract works with ETH prices per CUBIT: target = 0.4 × current price + 0.6 × initial price. The capitalization examples use the same 21 million basis and an identical ETH/USD conversion. A burn does not silently change this convention. Calibration in ETH still requires validation before launch.
Ticks then round the executable level. ETH is currency0, so a higher CUBIT price corresponds to a lower pool tick. The mathematical target, the tick actually placed and a sale’s net price can differ.
For a market below the base, the formula can produce a target above the market. Placement must then satisfy its on-chain conditions; this guide does not assume an ETH wall can be placed arbitrarily above spot.
What the interface must show
The new interface must distinguish the current market, the next target, each active wall and its depth, pending reserves and isolated tokens. A single “floor” line no longer summarizes the whole book.
The historical floorPrice reference is intended to describe the last funded wall, which may be lower than the previous one. It must not be interpreted as a guaranteed global minimum. Reading dapp data.
Primary source: user clarifications of September 10, 2026. WallLib integration, per-position views and their validation are still in progress. Older comments about peakTick do not define this rule.