What needs to happen for our DeFi Ecosystem ASAP?

Between late September and mid October, we conducted interviews with eight Polkadot Parachains (thank you so much!) that are either building DeFi products or having notable DeFi activities regarding their needs and concerns. We combined the learnings to an internal Parity Forum post on Oct 25, 2022.

I would like to open this post to this public forum to share these valuable feedbacks and would love to invite everyone to join this conversation.

Here are the most frequently mentioned needs:

1. Stablecoins

Stablecoins are the very foundation of any DeFi ecosystem, and are the driving force of liquidity. Our DeFi ecosystem is in dire need for mainstream centralized stablecoins such as USDT and USDC, with preference for the latter due to the prospect of attracting institutional liquidity. There has been growing interest around BUSD as well, especially the community behind it. These stablecoins should to be widely available and easily accessible to the teams and users. At the same time, deep liquidity is required for any other DeFi activities building on top of stablecoins. The community also calls for at least one strong and trusted natively-created decentralized stablecoins. Everyone hopes to see a full aUSD recovery.

2. Bridges

Parachains need secure bridges that can bring liquidity from elsewhere, especially from Ethereum. Snowfork carries a lot of expectations. In the meantime, LayerZero, Axelar and Wormhole are the more popular options.

3. Wallets and Custodians

Wallet has been an onboarding blocker. We need wallets that have better UIUX and multi-sig support. Hardware wallets are also a priority. Institutional-grade custodians such as Fireblocks who provide multi-sig solutions in lieu of Gnosis Safe for non-EVM chains are an absolute priority.

4. Liquidity

Our whole DeFi ecosystem is in the liquidity bootstrapping (and in certain cases, liquidity-rebuilding) phase. Common avenues for liquidity are 1) investors who hold DOT and project tokens; 2) asset-agnostic DeFi LPs; 3) project Treasuries; 4) Polkadot Treasury. Parachains bring up the idea of having actively trading market makers in supporting native liquidity across multiple chains.

5. XCM

A number of Parachains mentioned that it would be great to have a clear roadmap and centralized documentation on XCM. Integration so far has been confusing and is at the risk of being done incorrectly. Sometimes, teams have to retroactively detect the announced change. They also need guidance on how to integrate with other Parachains.

Meanwhile, Ben shared this post of Multichain Usability Improvements that covers some typical asset activity scenarios and the challenges around them, which I found quite relevant to our CeDeFi and DeFi discussion here.

18 Likes

Good topic, Rae!
Totally agree with the ideas. I’ll add up 2 more ideas for “what we need”:

  • Defi analytics toolings for multi-parachains. Specifically, a ranking board for cross-chain and cross-swaps / leading protocols/stablecoins. Only with such tools Polkadot Defi degens can seek the best protocol for their certain purpose.
  • A router using XCMP is like 1inch, but the product should find the best router by multi-chain swaps, not swaps on a single parachain. This would be much more helpful to the Defi user experience as well.
9 Likes

Adding to the excellent points raised above, I would add to the “analytics” category. It would be fantastic if we had dune analytics or something similar where based on the parachain data anyone can build dashboards. At the moment, building dashboards requires a lot of effort since those need to either be fed directly from the parachain via polkadot.js (difficult and time consuming to do), custom graphql via subquery,or squid needs to be built (people that build dashboards likely have a hard time doing that), or you need subscan (which is quite expensive for their API keys).

5 Likes

Awesome topic, agree on everything! I would like to elaborate on the points provided:

1. Stablecoins:

We would like to have some sort of ecosystem program developed where there is support for native stablecoins: In my vision it should entail following areas:

Liquidity program to bootstrap initial stablecoin supply. This relates to Liquidity point and all of the liquidity avenues apply here as well.

  • Parity/ Polkadot Treasury could play a bigger role here in bootstrapping native USDT and native USDC liquidity in the ecosystem.
  • It could either be 1) Parity working with funds to deploy native USDT/USDC liquidity in ecosystem DeFi projects, or 2) Polkadot Treasury to give out loans in the form of native USDT/USDC (instead of DOT) to ecosystem DeFi projects to help bootstrap liquidity.

