Designing a DEX for community currencies (CC-to-CC)

Encointer Devs
#1

With the emergence of new communities on the Encointer Network, the question arises if these communities should have a UX-friendly, decentralized and trustless means to exchange their local currencies.

The following is strongly opinionated. So is the Encointer protocol itself. So let’s dive in and have a discussion :wink:

Should we, really?

First of all, we should remind ourselves of the following stated objectives of Encointer:

  • reduce inequality (locally and globally) by building equal opportunity into the monetary design
  • strengthen local economies by scoping currencies locally.

We have to consider that enabling local currency exchange weakens the support (AKA protection) of local economy. Consumers are no longer forced to spend their local currency locally, but can exchange it to consume products and services from another community. On the other hand, there is reason to assume global inequality could be reduced if we allow trade among communities based on a monetary system that gives every human equal opportunity. Imagine economically strong community A trading with economically weak community B. Very likely, wages would be higher in A than in B. Members of A would therefore buy products and services from community B due to favorable prices - instead of buying the same good in community A. Given symmetric rules (and the absence of debt with compound interest), this should lead to the currency B gaining value vs currency A, thereby increasing buying power of members of B to buy products and services from A, thereby reducing the inequality between A and B. Of course, this is an over-simplification, but it shows that we likely face a conflict of interests within our own goals. We may face the same tendencies to protectionism like nation states do - and we shouldn’t give in easily.

Of course, people will always find a way to exchange currencies if there is a buyer and a seller. But it does make a difference whether or not we design such a path into our protocol itself. If we do, the design should further our stated goals and possibly leave trade-offs to global protocol governance, not to individual communities to cherry-pick.

Use Cases

There are basically the following scenarios where someone would like to exchange their CC for another one:

  1. working (and attending cycles) in one place, live (spend CC) in another
    • Is only plausible among CCs at relatively close distance
    • A special case is a metropolitan area where more than one community may emerge for different neighborhoods of the same city – and likely with the same branding and exchange rate. This, however, could rather be tackled by a concept of merging communities or allowing sub-communities to reduce the perimeter of cycle gatherings.
  2. visiting another place
  3. moving to another place
  4. shopping online/remotely

Out of scope is speculation as CCs are not likely a suitable target for speculation due to their nature (demurrage, low liquidity, price discovery by issuing communities’ businesses, not speculators)

Characterizing Local Currencies

  • relatively low market cap due to small geographic scope and no incentive to speculate
  • low trading volume (in contrast to the financial sector, local currencies are bound to real economic activity)
  • more stable than most other crypto assets, but not necessarily pegged to fiat currencies

Market Designs

The title already implies the first non-obvious design decision: Should it really be a “market” which lets the exchange rate vary according to supply and demand? Or should we just consistently assume equal buying power per human and fix the exchange rate at ΠAB=CIIA/CIIB (CII=nominal community issued income)?

Let’s still think about a few possible market designs before we revisit the above:

Centralized exchange

Mentioned for the sake of completeness only. Based on the spirit of Encointer, we would not prevent anyone of operating a CEX, but we have no interest in it and want to offer decentralized/unstoppable alternatives.
It is highly unlikely that any third-party exchange will list Encointer CCs. If only for the technical challenges of supporting non-standard fixpoint balances and demurrage.

Onchain-Orderbook-Based DEX

In an orderbook-based DEX, there always needs to be a counterparty willing to exchange in the opposite direction for each trade.

Pros

  • transparent price discovery
  • asynchronous and trustless: buyer and seller can meet asynchronously and without the need to trust each other

Cons

  • spread and limited liquidity: CCs have a very limited geographic scope and therefore very low expected trading volume. This will lead to high spread which is bad for UX. It is not likely that market makers will be attracted to narrow the spread. Also due to demurrage which makes holding capital for that purpose expensive. So, we have to expect that more often than not, a user will not find a favovorable deal in an orderbook based dex as there is very little opportunity for market makers to keep the orderbook filled.

AMM DEX

In Defi, automatic market makers (AMM) are very popular DEX designs. Most prominently, the constant product (AKA xyk, i.e. uniswap-v2) AMM.
The advantage of an xyk AMM is that it is always ready to trade at an algorithmic price and will never run out of funds.

For CC, however, an xyk DEX is not very attractive, because:

  1. inferior capital efficiency: If you want to exchange dx amount of CCA for CCB, there will be a slippage of dx/x (where x is the liquidity at the DEXs disposal) , therefore, your liquidity pool needs ~100x the amount of dx if you accept no more than 1% slippage.
  2. Incentivizing liquidity providers (the ones with excess capital) goes against the spirit of a monetary system that aims at reducing inequality and has redistribution built in with demurrage and CII.
  3. Leaving capital idling around in a DEX goes against the spirit of a transactional currency that is supposed to be constantly circulating.
    While there are designs better suited for stablecoins like stableswap, these rely on a symmetry of trades in both directions to maintain a stable exchange rate. They are effectively limited and stop trading in one direction when the limit is reached (or at least lose their peg).

Reminting

This is AFAIK a novel concept. The trading pairs would need to give up some monetary sovereignty, but thanks to Encointer’s personhood-based money supply protocol, this may be acceptable as the rules are the same on both sides.

The protocol could allow a community to consider another one as trusted and allow re-minting upon spending at a fixed or dynamic rate:

  1. burn x CCA from sender account
  2. mint ΠABx CCB on behalf of receiving account

