# PMTP Mechanics

Protocol Monetary Trade Policy (PMTP) enables monetary policy for Rowan enforced by Sifchain’s liquidity.

Problem Statement:
- Premise: Through inflation, Rowan holders use a standard tool in the cryptocurrency monetary policy toolkit.
- Problem: Rowan holders seek alternative monetary policy options.
- Solution: Protocol Monetary Trade Policy is a viable alternative, using Sifchain’s liquidity to influence trade on its DEX.

This “Protocol Monetary Trade Policy” feature opens a new space in cryptoeconomic design. We’re naming our first implementation of a feature of this kind after the category for now. Hopefully, the name sparks additional creativity in the ideation of future extensions or alternative methods of execution.

## Monetary Policy and Trade Policy

Fiat currency managers use monetary policy to influence the interest rates for short term borrowing or the supply of money. They use trade policy to influence the rate at which goods in their sovereign domain are exchanged.

The PMTP feature allows Sifchain governance to combine the two objectives by influencing exchange rates amongst assets (trade policy) to influence currency-wide purchasing power (monetary policy).

Most cryptocurrencies influence monetary policy through inflationary rewards: they increase the quantity of tokens a token holder has. Protocol Monetary Trade Policy allows Sifchain governance to instead influence the ratio a currency holder uses to trade their existing quantity of tokens for others.

## 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

#### Chain State
The chain state is the set of information from the consensus protocol. This is exogenous to the model of the liquidity pool in that blocks are validated without feedback loop that prevents the operation of the protocol. The variables specified below are the state of the chain necessary to be read by the monetary policy.

| Variable Name | Descriptive Name | Description | Symbol |
|----|----|----|----|
| start_block_height | Start Block Height| First block of a given policy period| $h_S$ |
| final_block_height| Final Block Height | Last block of a given policy period| $h_F$ |
| current_block | Current Block | Current block | $h$ |

#### Governance Decision
The governance decision is a policy input message that broadcasts a specified $r_{gov}$ for a specified length of time $l_{policy}$, with a computable $r_{final}$ as the intentional end-state of the policy at the end of its effective life at $h_f$.

| Variable Name | Descriptive Name | Description | Symbol | Domain|
|----|----|----|----|----|
| epoch_length | Epoch Length | Number of blocks in an epoch | $l_{epoch}$ | $\mathcal{I} \geq 0$ |
| policy_length_in_epochs | Policy Length in Epochs | Number of epochs in the policy; the specific governance policy period resulting from one particular vote | $l_{policy}$ |$\mathcal{I} \geq 0$ |
| gov_rate | Governance Rate | Per-epoch (approximately daily) rate of purchasing power increase voted in by governance | $r_{gov}$ | [-1,1]|
| final_compounded_rate | Final Compounded Rate | Overall rate of increase over the policy length| $r_{final}$|[-1,1]|

**Assumption: epoch_length is a governance design, where there is the need for the consensus protocol to execute an epoch module.**

**final_compounded_rate is a metric of gov_rate and policy_length_in_epochs**

#### Liquidity Pool Module State
Receives PMTP policy through governance decision, updating its parameters for $r_{gov}$ and $l_{policy}$. Combining this policy with the production of blocks from the protocol, allows for the computation of $r_{block}$ and $r_{running}$.

| Variable Name | Descriptive Name | Description | Symbol |
|----|----|----|----|
| block_rate | Block Rate| Incremental increase on a per block basis to reach ${final\_compounded\_rate}$ | $r_{block}$|
| running_rate | Running Rate| The purchasing power multiplier rate at a given block | $r_{running}$ |
| $y_o$ | $y_o$ | Rowan ($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. | $y_o(x)$ |
| $x_o$ | $x_o$ | Non-Rowan ($x$) 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. | $x_o(y)$ |

#### Additional Details on these Variables:
The total duration of a policy is the span of blocks between $h_S$ 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 epochs are a user experience affordance to put 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 $y$ token in Variable Definitions above) should increase by this percentage.

Let the final compounded rate, ${r_{final}}$, be defined as follows:
$${r_{final}} = (1 + r_{gov}) ^ {l_{policy}} - 1$$
Rowan should increase by this percentage between $h$ and $h_F$ (ie. across all epochs).

Now we compute $r_{block}$, which is the incremental increase on a per block basis (to reach $final\_compounded\_rate$):
$$r_{block} = (1 + r_{gov}) ^ {l_{policy}/({h_F-h_S})} - 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 - h_S $$

**Note:** At the first block of the policy, $r_{running}$ can be calculated ahead of time for every block in the policy, particularly if it helps make things easier for writing the code.

## Computations

### Rowan to TKN Swaps
Sifchain’s liquidity pool code sets a price ratio for assets in its two-sided liquidity pools. The formula for this price ratio for a given swap is the following, and we can set it to $x_o$ as the pre-PMTP output of the swap:

$$x_o(y)= f(X,Y,y) = \frac{yXY}{(y+Y)^2}$$

