Spherra — Litepaper

One pool for every stablecoin — and the only one whose math is proven.

Version 0.1 (draft) · status: pre-mainnet, not audited · no token

About this draft. This is the flagship narrative document — the thing a researcher reads
end-to-end and a KOL cites. It is written to be published on spherra.xyz/litepaper (web + PDF).
Figure placeholders (marked ▣ FIGURE) mark where visuals from the Visual & Motion pillar
(02-visual-motion-video.md) drop in — nothing is generated yet. Formulas, theorem names, and
verification commands are real and can be checked against the repository today.

Claim discipline (binding). The core math is formally verified; the contracts are not
audited — no firm is engaged yet, so we say "not audited," never "audited" and never "audit in
progress," until a firm is engaged and a report is public.
Nothing here promises yield, returns, or safety. Providing liquidity carries risk, including loss
of capital. See §10.

▣ FIGURE 0 — Cover · real-3D / hero render (pillar 02 · "Orbital orb")
The luminous n-dimensional orbital surface on the void #0B0E14 ground, proof-blue #6EA8FE
lattice, the wordmark and the line "n stablecoins. 1 pool. 0 sorry."
[Placeholder — cover art not generated yet.]

Abstract

Stablecoin liquidity in DeFi is fragmented across hundreds of pairwise pools, and when one stablecoin depegs, the liquidity providers get drained. Spherra fixes both. It is an n-token automated market maker where liquidity lives on the surface of an n-dimensional sphere: up to 30 stablecoins in a single, capital-efficient pool, with concentrated-liquidity "ticks" generalized to n dimensions. When a stablecoin breaks its peg, Spherra doesn't blow up — it quarantines the bad asset and gracefully reduces dimension, protecting the rest. And the core math isn't just tested, it is formally verified in Lean 4 (zero sorry, standard axioms) and differential-tested against a 60-digit reference oracle. Spherra implements the Orbital AMM design published by Paradigm, as a rigorous, independent, and proven implementation. One pool. Proven. Built to survive the break.

1. The problem: stable liquidity is fragmented and fragile

Stablecoins are the settlement layer of DeFi — the dollar rails everything else rides on. Yet the way we provide liquidity for them is quietly broken in two ways.

It's fragmented. Today, every stablecoin pair is its own little pool: USDC/USDT here, USDT/DAI there, a metapool bolted onto a base pool somewhere else. Liquidity that should be one deep, shared book is instead scattered across dozens of shallow ones. Traders route through multiple hops and eat slippage at each; liquidity providers spread thin and capture less; and the whole system carries the gas, contract surface, and operational overhead of many pools instead of one.

It's fragile. A conventional multi-asset stable pool treats every asset as redeemable near 1:1. That assumption is load-bearing — and when one asset breaks it, the pool becomes the exit. Arbitrageurs dump the depegging asset into the pool and pull the healthy ones out, until the pool is a bag of the worst asset and the LPs of the good stablecoins have absorbed the loss. We have all watched this movie. The "safe" corner of DeFi turned out to be the quietly fragile one.

▣ FIGURE 1 — "The two failures" · diagram (pillar 02 · n-Constellation system)
Top: fragmentation — a scatter of shallow pairwise pools. Bottom: contagion — a depeg draining the
healthy assets out of a shared pool. Two panels, calm annotation.
[Placeholder — not generated yet.]

Spherra is a direct answer to both: unify the liquidity, and engineer for the day an asset breaks.

2. The idea: one sphere

Instead of a mess of pairs, put every stablecoin on one surface.

Spherra holds up to 30 stablecoins in a single pool whose reserves live on the surface of an n-dimensional sphere (one dimension per token). A trade is simply a slide along that surface from one token's axis toward another's. One deep pool replaces the hundred shallow ones — deeper liquidity, tighter spreads, and a single place to route stable flow.

This is the Orbital AMM design, published as research by Paradigm. Spherra is the team that built it — and, uniquely, proved it. (We implement a published design; this is not a claim of endorsement or partnership.)

▣ FIGURE 2 — "From pairs to one sphere" · diagram / AI-gen hybrid (pillar 02)
Left: a tangle of pairwise USDC/USDT/DAI/… pools. Right: those same tokens as points of light on a
single glowing sphere — one deep pool. A morph or arrow between the two states.
[Placeholder — not generated yet.]

The mental model to carry through the rest of this paper:

The pool is a sphere. Each stablecoin is an axis. The pool's reserves are a single point on the

sphere's surface.

A trade moves the point. Swapping token i for token j slides the reserve point along the

surface — the geometry sets the price.

