Some notes

Notation

We note $\mathcal{C}$ the set of Encointer communities (and $a\in A$ when $a$ is a user from $A$).

For an Encointer community $A \in \mathcal{C}$, we note:

• $\tau_A$ the name for its token, and for $x \in \mathbb{R}_+$ we note $x\tau_a$ for $x$ tokens

• $d_A \in [0,1[$ its demurrage rate, i.e. the proportion of the supply burnt at each cycle (constant)

• $U_A$ the UBI, i.e. the number of tokens $\tau_A$ received by each participant at the beginning of a cycle (constant)

• $N_A$ the number of participants (non constant)

• $S_A$ the supply of tokens $\tau_A$ (non constant)

For an AMM between a pair of communities $(A, B) \in \mathcal{C}²$, we note:

• $r_A^{A,B}$ the reserve of tokens $\tau_A$ in the AMM. When there is no ambiguity on the pair of tokens, we simply write $r_A$.

• $\tau_{AB} = \tau_{BA}$ the minted token of the AMM, that represents shares in the pool and that is minted upon liquidity providing

We write:

• LPer for liquidity provider
• LPing for liquidity providing

Simplified problem

Let $(A, B) \in \mathcal{C}²$ two communities. We can assume that $A$ is honest. We also assume:

• $d_A = d_B$
• $U_A = U_B$ (without loss of generality)

We want to build an AMM-like DEX to make it possible to swap $\tau_A$ for $\tau_B$ and vice versa.

Difficulties

LPers must provide both tokens

Typically, LPing operations have no effect on the swapping rate of AMMs. The ratio $r_A / r_B$ is an invariant for LPing operations. This implies that LPing must be balanced, and that LPers deposit both $\tau_A$ and $\tau_B$.

However, in our case, it might be hard for a user to acquire both tokens, and be able to provide liquidity. It is hard to predict to which extent it is feasible. We can imagine a business from $A$ that accepts $\tau_B$. This would allow the business to build capital in both tokens and then to be able to provide liquidity.

Paired liquidity providing

Or, the design allows users to associate in order to provide liquidity. If $a \in A$ wants to provide liquidity, they must find a user $b \in B$ who agrees to do it with them (or more generally, a set of users from $A$ agrees with a set of users from $B$). They both agree on the amount they want to provide and lock their respective tokens together (with regard to the proportion required by the AMM). Each of them receive the same amount of $\tau_{AB}$ that can be redeemed for $\tau_A$ and $\tau_B$ as it is done in a classic AMM.

We can also have the intuition that this form of paired LP encompasses the idea of trust between communities because providing liquidity for a user $a \in A$ is similar to trading some of its $\tau_A$ for $\tau_B$. We can also imagine other ways of implementing paired LP, with more or less dependents providers.

Lack of liquidity

Considering the special case of a local currency, with demurrage and ubi, it is not clear if we would have enough liquidity in the AMMs.

In this case, one solution could be to apply a multiplication factor $\rho \in [1,+\infty[$ to the liquidity provided (contrary to classic AMMs problems, we have the ability to mint new tokens). When a LPer (or paired LPers) provides $x_A \tau_A$ and $x_B \tau_B$ to the AMM, $(\rho -1)x_A \tau_A$ and $(\rho-1)x_B \tau_B$ are minted and added to the AMM. The total operation thus results in an increase of reserve of $\rho x_A \tau_A$ and $\rho x_B \tau_B$. When a LPer redeems its minted tokens, the inverse multiplication factor is applied to the funds they get back.

A limit on this form of credit line between communities can be decided by on-chain governance and agreement.

Byzantine community and reward

Suppose $a \in A$ wants to escape demurrage/get rewards without risks. They create a fake community $B$ and start providing liquidity for the AMM $\tau_A, \tau_B$. $a$ is the only one who can paired LP because they are the only one who own $\tau_B$ tokens. Thus, $a$ escape demurrage/get rewards freely.

Rewards depends on amount of trades

It is intuitive that the advantages LPers get, somehow depends on their utility, for example the amount of trades on the AMM.

Instead of a fixed demurrage reduction, we can give a reward to each LPer at the end of each cycle, that depends on:

• the amount of trades issued during the cycle
• the amount of liquidity provided compared to total liquidity (as in classic AMMs)

This reward can come from either swap fees paid by the users, or by freshly minted tokens (which is equivalent to a demurrage discount).

Still, we need a way to distinguish real swaps from swaps made only to increase rewards: These "fake" swaps can take two forms:

• numerous swaps that cancel each other
• swaps with byzantine community controlled by a LPer

To prevent this, we can think of several mechanisms:

• use PoP to not take into account swaps by LPers, and use "quadratic voting"
• sum the value of swaps by each users on a cycle, to not take into account swaps that cancel each other from a same user
• charge fees on swaps to make it non profitable for LPers to issue swaps only to increase rewards (for example fees increase with number of swap for 1 user)

Rewards depends on average/last slippage

High slippage means we need more liquidity. We can increase rewards for LPers who provides liquidity for pair where we observe high slippage. This would make LPs on this pair more attractive.

Example of rewards function

(The following is only an example and it may not be optimal).

It may be better to not totally compensate demurrage (to keep the supply controlled). Let $x \in \mathbb{R} _+$ be the score of a pair (a variable that encompasses the utility of liquidity, depending on amount of trades, slippage etc). The reward could be calculated for each cycle as $f(x) = \frac{d}{dx+1}$. $f$ is the demurrage that is applied to the liquidity. Note that $f$ is strictly decreasing, continuous and we have $f\in]0, d]$.

• worse case: $x=0$ and $f(x) = d$ (normal demurrage)
• best case: $x \rightarrow \infty$ and $f(x) \rightarrow 0$ (no demurrage)

Score computing

We can separate rewards for $\tau_A$ and for $\tau_B$. We thus compute two scores, resp $x_A$ and $x_B$.

We can imagine something looking like $x_A = \frac{ \sum_{i\in \mathcal{U}} \sqrt{T_A,i} }{\sqrt{S_A}}$, with $T_A,i$ the summed amount (over a cycle) of $\tau_A$ bought by user $i$, and $\mathcal{U}$ the set of users. We then have $f(x_A)$ to apply to $\tau_A$ liquidity, and $f(x_B)$ to apply to $\tau_B$.

Even with summed transactions on each cycle, it is still possible to make a big transaction in one direction, and revert it (with the opposite swap) on the next cycle, to maximize $T_{A,i}$. However, slippage limits this behavior.