Why we need to care about current Defi growth?

  1. Introduction
  1. What is happening ?
  • multiple defi projects including lending/dex/derivatives/assets/payment cartegories are growing together

  • locked assets on defi are growing with speed of doubling every month to reach $4billion as now

  • it is not driven by one or two projects, but by decentralized set of different projects

  1. Explosion of Transactions on Ethereum Network
  • https://etherscan.io/chart/tx : Ethereum transactions are reaching the last peak in January 2018, caused by the famous Cryptokitty. It was a temporary hike because it is led by a single game. But now, we see tens of Defi projects growing together which are very reluctant to be broken by Ethereum network congestion issue

  • if gas is too expensive, a game like cryptokitty can be just abandoned by users. But, Defi is related to much larger assets and its return than relatively small amount of the transaction gas. Defi users have much higher tolerance and patience for network congestions and higher gas fees. I expect Defi will keep its growth rate much longer until it slows down to wait for Eth 2.0 scalability expansion.

  1. How we see this kind of explosion?
  • Now, people see this transaction explosion not as a bad sign of Ethereum network. Everyone knows that there exists various options for Ethereum to scale out the tps and latency. It is just a matter of time. Wonderful thing for them is that “EVEN THOUGH” gas fee is very high and latency is bad, “STILL” more and more users are coming in to even boost the growth of Defi.
  1. What is our(Cosmos Ecosystem) stance on this phenomenon?
  • 2 years ago, maybe we can laugh at such tx congestion and the old consensus technology. Now it is not the case. PoS technology is not rare anymore, and it is just a matter of time or choice for Ethereum to switch its engine to PoS.

  • Of course we can say Tendermint and Cosmos-SDK has relatively better codebase to utilize, but such special advantages worns out when we observe a lot of other tools coming inside the entire industry.

  • IBC : IBC is one of the most valuable asset for Cosmos. But any technology without usecase will not survive longer than other tools. Business does not succeed with one element. It needs technology, but other ingredients such as business development, ecosystem building, market targeting, user attraction, smooth operation, are equaly important too.

  • When we compare the ecosystem of Ethereum Defi and Cosmos, we can confidently say that we are more than 2 years behind, except for PoS consensus. Community members and atom holders, please be angry and be awaken to push “BUIDL” to attract more usecase of the Cosmos Hub. And I really think our energy should be focused more on market-driven tools rather than technological idealogical stuff. Yes, backend developers want to dig this I know, but unfortunately market doesn’t care about it much right now.

  1. Direction to Interchain Defi
  • I see the growth of WBTC(176M locked assets), RenBTC(41M locked assets, utilizing tendermint), and other baby(but with crazy growth rate) Defi projects to provide heterogeniuous blockchains to Defi users. I admit both of them has flaws and disadvantages, but markets are not too critical about it. The market utilizes what are provided, and asking for improvement in the future. We don’t need 100% perfection for the first product.

  • If Cosmos want to become the hero of interoperability, we should try our best to connect different kinds of blockchains, not only BTC, ETH, but also many other “ISLAND BLOCKCHAINS”. Honestly I see better business development from Polkadot than Cosmos to achieve this goal, despite of their late implementation, when I consider current status of Cosmos.

  1. Why I am writing this?
  • I want to stimulate and warn the community that it is the timing when we should accelerate more than 100% we can. Hopely having discussions about where Cosmos should focus on, how we can accelerate such activities, etc.

  • Atom holders have rights to blame AiB and ICF. Objectively speaking, they did a good job in some area, but some areas are under average and needs more attention. When we feel sorry about criticizing the team, I think we will be even more late.

  • But basically the reason why I am writing this is that B-Harvest is fully on this boat, and our destiny is directly correlated to the destiny of Cosmos. We have such enthusiasm and loyalty, so coming with eager to drive changes and critics of the status. Also I don’t see much of discussions like this kind of broader direction of the network. Many holders were temporary happy about IBC inclusion some weeks ago, but they are disappointing because there exists no clear business roadmap to attract IBC usecases. I would say, excessive decentralization without strong leadership is slowing down this network.


Agreed on most points.

I think the logical step forward is for the ecosystem to better sketch out 1. what the next step looks like and 2. how we can get there.

From my personal brainstorms, I believe there exist a few pre-requisites for interchain finance to truly take off, roughly in the following order:

  1. IBC
  2. Shared security / Cross-chain collateralization
  3. Gas-efficient peggy + BTC bridges
  4. New zones

