Terra stablecoin and Luna unstable reservecoin review

Terra has secured 32M$ funding to implement their stable coin. Let's review Terra's 19-page whitepaper, which is very technical from an economic and scientific point of view. However, this level of technicality ends at economics, as both technical implementation and blockchain logic is missing from the paper entirely.
Terra has secured 32M$ funding to implement their stable coin. Let's review Terra's 19-page whitepaper, which is very technical from an economic and scientific point of view. However, this level of technicality ends at economics, as both technical implementation and blockchain logic is missing from the paper entirely.

The document that we are working on can be considered a scientific whitepaper, as opposed to a general overview whitepaper. It is possible that Terra may later provide more documents that detail the technical blockchain issues that are missing. Consider the following an exploration of the questions that we would like to see answered in the future.

Introduction to Terra and Luna


Terra is a stablecoin of unlimited supply and is being expanded and contracted through multiple stabilizations schemes.

  • Variable taxation fees adjust depending on Terra’s price. If Terra’s price is falling due to oversupply, transaction fees will rise. Iterative DMMD, similar to TCP's AIMD network balancing algorithm, is used for throttling the variation.
  • LUNA token is a fixed supply variable price token, which has the utility of being staked to the stabilization fund called the Stability Reserve. Stakeholders are also entitled to participate in the democratic process of governance at the protocol level. Taxes collected from Terra transaction fees end up as rewards, in the likely form of dividends.
  • In case of market extremes:

    • Market shocks will be handled with the liquid fiat/crypto reserve including the Luna token reserve (the value of which is always maintained to be above the circulating Terra supply) is used to buy back Terra and burn it. The reserve is resupplied during oversupply when it collects higher tax rates.
    • Extreme undersupply will be solved by minting new Terra and selling it to exchanges, where received funds will be used to reinforce the reserve, and the surplus distributed through a method so-called Decentralized Fiscal Spending.

  • Market volatility is governed by oracles, collecting data about price relationships of Terra and related fiat and cryptocurrencies.

Blockchain logic is completely omitted


In the whitepaper, terra.money is declared to be a protocol and an infrastructure for both Terra and Luna coins, plus 3rd party decentralized applications. However, nothing is written about the infrastructural capabilities or implementation solutions of the protocol, and governance of the blockchain is also left out.  Nowhere is it even mentioned that the infrastructure will be blockchain-based, but it can be derived from the mentions of blocks and block sizes. Many questions are left unanswered. For example:

  • What is the consensus algorithm of the blockchain itself? Will it be proof of stake or proof of work?
  • Who is going to run the infrastructure and who or what decides who gets the privilege of producing block at a specific point in time?
  • What is the block timing and size? Is it fixed, or is it dynamic - and what factors determine these?

The trouble with the price estimation via deposit holder vote


This brings us to the 3.2 section of the whitepaper mentioning price estimation via deposit holder vote, which acts like an oracle. In this case, “deposit holder” refers to a Luna token holder. Staking a large sum of Luna to cold storage (which freezes the Luna token for 100 calendar days) is required to participate in the democratic voting process and become so-called stability provider. In another section it was mentioned that 1000 Luna is enough to become voting-enabled delegate, although the total supply of Luna is not mentioned anywhere, except that it will be decided in the genesis block. As there is no glossary of terms, we might assume that stability provider and voting-enabled delegate are the same person, as their requirements are pretty similar in wording. Except at one point it was mentioned that delegate must run a node, so owning tokens in a wallet and staking them might be not enough. The problem is in the statement, quote:
Every n blocks, stability providers cast their vote on what they think the exchange rate for Terra was. These votes are all cast on the same block, and the votes that exceed the block size are disregarded.

The writer of this statement was not aware that 1) that there is no valid mechanism described in the whitepaper that decides who is the block producer, and 2) that anything broadcast to the network, at any point of time, is already public information accessible to all the nodes of the network regardless of the block being produced or not. So if voting delegates are required to be running the nodes, they will be aware of each other’s decisions before the block will ever be produced. Or if the block producer for that specific block would be known in advance, and block production would be held before votes are collected, network spoofing could be applied to collect the information.

Also, such a block producing node would need to be publicly known and could be attacked as at that point in time, it would be the weak point of the network. Furthermore, waiting for a real world dependent physical action like voting to resume block production might freeze the chain indefinitely. In case of such a block being decided for the specified future block and votes to be collected or prepared in advance, the block could be compromised because there would be no secure way to guarantee it to be Byzantine fault tolerant. As such, the voting result might be severely compromised, as the structure of voting would be clear, the encrypted message would be known, and it might be enough time to break it, or the node might get broken into before voting for the message to be tempered with. Also, there is a weak point for attacking such a known block in advance by clogging it with transactions before a single vote could be cast, preventing the voting process from happening for eternity if orchestrated correctly by the attacker(s).

