Comdex Mainnet Software Upgrade Proposal Discussion

Summary

The purpose of this software upgrade proposal is to upgrade the comdex-node software version on the comdex-1 chain from v0.1.3 to [v5.0.0] (release yet to be made). It will also add a number of updates, fixes, and new modules to the Comdex mainnet chain.

Details

Comdex is preparing for the Mainnet launches of our DeFi apps - cSwap DEX and Harbor Protocol. In order to bring these dApps on Comdex Mainnet, we have to push a software upgrade on their mainnet chain, Comdex-1.

This new node version is meant to upgrade the v0.1.3 to [v5.0.0] (release yet to be made).

The v5.0.0 update will be a major change that will set the parameters required for the launch of cSwap and Harbor Protocol. Certain functionalities of these dApps require governance proposals to be passed and voted on by the community.

These parameters are bundled in this upgrade and will be made live once this proposal is passed. Detailed information regarding the specific parameters and upgrades is in the following sheet:

Discussion Points:

  1. Parameters for cSwap DEX that require governance proposals to be deployed on-chain, such as:
  • Pool creation fee
  • Max price limit ratio
  • Pool creation fee is the fee charged by protocol to create a new pool with an asset pair.
  • Max price limit ratio is the tolerance range implemented for the threshold of limit orders.
  1. Parameters for Harbor Protocol that require governance proposals to be deployed on-chain, such as:
  • Stability fee,
  • Liquidation penalty,
  • Drawdown fee,
  • Surplus threshold, and
  • Auction duration.
  • Stability fee is the interest charged on debt issued annually
  • Liquidation penalty is the penalty charged on liquidated vaults by the protocol
  • Drawdown fee is the fee charged by the protocol for minting $CMST
  • Surplus threshold is the max surplus value exceeding which the surplus will get distributed to veHarbor token holders
  • Auction duration sets the time for which the auction will run

Similar parameters are added to the sheet and next to it are the details of each parameter and the parameter value at launch.

All the parameters mentioned in the sheet are important to discuss and set the correct value for each parameter. We request our community to give us their valuable opinion and feedback on these parameters and values.

Weā€™d be more than happy to answer any questions/queries you may have regarding any of the parameters.

10 Likes

What about % change for starting liquidation? is it buffer and cups parameters?
Whant to figure out what volatility will be allowed.

3 Likes

Harbor governance voting time is set up for 3 days, is that enough so that the majority of the community can comment and vote?

Other than that I dont have more comments, I would like to see how these parameters compare to similars protocols in the ecosystem

2 Likes

There is a specific CR ratio for each collaterals whitelisted to mint CMST below which the collateral will be auctioned off in Dutch auction style. If the current price at which liquidation took place is 10$, then auction starts at 20% premium (12$), which is the buffer parameter, and gradually declines to 50% discount from the buffer amount (i.e. 6$), which represents the cusp parameter. In the event that no one bids, the auction restarts with a new market price and repeats the process. To prevent extreme volatility, the collaterals have a debt ceiling that protects the protocol.
I hope that answers all your questions.

1 Like

Hey DelRey,
In the initial stages of the protocol, a lot of proposals will need to be passed. For smooth and efficient running of the protocol, the voting period has been set for 3 days. Once the system starts to function as intended this time will be extended to 5 days.

1 Like

Thanks! Itā€™s clear now.

I think the cSwap parameters are as they should be. LFG!

1 Like

I am very excited to see this on mainnet. We have been craving for these protocols for a while, so being so closed is awesome.

With respect to the parameters; a lot of them will have to show themselves during the use of the modules. A couple of questions;

  • (cSwap) the SwapFeeRate is set to 0.3%. On Osmosis there are pools with 0.2% & 0.3%. Has research been done whether this makes a difference in terms of TVL and usage? Because I can imagine that a lower swap fee is better for usage, but a higher swap fee (and thus a higher APR for liquidity providers) is better for TVL.
  • (Harbor) there is ā€œdustvalueā€ specified. Is there an explanation how this works?
  • (Harbor) there will be 2 governance types from the getgo? A type for emission pairs and a type for ā€œregularā€ governance?
  • (Harbor) 5% of the total Harbor supply will be minted towards the addresses of the Foundation? Which means that 95% will be community controlled?
  • (Harbor vault details) Very cool to have this sheet. It will be a live overview based on changing market conditions influencing the collateral ratio. Is there a live updated sheet already which runs on the background for people to look into the mechanics?
1 Like

Hey @Leonoors_Cryptoman
We are excited as well to bring these platforms to mainnet!
As far as the parameters are concerned

  1. cSwap(SwapFeeRate) - The 0.3% rate is set as a general rate and would be improvised with further upgrades and research backing it.
  2. Harbor(dustvalue) - The dustvalue parameter is specific to auctions; this is to prevent spam and looping of auctions; at a high level, dust value is where the auction would stop if the auctioned collateral value is below 0.1$
  3. Harbor - In the initial stages, only ā€˜Regular governanceā€™ proposals are shown in the sheet; later, once emissions are enabled, there will be two types of votes 1. To direct emissions 2. For parameter changes
  4. Contract would send 5% of the ā€˜Emissions supplyā€™ allocated from the total token distribution to the foundation address, not from the Total supply of Harbor
  5. Harbor vault details sheet would be automated and updated in real-time once the protocol is live and has different assets whitelisted as collateral