You can copy the code but you can’t copy the liquidity. So emphasis must be put on providing symbiotic features to existing DeFi applications rather than outright copying what already exists and hoping liquidity will come. I believe this will likely be in the form of new DeFi primitives unique to the architecture of Cosmos blockchains (i.e. proof-of-stake or interoperability) or providing meaningful efficiency (i.e. user convenience or scalability) to existing applications.

Some areas that I believe can provide symbiotic relationships for both Cosmos and existing DeFi applications on Ethereum are as follows:

  • Liquid staking as a new DeFi lego block
  • More efficient + more trustless BTC bridges
  • Interoperability as a scaling solution
  • Sovereign path to ETH 2.0 migration

Would love to hear what other people think as well!


In Kira we are working on the base alternative consensus for all DeFi projects on cosmos - MBPoS as the biggest issue we see it securing your zones. If you send more to the chain then the value of assets at stake the validators instantly have incentives to misbehave - that is lethal in case of DeFi. Only way to solve this issue is shared security for the cosmos hub, and for that we will need CosmWasm and improved gov so hub can move towards shared security model efficiently.

Only issue that I see is that ICF is not allowed to fund any projects that want to do this type of DeFi apps that we want to see, not even solutions like MBPoS to make them secure (that is before shared security even comes into play). I understand that and that’s why I think pushing towards shared security + CosmWasm + better gov is best we can do.

1 Like

@bharvest Thanks for bringing this up. It’s definitely clear that DeFi has emerged as a predominant use case in crypto, and Cosmos should want to position itself to capture growth in this market.

In regard to the broader Cosmos ecosystem — there have been some early signs of validation of the thesis around App-specific chains for cross-chain DeFi (Kava, VEGA, Acala, Terra, Celo, Thorchain, and many others), and I think longer-term, Cosmos is on the right track to being competitive in this space. However, I very much echo the concern that Cosmos is moving too slow, and I am fully onboard to jam on what we need to do to speed up the progress.

I like how @dogemos has framed things in terms of the prerequisites. IBC & shared security are the obvious must-haves, and until we have those, it will be tough for a great cross-chain DeFi ecosystem to pop up on Cosmos.

Honestly I see better business development from Polkadot than Cosmos to achieve this goal, despite of their late implementation, when I consider current status of Cosmos.

A big part of this is that Polkadot has the more complete product at this point — they’re on a clear, short-term timeline to shared security (parachains) & cross-chain communication.

The core differentiator for Cosmos is the community/ecosystem it’s built over the past couple years. Once Cosmos has IBC/shared security, its value prop grows significantly. The faster we can get here, the better —though much easier said than done. As a community, I think we need to rally to get these things knocked out before anything else. Would love to hear others’ take on what all this might entail.

One thought on this: With development decentralizing and the community pool funding key projects, we should consider offering much larger rewards to dev teams who are building key pieces of infrastructure. Cosm-Wasm, for example, seems to be viewed by just about everyone as super, super important for the Cosmos Hub, and yet we only spent about $75k (at the time) to fund development on this. Admittedly, I know little about the cost of funding development, but given the value this is going to add to Cosmos, it feels like we underpaid here. If we were to create much larger bounties for key development priorities, this would hopefully incentivize more developers to get involved and accelerate the progress. Theoretically speaking, if we can spend $1mn to drive $10mn/$100mn/$1bn in value to Cosmos, it is worth it every time.

The other question in regard to DeFi on Cosmos which has been discussed a little already is ‘What role will the Cosmos Hub play in the ecosystem?’ This is something I’m still thinking on, but at a high-level, it definitely makes sense for Cosmos Hub to own some of the key primitives of the cross-chain ecosystem we hope to build around it. This is another thing we should get started on as soon as possible.