UI hub for AMMs and stablecoin swaps, minting, trading, using that freshly minted liquidity across the ecosystem. IMO it will allow retail users to at least see all of the options in one place. May be working closely with subscan / subwallet here on providing such features.

A group of market makers who are explicitly willing / aiming to work with the ecosystem and make markets both on CEX-es and DEX-es

2. Bridges:

Currently in an absence of the common solution a lot of teams are engaged in building their own setup, which could be broken down into two broad categories:

  • Solutions based on Chainsafe’s Chaindrige (Sygma) pallets
  • Solutions based on EVM-based bridges + XCM (Multichain, Axelar, Celer, Synapse, Wormhole, LayerZero, Wrapped)

For starters I see a good opportunity in providing a unified UI hub for all the possible options, where users will have a choice: how and where their external liquidity ends up in the ecosystem, I believe this endeavor should be pushed through the grants program.

I know a lot of people / teams are waiting for Snowfork, but it’s best when we have several options at the table. There was an interesting discussion about this topic here, yet I think it would be optimal if parity started engaging with the above-mentioned teams to build pallet / native bridging solutions directly. We have to be aggressive here, as none of the teams we spoke to see Polkadot as their priority, so maybe think of some incentive program here.

Basically, I see it as a common good parachain (statemine?) where all the bridges are connected to and where all the bridgeable assets originate, we could further think of and develop diversification schemes to reduce the risk of a single bridge hack as described in the abovementioned post.

3. Wallets and Custodians

The main obstacle here is the need from the wallet side to support different data models for different parachain architectures. Also, there is no solution which supports both EVM and non-EVM chains (there is Encrypt wallet but they charge very high fees for integration, maybe it’s best to approach them as an ecosystem?)

We experience real difficulties with integration, as our architecture is not similar to the widely used ORML module.

4. Liquidity

Lots of problems here:

  • No initial bootstrap, limited options, hard to attract institutions / whales.
  • No ecosystem-friendly market makers willing to work with DEX
  • Fragmented bridging and limited outside liquidity options
  • Hard to compete with bigger, better funded projects and high APRs when doing liquidity bootstrap campaigns
  • No listing support from parity, no common pool of CEX-es working with the ecosystem as a whole (+ problems on side of CEX-es supporting various parachain integrations)

5. XCM

Strongly in favour of the centralised documentation / roadmap on XCM. One thing we lack in particular is the ability to read storage data of other parachains / pallets via XCM.

5 Likes

Some more detailed thoughts on Ledger hardware wallet based on the input from our devs.

Issues with ledger app integration:

There should be one universal ledger app that will work with all parachains. The closest analogue is the Cosmos ecosystem, in which one application supports most of the projects. A less similar analogue is an ether application that works equally well for all projects on ether + for all EVM networks (BSC, HECO, Moonbeam, …)

Problems of creating different ledger apps for different parachains:

  1. The Ledger team is overwhelmed with work and responds EXTREMELY slowly. From our experience, the answer to your request may come in a month or two.

  2. Unique derivation path for each app (a unique account for each relay chain and parachain). Which leads to a number of problems:

  • Most applications do not have derivatives path selection functionality. So users, who transfer tokens from Kusama to parachain, for example, have their account changed and lose access to their tokens. The entire flow is not directly obvious to the average user (need to export mnemonic with correct derivation path).

  • The inability to participate in a crowdloan with a ledger with guaranteed access to its rewards on a parachain without exporting mnemonics to less secure environments (for example, an extension, a mobile application). Most likely, a new project that participates in the crowdloan will not have it’s app built for a long time, because of which users will have to wait and get a negative experience from the entire ecosystem.

  • Even if developers of parachain/relay chain applications will include functionality for selecting derivation paths in their ledger applications, this will cause all applications to need to upgrade to support new parachains. The alternative is for users to set derivation path manually, which is complicated for average user