LPs shape the surface. Liquidity providers concentrate their capital in regions of the sphere

(see §4), so the pool is deepest exactly where stablecoins actually trade: near their peg.

A depeg drops a dimension. If a stablecoin breaks, its axis is quarantined and the sphere

reduces from n to n−1 dimensions — the survivors keep trading (see §5).

Everything else is detail in service of those four ideas.

3. The geometry

3.1 Why a sphere

Curve's StableSwap made a two-asset insight concrete: near the peg, a stable pool should behave almost like a constant-sum market maker (swap 1:1, near-zero slippage), and only bend toward constant-product behavior as reserves get lopsided (so it can never be fully drained at par). Orbital generalizes that intuition from a 2-asset curve to an n-asset surface: a sphere, on which the "all assets equal" point (perfect peg) sits at the symmetric center, and imbalance moves you around the surface.

▣ FIGURE 3 — "The orbital surface" · real-3D (pillar 02 · honest 2-sphere)
A rotating 3-token sphere (a genuine 2-sphere, mathematically faithful): the peg point at center,
the three token axes, a labeled reserve point on the surface. Nerd-mode overlay optional.
[Placeholder — not generated yet.]

3.2 The invariant (for the curious — skippable)

Under the hood, the pool commits only to states that satisfy a single invariant. In the implementation's "torus" form, with S the sum of reserves, Q the sum of squared reserves, n the active token count, and consolidated tick parameters rInt, kBnd, sBnd:

F(S, Q) = ( S/√n − kBnd − rInt·√n )²  +  ( √(Q − S²/n) − sBnd )²  −  rInt²

In plain English: F measures how far the pool's aggregate reserve point is from the exact surface it is required to sit on. The protocol enforces one global rule on every state it commits:

−ε ≤ F ≤ 0 — the pool always sits on or just inside the surface, never outside it.

F ≤ 0 means the pool holds at least what the invariant requires; the small tolerance ε is not a guess — it is calibrated from measured rounding dust (§6.3). This "one-sided" rule is why every rounding error can only ever accrue to LPs, never against them (§6.4).

You do not need this formula to use Spherra. You need to know that it exists, that it's enforced on every state, and that it has been machine-checked (§6.1).

3.3 A trade is a slide along the surface

When you swap, the pool solves for the output that keeps the reserve point exactly on the surface (rounding the output down so F ≤ 0 holds). Large trades bend the path; as liquidity thins or the path crosses a tick boundary, the pool segments the trade and re-solves — all in closed form, without sampling. The result is best-execution pricing across all n stablecoins from one book.

▣ FIGURE 4 — "A trade travels the sphere" · hybrid loop (pillar 02 · social loop library)
A node sliding along the surface from one axis toward another as an amount is dragged; price/slippage
readout ticking; a tick-plane lighting up on crossing. Loops cleanly for social.
[Placeholder — not generated yet.]

4. Capital efficiency: concentrated liquidity in n dimensions

A single giant pool would be pointless if the capital were spread evenly across the whole surface — most of it would sit in price regions no stablecoin ever visits. So Spherra gives LPs concentrated liquidity: the Uniswap V3 "tick" idea, generalized to the n-dimensional sphere.

An LP places liquidity at a chosen tick — parameterized by a depeg point p ∈ (0.5, 1) that says, in effect, "keep my liquidity active while these stables stay within this band of the peg." Tighter ticks concentrate capital nearer the peg (maximum efficiency where the volume is); wider ticks hold a bigger cushion for when a stable wanders. The pool internally classifies each tick as interior (in the deep, near-peg region) or boundary (pushed to its edge), and the aggregate surface is the composition of all of them.

The payoff: the same dollars go further. Liquidity sits where stablecoins actually trade, so the book is deeper and spreads are tighter than an equivalent amount of evenly-spread capital — across all the pool's stablecoins at once, not one pair at a time.

▣ FIGURE 5 — "One deep pool beats a dozen shallow ones" · data-viz chart (pillar 02 + dataviz)
Depth / slippage curves: the same notional capital as N pairwise pools vs. concentrated on one
orbital tick. Clearly label "illustrative" unless drawn from the real invariant. Optional slider:
stablecoins 2 → 30, watch fragmentation collapse into one curve.
[Placeholder — not generated yet.]

LP positions are held as ERC-1155 tokens, one id per tick, so a position is composable and transferable, and each tick's accounting (including any settled-asset claims from a quarantine) is tracked independently and exactly.

5. Depeg resilience: dimension reduction

