---
# System prepended metadata

title: PMTP - Pricing

---

# PMTP - Pricing

## PMTP Basics
Sifchain’s swap formula:

$$y(x)=\frac{xYX}{(x+X)^2}$$

Is modified to accomodate weighting of the X and Y tokens in the pool as follows:

$$y(x)=Y(1-(\frac{X}{x+X})^\frac{w_x}{w_y}) (1-\frac{x}{x+X})$$
subject to the constraint $$  w_x + w_y = 1$$

Thus giving the PMTP mechanism. 
Here, $w_x$ and $w_y$ control the weight that is assumed for each token in the pool, removing the implicit pre-existing assumption that equal quantities in the pool result in equal prices (equivalently, the special case where $w_x=w_y=1/2$). 


## Track Purchasing Power Multiplier

Goal: On a per block basis, we need to increase the purchasing power multiplier $r_{running}$ so that it fits the constraints set by governance parameters. We outline this in the subsequent steps and have a numerical computation example in the spreadsheet in Appendix 1.


### Variable Definitions


| Name | Description |
|----|----|
| $h$ | First block of a given policy period|
| $h_F$ | Last block of a given policy period|
| $h_{current}$ | Current block |
| $epoch\_length$ | Number of blocks in an epoch |
| $number\_of\_epochs$ | Number of epochs in the policy |
| $r_{gov}$ | Per-epoch (approximately daily) rate of purchasing power increase voted in by governance |
| $final\_compounded\_rate$ | Overall rate of increase over the policy length|
| $r_{block}$ | Incremental increase on a per block basis to reach ${final\_compounded\_rate}$ |
| $r_{running}$ | The purchasing power multiplier rate at a given block |
| $y_o(x)$ | $y$ amount resulting from the swap at the starting time. Calculate the value of y that a user would get if there was no purchasing power increase. |
| $w_x$ | Exponent weight for Rowan  |
| $w_y$ | Exponent weight for non-Rowan token  |

#### Additional Details on these Variables:
The total duration of a policy is the span of blocks between $h$ and $h_F$ 

The duration of the policy can be divided into epochs which are sections of blocks of equal length.  An obvious option for epochs would be one epoch per day.  Of course, this would need to be measured against an average block duration as not all blocks have equal duration.  For example, if blocks were approximately 5 seconds long then an epoch would be 17280 blocks, but because the blocks were not exactly 5 seconds long the epochs would not be exactly 1 day long. 

The epoch are a user experience affordance to make governance reasoning about the effects of PMTP in intuitive units.

### Use $r_{gov}$ to Derive $r_{block}$

Let $r_{gov}$ be the per-epoch rate increase voted in by governance.  Each epoch, the purchasing power of Rowan (treated as the $x$ token in the above formulas) should increase by this percentage.

Let ${final\_compounded\_rate}$ = $(1 + r_{gov}) ^ {number\_of\_epochs} - 1$.  Rowan should increase by this percentage between $h$ and $h_F$ (ie. across all epochs). 

Now we compute $r_{block}$:
$$r_{block} = (1 + r_{gov}) ^ {{number\_of\_epochs}/{h_F}} - 1$$  
$r_{block}$ function derivation can be found in Appendix 1 at the end of this document

** From this point onward we only focus on blocks. Given a block rate calculated at the initial governance decision, there is no further role for the epoch rate or to keep track of epochs. The block rate is not recalculated again after the initial goverance decision, so a token against which Rowan is losing value in the original pricing $y_o$ will not reach the implied governance target. 

### Use $r_{block}$ to Derive $r_{running}$

Let $r_{running}$ be the running rate that is compounded over time (at any particular block).  Similarly

$$r_{running} = (1+r_{block})^i-1$$
where 
$$ i = {h_{current}} - h $$


## Final Computations

Now that we know the purchasing power increases by $r_{running}$ for any given block, we can then use it to calculate $y(x)$ for a given swap as it occurs.

Step 1: Calculate the value of y that a user *would get* if there was no purchasing power increase.  We can call this value $y_o$.

$$y_o(x) = f(X,Y,x) = Y(1-(\frac{X}{x+X})^\frac{w_x}{w_y}) (1-\frac{x}{x+X})$$

We can even simplify this (for the policy start time) by just using the old swap formula instead.

$$y_o(x) = f(X,Y,x) =\frac{xYX}{(x+X)^2}$$

The two formulas are identical when $w_x$ = $w_y$ = $0.50$ which is the case for this particular step.

Step 2: Now that we have calculated $y_o$ we can use it to determine the value a user *should* get with the purchasing power increase.  This value is y(x) and is the output of our swap function.

$$ y(x) = y_o(1+r_{running})$$


### Addendum
The weights are no longer as important for our calculations given this structure.  If we choose to share the weights:
#### Deriving the weights $w_x$ and $w_y$:
Use the liquidity depth values $X$ and $Y$ at that given time, take the $x$ swap input to get the output $y$ as above, and calculate:

$$log_ba$$
where 
$$a = 1-\frac{y}{Y(1-\frac{X}{x+X})} = 1-\frac{y(x+X)}{YX} $$

$$b = \frac{X}{x+X}$$

From this we can get the following weights for each block: $$w_x = \frac{log_ba}{1+log_ba}$$  $$w_y = 1 - w_x$$


## Appendix 
#### Appendix 1: Reference Spreadsheet
Shows a numerical example of using $r_{gov}$ to derive $r_{block}$, then using $r_{block}$ to derive $r_{running}$, computing $y_o$ from $r_{running}$, and finally calculating the weights $w_x$ and $w_y$. Random number generation was used for the inputs x, X, and Y. There are two examples: the first with one swap per block, and the second with zero, one, and or many swaps per block.
https://docs.google.com/spreadsheets/d/1jRHXJDZOfc-u_VWO8SCILPRF34JIEI6zDjRwcqmxAm8/edit#gid=1690856320
#### Appendix 2: Deriving $r_{block}$
$$ (1+r_{block})^{h_F} = (1+final\_compounded\_rate) = (1 + r_{gov})^{number\_of\_epochs}$$

$$ 1+r_{block} = (1 + r_{gov})^{{number\_of\_epochs}/{h_F}}$$

$$ r_{block} = (1 + r_{gov})^{{number\_of\_epochs}/{h_F}}-1$$


## Open Questions:
1. Does the section below make sense or do you need a copy of the inverted $r_a$?

`"Note: The examples in the spreadsheet assume a user is swapping Rowan for some TKN, so it is always showing a purchasing power increase. To make the above logic work in the opposite way, where a user is swapping TKN for Rowan, $r_a`