The ledger app works as a full-scale decoder, where pallet numbers and their respective methods are hard-coded. This leads to following problems:

  1. Some transactions become unavailable after the runtime upgrade if there are changes to pallet indices and/or changes to extrinsic types.

  2. These problems in conjunction with slow ledger support response lead to the fact that users lose access to their assets for a prolonged period of time

Possible solution:

Abandon call data decoding on the device.

The main reason why it is necessary to make a distinct ledger app for each parachain is the need to decode the call data of every extrinsic.

Ethereum ledger app, for example, never decodes transactions, one exception being a transfer. That is, the user checks data in the metamask, for example, and approves it on a ledger.

In the case of the Polkadot ecosystem app, the call data is already being decoded in apps/mobile apps. In order to be sure that the ledger has a corresponding call data, it’s possible to display the hash of the call data both in the extension / mob. application, and on the ledger. This will eliminate the need to implement an extra decoder for each parachain after the runtime upgrade.

2 Likes

Love this topic and totally agree with the ideas! I’ll add up 2 ideas for “what we need”:

  • DeFi aggregator like 1inch or Matcha using XCM. Right now the liquidity is scattered on different parachains. It would be helpful to have a DeFi aggregator which can find the best route to swap assets by leveraging liquidity on different parachains.

  • Liquidity bootstrap for decentralized collateralized stablecoins. Centralized stablecoins are definitely a must-have for institutional investors. But decentralized collateralized stablecoins are better ways to leverage existing assets in the Polkadot ecosystem for stablecoin liquidity. It would be great if we can have more DOT collateralized in decentralized collateralized stablecoin protocols to increase the issuance of Polkadot-native decentralized stablecoins and accelerate the adoption.

5 Likes

I agree with many points here.

One thing I definitely want to point out here is that we need a better wallet in our polkadot ecosystem to support further user growth in overall DeFi ecosystem. In terms of UX, especially regarding multi VM, it could be ideal to have a better option.

3 Likes

I believe there is an oversight here, no? SubWallet has supported both EVM and Substrate parachains for more than half a year now and we charge absolutely NO FEE for integration. Other native wallets such as Nova Wallet & Talisman have also supported EVM for a long time now. You can refer to this chart in Polkadot Deep Dive Report Q3 2022 by dotinsights and SubWallet.

@suguru please check out wallet options here sir.

4 Likes

I don’t understand how this can be secure. The extension/application is not trusted, hence the hardware wallet. The application can display what ever hash it wants, it does not have to correspond to the data being displayed. If we trust that, we don’t need a hardware wallet, but merely a yubi key.

Displaying the hash seems almost equivalent to, but less honest to displaying: “Signing whatever you are seeing on your computer screen - fine? [Ok] [Cancel]”

Am I misunderstanding something?

Yep, I do: Displaying the hash does have some value. If we assume the machine is hacked but the extension is fine. It is not possible for another application to try to get something else signed, assuming the user checks the hash properly. Still if we assume the machine is hacked, it should be possible for an attacker to manipulate the extension as well :thinking:

1 Like

Thank you for bringing these up! They make great RFP for builders and the BDs. Once we have the supply side of liquidity aggregation, it would be great to see demand side of aggregation such as yield aggregators (like Yearn) and asset management tools (like Zerion). Next up would be interesting to have the derivatives I believe.

3 Likes

Absolutely. We have a prior good example where the Kusama Council and Community approved Karura’s Treasury proposal to leverage the liquidity subsidy initiative to do exactly that. The proposal is an interesting hybrid of the Liquidity Subsidy and the Rewards Subsidy. Teams are encouraged to consider leveraging this scheme both on Kusama and on Polkadot.

On the note of native Stables, I’m aware of the following:
aUSD, BAI, EOSDT, XSTUSD, dPRIME, USP
Am I missing anything?

1 Like