1 Like

Iā€™m glad the team is finally going to launch their products.
My opinion regarding network parameters is below:

  • SwapFeeBurnRate in the initial phase should be set quite high to inhibit the supply of tokens from bonuses, which I guess the team plans to allocate to the liquidity pool on cswap.
  • SwapFeeRate should also be higher initially. If the APR from the pool is initially large to encourage new users, I think the fee should be higher than 0.3%
    -WithdrawFeeRate should be 0% unless there is an option to exit the pool immediately then you can raise the fee to> 1%

As for the other parameters, I have no opinion at the moment

Thanks for the answers! Good to hear.

Regarding point 4; is there a plan for the emissions towards the foundation addresses? Or is that handled on the go? Would be cool if there is a plan for it (payment of salaries, development, growth, ā€¦)

Hey all,

Very exciting about the upcoming launch. Here are my thoughts on the parameters:

cSwap

  • PairCreation and PoolCreation - values seem fine, although its unclear why these are separate things. Doesnā€™t the creation of a pair imply that there will be a liquidity pool for the pair? Ideally the dex would source liquidity across all pools and find the best place to pull from

  • MaxPriceLimitRatio - fine

  • SwapFee Rate - 0.3% is standard, would ideally like to see some of those fees go to CMDX holders

  • WithdrawFeeRate - should always be 0

  • SwapFeeBurnRate - always 0

  • Add pool pairs - two chosen to start are the obvious ones but maybe could add a stable/CMDX pair also. I know probably waiting for CMST but Axelar USDC could work in meantime

Harbor

  • Stability Fee - reasonable
  • Closing Fee - reasonable

Do these fees go to CMDX or HARBOR holders/stakers? Where is the value capture for each type of holder?

  • Liquidation Penalty - reasonable. Is it like Rari where people will buy the liquidated positions?

  • Drawdown fees - reasonable

  • Debt ceiling and floor - good starting points. See how system develops before going to high. Donā€™t want to end up in a Rari position

  • Minimum CR - this is a lot of assets to start out with. I would recommend focusing on ATOM OSMO JUNO CMDX in beginning all with 150%. Lowcaps are too risky and will leave people salty when they get liquidity to do low volume price movements

  • Dust value - fine

  • Thresholds - makes sense re HARBOR tokens. Wondering why the CMDX token couldnā€™t have been used as native token for Harbor as well?

  • Other parameters all seem pretty straightforward - encourage voting quickly and make sure people know votes are live. Since only three days, try to not to release votes on Friday

  • Emissions Rate - this is on top of the 500M tokens or where is this coming from?

One other question I have is where are price feeds sourced from to manage Harbor CDPs? Osmosis? Presumably they canā€™t come from cSwap.

Exciting stuff everyone. Looking forward to launch.

1 Like

Hey @jackfrutaco

  • Regarding PairCreation and PoolCreation: Creating a pool is a two-step process; First, the pair of a particular pool needs to exist. This will be to execute p2p trades on the order book, while the next step is to create a pool using that pair.
    A pair can exist even without a liquidity pool.
  • Liquidation Penalty works similarly to Makerā€™s Liquidations 2.0 Dutch-styled auctions; Users can bid on liquidated vault collateral to obtain them at a discount.
  • Why CMDX couldnā€™t it be used as a native token for Harbor?
    1. If we used CMDX as the native token for Harbor, we would have to compromise the borrowing of CMST using CMDX as collateral, as one cannot act as the recapitalization source and the asset taken as collateral to borrow CMST; thus, $HARBOR would never be used as collateral to borrow CMST. Hereā€™s a detailed article to explain: https://blog.comdex.one/why-isnt-harbor-collateral-to-mint-cmst-80066ed43d3e
    2. Harbor requires intensive governance participation and a new value capture model; if CMDX were used, it would need a significant tokenomic transformation.
  • As far as price feeds are concerned, they come from coingecko, and cSwap would be one of the external sources. Prices are TWAPed every 30 minutes to prevent sudden fluctuations.

Would there be a way to obtain the price information from multiple sources? Also CoinGecko is not without errors, and have seen some issue with the prices lately for coins which are not available on too many exchanges. The main ones go ok, but for example coins with the combination Osmosis + Hotbit and a low volume / liquidity on Hotbit go wrong sometimes.

Implementing a method where multiple sources are used and outliers are detected would be of added value imo.

The coingecko price is aggregated from multiple sources.
The protocol balances the risk associated with low-liquidity coins that are unavailable on many exchanges by adjusting the debt ceiling and CR ratios.

True, but I have seen some weird cases where coins which are located on not too many exchanges with a relatively low volume are manipulated. Coingecko is fooled for those coins. Checking also for example CMC (although I donā€™t go there lately anymore) gives already a first layer of defense.

But good that the ceiling and ratio are already taking such liabilities into account.

1 Like

hey ser . how to vote ?

As said in the beneath threads price and its source are a very important point. In the context of a swap problematic related to slippage has been tackled ?
How to manage spread sometimes important between the displayed price and the real price appliec?

Itā€™s clearly now. Thank for your information