Terra Core priorities for Q1/Q2 2021

Last edited by @dokwon on 04/19/2021

This doc outlines the current engineering priorities for the Infrastructure team of Terraform Labs for Q1/Q2 2021. Main changes will be prepping for the Columbus-5 mainnet upgrade, as well as improvements on ecosystem tools such as finder and station.

Dev roadmap for application projects such as Anchor and Mirror are not included in this document, and may be published separately.

Terra Core

Development Progress - 85%

Make the following changes for Columbus-5. Tentative completion date: May W2

  • Simplify treasury module logic

    • Adjusting Terra seigniorage distribution - #14 by dokwon
    • In col-4, reward_weight portion of the seigniorage is is placed in a buffer that rewards faithful oracles over a period of 3 years, and 1-reward_weight is sent to the community pool. reward_weight is calibrated every 1 month by the treasury module to calibrate burns vs staking returns.
    • Currently reward_weight is set to 0, such that all seigniorage is being directed to the community pool
    • In order to keep the narrative simple to "staking rewards come from fees, all seigniorage is burned, we suggest the following change:
      • reward_weight to be set to 1
      • max_change of reward_weight to be set to 0 - the treasury module will refrain from further changing the reward_weight parameter arbitrarily
      • reward_weight portion of the seigniorage to be burned
      • 1-reward_weight parameter to go to the community pool
  • Dividend swap fees to faithful oracles instead of burns

    • recent rise in Luna prices have lowered staking yield to below a dollar
    • without making assumptions about increase in payments txn volume, the only way to make sure the ecosystem captures value well (linear to AUM) is to dividend swap fees instead of burning them
    • this will only result in ~2% less burn happening, while staking yield will increase above 10%
    • this further creates incentives for validators to not submit “abstain” votes for oracles
  • Upgrade SDK ver to Stargate

    • CosmosSDK@v0.40.x(stargate) and CosmWasm@v0.13.x (wasmer@v1.0.0)
    • Upgrade module to be included s.t. no manual upgrades ever have to happen again
  • Include IBC related modules, darkflighted until governance passes

  • Separate mint / burn swap base pools in the Market Module

    • The basepool parameter is set to simulate a virtual AMM for swaps that mint/burn terra, to prevent the on-chain market from becoming more “liquid” than the off-chain market. This prevents arbitrageurs from frontrunning the Terra oracles (which are bound to be slower than CEXs) to arb against price changes in the offchain market
    • We can prevent frontrunning by setting the size of the Terra burn swap basepool to be small, while allowing Terra minting to occur more efficiently by separating the basepools foor minting and burning of Terra (setting the former to be large)
  • Optimize gas efficiency of oracle votes

    • Submitting prevotes and votes for 15 fx pairs every 5 blocks is expensive - we should find a way to optimize this
    • Item 1 should make it easier for oracles to shoulder costs
  • Charge gas cost for the log size from the contract

    • Now there is no way to restrict contract log size, so it is very easy to occupy the node operator’s local storage by emitting huge contract event logs.
    • We currently allow a node operator to specify the whitelist contract addresses for logging.
    • If we charge gas cost to the contract log, we can prevent storage spamming and also can remove contract whitelist feature
  • Cosmos SDK Vesting accounts bug

  • New Params to restrict contract log & data size in CosmWasm to prevent spamming

    • MaxContractDataSize: 256 bytes, 
      EventParams {
         MaxAttributeNum: 16,
        MaxAttributeKeyLength: 64,
        MaxAttributeValueLength: 256,
  • (Optional) Prioritize transaction ordering in the mempool to cope with transaction flooding.

    • Mimic Ethereum mempool logic
    • This can be added later without fork
  • (Optional) Change genesis export & import from json loading to json streaming

    • Minimize genesis encoding & decoding cost
    • NOT DOING in columbus-5 -
    • We will need to do
  • (Optional) Terra Name Service

    • include the nameservice module from the cosmos-sdk

Luna economics improvements (application layer)

  • Buyback and unify staking rewards (Station) - DONE (“swap multiple coins” feature)
    • “Withdraw rewards” requires buys for Luna on Terraswap for all stablecoin rewards accumulated (buyback and dividend similar to mirror)
    • This will make it easier for service providers to offer Luna staking
    • Mechanism to be implemented as a smart contract and included as a part of docs.terra.money for folks looking to implement Luna staking
  • Station swaps to favor Luna economics - DONE
    • UST → Luna swaps uses terraswap (buys Luna)
    • Luna → UST swaps uses layer 1 swap (burns Luna)

Breaking Changes for wallets and exchanges

  • terrad & terracli => terrad
  • terrad home path has been changed to ~/.terra from ~/.terrad
  • New proto signing logic added, but still support legacy amino signing
  • No coins returned for account query
  • Need to add Bank SendEnabled(per denom) params at oracle whitelisting; if not specified, DefaultSendEnabled of bank parameter will be used
  • EstimateFee interface change
    • EstimateFeeRequest now receives BaseReq (with gas == “auto”) instead of StdTx
    • EstimateFeeResponse now return StdFee
  • New grpc removed estimate_fee endpoint, but can use /cosmos/tx/v1beta1/simulate and /terra/tx/v1beta1/compute_tax to get gas and tax amount
  • Legacy EstimateFee’s request & response format changed to use BaseReq and return StdFee
  • (client) #7246 The rest server endpoint /swagger-ui/ is replaced by /swagger/, and contains swagger documentation for gRPC Gateway routes in addition to legacy REST routes. Swagger API is exposed only if set in app.toml.
  • REST API /market/terra_pool_delta removed and /market/mint_pool_delta & /market/burn_pool_delta added [Feature] Separate mint and burn swap pool by YunSuk-Yeo · Pull Request #467 · terra-project/core · GitHub
  • tx log msg.sender now can be terravaloper address
    • oracle/MsgDelegateFeedConsent
    • staking/MsgEditValidator
    • slashing/MsgUnjail

Ecosystem (Station, Bridge, Finder)

  • [New Product] Bridge.terra.money - DONE
    • A unified interface to send and receive Terra assets on the interchain
    • front end interface that sits on Wormhole, Axelar and Shuttle
    • station supports the ability to receive & send assets in all supported networks
  • Retire shuttle, migrate existing Ethereum integrations to wormhole
  • Station web to allow signin from station extension
  • [New Product] Station mobile - DONE
  • Contracts need to become more legible on Finder → on-going

Yes chief!! Making moves!

awesome features. looking forward to all of them.

one click luna swap - think of swap all rewarded assets into Luna at once - now you have to swap each asset separately into Luna.

@dokwon , just want to check whether Col-5 is still on track and whether the new CosmosSDK@v0.40.x(stargate) and CosmWasm@v0.13.x (wasmer@v1.0.0) would be included? Very excited for it.

I’ve been reading through the current smart contract docs, but I realize quite a few of the examples will be outdated once the SDK has been upgraded. Will the team also help to update those tutorial docs? I think it will be very helpful to onboard new devs into the eco system.

Just left an update. Big changes coming in this new upgrade!


I am looking forward to use Station mobie soon. thank you

super excited for these upgrades!


Amazing times ahead, I’m really looking forward to the upgrade.

I was thinking about the implications but I couldn’t find the current amount of swap fees that is burnt now. Is there an easy way to see how much volume goes through the burn/mint mechanism? I would love to see how the burn/mint volume (and the swap fees) scales with the total value of stablecoins or with the volume of transactions on Terra.

Aren’t these incentives proportional to the volatility of the demand for stablecoins? As far as I understand it, the more the demand for stablecoins changes (ie. more arbitrage opportunities), the more swap fees the system will incur.

Hey - There are multiple ways to look this data up. If you are just looking for rough visualizations/statistics, dashboards made by Smart Stake or Flipside’s Community Console are great places to start.

I ran some rough numbers with regards to how the staking returns will change. Currently, the staking rewards sit at around 4-5% annualized excluding all external airdrop rewards. This can be confirmed on Flipside’s data dashboarding as well. Adding in the swap fees would push the expected annualized staking yield to the mid 7% range. This would be roughly a 75% increase in staking rewards.