Units and Rounding

Signals v1 uses multiple unit systems with strict rounding rules to avoid arbitrage and accounting drift. The protocol combines trading, settlement, and maker accounting on-chain. Small rounding biases can compound over time, so unit conversions and rounding direction are part of the mechanism, not a UI detail.

Rounding is a policy choice, not an accident. The direction of rounding determines who bears tiny discrepancies, and that shapes long-run fairness.

Unit systems

Signals crosses three numeric layers:

• token units for debits, credits, and payouts
• WAD for internal fixed-point math at $10^{18}$ scale
• integer ticks for the outcome grid

These layers exist for different reasons. Token units are the externally meaningful asset transfers. WAD is the precision layer used to keep CLMSR math and vault math stable. Ticks are the discrete settlement alphabet.

Each layer uses a different unit for a different purpose. Trading uses token units, internal math uses WAD for precision, and outcomes live on the discrete tick grid.

Because these units are not the same, conversions happen at every critical boundary: trade cost, fee calculation, claim payout. The rounding rules define how those boundaries behave.

The unit design is intentionally conservative. Signals uses:

• high precision internally to avoid accidental loss of information during CLMSR math and allocation math, and
• deterministic rounding at the external boundaries so that realized cashflows and payouts are reproducible from public inputs.

WAD as internal precision unit

WAD arithmetic provides high precision for on-chain math. It allows the curve, fees, and allocations to be computed without losing detail prematurely. The conversion to token units happens at the externally visible boundaries.

WAD is also the unit where most invariants are easiest to state. Path independence is a statement about a potential difference in WAD. Fee waterfall conservation is a statement about WAD totals. Rounding rules are then applied when leaving the WAD layer.

Rounding rules

Trade costs are rounded up, and trade proceeds are rounded down. These choices protect solvency and keep accounting conservative.

This is not arbitrary. Rounding up costs ensures the system does not undercharge for risk, and rounding down proceeds ensures it does not overpay. Over many trades, that asymmetry prevents subtle value leakage.

The consequence is small but consistent: traders pay a tiny premium on entry and receive a tiny discount on exit. That premium is the price of deterministic, solvent accounting.

Round‑trip transforms should remain stable: cost → quantity → cost should return within one unit of precision. That tolerance is what keeps rounding from creating arbitrage loops.

Rounding rules apply consistently across surfaces:

• A quoted base cost in WAD becomes a debited token amount.
• A quoted proceed in WAD becomes a credited token amount.
• Fees are computed as explicit overlays and then rounded consistently.
• Claim payouts and vault accounting settle at token precision.

A concrete rounding model

The protocol performs much of its internal math at WAD scale and then converts to token units. If a token has $d$ decimals, the conversion factor is $10^{18-d}$.

One way to describe the intent is:

• Convert a WAD-denominated cost to token units by rounding up.
• Convert a WAD-denominated proceed to token units by rounding down.

In formulas, for a WAD amount $A$:

$$\text{toTokensFloor}(A) = \left\lfloor \frac{A}{10^{18-d}} \right\rfloor,\quad \text{toTokensCeil}(A) = \left\lceil \frac{A}{10^{18-d}} \right\rceil$$

For ctUSD with $d=6$, the factor is $10^{12}$. The trade surfaces therefore use:

$$\text{cost}_6 = \left\lceil \frac{\text{cost}_\text{WAD}}{10^{12}} \right\rceil, \qquad \text{proceeds}_6 = \left\lfloor \frac{\text{proceeds}_\text{WAD}}{10^{12}} \right\rfloor$$

The exact implementation details live in contract code, but the economic rule is the specification: costs are conservative on entry and proceeds are conservative on exit.

Fee overlay composition

Fees in Signals v1 are applied as an explicit overlay after base pricing. That creates two rounding surfaces:

• base CLMSR math produces a WAD value
• fee overlay math produces another WAD value derived from the token-level base amount

