Curve Parameters

The amplification coefficient (A) is a constant that determines the curvature of a stable swap pool's bonding curve. It controls the trade-off between low slippage for similar assets and capital efficiency.

• High A (e.g., 2000): Creates a flatter curve, ideal for stablecoin pairs (e.g., USDC/DAI), minimizing slippage near parity.
• Low A (e.g., 50): Creates a more curved, Uniswap-like function, suitable for correlated but not pegged assets.

The reserve balances (x, y) represent the current quantity of each token in a liquidity pool. They are the dynamic variables in the bonding curve's invariant function (e.g., x * y = k for constant product). The price for a trade is calculated based on the ratio of these reserves after the proposed swap, ensuring the invariant is maintained.

The invariant function is the core mathematical equation that must remain constant before and after any trade, defining the bonding curve's shape. The two primary types are:

• Constant Product (x * y = k): Used by Uniswap V2, creates a hyperbolic curve.
• StableSwap Invariant: A hybrid function used by Curve Finance that approximates constant sum (x + y = k) when assets are near parity, reverting to constant product when reserves are imbalanced.

Fee parameters are deducted from each trade and distributed to liquidity providers. They are typically defined as:

• Trading Fee (%): A percentage of the trade amount (e.g., 0.04% for Uniswap V3 pools).
• Protocol Fee (%): An optional additional fee that can be directed to the protocol's treasury, often governed by token holders.

Price on a bonding curve is the instantaneous exchange rate, derived from the slope (derivative) of the curve at the current reserve point. Slippage is the difference between the expected price and the executed price, which increases with trade size as the move along the curve depletes one reserve. It is a direct consequence of the curve's parameters and liquidity depth.

Parameter governance refers to the process of setting and updating a pool's parameters (like A or fees). In decentralized protocols, this is often managed by:

• Immutable Factory Settings: Set at pool creation (common in early AMMs).
• DAO Vote: Governance token holders vote on parameter changes.
• Gauge Weights: In protocols like Curve, A can be adjusted via gauge votes that influence liquidity incentives.

The most fundamental curve is the constant product formula, used by Uniswap V2 and many AMMs. It defines a hyperbolic curve where the product of two token reserves (x * y = k) remains constant. This creates infinite liquidity but leads to slippage that increases with trade size. The price of token X in terms of Y is given by Price_X = y / x.

The StableSwap invariant, pioneered by Curve Finance, blends the constant product and constant sum formulas. The key parameter A (amplification coefficient) controls the curve's shape:

• High A (e.g., 1000): Curve is flatter near parity, enabling low slippage for stablecoin pairs.
• Low A (e.g., 50): Curve behaves more like a constant product AMM, suitable for correlated but not pegged assets. This parameter is often set by governance and can be adjusted for different pools.

Curves incorporate fee parameters that are subtracted during swaps. A typical model includes:

• Swap Fee (γ): A percentage (e.g., 0.04%) taken from the input amount of a trade.
• Protocol Fee: A fraction of the swap fee (e.g., 1/6th) diverted to the protocol treasury.
• LP Fee: The remaining fee distributed proportionally to liquidity providers. These fees are critical for sustaining the protocol and incentivizing capital provision.

Key curve parameters are often managed by decentralized governance. For example, Curve DAO votes can adjust the amplification coefficient A or fee structures for specific pools to optimize for current market conditions (e.g., adjusting A if a stablecoin depegs). Some advanced implementations use dynamic parameters that adjust algorithmically based on pool imbalance or oracle prices.

In token bonding curve launches (e.g., for continuous fundraising), parameters define the minting/burning mechanics:

• Reserve Ratio: The fraction of collateral backing each token.
• Curve Slope: Dictates how sharply the price increases with supply (e.g., linear, exponential).
• Floor/Ceiling Price: Minimum and maximum possible token prices. These parameters are immutable once set and determine the token's long-term economic model.

The generator point (G) is a specific point on the curve used to generate public keys. Its order (the number of times it can be added to itself before reaching the point at infinity) must be a large prime number. If the order has small factors, it enables small subgroup confinement attacks, where an attacker can extract partial private key information. Proper validation of received public keys must check they lie on the correct curve and subgroup.

Even with secure parameters, flawed implementation can break security. Critical considerations include:

• Side-channel attacks: Timing or power analysis can leak the private key during scalar multiplication.
• Invalid curve attacks: Failing to verify that a received public key point is on the intended curve can allow an attacker to force computations on a weaker curve.
• Random number generation: A non-cryptographically secure random number for the private key or nonce (e.g., in ECDSA) leads to key compromise.

A major security concern is whether curve parameters were generated verifiably at random. If an entity can choose parameters with a hidden mathematical relationship (a trapdoor), they could potentially break the cryptography later. This led to the development of rigid curves like Curve25519 and the Nothing-Up-My-Sleeve numbers in Curve secp256k1 (used by Bitcoin), where constants are derived from publicly verifiable, non-manipulable inputs like the digits of π.

A full set of domain parameters for a curve includes the prime field (p), curve equation coefficients (a, b), the base point (G), its order (n), and the cofactor (h). Protocols like TLS and blockchain systems must specify and validate these parameters precisely. For example, Bitcoin's secp256k1 is defined by specific (p, a, b, G, n, h) values. Any deviation, even in a single bit, creates a different, potentially insecure, cryptographic group.