# Bonding Curves

A bonding curve is a mathematical formula that defines the relationship between an asset's price and its supply. Bonding curves are used to algorithmically adjust asset prices in AMMs.

sudoswap supports three types of bonding curves: linear, exponential, and constant product (x * y = k).

**Linear Bonding Curves**

**Linear Bonding Curves**

With a linear bonding curve, the price of an NFT is increased by a flat amount (called delta) every time an item is bought from the pool. Conversely, the price of the NFT is decreased by that same flat amount every time an item is sold to the pool.

For example, a liquidity provider may create an NFT<>ETH pool with a Start Price of 1 ETH and a delta of 0.1 ETH. Assuming they provide enough liquidity, the price of an NFT will increase to 1.1 ETH after one item is purchased from the pool. After a second item is purchased, the price will increase to 1.2 ETH, and so on. At any point, if an NFT is sold to the pool, the price will decrease by 0.1 ETH.

**Exponential Bonding Curves**

**Exponential Bonding Curves**

With an exponential bonding curve, the price of an NFT is increased by a certain percentage (also called delta) every time an item is bought from the pool. Conversely, the price of the NFT is decreased equivalently every time an item is sold to the pool.

To calculate the equivalent decrease, convert the percentage to a decimal index (e.g. for 50%, the index would be 1.5) and divide the price by this number.

For example, a liquidity provider may create an NFT<>ETH pool with a Start Price of 2 ETH and a delta of 50%. Assuming they provide enough liquidity, the price of an NFT will increase to 2 + 50% = 3 ETH after one item is purchased from the pool. After a second item is purchased, the price will increase to 3 + 50% = 4.5 ETH, and so on. At any point, if an NFT is sold to the pool, the price will be divided by 1.5.

## Constant Product Bonding Curves (x * y = k)

With a constant product bonding curve, the price of an NFT is adjusted every time an item is bought from or sold to the pool, such that the product (k) of two virtual reserves (x and y) remains constant after every trade. These virtual reserves correspond to the number and value of NFTs the pool will buy or sell.

An additional concentration parameter allows liquidity providers to tighten or lossen constant product bonding curves.

## GDA Curve

The GDA curve is an implementation of the discrete gradual Dutch auction, where `spotPrice`

is the price of the currently "auctioned" NFT irrespective of time decay, and `delta`

stores the auction parameters `alpha`

and `lamba`

, as well as the timestamp of the last trade `prevTime`

.

In contrast to the specification linked above, the GDA curve calculates the price of each item as a function of the last. The net price exclusive of fees for a user to buy *x* NFTs is `inputValue_ = (spotPrice * (alpha^x - 1)) / ((alpha - 1) * 2^(lambda * timeElapsed))`

where `timeElapsed`

is the time elapsed since the last NFT was sold.

Conversely, the net price for a user to sell *x* NFTs is `outputValue_ = (spotPrice * 2^(lambda * timeElapsed) * (alpha^x - 1)) / (alpha^(x - 1) * (alpha - 1))`

where `timeElapsed`

is the time elapsed since the last NFT was sold.

Immediately after every trade, the pair state is updated:

Pair sells:

`spotPrice = (spotPrice * alpha^x) / 2^(lambda * timeElapsed)`

Pair buys:

`spotPrice = (spotPrice * 2^(lambda * timeElapsed)) / alpha^x`

In both cases, `delta`

is also updated to reflect the current `block.timestamp`

.

**Parsing ****delta**

The GDA curve stores three values in `delta`

. They are the auction parameters `alpha`

and `lamba`

, as well as the timestamp of the last trade `prevTime`

.

Since `delta`

is of type `uint128`

, this is achieved as follows:

The highest 40 bits represent

`alpha`

with 9 decimals of precision.The middle 40 bits represent

`lambda`

with 9 decimals of precision.The lowest 48 bits represent the timestamp of the last trade

`prevTime`

.

For a given auction, `alpha`

and `lambda`

are constants, while `prevTime`

(and thus `delta`

as a whole) must be updated immediately after every trade.

Last updated