The invariant is that the final debited amount for a buy is never smaller than the WAD-implied amount under conservative rounding. The final credited amount for a sell is never larger than the WAD-implied amount under conservative rounding.

This is why the pricing engine and fee overlay both use conservative rounding. A single rounding error is small. A systematic bias across large volume is not.

Oracle scaling and tick mapping

Settlement values are derived from oracle prices and then scaled into a fixed 6-decimal unit before tick mapping. Oracle feeds can have different decimals such as 8. The oracle module scales the feed price into a 6-decimal settlementValue and then maps:

$$\text{rawTick} = \left\lfloor \frac{\text{settlementValue}}{10^6} \right\rfloor$$

followed by clamping to market bounds and aligning to tick spacing. This is a separate rounding boundary from WAD-to-token conversion: oracle scaling defines the settlement value unit, and WAD conversion defines trade and accounting units.

Oracle scaling is a deterministic integer transform. Let $p$ be the feed price and let $d_f$ be feed decimals. The scaled settlement value uses 6 decimals:

If $d_f \le 6$:

$$\text{settlementValue} = p \cdot 10^{6-d_f}$$

If $d_f > 6$:

$$\text{settlementValue} = \left\lfloor \frac{p}{10^{d_f-6}} \right\rfloor$$

The floor in the scale-down case is part of the contract. It defines the behavior when the oracle feed has finer decimals than the settlement unit.

Tick spacing alignment is another deterministic rounding rule. After rawTick is clamped into the market tick range, it is aligned down to spacing $s$ relative to $\text{minTick}$:

$$\tau = \text{minTick} + \left\lfloor \frac{\text{rawTick} - \text{minTick}}{s} \right\rfloor s$$

This is the final settlement tick used by claims.

Example

Suppose a trade produces a base cost of 1.234567 tokens but only 6 decimals are supported. The system rounds up to 1.234568 for costs and rounds down for proceeds. The exact rounding direction is part of the contract logic, which makes it explicit and consistent.

The same pattern shows up in sell proceeds. If a sell proceeds amount is computed in WAD and then converted to token units, the conversion rounds down. That prevents overpayment by a single unit at the external boundary.

The same principle applies to fees. If a fee is computed as a fraction of a base amount, the base amount is already subject to a rounding direction. The fee then inherits a consistent rounding rule so that:

• the total debited amount is never smaller than the conservative WAD value, and
• the total credited amount is never larger than the conservative WAD value.

The same logic applies to claims. If a payout is fractional beyond token precision, it is rounded in the direction that preserves solvency.

Where rounding shows up

• Trade costs: rounded up to protect solvency.
• Trade proceeds: rounded down to avoid overpayment.
• Fees: rounded consistently with base cost.
• Claims: rounded to token precision at final payout.

Rounding as specification

Rounding is not just a math implementation detail. It defines who carries the edge in tiny mismatches, and it shapes the long-run safety of the system. Because Signals is a high-volume trading mechanism, even a small rounding bias can become meaningful when aggregated across many trades and many days.

Rounding rules are part of the economic design, not just an engineering choice.

Rounding direction is enforced in contract logic. Trade costs and proceeds are defined by state transitions and unit conversions.

Boundary cases

Rounding becomes more visible in edge regimes:

• Very small trades: rounding can be a meaningful fraction of the total.
• Large batches of trades: tiny per-trade rounding differences can accumulate.
• Claim boundaries: half-open interval semantics and token-unit rounding both affect boundary outcomes, but they affect different layers: interval semantics choose the tick; rounding chooses the token-unit payout at that tick.

One additional boundary case is scale mismatch between units. Oracle feeds can have decimals that do not match the settlement unit, and fee policies can depend on token units while base pricing lives in WAD. The protocol resolves these mismatches explicitly through fixed scaling and fixed rounding direction.

Clarifications

• Rounding does not “favor” any single user; it enforces a consistent rule.
• Rounding is not a fee; it is a deterministic conversion boundary.
• Small rounding differences can accumulate in high‑volume regimes.