A Local Exchange Trading System On Top Of Ergo

A local exchange trading system (LETS) is a local mutual credit association which members are allowed to create common
credit money individually, with all the deals in the system written into a common ledger.
As an example, assume that Alice with zero balance is willing to buy a liter of raw milk from Bob.
First, they agree on a price, for example, assume that the price is about 2 Euro (as Alice and Bob
are living in Ireland). After the deal being written into a ledger, Alice's balance becomes -2 (minus
two) Euro, and Bob's balance becomes 2 Euro. Then Bob may spend his 2 Euro, for example, on
home-made beer from Charlie. Often, such systems impose limits on negative balances, and sometimes
even on positive ones, in order to promote exchange in the community.

Historically, such systems become popular during crisis times. The first system was established by Michael Linton in
a Canadian town stuck in depression back in 1981. Local exchange trading systems were extremely popular during
1998-2002 Argentine Great Depression. Most LETS groups range from 50 to 250 members, with paper-based credit notes and
ledger maintained by a core committee. However, paper-based LETS currencies have shown some problems, such as
counterfeit notes, possible rogue behavior of system managers, and so on. Therefore, blockchain-based LETS could be superior
to the old systems. More information on LETS could be found in
"The Ecology of Money" book (by Richard Douthwaite) and
Wikipedia.

In this article we show how LETS could be implemented on top of Ergo. To the best of our knowledge, this is
the first implementation of such kind of community currency on top of a blockchain.
Our reference implementation
is simple and consists of two contracts, namely, a management contract and an exchange contract.
We skip Ergo preliminaries, so please read
the ICO article and
ErgoScript tutorials(basic and
advanced) for starters.
Nevertheless, we are going to introduce a couple of new terms in following sentences.
If a token is issued with amount equal to one, we call it the singleton token. Similarly,
a box which contains the singleton token is called the singleton box.

The management contract is controlling a singleton box which holds members of the LETS system.
The contract enables the adding of new members at the pace of one member per one transaction. The box
is not storing members, but only a small digest of authenticated data structure built on top of
the members' directory. A member is associated with a singleton token issued in a transaction which
is adding the member to the directory. The transaction creates a new member's box which contains
the member's singleton token. The member's box is protected by the exchange contract. Also, the newly
created member's box has initial balance written down into the R4 register, and the balance is
equal to zero in our example. The transaction creating a new member must provide a proof of correctness for
directory transformation.

The management contract box is controlled usually by a committee, and the committee could evolve over time. To support
that, we allow committee logic to reside in the register R5.
For example, assume that a new committee member has been added along with a new LETS member,
the input management contract box is requiring 2-out-of-3 signatures, and the output box requires 3-out-of-4 signatures.
In this case contents of the R5 register in the input and the output box would differ.

The management contract code in ErgoScript with comments is provided below. Please note that
"userContractHash" is about exchange contract hash.

    val selfOut = OUTPUTS(0)
 
    // Management script
    val managementScript = selfOut.R5[SigmaProp].get
 
    // The management script template is replicating self, and management script is satisfied
    val scriptCorrect = (selfOut.propositionBytes == SELF.propositionBytes) && managementScript
 
    // A spending transaction is creating boxes for directory, user, fee.
    val outsSizeCorrect = OUTPUTS.size == 3
 
    // Checks that the management label token is replicating self
    val outTokenCorrect = (selfOut.tokens.size == 1) && (selfOut.tokens(0)._1 == letsToken)
 
    // Checks that new token is issued, and its amount is correct
    // OUTPUTS(0) tokens already checked via outtokenCorrect
    val issuedTokenId = INPUTS(0).id
    val userOut = OUTPUTS(1)
    val correctTokenAmounts =
      (userOut.tokens.size == 1 &&
        userOut.tokens(0)._1 == issuedTokenId &&
        userOut.tokens(0)._2 == 1 &&
        OUTPUTS(2).tokens.size == 0 &&
        outTokenCorrect)
 
    // Checks that the new user has been created with the zero balance
    val zeroUserBalance  = userOut.R4[Long].get == 0
 
    val properUserScript = blake2b256(userOut.propositionBytes) == userContractHash
 
    // Checks that the new token identifier has been added to the directory
    val selfTree = SELF.R4[AvlTree].get
    val toAdd: Coll[(Coll[Byte], Coll[Byte])] = Coll((issuedTokenId, Coll[Byte]()))
    val proof = getVar[Coll[Byte]](1).get
    val modifiedTree = selfTree.insert(toAdd, proof).get
    val expectedTree = selfOut.R4[AvlTree].get
    val treeCorrect = modifiedTree == expectedTree
 
    correctTokenAmounts && scriptCorrect && treeCorrect && zeroUserBalance && properUserScript       
    correctTokenAmounts && scriptCorrect && treeCorrect && zeroUserBalance && properUserScript correctTokenAmounts && scriptCorrect && treeCorrect && zeroUserBalance && properUserScript      

The exchange contract script is fairly straightforward and provided below along with comments describing its logic. In the
contract, it is assumed that a spending transaction for an exchange contract box is receiving at least two inputs,
and the first two inputs should be protected by the exchange contract script and contain LETS member tokens. To check
that singleton member tokens in the inputs do indeed belong to the LETS system, a spending transaction provides the management
contract box as the first read-only data input, and also should provide a proof that the member tokens do belong to
the directory authenticated via the R4 register of the management contract box. "letsToken" in the script is about
the singleton token of the management box.

  // Minimal balance allowed for LETS trader
  val minBalance = -20000

  val lookupProof = getVar[Coll[Byte]](1).get

  // The read-only box which contains directory of LETS members
  val treeHolderBox = CONTEXT.dataInputs(0)
  val properLetsToken = treeHolderBox.tokens(0)._1 == letsToken
  val membersTree = treeHolderBox.R4[AvlTree].get

  // A spending transaction is taking two boxes of LETS members willing to make a deal,
  // and returns boxes with modified balances.
  val participant0 = INPUTS(0)
  val participant1 = INPUTS(1)
  val participantOut0 = OUTPUTS(0)
  val participantOut1 = OUTPUTS(1)

  //Check that members do indeed belong to the LETS
  val token0 = participant0.tokens(0)._1
  val token1 = participant1.tokens(0)._1
  val memberTokens = Coll(token0, token1)
  val membersExist = membersTree.getMany(memberTokens, lookupProof).forall({ (o: Option[Coll[Byte]]) => o.isDefined })

  // Check that LETS member balance changes during the deal are correct
  val initialBalance0 = participant0.R4[Long].get
  val initialBalance1 = participant1.R4[Long].get
  val finishBalance0  = participantOut0.R4[Long].get
  val finishBalance1  = participantOut1.R4[Long].get
  val diff0 = finishBalance0 - initialBalance0
  val diff1 = finishBalance1 - initialBalance1
  val diffCorrect = diff0 == -diff1
  val balancesCorrect = (finishBalance0 > minBalance) && (finishBalance1 > minBalance) && diffCorrect

  // Check that member boxes save their scripts.
  // todo: optimization could be made here
  val script0Saved = participantOut0.propositionBytes == participant0.propositionBytes
  val script1Saved = participantOut1.propositionBytes == participant1.propositionBytes
  val scriptsSaved = script0Saved && script1Saved

  // Member-specific box protection
  val selfPubKey = SELF.R5[SigmaProp].get

  selfPubKey && properLetsToken && membersExist && diffCorrect && scriptsSaved

Note that both contracts could be modified in many ways to get new systems with different properties. So hopefully
some day this article will be continued!