Please see [AMM Specification](https://hackmd.io/6VK2LSYjRTyeNCoHpVt2hg) for more details including variable definitions and the derivation of this formula.

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

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

Mathematically, this multiplier to derive $x(y)$ is a local linear approximation.

### TKN to Rowan Swaps

Calculate $y_o$:

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

Now that we have calculated $y_o(x)$ 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) = \frac{y_o(x)}{1+r_{running}}$$

## No policy condition
A null PMTP policy would be consist of a:
1. $l_{policy} = 0$,
2. $l_{epoch} = 0$, and
3. $r_{gov} = 0$, where previous $r_{final}=0$

A policy with $r_{gov} = 0$ with a nonzero length would be an intentional policy in effect for its policy length. There would be cases to pledge an $r_{gov} = 0$ for some period of time.

## Sign Convention on PMTP Policy
An $r_{gov}$ with positive rate, where $0<r_{gov}\leq1$, then a trade of RWN to TKN will result in a greater return of TKN in the amount of $(1+r_{running})$. This is the intended direction of PMTP to 'increase the purchasing power of Rowan'.

An $r_{gov}$ with negative rate, where $-1<r_{gov}\leq 0$, then a trade of TKN to RWN will result in a greater return of RWN in the amount of $(1+r_{running})$. This is the opposite direction of PMTP to 'increase the purchasing power of Rowan'. However, a 'negative' policy could used to drive the relative weight of the liquidty pools in the opposite direction.

## Appendix

#### Appendix 1: Deriving $r_{block}$
$$ (1+r_{block})^{h_F-h_S} = 1+r_{final} = (1 + r_{gov})^{l_{policy}}$$

$$ 1+r_{block} = (1 + r_{gov})^{{l_{policy}}/{(h_F-h_S)}}$$

$$ r_{block} = (1 + r_{gov})^{{l_{policy}}/{(h_F-h_S)}}-1$$

#### Appendix 2: Reference Spreadsheet for Rowan to TKN Swaps
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 3: Reference Spreadsheet for Swaps in Both Directions
The same per-block calculations can be used from the Rowan to TKN calculations, so $r_{block}$ and $r_{running}$ will be the same as in the other direction. We solve for $y_x$ as above in the case of TKN to Rowan swaps, and the spreadsheet highlights the different calculations for the PMTP-modified $x_y$ and $y_x$ based on the direction of the swap.
https://docs.google.com/spreadsheets/d/1jRHXJDZOfc-u_VWO8SCILPRF34JIEI6zDjRwcqmxAm8/edit#gid=1183483560

## MVP Goals
Establish a PMTP governance framework for managing monetary policy through time-based parameter selection over trade policy.

## Future Goals
Extend the PMTP governance surface to include parameter selection for trade policy based on trading activity

## Further Reading:
https://www.nber.org/system/files/working_papers/w18092/w18092.pdf
https://arxiv.org/pdf/1905.11905.pdf
https://www.imf.org/external/pubs/ft/wp/2008/wp08132.pdf

<!-- ---
Breakdown of the variable table in the begining of the document to model the processes affecting a liquidity pool:
-->
<!-- <!-- <!--
<!-- ## Chain State
The chain state is the set of information from the consensus protocol. This is exogenous to the model of the liquidity pool in that blocks are validated without feedback loop that prevents the operation of the protocol. The variables specified below are the state of the chain necessary to be read by the monetary policy.

| Variable Name | Descriptive Name | Description | Symbol |
|----|----|----|----|
| start_block_height | Start Block Height| First block of a given policy period| $h_S$ |
| final_block_height| Final Block Height | Last block of a given policy period| $h_f$ |
| current_block | Current Block | Current block | $h$ | -->

<!-- ## Governance Decision
The governance decision is a policy input message that broadcasts a specified $r_{gov}$ for a specified length of time $l_{policy}$, with a computable $r_{final}$ as the intentional end-state of the policy at the end of its effective life at $h_f$.

| Variable Name | Descriptive Name | Description | Symbol |
|----|----|----|----|
| epoch_length | Epoch Length | Number of blocks in an epoch | $l_{epoch}$ |
| policy_length_in_epochs | Policy Length in Epochs | Number of epochs in the policy | $l_{policy}$ |
| gov_rate | Governance Rate | Per-epoch (approximately daily) rate of purchasing power increase voted in by governance | $r_{gov}$ |
| final_compounded_rate | Final Compounded Rate | Overall rate of increase over the policy length| $r_{final}$|

**Assumption: epoch_length is a governance design, where there is the need for the consensus protocol to execute an epoch module.**

**final_compounded_rate is a metric of gov_rate and policy_length_in_epochs** -->

<!-- ### Liquidity Pool Module State
Receives PMTP policy through governance decision, updating its parameters for $r_{gov}$ and $l_{policy}$. Combining this policy with the production of blocks from the protocol, allows for the computation of $r_{block}$ and $r_{running}$.

| Variable Name | Descriptive Name | Description | Symbol |
|----|----|----|----|
| block_rate | Block Rate| Incremental increase on a per block basis to reach ${final\_compounded\_rate}$ | $r_{block}$|
| running_rate | Running Rate| The purchasing power multiplier rate at a given block | $r_{running}$ |
| y_o | y_o | $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. | $y_o(x)$ |
| x_o | x_o | $x$ 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. | $x_o(y)$ |
-->