Expansion by decentralized fiscal spending is executed through Ethereum, instead of using Terra or Luna, is most likely centralized


While the reserve fund is guaranteed by Luna stake, which is held at the reserve in case of recession Terra-burning for economic contraction to be achieved, ethereum is employed in the process of expansion to compensate the reserve debt and to fund the decentralized fiscal spending. One thing wrong here is that instead of crediting, ethereum would significantly hinder the expansion process as if the pool of reserve stakeholders is truly decentralized, the distribution of ethereum to cover the debt would be dependent on the technical performance of the Ethereum network.

Besides the risk of running into a clogged Ethereum network, the price of such payback distribution might be very expensive and makes no sense when comparing it to the tokens used internally on the infrastructure like Luna or Terra itself. Also, if Terra/Luna protocol is not an Ethereum fork or is not made compliant, there will be issues with the implementation of such procedure, as an external oracle on both infrastructures will be necessary to oversee the process, which is not described in the whitepaper. And assuming Terra/Luna is not the protocol running on Ethereum, which it most likely might not be, executing the exchange of freshly minted Terra through a decentralized exchange will be impossible and doing so will impose a centralized risk factor and a new single point of failure. Nevermind the centralized management factor of a delegate who will need to be trusted for operating the deposit of new Terra tokens and withdrawal of ethereum from the centralized exchange.

The grand scenario: centralized over-dump of stolen Terra meant for economic growth


Now imagine that a hacker managed to compromise the centralized exchange which sells newly-minted Terra for ethereum and goes undetected for some time. Even better - the cartel of centralized exchanges who trade both ethereum and Terra decides to force Terra token out of stability as they hold a pretty sizable number of ethereum relative to Terra emission capability. As the new Terra emission is stolen, the market is still undersupplied, the price is rising at competing exchanges (which, still unknowingly, will be participating in the affair) and new, even larger batch of emission is issued due to the progressive algorithm described in the whitepaper. As Terra’s price skyrockets, newly-minted Terra tokens are flooding the hacker's accounts. And then, when the hacker is comfortable enough, he dumps them, not only countering the market shortage but greatly oversupplying the market with Terra.

A cherry on the top


Code-level specifications and implementation details of the platform are outside of the scope of the Terra whitepaper, as mentioned in section 6. Unless significant improvements are to be introduced to the whitepaper, Terra at this moment is a magic stablecoin created for mass adoption, doomed to be limited by dependency on the $28Bn market-capped, 100% over-utilized-for-years Ethereum. Infrastructure and operational costs are never considered in the whitepaper. When claiming relatively low fees, even if dynamic, it is assumed that the network would be sustained by Luna token holders financing and running the entire infrastructure of which a consensus algorithm is yet to be decided on. Economically the stabilization of this stable coin sounds pretty solid, however, I see no way of implementing it on the blockchain or in any other decentralized way.

Communication with Terra


We reached out to the Terra team. After our initial questions were not answered to our satisfaction, we shared this analysis with them and invited them to provide a rebuttal. This was their response:
I think you got way ahead of yourself with assumptions about the business model and protocol. This leads to errant conclusions and speculation about how Terra will work, when in fact your analysis does not sync with what we are currently implementing. I would simplify and streamline your analysis to include only facts, or wait until we share more information publicly. Not publishing might be the best option at this stage. There's no point in putting out information that is not true, outdated, or speculative. You'll really like what we are doing to solve the problem of creating a decentralized stablecoin. Think of our white paper as a starting point, there is much more to the protocol than what is outlined at a high level in the white paper.

While we appreciate Terra’s concern with the optics of us sharing speculative information, we stand by our analysis so far. We can only speculate based off of the information that has been provided to the general public so far. Terra may yet impress us when they release more technical information.

Terra is within their rights to be tight-lipped about this information. They have no obligation to tell us any more than what they’ve shared publicly. However, when limited details are provided, people are going to speculate on what the lack of more concrete information means.

We maintain our opinion that when you are raising funds for a blockchain-based project, it’s important to provide details on how the blockchain will be implemented. We reserve final judgment on the quality of this project until Terra is ready to provide us, and the general public, with those details.