A key question is, of course, how we can define/derive ΠAB.

fees

There is no market operator nor liquidity provider that has to be incentivized for re-minting, so fees could be defined as low as pure spam prevention allows

UX

Re-Minting should be automatic, without the user even noticing. You just go to another town, scan invoice QR codes in CCB, and the app automatically remints in order to pay the invoice.
A confirmation screen shows the reminting rate and the amount to burn in CCA (the price, as percieved by the user)
This would be very similar to wise, which automatically converts your fiat behind the scenes

Macroeconomic effect

Allowing bidirectional re-minitng at i.e .1:1 actually makes two CC fungible, so all monetary analysis and governance must encompass both CC as an aggregate. Imagine one CC changing their CII while the other doesn’t. Or imagine different demurrage rates.

Therefore, a re-minting contract could be brittle: It gets canceled whenever one of the communities changes one of their monetary parameters. A new re-minting would then have to be re-established based on the new setups
Also, re-minting widens the scope of economic circles. While this can be a good thing to keep the CC flowing, it also weakens the «local loyalty» aspect, the wider the re-minting scope goes. Imagine all CCs worldwide would mutually enable re-minting at a fixed 1:1. There would be no local-community currency aspect anymore to Encointer.

Imbalance Considerations

If people from community A visit community B and spend their CCA without the store even noticing a difference, that may be very convenient from a UX perspective, but also raise concerns, like “they come to us eating for free”. Clearly, it’s not for free, because CCA has the same rules as CCB and money is issued as CII. Still, a systematic asymmetry may cause resentment.

Therefore, this imbalance should be transparently measured and there should be forces that tend to restore the balance.

The following safety measures could be put in place:

  • time-limiting reminting rate: only allow a certain volume of reminting per day.
  • supply-limiting reminting: only allow a certain fraction of own supply to originate from reminting a cerain other CC

Hard limits are very bad for UX, though. Imagine you’re used to pay in a store in the neighboring city and it used to work previously, but today it doesn’t because the limit has been reached.

Instead of hard limits, we could install bonding curves that just make the reminting rate less attractive if they are unidirectional. The “exchange rate” would therefore deviate from 1:1 dynamically, based on the asymmetry of reminting. Such a market would be very similar to AMMs, but without the need for liqidity pools,

Web-of-trust

Economic activity between communities implies trust (not only in the economy, but also that the community follows the rules of the personhood protocol). This information can also be leveraged for weighting votes for global decision making among all communities. (See also How can we make onboarding of new communities permissionless?)

But how do we quantify meaningful economic exchange in our setup? How do we separate exchange rate from trust indicator? A community may have a weak economy but still enjoy a lot of trust concerning the personhood protocol.

The need for a WoT to decentralize and democratize governance clearly is an argument in favor of establishing a DEX

Discussion

Before we continue with the design, we should decide on the fundamental principle. There are tradeoffs in every case.

Demurrage Reduzieren
#2

Good article on the “should we” question. Network effects are necessary for (complementary) currencies to thrive:

#3

Very interesting post, here some of my thoughts

TL;DR: This is a very interesting topic, especially the reminting approach, with very interesting challenges. But IMO we should try not to solve problems that we dont have (yet) and focus on more important things like creating a trust protocol between communites, which will also lay a foundation for the DEX. And as soon as we decide to kick off the DEX, I would love to be part of it.

  • How can you assume the absence of dept with compound interest? It is the core of our worldwide economic system.

  • I really like the reminting approach.

  • How to define ΠAB?

    • We need to consider demurrage, issuance and buying power
    • Let’s say we have LEU with 44 LEU per cycle and a buying power of 1 LEU = 1 CHF
    • And we have BAER with 22 BAER per cycle and a buying power of 1 BAER = 0.5 CHF
    • And equal demurrage

    Then to me it is already not obvious what we want:

      - 1 LEU = 2 BAER means that you have the same buying power per token
  - 1 LEU = 1 BAER means that you have the same buying power per issued reward (you get 2 BAER for your LEU due to higher buying power, but as the BEAR community only gets half the issuance, you also only get half)
  - 1 LEU = 0.5 BAER means that you have the same nominal income per cycle

  • Reminting inflation issue → If a lot of ccA is swaped into ccB, there will be inflation in ccB because the money supply changes

    • This should in turn effect the exchange rate somehow?
    • Could we view the total issuance of both communities as the liquidity pools and use it to determine (part of) the exchange rate?
    • It would be in the opposite direction as traditional DEXs though: The more liquidity, the higher the price, because this means that everybody wants it.

  • What problem are we trying to solve with the DEX?

    • We should try not to make too many assumptions, then overengineer a solution and then realise that the reality is different than we assumed.
    • Most likely scenario for DEX: Neighboring communities want to be able to buy stuff in each others acceptance points.
      → So what might happen: Assuming two communities in Zürich K4 and K5, with currencies LEU4 and LEU5. Shops in K5 will accept LEU4, maybe charging different prices and like implicitly this acting as an exchange: Problem solved and we do not have to implement anything.

  • What is in my opinion a very important thing to focus is a trust protocol between communities, we will need this for as a basis for so many things as the DEX, global democracy, permissionless community onboarding, resilience against location squatting and bot communities…

#4

We currently have a master student working on this topic with promising results. stay tuned! We will publish his report in a couple of weeks

2 Likes