This is the feature that named the category. Spherra is designed to survive a depeg — to treat one stablecoin breaking as a handled event, not an extinction.

5.1 The failure mode we engineered against

As in §1: in a normal multi-asset stable pool, a depeg turns the pool into an exit for the bad asset, and the healthy-asset LPs eat the loss. The naïve "one big pool" makes this worse, not better — more good assets to drain.

Spherra inverts it. The bigger the pool, the more there is to protect — so we built the protection into the geometry.

5.2 Quarantine = dropping a dimension

When a stablecoin is determined to have broken its peg, the pool freezes it: the token's axis is walled off, and the trading surface reduces from an n-sphere to an (n−1)-sphere. The broken stablecoin is isolated on its own quarantined layer; the remaining stablecoins keep trading on a clean, lower-dimensional surface as if nothing happened. Crucially, the freeze is exact and reversible, and the healthy assets' prices are continuous across the freeze — nothing lurches. (That continuity is not a hope; it's a proven theorem — §6.1.)

▣ FIGURE 6 — "n → n−1" · hybrid loop (pillar 02 · flagship depeg loop)
A healthy orbit; one axis flashes depeg-red #F85149; it is cordoned in quarantine-cyan #7EE8E0;
the sphere visibly drops a dimension; the survivors keep orbiting. Caption: *"one breaks. the rest
don't care." (Brand law: the break and the save* are different colors.)
[Placeholder — not generated yet.]

5.3 The lifecycle: freeze → unfreeze → settle → lift

Quarantine plays out on a timeline, not in a panic. Freezes stack strictly last-in-first-out, so nested quarantines resolve cleanly.

Freeze — quarantine the broken stablecoin; reduce dimension. Instant and reversible.
Unfreeze — if it repegs, it comes right back, exactly, and the sphere returns to n

dimensions.

Settle — if it's truly gone, LPs' claims on the settled asset are made redeemable. This is the

one irreversible step, so it sits behind a timelock (queue now, execute after a delay), and a guardian can veto a queued settle.

Lift — later, a healthy stablecoin can be (re-)listed into the pool at parity.

Per-tick claims on a settled asset are tracked exactly and sum to the pool's real balance of that asset (a conservation property we test directly). No LP's claim is diluted by another's.

▣ FIGURE 7 — "The depeg playbook" · diagram (pillar 02 · n-Constellation)
A horizontal timeline: freeze → (unfreeze | settle → lift), with the guardian and timelock marked on
the irreversible step. Plain-language captions under each stage.
[Placeholder — not generated yet.]

5.4 What triggers a freeze

The pool maintains its own time-weighted implied price for each stablecoin, derived directly from the pool's geometry (not an external price feed). A freeze-trigger module watches it: if a token's time-weighted implied price stays below a threshold for long enough, anyone — a permissionless keeper — can trigger the freeze. A guardian can always freeze immediately, bypassing the trigger, for fast response. The trigger module is swappable by governance, so the freeze policy can evolve without touching the core pool.

A note on "oracle." Spherra uses the word for two different things and we keep them distinct: the
on-chain price oracle (the TWAP implied-price freeze trigger, described here) and the reference
oracle (a 60-digit mpmath engine used only in testing — §6.2). They are unrelated.

6. The proofs: why "proven" is a category, not a slogan

Most protocols ask you to trust them. We'd rather you check. The reason a cautious LP can choose Spherra over a higher-emissions farm is that the safety story is verifiable, in layers.

▣ FIGURE 8 — "The rigor stack" · diagram (pillar 02 · Torus Sigil / proof seal motif)
Five stacked layers: formal proof → 60-digit differential test → invariant fuzzing → calibration →
independent audit (not yet started), feeding a small, dependency-light contract. Mono "receipt" styling.
[Placeholder — not generated yet.]

6.1 Formally verified in Lean 4 (zero `sorry`)

The two parts of the math that can actually hurt you are machine-checked in the Lean 4 proof assistant, with zero sorry (Lean's keyword for an unproven gap) and standard axioms:

The exact split — that trades on the n-dimensional surface, and the reconstruction of per-tick

reserves from aggregate state, are computed correctly, with no drift.

Dimension reduction — that quarantining a depegged stablecoin is mathematically sound and

reversible, and that the healthy assets' prices are continuous across a freeze.

Almost no AMM in existence can say its core math is machine-checked. Ours can. The proofs are open (theorem index in the Appendix).

What formal verification does and does not mean: it proves the math is correct — it does not,
by itself, prove every line of Solidity is bug-free. That's what the differential tests and the
independent audit are for. The first two are done; the audit is not — no firm is engaged yet.

6.2 Differential-tested against a 60-digit oracle

A proof on paper is still paper until the code matches it. So we built an independent reference engine in Python at 60 digits of precision (mpmath) and check the Solidity against it, bit-for-bit, across full trade/lifecycle trajectories — 2,699 passing assertions back the reference behavior. Measured relative error of the invariant versus the oracle is on the order of 1e-24. Every disagreement is pure, bounded Solidity rounding — which is exactly what we used to calibrate the tolerances (§6.3).

6.3 Invariant fuzzing + a calibration campaign

We throw randomized sequences of swaps, deposits, freezes, and settlements at the pool and assert the core invariants never break — torus F ≤ 0, tick classification bands, solvency floors, and claims-conservation among them. And we didn't guess our safety tolerances: a calibration campaign measured the actual rounding dust the system produces and set every constant from that data — tightening the main invariant tolerance by two orders of magnitude from its initial value.

6.4 Pool-favorable rounding

The invariant is enforced one-sided (F ≤ 0): swap outputs round down, and if a solution would land outside the surface it's decremented until it's inside. The practical consequence: rounding dust can only ever accrue to LPs, never against them.

6.5 A small, auditable surface

Spherra is Solidity 0.8.24 and Foundry. The core pool has no external dependencies (forge-std only); the vault and router layer uses OpenZeppelin, and there are no other external runtime dependencies. Less code means fewer places for a bug to hide and a cleaner audit. No independent audit has been done yet; the report will be published the day it's complete.

7. For liquidity providers: shares, fees & risk

Who provides liquidity, and why. Spherra is a pure protocol with no token — there is no airdrop, no points program, and no emissions. LPs come for the product, not a farm: deeper liquidity, best execution across every stablecoin, capital efficiency from concentrated ticks, and a venue that is designed to survive a depeg and can prove its core math.

How LP positions work. You deposit at a tick of your choosing (§4) and receive an ERC-1155 position (one id per tick) representing your pro-rata share of that tick. You can add or remove liquidity, and — if a stablecoin in the pool is ever settled — claim your exact per-tick share of the settled asset.

Fees. LPs earn a share of the swap fees their liquidity supports — real fees from real volume, not inflation. Spherra charges a small, governance-set stableswap-tier fee, taken on the input side and added to reserves in a way that preserves the F ≤ 0 invariant, so fee accrual never puts the pool outside its surface.

Status (honest). The base protocol was specified feeless; the fee module is being enabled for
the v1 launch and will be in scope for the audit once a firm is engaged. Until it is live and audited, treat fee mechanics
as provisional, and note that we make no promise of any yield amount or APY — LP returns depend on
volume and market conditions and are never guaranteed.

Risk. Providing liquidity carries risk, including loss of capital. Smart-contract risk exists; no independent audit has been done; and a depeg, while handled by dimension reduction, is not costless to the LPs of the asset that broke. Do not deposit more than you can afford to lose. See §10.

8. Trust & governance

Spherra keeps governance minimal and auditable — the less discretion in the system, the less there is to trust or to exploit.

Owner — slow governance, transferred in two steps (propose → accept, so a fat-fingered

transfer can't brick control). Sets policy; gated behind the timelock for irreversible actions.

Guardian — a fast safety role the owner can rotate in one step: can freeze a suspected depeg

immediately (bypassing the trigger) and veto a queued settle. It cannot steal funds; it can only buy time.

Timelock — the irreversible settle must be queued and then executed after a delay (bounded

between a floor and a ceiling set at deployment), giving LPs and the guardian time to react.

Freeze-trigger oracle — a swappable module that lets permissionless keepers freeze a token

once its time-weighted implied price breaches a threshold. Governance can upgrade the policy without touching the core pool.

▣ FIGURE 9 — "Who can do what" · diagram (pillar 02 · n-Constellation)
A compact map: Owner / Guardian / Keepers / Timelock and which actions each can take (freeze,
queue-settle, execute-settle, veto, lift, swap trigger). Emphasize "guardian buys time, can't take
funds."
[Placeholder — not generated yet.]

What's verified vs. what isn't (we'd rather you know the edges):

Layer	Status
Core math (exact split, dimension reduction)	✅ Formally verified in Lean 4, zero `sorry`
Solidity rounding / invariant behavior	✅ Differential-tested vs 60-digit oracle + fuzzed
Full contract (all paths, incl. fees)	❌ Not audited — no firm engaged yet
Economic assumptions, keeper liveness, guardian trust	⚠️ Stated and minimized, not eliminated

Supported assets (v1). 2–30 tokens per pool; 18-decimal, non-fee-on-transfer stablecoins (others must be wrapped). These constraints are deliberate — a smaller, well-specified surface is an easier one to prove and audit.

9. Roadmap

No promises beyond what we can back. The near path:

Audit → mainnet. Engage and complete an independent audit, publish the report, and launch on

mainnet (~1–2 months from this draft). The fee module ships enabled and audited.

Depth first. Seed anchor liquidity and open the pool through a guarded → open sequence, so the

book is deep before it's public.

More stablecoins. Add stablecoins to the sphere over time — each new one deepens the shared book.
Integrations. Aggregators, wallets, and front-ends routing to the pool turn Spherra into

infrastructure, not a destination.

The sphere grows. Public dashboards, more pools, and continued research and verification.

No token. Spherra is a pure protocol. We are not planning a token, an airdrop, or a points program, and any claim otherwise is not from us.

10. Risks & disclosures

Providing liquidity to Spherra is not risk-free. In plain English:

Loss of capital. LPing can lose money. Do not deposit more than you can afford to lose.
Smart-contract risk. Despite formal verification of the core math and extensive testing, software

can have bugs. No independent audit has been done yet, and no firm is engaged.

Depeg risk. Dimension reduction is designed to contain a depeg and protect the healthy assets —

it is not a guarantee, and the LPs of the asset that breaks can still take a loss.

Governance & keeper assumptions. The guardian, timelock, and permissionless keepers are minimal

but real trust/liveness assumptions; see §8.

No yield promise. Any fees depend on real volume and market conditions. Nothing here is a promise

of return, an APY, or a price prediction.

Nothing in this document is financial, investment, legal, or tax advice, or a solicitation. Security contact and responsible-disclosure details will be published at spherra.xyz/security.

11. Verify it yourself

We publish the receipts. Everything below can be checked against the repository.

Run the test suite (differential tests need FFI; run with the sandbox off — Foundry needs network for

trace signatures): git clone <repo> && cd contracts && forge test --ffi

Query the 60-digit reference oracle directly:

echo '{"op":"state","n":4,"ticks":[{"p":"0.95","A":"1000"}],"history":[]}' | python3 analysis/reference_cli.py

Build and check the Lean proofs in analysis/orbitalproofs/ (see that directory's README).

▣ FIGURE 10 — "The receipt card" · AI-gen static (pillar 02 · number-card template)
Lean: 0 sorry · Differential assertions: 2,699 ✓ · Precision: 60 digits · Ext deps: 1 · Audit: not started
Mono, screenshot-able at thumbnail size.
[Placeholder — not generated yet.]

Appendix

A. Theorem index (Lean)

The formally-verified core lives in analysis/orbitalproofs/. Key results referenced above (cited in the SPEC as [L: name]):

exact_split — correctness of the per-tick reserve reconstruction from aggregate state.
unique_split — per-tick reserve vectors are uniquely determined by aggregate reserves + scalar

params + classification (the basis for O(1)-in-tick-count storage).

boundary_placement — the identity used to place boundary ticks (conservation by subtraction).
Dimension-reduction results — soundness, reversibility, and price-continuity of freeze.

(Exact theorem names and statements: see the Lean sources and contracts/SPEC.md.)

B. Glossary

Orbit / sphere — the single pool; the n-dimensional surface reserves sit on.
Tick — a region of the sphere where an LP concentrates liquidity (depeg param p).
Depeg — a stablecoin losing its peg.
Quarantine / dimension reduction — isolating a depegged stable and dropping the surface from n

to n−1 dimensions.

Freeze → unfreeze → settle → lift — the quarantine lifecycle (§5.3).
Formal verification / Lean 4 / sorry — machine-checking the math; sorry is Lean's unproven-gap

keyword. Spherra' core has zero.

Differential testing — checking the contract against a high-precision reference engine.
Price oracle vs. reference oracle — the on-chain TWAP freeze trigger vs. the 60-digit mpmath

test engine. Distinct things.

Guardian / timelock — minimal governance: fast pause vs. delay on irreversible actions.

C. References & sources

The Orbital AMM design, published by Paradigm (prior art / design lineage).
contracts/SPEC.md — the normative implementation specification.
analysis/orbitalproofs/ — the Lean 4 proofs.
analysis/reference_cli.py — the 60-digit mpmath reference oracle.
contracts/ — the Solidity implementation and Foundry test suite.

Spherra · the proven stablecoin AMM · not audited · no token · capital at risk. This litepaper is a draft and will be updated as an audit is engaged and completed and mainnet approaches.