Thanks for your opinion.
I would like to dig deeper on what you listed for pre-requisites and further utilities


  1. IBC
  • backend : I have no worry on backend. Berlin Gmbh is doing a great job on implementation. But I also think there should be a good discussion process to expand the utility of IBC. I imagine that we will have much broader range of capability for IBC in future, and a lot of them will be implemented from community’s help. So I think there should exist a guided process to discuss, design, and implement such expanded IBC features from the community. Well structed process is as important as the implementation itself, which is the crucial part for community to easily approach and participate. Interchain Account is a great example of community-driven-IBC expansion.

  • frontend(relayer) : I think the relayer implementation is much less emphasized than what it should be. We know that the team invested a lot of effort to provide the stable Tendermint node client. Compared to that, relayer client is implemented by one person who were also busy for so many things. I think stable relayer client is as important and difficult as the stable Tendermint node client. Therefore we need to invest good amount of fund, focus and effort to provide the community well-functioning IBC relayer program without frequent error or disabilities. The stability of the relayer is the heart of the user experience on IBC. If mass think IBC is not stable enough, we might lose a lot of opportunity because of the instability of relayer. This should be very critical point for adoption of IBC. (I heard that relayer improvement is handed to Akash network. I am not sure the codebase is open at this moment. Please let us know if someone knows where the codebase is)

  • User Interface(wallets) : This area is also under-focused part of our ecosystem. Generally, IBC and AiB used to be interested in backend stuff, and they used to ignore how frontend and interfaces are important in the ecosystem. I know that Luni is funded to build the user interfaces, but I think it is not very successful. Still the service is not very stable, and objectively, cosmostation is providing much better service. However, what we want to pursue is “metamask” like chrome extension wallet, or mobile wallet with explorer functionality. Metamask is heavily funded by Consensys and they were providing a great utility for the mass people who uses different kinds of smart contract solutions. In our ecosystem, I think “Chainapsis” is the only one who provides chrome extension wallet for Cosmos ecosystem, and someone like chainapsis should be given a lot of funds and support to provide various web extension wallet utilities for the entire community. Teams cannot provide free stuff forever. AiB and ICF has duty to provide them enough resource to continue the work. I criticize AiB and ICF not focusing on the frontend and interface area of ecosystem.

  1. Shared security
  • Delayed implementation : We constantly have observed the status of shared security. It was abandoned from last summer, and still not moving to any direction for almost a year. This is one of the most important part to be criticized. We all agreed that shared security is one of the most important feature for Cosmos Hub, but we abandoned for a year. B-Harvest tried to bring this up to the community several times, but we also admit that we couldn’t drive it further. Frankly, it is shame for all of us but especially for AiB and ICF. I heard that finally AiB is focusing on shared security, but still I don’t see any public discussion about it. I hope the community and AiB/ICF is regreting about this ignorance of shared security implementation, and do their best to provide a good design of shared security in very near future.

  • Design Space : I think shared security implementation is not a matter of time. I think there exists very wide area of possible design space, and decision is not trivial. I think we need proper enough discussion about design space before implementation. However, I am not sure AiB is willing to do this process. I hope them to listen to various demands from community before finalizing the design. All utilities should come from actual demand, not from ideal imagination.

  • Good write-up by cwgoes : https://github.com/cosmos/ics/issues/448 . But I am not sure where this is heading to in the perspective of action. I see this write-up is done about a month ago but there are not much of discussion happening.

  1. Peggy and BTC bridges, and other peg zones
  • Peggy : I heard peggy is under implementation by Althea. And I think the repository is not publicly available. So, I cannot tell that this implementation is currently well processed at this moment. I am not sure why it is not publicly available since from my memory, most ICF funded projects were open from begining. I think Peggy also should be open so that community can track the implementation process because it is one of the most important ingredient for IBC usecases. It is not something that we can just trust Althea and be blind about it.
    (addition) : peggy by althea (https://github.com/cosmos/peggy/tree/althea-peggy)

  • BTC bridge : There were some promising PoC about a year ago, but there is no much progress IMO.
    Please let us know if there exists other project. RenBTC is built upon Tendermint, but I am not sure it is “our ecosystem” because basically they are only serving Ethereum at this moment. I think that not only the implementation, but also the intention and roadmap to be connected to the Cosmos Hub and support anything needed to transfer assets to the Hub is necessary condition of a project to become our ecosystem.
    (addition) : bitcoin relay by summa-tx(https://github.com/summa-tx/relays/tree/master/golang)

  • Other bridges
    I also heard ZEC is trying to connect to the Cosmos Hub, but I think it is also stuck nowhere.
    I think we should try our best to also connect different kinds of blockchains such as BCH, BSV, LTC, and many more other blockchains. I don’t see any progress so far, but hope to see multiple projects in near future. I think AiB and ICF should be leading this direction and fund various teams to discuss with each blockchains.

Defi, Liquid Staking and Security

  1. Defi and Security
  • I personally think that “Hub-Level-Security” is a necessary condition for ANY Defi utilities in our ecosystem to become a successful Defi service provider to compete with global blockchain space. We know that all of the successful Defi services at this moment have “Layer 1 (Ethereum) level security”. I don’t think external users outside Cosmos ecosystem will trust any layer 2 security to put their significant assets. It will block the potential to grow further outside our ecosystem.

  • Shared Security and Defi : I think shared security and Defi will be a great synergy. But if the Hub provide the security to a Defi zone, then obviously the zone should reward the security provider, delegators of atoms. So the zone should give up significant amount of its reward right to the atom delegators, which will be quite controversal for the zone’s founders and zone token holders. We need to think appropriate way to balance such things. Personally I think a Defi zone without its native token will best represent the utility for the hub because the zone is solely owned by atom delegators. But some kinds of hybrid approach can provide alternative ways to co-exist.

  • ZK-rollup : recently, zk-rollup became hot technology to provide Layer-1-security even from centralized operation of Layer 2. (https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/). Its advantage is that, because zk-proof proves the consistency complete computing process without any necessity to trust layer-2 validators, it can be scaled out without security sacrifice. So, I think zk-rollup is another way to provide any Defi zone Hub-level-security without trust on zone’s validators.

  1. Defi and Staking, and Liquid Staking
  • Defi investment : Currently, uniswap liquidity pool provides approximately 70~80%/year commission fee rewards in average. (https://uniswap.info/home) I think investment into liquidity pools of DeX can be a great investment instrument in future, but at the same time, it will danger the security of dPoS since the reward rate will be much less competitive than Defi’s instruments. So in this context, delegators need a way to invest in Defi without undelegate their token --> liquid staking.

  • Liquid staking : There are quite a significant economic value in liquid staking, but at the same time, it is very risky to the security of the blockchain. So we need a safe approach to achieve liquid staking without concentrated risk to danger the security of dPoS. Concentrated risk of liquidity staking is I think the most threats which should be avoided in any circumstances because the attack vector surface is focused into one codebase or one account. I hope to see a naturally decentralized solution to provide liquid staking which does not have any concentrated risk.


If you send more to the chain then the value of assets at stake the validators instantly have incentives to misbehave - that is lethal in case of DeFi

I 100% agree with this statement. Defi needs at least 3~5 times more collateralized security than deposit asset size. If the hub receives more than $200M deposits, we can say that even the hub security is not enough to hold such deposit. This is the direct reason why Atom price should be appreciated higher. (Token price directly correlated to the success of Defi on the Hub, therefore branding and marketing for Atom price is also crucial factor for the success of Defi on the Hub.)

Only way to solve this issue is shared security for the cosmos hub, and for that we will need CosmWasm and improved gov so hub can move towards shared security model efficiently.

  1. I think CosmWasm is not the necessity condition for shared security. Shared security implemented on IBC and staking module can improve the security of Defi zones without utilizing CosmWasm.

  2. I think shared security is NOT the only way to increase security of Defi zones. zk-rollup technology also provides layer-1 security to the Defi zones. It solves layer-2 trust issue with zk-snarks without relying on honest behavior of layer-2 validators. This is why it is the most prominent scaling solution in Ethereum ecosystem compared to optimistic rollup or plasma, which are relying on the honesty of layer-2 validators’ behavior.

  3. Therefore, I think the Cosmos Hub should possess a zk-rollup module to handle several kinds of core Defi functionality on Defi zones. By this way, the Hub can provide its security to Defi zones without utilizing additional security collateral to zones(shared security case)

Only issue that I see is that ICF is not allowed to fund any projects that want to do this type of DeFi apps that we want to see, not even solutions like MBPoS to make them secure (that is before shared security even comes into play)

  1. I think multi-token dPoS is relatively weak security compared to native-token dPoS.
    Large amount of native-token delegation cannot be liquidated in short time and it will cause a lot of market impact if delegators want to liquidate it.
    But All other-token delegation can be easily undelegated and exit the network without any troubleness of market impact. So, the delegation via non-native token has relatively very weak security, causing unstable security size of the network. This will become disadvantage of any Defi zone compared to stable Layer-1 level security networks

  2. I am not sure why multi-token staking is No-Go for ICF? If it is not directly related to any Defi, I don’t think it blocks ICF to fund. Maybe because Kira is DeX project? Or maybe it only solves the security issue in weak way?

1 Like

Point of multi staking is that all of the assets at stake are liquid through 1:1 derivatives which powers the underlying DeFi app, so that point is not correct.

There is still a native token, the MBPoS is a an extension of n/bPoS, so claim that native dPoS is more secure simply does not make much sense from logic perspective, as it can only exceed the security, not decrease. Furthermore governance of the network controls which assets can be staked and what % of rewards can be shared with such assets - this induces both liquidity and security into the network. It also does not influence the voting power - only value of assets at stake.

So can the native token in b/nPoS thought the CEX’es, and there is always an unbonding period regardless which asset you stake.

I am not sure how exactly a native token with huge market volatility has more stable “value” at stake : ). Its sort of like claiming that multi-collateralized DAI is less secure and more volatile than normal single-asset DAI. I do not think Maker is wasting their time on that one : )

Kira is not a dex project a dex module is a simplest DeFi app example we have to demonstrate a positive feedback loop of MBPoS, the grant was for a Kira Core - which is a soft dev company to deliver MBPoS and not for anything related to DeX functionality.

Why multi token staking model is not ultimate solution to expand security :

  • if a whale wants to liquidate his/her native token(10% for example), 10% of native token should not only be unbonded but also be “sold” in market, which is almost impossible without significant market impact. So the 10% of native token can be viewed as midterm to longterm security.

  • if btc or eth is staked into a network via multi-token staking, this can be simply unbonded and pegged out to the original blockchain to be sold at market with relatively much less market impact. Therefore it is seen as temporary short term security which can be disappear in 2 weeks because of any economic/political incentives of the holder.

So I think multi token staking is not the solution to achieve enough security for the Defi zone.

Also, for the hub, it will not work as reliable security enhancement solution because of the same reason. It should add the security but the quality of security is much lower than native token staking.

This analogy is similar when we consider shared security. A zone can be supported by shared security from the hub, but the decision of shared security can be withdrawn by governance decision on the hub, anytime when hub wants.

So even though shared security support a zone via shared security, the quality of security is much weaker than the security on the hub. I describe this as a contractual security with withdraw option at any time by security provider(hub).

So, I think even shared security only can become ultimate solution to achieve enough security for defi when the relationship is giving atom stakers clear long term benefits so that they want to keep providing shared security for long time.

That is a false statement. Unbonding and waiting 21 days have nothing to do with selling the asset. If you want to instantly unbound by selling and paying a premium to traders then you would place an order on the bonded vs unbonded token order-book, so only that order book would be affected and it has nothing to do with that asset market price of that token. That is the most basic staking derivatives use case and something that every CEX already allows…

The holders are the ones controlling which assets can be staked and which not and what % of rewards is distributed - this is used to attract liquidity coming thanks to those foreign assets being deposited - and effectively make the income from the network fees - this in turn creates incentives to stake even more foreign assets.

Note that your liquidity is never limited, and that derivatives can also be staked or used in other DeFi’s

For example
-> stake on A + earn rewards -> use CDP on B to issue stablecoins

Unbonding and waiting 21 days have nothing to do with selling the asset.

When we think of quality of security, we should think about how much it is easy to be liquidated to other assets(fiat or other tokens). He can unbond and not sell the token, but then the capital is locked so it cannot be utilized for other economic purposes. So, how much it is easy to sell and liquidate the assets is the core factor for the quality of the security.

If you sell only 1% of atoms on the market, the market impact will as large as 10%, which is more than current slashing rate. What it means is that, for large holders, the liquidity risk is much larger than the slashing rate. And this liquidity risk is the core reason why staked atom provides midterm-longterm stable security. I think you don’t recognize how important is this liquidity factor for larger holders.

If the staked assets are pegged btc, then even $10M of pegged btc can be easily unbonded and pegged out, and be sold in CeX, causing not much of market impact. Then the holder can utilize this capital for other economic incentives. So, in this case, staking is just a very flexible investment which can be turned into other investment easily without much cost.

this is used to attract liquidity coming thanks to those foreign assets being deposited

I think this kind of positive loop will be happening when the network already provides enough security. I think the enough security is a necessary condition to boost the bootstrapping process of more liquidity and users. Consider the Defi products in Ethereum ecosystem. There exists very little solutions with less than layer1(Ethereum) security.

This is a special case for Defi utility. In other utilities, usually users do not need to deposit significant amount of their assets into the network. It is only the Defi case that users put more assets so that they cannot ignore the security risk of the Defi operators.

This post is to summarize what @okwme has explained about ICF’s effort for Defi of Cosmos and its ecosystem in Cosmos Governance Working Group telegram channel. Thank you so much for the transparency effort to community!

  1. Uniswap : ICF funded IXO and SimplyVC to provide more generalized uniswap model PoC.
  1. ICF’s adversity to financial product
  • ICF lawyers advise extreme caution on activities around financial product
  • ICF would like to keep negative attentions away by avoiding funding projects with reguratory risks
  • Although ICF can fund something like building generalized uniswap PoC, it cannot fund for actual DeX product operation and it should be the community fund to support further step towards working solutions.
  1. Better information delivery from ICF
  • ICF will do better highlighting the amazing work coming out of the community
  1. ICF focusing low level technology
  • Instead of funding directly to each solution of its own, ICF is trying to fund the low level technology which enables more projects to build faster and cheaper
  • “How useful is this to the wider community?”
  1. Community pool
  • until v0.40 upgrade, community pool cannot accept donations
  • expansion of community pool functionality can be added on the Hub for better self-sustainablity of the Hub (discussion going on in GWG with @Gavin )
1 Like

I think you missed an important point that with multi staking it is not only possible to stake crypto like BTC but stablecoins and digital fiat. This means that regardless of the market movement your DeFi app built on top of MBPoS can offer you stable income regardless if you are long term holder of BTC or only speculator counting returns in USD - you can always swap staked BTC for staked eUSD. There is no real need to stop securing the DeFi app that brings you a stable income by you locking up currency that you really trust unless you are exiting crypto world entirely. The value of the native staking asset and block rewards alone is not the only thing that incentivises increasing the security of multi-PoS - it’s the fee rewards :slight_smile: This kind of price movement economy and how it impacts security is a very very old and legacy approach at this point, and I do not think it works well for the interchain ecosystem that is way more impacted by honeypots than typical “master chains” from the old paradigm.

Brief summary of current status of Cosmos Defi ecosystem and beyond.

Elements of DeX

  1. eth peggy is almost PoC ready
  • but althea-peggy should be integrated to the main branch of peggy
  1. btc peg PoC is ready implemented by summa-tx

  2. uniswap like dex PoC is ready by ixo and simplyvc

  3. chrome extension wallet by chainapis

  • it needs some functional expansion to handle arbitrary message type from cosmos-sdk custom modules?

These 4 parts are the core softwares to build the most simple dex feature on the hub with erc20, btc and tokens from cosmos zones. So we are actually ready to move on!

push forward

Still each of the projects need to be took over by teams who have technical ability to push each PoC into production level solution and possibly also responsible for operation. Great candidates of teams from the community should step up for these crucial jobs.

community fund, it is time to invest!

Unless funded by AiB, it is now quite certain that these teams should be funded by community fund, and this is the area of community to push forward.

Also, those teams who implement production level solution and hand on the actual operation “forever” should be incentivized accordingly to acquire enough resources and growth upside by allowing them to gain some revenue stream from the commissions gathered from each project. Because, one time funding will never cover the opportunity cost of operation effort for endless timeline.

consensus operation options : hub or shared security or zk-rollup?

Also, the the option of network operation for 1/2/3 should be chosen from below options all of which will provide “almost” hub-level-security.

  1. directly on the hub’s module and operated by hub validators
  2. operated on each zone with shared security provided by the hub
  3. zone with zk-rollup proof on the hub

Upside of 1 is that implementation is straight forward and it gains 100% perfect hub-level-security

Downside of 1 is that gaia will be more crowded with txs and it might cause instability of operation and security for the entire hub.

Upside of 2 is that it will not impact on hub’s security or operation, and will not need additional modules on hub’s gaia

Downside of 2 is that shared security should be waited for quite a long time(expecting 2021 2Q at best). And security from shared security is not as strong as the original hub’s security.

Upside of 3 is that it will provide eventual hub-level-security without shared security and it allows the zone to be operated in centralized way(higher performance) thanks to zk-proof.

Downsid of 3 is that the implementation is technically very challenging and it will take relatively more time. Also it will have longer finality on the hub than option 1. Also it needs the rollup module added on the hub

1 Like