5 posts tagged with "surplus"

Status: Proposed exact-arithmetic mechanism for externally owned CAV. The independent settlement fractions and CavalRe payable journals below describe the research model. Current contracts implement a narrower Surplus top-up mechanism, summarized after the atomic settlement requirements.

In this proposal, Surplus is externally owned CAV held by the Protocol for sale. CavalRe owns the CAV, authorizes its use, and receives the sale proceeds in CavalRe Treasury. CavalRe and the Protocol are distinct accounting entities.

The mechanism can route independent fractions of the user's pay and receive legs through Reserve. The remaining amounts execute as a CavalRe-owned CAV sale. A pure sale bypasses Reserve and leaves Multiswap prices unchanged. A mixed settlement is accepted when its complete Reserve endpoint passes the gauge-invariant safety condition.

Multiswap prices are gradients of a concave projective potential. Post-trade execution therefore produces a nonnegative Bregman divergence. For a closed swap, that divergence accumulates in LP Token backing. For a partial liquidity action, it finances the permitted change in the price surface. For externally owned Surplus, it combines with an explicit value flow across the Reserve boundary.

These are not three unrelated safety arguments. They are special cases of one exact balance law:

Projective-potential change equals Bregman production plus Reserve boundary value flow plus price-surface reset.

This article derives that law from the native Multiswap state and applies it to swaps, liquidity operations, and externally owned Surplus.

Multiswap uses double-entry accounting. Every posting is balanced within one token ledger: the debit and credit contain the same amount of the same token. A cross-token action is therefore a collection of balanced same-token journal entries, never one debit in token $A$ and one credit in token $B$.

Accounting conservation is always required. Safety is a second question: after the complete atomic action has been posted and the price-forming state has been updated, did the pool move in the permitted projective direction?

This article gives the full-ledger test and explains why many journal entries cancel before the safety calculation.

Scope: Exact-arithmetic accounting model. The externally owned CAV and CavalRe payable entries illustrate a proposed ownership structure. Current Surplus settlement uses a reduced Reserve quote and receive-side top-ups; it does not implement these proposed payable journals. See Fees and Surplus.

Historical proposal: This article explores a price-preserving Surplus candidate. The implemented settlement policy uses a reduced-pay second quote and Surplus top-ups; it preserves the direct user payout but can change relative pool prices. See Quote Engine for current behavior.

Multiswap pools can hold protocol-owned token inventory in a Surplus account. For a token-launch pool containing a pay asset $A$ and a launched receive asset $B$, the protocol would like to sell available Surplus $B$ without changing the user's direct quote. Some of the user's $A$ can enter Reserve, and the rest can be divided between Rewards and Treasury.

The allocation cannot be chosen independently of pool safety. Protecting the $B$ Reserve changes the physical Reserve endpoint. Preserving the direct relative prices then requires a common price gauge, and that gauge changes the LP Token's total scale.

For a two-asset pool, the resulting allocation problem has a simple solution:

1. available Surplus inventory determines the fraction of $B$ paid by Reserve;
2. LP safety determines the minimum fraction of $A$ that must enter Reserve;
3. an optional configured floor may increase that pay-side Reserve fraction;
4. Rewards and Treasury divide the remainder equally; and
5. an infeasible Surplus attempt uses ordinary direct settlement instead.

The minimum pay allocation is closed form for every $0<e_s<1$. When $e_s=e_P=1/2$, the direct receive quote and the complete receive-side safety boundary are also closed form.

This article derives that candidate from first principles. It is not current implemented protocol behavior.

Historical proposal: This article explores a price-preserving Surplus candidate. The implemented settlement policy uses a reduced-pay second quote and Surplus top-ups; it preserves the direct user payout but can change relative pool prices. See Quote Engine for current behavior.

Multiswap can hold protocol-owned token inventory in a Surplus account. When a user receives an asset held in Surplus, the protocol would like to deliver some or all of the output from that inventory instead of depleting the asset's pool Reserve.

The settlement source should not change the user's quote. It should not change the relative post-trade prices either. A user exchanging the same amounts against the same opening pool state should reach the same market prices whether the receive tokens come from Reserve, Surplus, or a combination of both.

That goal is harder than moving tokens between accounts. If Surplus protects a receive Reserve while the pool assigns the asset the higher price caused by direct Reserve depletion, the asset appears scarce without becoming scarce. The resulting coefficient expansion falls outside the Post-Trade Elasticity coefficient order.

This article develops a candidate alternative. The key observation is that Multiswap prices have a common scale gauge. Absolute prices depend on the internal scale unit; relative prices do not. Surplus settlement can therefore target a common multiple of the ordinary direct-swap price vector. A single global scale-accumulator update applies that gauge to the full pool without looping over every Reserve Asset. Explicit pay and receive legs then receive their own constant-time compensations.

The candidate has four principal results:

1. the user's direct-swap quote is unchanged;
2. every relative post-trade price equals the direct-swap relative price;
3. every Reserve Asset coefficient remains fixed or contracts;
4. Surplus coverage can be capped so the LP Token coefficient remains safe without minting or burning LP Tokens.

The construction is a research candidate, not implemented protocol behavior. It assumes exact arithmetic, positive reserves and scales, homogeneous elasticity

and fee-free settlement. Fees are outside this candidate model rather than an unresolved part of it. Rounding, account-level authorization, and implementation tests remain open before implementation.