Thanks so much Peter! Often times, liquidity is described as a chicken-n-egg problem. But I believe we still can prioritize, and put the incentives in the right place. Would you have suggestion regarding the sequence of getting liquidity right for our defi ecosystem? For instance, there’s work being done on centralized stables, and with the custodians at the moment. What would be chain reaction steps next?

1 Like

There will also be a DeFi session on Dec 1 during the Polkadot Summit. If you will be in Lisbon during that time, please join us!

2 Likes

Awesome, my apologies, never used subwallet (a matter of habit using polkadot.js)! Good thing we support subwallet as one of the options for users along with polkadot.js and talisman, would love to co-market more once we launch live!

1 Like

Thanks for spearheading this discussion Rae!

Thought I use this post to intro myself to the community. I’m Nicolas and I just joined Parity as the DeFi Lead on the BD team. Together with Rae we’ll be working on channeling all of your ideas, suggestions and pain points, into actionable items that we can then execute on from the Success (Rae) and the BD (me) teams. With the help of you all, our goal is to make Polkadot/Kusama into a thriving and innovative DeFi ecosystem.

Having said that, all of your inputs are going to be instrumental for us to determine where to focus our efforts. As Rae mentioned, we’ll be doing a deeper dive next week @ Barcamp on all of the points mentioned above so please join us if you are going to be around. For the ones that aren’t able to attend, we’ll be making a forum post with the inputs and outputs of our session for everyone to provide further feedback and updates. The idea is to have several of these spaces (virtual or physical) that help us create a permanent feedback loop to align the community’s asks with Parity’s efforts.

I’m looking forward to interacting with you all as I continue to settle in my new role here at Parity!

6 Likes

Hi, Rae! On a very high level we see it the following way:

Step 0: Infrastructure support

  • Native bridge solution / bridge hub
  • Fiat-backed stables + CEX withdrawal support
  • Custodian + wallets + unified (across parachains) msig support for them to work effectively

Suggested next chain reaction:

Step 1: Institutional support

  • Commercial bundle deal with CEXes for integration + listing support
  • A network of market makers who are willing to work with the ecosystem and make markets for native assets on CEXes and DEXes.

Step 2: Liquidity

  • Polkadot Treasury to provide DOT loans to help projects bootstrap initial liquidity
    Example use cases:

    • Use of DOT as collateral for minting native decentralized stablecoins
    • Use of DOT as collateral for minting assets wrappers, e.g. IBTC, or liquid DOT staking for bootstrapping liquid DOT wrappers liquidity and many more (e.g. reward incentives).
1 Like

EVM ledger app doesn’t event show trx hash and yet ledger is widely used with EVM-based chains

I won’t doubt that. In Eth space they also use NFT’s which only hold a URL and sell them for millions. There are lot’s of stupid things in wide spread use, but I think we should strive to do better.

In my understanding the whole point of a hardware wallet is to be able to securely sign transactions of whatever kind, by seeing what you are signing on the built-in display. If we don’t provide this feature, we are not actually providing a hardware wallet. Like that is not MVP, we just punted on the single one feature the device was meant to fulfill.

Can’t we solve the problem at a different level? Like, with stability guarantees of the runtime? Then the problem would merely be any newly introduced calls/transactions are not supported until a new firmware update is provided, but everything else continues to work. I am not too deep in the space, but that ought to be possible?

I would like to express my opinion on the Wallet.

Certainly, Subwallet and Talisman can be considered Multi-VM Wallets that support EVM and Non-EVM chains. However, they are still far from new user onboarding.

So, if we look at the Ethereum L1 and L2 ecosystems, we can see that they are trying to move away from EOA and focus on AA (account abstraction) and Contract wallet. They will no longer have to force their users through the very complex process of private key management.
It will certainly be the next trend that will spread to billions of people.

If we try to develop these on the Polkadot Ecosystem, we will end up developing on a SmartContract platform such as Astar/Moonbeam/Gear.
However, Most Parachain does not support contract pallets, and they will not be able to use those products.

I don’t have a solution yet, but a major breakthrough here would be onboarding new users.
It would also be possible to develop while acquiring Grants from such as w3f.

2 Likes