Consideration on AMM parameters

[ignazio-bovo]

AMM pricing formula:

price = a * x + b

Considerations

• x = AMM provided liquidity: i.e. only the token minted through the AMM will be taken into account for price computation). This will make the semantics for b to be "initial unit price". I think that this is way more manageable than using the token_total_supply from a runtime POV.
• There are no trivial consraints for a. Can a be zero? I don't think so, otherwise you should issue a sale usability
• Can b be zero? I think it should if we allow a sale to have sale_price = 0.
• Dangers of having a,b too high: Numeric overflow in price computation. But the eval function will protect against this.
• Dangers of having a,b too low: Supply dilution (which can be view as vulnerability ) thus they should be set by the governance
• a,b should be thought as on a $10^{-10}$ scale since we are quoting the price in HAPI

[bedeho]

Can a be zero? I don't think so, otherwise you should issue a sale usability

I don't see why not really, some may even want it, but more imporantly, there are lots of edge cases of "problems" with any values, see response here: #4151 (comment)

Can b be zero? I think it should if we allow a sale to have sale_price = 0.

I think this value also should pretty much be unconstrained.

Dangers of having a,b too high: Numeric overflow in price computation. But the eval function will protect against this.

What is eval function?

[ignazio-bovo]

• a should have a min cap to avoid dilution by issuer
• a should not necessarely have a max cap, as overflow checks are in place

[ignazio-bovo]

Runtime expects the extrinsic caller to specify bot parameter a and b used for the amm price point computation:

joystream/runtime-modules/project-token/src/types.rs

Lines 575 to 576 in 564e4e0

	pub struct AmmParams {
	/// Slope parameter : a

joystream/runtime-modules/content/src/lib.rs

Lines 3721 to 3722 in 564e4e0

	pub fn activate_amm(
	origin,

During our design meetings however, we established that however there should have been a default value.

This can be enforced either:
A. by Atlas (front end)
B. by runtime by allowing the AmmParams to take optional a,b parameters and setting the default ones (above) in case they are null

EDIT: One pro of option A (instead of having the value hardcoded in the runtime code in B) is that if the value doesn't work we re-deploy atlas instead of performing a runtime upgrade. Another pro is that we can fetch JOY price if needed

@bedeho

[ignazio-bovo]

Goal: emulate Deso curve for CRT circulation ~ CRT USD-price profile:

Deso is using the following formulation for its AMM.
(Actually their documentation simplifies the formula see here)

crt_token_price_usd = .003 * crt_circulation^2 * deso_price_usd

namely a y = a * x^2 + b (with b = 0) model as opposed to our linear y = A * x + B model
In the runtime the amount A / hapi_price_usd is called slope and B / hapi_price_usd is called intercept. (Since JOY balances are always HAPI denominated in the runtime).
If we want to find A that best approximate the the curve presented by deso when the circulation is small we can use (weighted) least square regression, in google sheet (the estimate is obtained from the X and Y columns that are resp Coin circulation * weights and Coin usd price * weights):

This gives the value for A = 0.45.. from this the front end can suggest the default slope value A / hapi_price_usd and for intercept Atlas can directly prompt the user for the desired initial price or simply set 0
Using our formula now gives the following curve profile:

Notice how the values for CRT circulation ~ CRT USD-price are similar to the ones provided by deso when the circulating amount is small.
Also the value for the intercept is slope * 2 (just to have values on the same scale)

To summarise

1. Atlas will suggest (display to the user) default values A/joy_price_usd with joy price usd is fetched live and then as intercept will suggest the user to input either his desired initial price (like he would do in a normal sale) or 0
2. Atlas will put in the activate_amm transaction AmmParams: slope = A/hapi_price_usd = 10billions * A/joy_price_usd and intercept = user_provided_slope * 10billions

Given the above observation slope: u128, intercept: u128 as runtime types