Constant RANKED_AVG_SCALE 

pub const RANKED_AVG_SCALE: i128 = 10_000_000_000_000_000_000; // 10_000_000_000_000_000_000i128

The fixed-point scale grovedb’s Avg axis sorts by: avg_fixed_point = floor(sum * RANKED_AVG_SCALE / count) with euclidean (toward -∞) division.

Re-exported from grovedb rather than re-declared so the two can never drift — the encoded sort keys in storage are produced with grovedb’s constant, and a platform-side copy that fell out of step would silently mis-scale every average the client renders. SCALE for the fixed-point average: 10^19, the largest power of ten whose worst-case product |i64::MIN| × SCALE still fits in i128 (≈ 9.2×10^37 against i128::MAX ≈ 1.7×10^38 — proven by the compile-time assertion below).

The scale is chosen to maximize ordering resolution. Two distinct averages s1/c1 ≠ s2/c2 differ by at least 1/(c1·c2), so they can collapse onto one fixed-point value only when c1·c2 > SCALE — at 10^19 that requires both counts above ~3.16 billion. A collapse is benign (the full secondary key is sort_key ‖ item_key, so tied averages order deterministically by item key), but at billions-of-rows table sizes the previous 10^15 scale started collapsing averages it should distinguish: its threshold was two children of ~31.6 million rows each.

Fixed-point values at this scale do NOT round-trip through f64 (anything with |avg| > ~0.0009 exceeds 2^53). That is deliberate: the index never touches floats — ordering, encoding and consensus all operate on the i128 — and a consumer wanting a float view divides by SCALE and accepts ordinary f64 rounding of the display value.