Permissioned pallet-contracts deployment to Asset Hub for DeFi primitives

Ecosystem
1

Summary:
Ivy believes that it would benefit the Polkadot ecosystem to convert some of the free blockspace within the asset hub parachain into a space for DeFi primitives to operate. However, in order to ensure the current high standards of system parachains are maintained, we believe it is in Polkadot’s best interest that the smart contracts pallet be limited to whitelisted multisig addresses from vetted teams only, with whitelisting being done through governance. This would lead to increased utility of the Asset Hub chain as a place that gives users a home base of assets and basic DeFi utility.

Key Beliefs:

  • Ethereum’s user base size is where we think Polkadot can get to (as a minimum).
  • Polkadot has the most forward-looking tech around
  • Polkadot’s current structure, pushing all actions to parachains, means that the user experience is not simple enough.
  • Parity already has enough work to do scaling Polkadot

Thesis:
The same modularity that leads to Polkadot’s great scaling, parachains, is what has led to the fractured user experience on Polkadot. In order to solve that, a home base needs to be established for Polkadot assets. Asset Hub is the chain to do it – a system chain with an abundance of blockspace already purpose-built for assets – but it also needs utility on its own, rather than immediate teleportation to parachains, in order to be a viable launchpad for other actions across parachains. Parity could build out this functionality, but their expertise is better utilized doing what they’re already doing, as asynchronous backing, accords, and agile core time will be propelling Polkadot to the next tier of tech domination.

Before we get there, we need to have somewhere familiar and safe for new users to land while they are learning the other parts of Polkadot, like parachains, shared security, XCM, and extrinsics. Everyone already knows how to launch a meme coin and transfer it to their buddies, and while they might not push the blockchain forward from a deep tech perspective, they are an important part of growing the user base of a blockchain and simplifying the user experience. But then, what is there to do after their meme coin has launched on Asset Hub? Polkadot has effectively skipped the DeFi building phase of 2018 and 2019, and instead went straight to extremely advanced parachain functionality while lacking a base of degens and cryptokitties. Luckily, it is easily rectified by putting some of that functionality back on an easy-to-understand system chain like the Asset Hub.

This is where having the tech that Polkadot already contains gives us an advantage. We want to keep the Asset Hub limited to high quality projects that are primitive in nature and make the barrier to entry for these primitives quite low, but not so low that it gets bogged down like Ethereum. Open governance allows for this happy medium: Dot holders can vote on which projects get approval to deploy on Asset Hub with much lower due diligence needed compared to modifying the Asset Hub’s runtime, accelerating deployment of usable tools to the market. Users still get all of the stability of a system chain, while having an expanded ability to interact with their Dot through a simple suite of dApps. Parachains then continue to employ their current high functionality, now with a stable asset base beneath them.

5 Likes
2

Can you provide further tangible examples about what type of contracts with which exact DeFi functionality you foresee a hypothetical team (possibly already owning a parachain) would deploy on Asset Hub, and how this would be beneficial?

First glance, this is somewhat analogous to the hybrid chain idea, where certain DeFi functions exist as a “light version” on Asset Hub but can be provided in a more specialized way elsewhere.

Yet, I also find the political ramifications of team deploying code on a system chain to possibly be destructive.

I think some tangible examples and how they are better than the existing model of DeFi activities would help understand the proposal better.

3 Likes
3

I don’t like the idea of permissioning, especially since the main point of contracts is to allow untrusted people to deploy untrusted code. But I understand the desire to have contracts that can interact with assets on AH.

Whether some of AH’s blockspace is available for contract execution is more a matter of whether that interaction must be synchronous or not. For interactions that don’t require synchronicity, it’d make much more sense to deploy those contracts on a smart contract system chain, rather than just adding another thing to AH. If contracts do require synchronicity, then the smart contract chain could also have an interface to accept/represent assets from AH. Then instead of a slice of blockspace, the whole block is dedicated to contracts.

For interactions that absolutely must be synchronous and must be on AH, then we could explore the idea of hybrid blockspace where we set aside say 10% of the blockspace for contract execution. If there is a lot of demand for this tranche of blockspace, then the gas price will increase a lot, motivating contract developers to migrate to a contract chain or rethink their application architecture to work asynchronously.

7 Likes
4

Kian:

Yet, I also find the political ramifications of team deploying code on a system chain to possibly be destructive.

Joe:

I don’t like the idea of permissioning, especially since the main point of contracts is to allow untrusted people to deploy untrusted code.

Assuming I’m interpreting this correctly, I think these are mostly the same point: don’t elevate dApp teams to have some level of control over a system chain that others don’t have. We’re not super invested in the permissioned part of the proposal, more it was a base for not inviting spam onto Asset Hub. However, Joe’s suggestion of a portion of blockspace being sectioned off seems to be a solid middle ground.

Kian:

I think some tangible examples and how they are better than the existing model of DeFi activities would help understand the proposal better.

Sure! Right now, it’s tough in our view to go from 0 to 1 as a Polkadot project team interested in issuing an asset without accepting the idiosyncrasies of a non-system parachain. Non-system parachains seem to us to be walled off: governance action is required to fully participate in another parachain with an asset from Asset Hub, but this requires some amount of notoriety, either with the sudo owners or with the governing community, and a path to recognition currently isn’t attainable from within Asset Hub. Either you deploy onto a parachain natively and assume oddities like differing XCM formats (like many of the bridged Eth assets), or deploy onto Asset Hub with no well-travelled path to gaining the recognition needed to get approval from a parachain’s governance system. In our view, the way to solve the problem of wanting to deploy your asset on Asset Hub and gain sufficient community awareness to be accepted onto other parachains is through a smart contracts deployment in that same readily accessible place. The access part of the 0 to 1 problem is solved, a user need only come up with an idea good enough that other parachains want to integrate it.

Joe:

If there is a lot of demand for this tranche of blockspace, then the gas price will increase a lot, motivating contract developers to migrate to a contract chain or rethink their application architecture to work asynchronously.

Absolutely, if projects are so successful that they bog down the sectioned smart contract blockspace, the access problem has been solved and they should be motivated to move to another blockspace product of their choosing, and presumably users would be enticed to move with them.

1 Like
5

This case: EVM CCTP Contracts from Circle to bring liquidity of USDC from EVM L1/L2 chains into Polkadot. It’s here, right now as Asset 1337

https://statemint.statescan.io/#/assets/1337

But despite this important achievement, no one has a clue how to work with it today.

If you somehow didn’t know, Circle USDC “market cap” is 5x bigger than Polkadot and CCTP is Circle’s solution to run centralized bridges to improve user experience over “wrapped asset” bridges. The other major stablecoin (USDT) left Kusama.

Despite this, a quick check into what Asset Hub’s plans are for CCTP reveals an astonishing fact:

There is no plan from Assethub to address CCTP.

Having a non-system parachain like Moonbeam to have EVM Assethub Status is not what Circle and every day users would expect from a system chain and leaves the entire ecosystem with a “WTH were you Assethub guys thinking in not having a plan for CCTP?”

Seriously, what is the plan?

If there is ever a case where an OpenGov referendum should be needed for Asset Hub to make practical things happen over some idealism of AH’s barely used blockspace, this is it!

I understand that not having XEN blow up like Moonbeam is important. So @Noah 's idea that it be permissioned or @joe’s idea that it be restricted to 10% is useful – I think we would all want a fully jammed Asset Hub filled not with XEN but with CCTP. However, having no plan for CCTP will increase network effects for chains that have CCTP integration (Base, Arbitrum, Avalanche, …) and its imperative that AssetHub prioritize this most important case.

If the people in charge can’t come up with a plan, I consider that a sign of incompetence.

4 Likes
6

This will not be the case for much longer - in the coming weeks, HydraDX will be deploying permissionless asset registry, LBP & XYK pools. Anyone will be able to create an asset on AssetHub and immediately launch a pool for it on HydraDX. No governance required.

AssetHub doesn’t have to do everything - it just needs to the the hub for assets :wink:

9 Likes
7

Congrats! That sounds like a pretty useful feature for HydraDX, and we commend the permissionless approval strategy, but it doesn’t solve many of the connection problems that we’re mentioning. Has hydradx enabled smart contract functionality as well?

8

Wow that’s awesome!

9

As part of smart contract parachain on Polkadot this is not realistic.
Just having the pallet-contracts deployed wouldn’t bring any DeFi primitives to the Asset Hub. DeFi needs trusted indexers, oracles, developer toolings, …

Some questions that might be good to think about:

  • Who will do the maintenance of the pallet-contracts with runtime upgrades?
  • Who will do the BD to get the infrastructure ready for DeFi to be used?
  • Where will the funds come from to onboard those infra toolings?
  • Why isn’t utilizing XCM an option to focus on building those Asset Hub DeFi?
2 Likes
10

:100: :100: :100: :100: :100:

1 Like
11

While I understand and the appreciate the rationale behind the suggestion but I believe it is not the way to go for multiple reasons – a lot of them have been stated by other ecosystem agents above.

Asset Hub should be a hub for assets, that’s it. I understand the pain points, it’s useless for a retail user to create an asset on Asset Hub at the moment, but we are an evolving ecosystem. These pain points will be alleviated in the near term future.

As an ecosystem, we are still exploring the true power of XCM on the application layer but through quality product development the experiences can be built that make the whole of Polkadot ecosystem feel like a unified experience whilst in the underlying the apps use multiple parachains to build their product offering.

Plus, the points that Ivy suggests are going to be moot in a 24 months horizon. When you’ll be able to harness Polkadot’s cores for more than just parachains – you should ideally be able to deploy smart contracts on a Polkadot core that are able to interact with the Asset Hub through XCM.

Asset Hub should not be treated as the “home base” for DeFi on Polkadot. That is grossly unfair to parachain teams, who are the primary consumers of Polkadot’s offering, blockspace.

In my view, the problem that Ivy lays out can be solved with a mix of quality product development and Polkadot’s new roadmap.

5 Likes
12

Thanks - we are very excited for this to go live. And yes, we are indeed adding EVM smart contract functionality to HydraDX in order to allow integration of MetaMask - other smart contracts could be added but these would need to be “whitelisted” similarly to how you described in your original post.

1 Like
13

I struggle with this proposal. I obviously come at this from a biased perspective and I’ll confess I’m more familiar with Moonbeam and its offerings vs other chains like Astar, so I will speak from a Moonbeam centric perspective.

Adding ever more competing functionality to system parachains is a discouraging trend and imo the wrong way to go if you want to build a great ecosystem of chains. We saw this sentiment when the asset hub and the system dex were proposed. Both were very unpopular with existing parachain teams.

For this proposal, what is the problem we are trying to solve?
If it is to create a home for assets and defi on polkadot, a place that has a cohesive user experience, that can easily onboard users from ethereum and other ecosystems, and that has smart contract functionality, and is easily integrated with custodians, exchanges, etc, why can that not be a parachain like Moonbeam?

In the current setup Moonbeam to some extent competes with system parachain efforts like AssetHub (e.g. with xc20 and xcm enabled ERC20s) and BridgeHub (e.g. Moonbeam Routed Liquidity). From my perspective this is wasted, duplicative effort that could be put towards growing the ecosystem and onboarding more users.

I have asked various people why build system parachains with duplicated functionality vs supporting a chain like Moonbeam. The arguments fall into a few buckets:

(1) EVM is old / slow / bad technology, we need a Substrate native solution.
(2) We can’t pick winners, so a system parachain is neutral and doesn’t favor any one team over another.
(3) Institutions don’t trust parachains so we need system parachains for institutional adoption.
(4) The security of Moonbeam is weaker because it has its own token. It is much easier to governance attack Moonbeam because the market cap of GLMR is so much lower than DOT. So that makes it an unsuitable home for assets / defi / etc, and a possible weak link in the chain. Having a DOT secured system parachain is more secure.

Here are some of my responses to each of these points:

(1) EVM is old. Yes, it is. It isn’t as elegant as a Substrate native solution. But that being said, the market has spoken at this point. Especially with the L2s being for the most part EVM based. EVM has won as far as smart contracts are concerned. EVM is the least common denominator out there. If you want to integrate with exchanges, custodians, wallets, and onboard users, then EVM is the logical choice. Doing anything else brings with it a huge amount of friction and delays in time to market, which many parachain teams on Polkadot have discovered, and why many of them will likely end up including the EVM in their chain. EVM is the best way to onboard users from outside polkadot, into a familiar user experience. From there you can red pill them via xcm to other substrate based chains and substrate native functionality.

(2) We can’t pick winners. I would argue by not supporting parachains and building system parachains with competing features you are picking. The polkadot core is competing directly with parachain teams. If picking needs to happen, it would be better to put it to a DOT vote and let governance decide which existing parachains to support.

(3) Institutions don’t trust parachains. I’ve heard this from a number of people. I’m not sure I buy this. I’ve spoken with many institutions myself who are active onchain. What they need are the proper tools and custodians to be able to interact safely with the chains in question. On Moonbeam today there are multiple institutions that are active. Many of them are using Fireblocks as a custodian and to be able to safely interact with Moonbeam deployed protocols. As far as protocols are concerned, I understand that a given institution may not want to interact with a given specific protocol. But there is a Curve deployment on Moonbeam and a Uniswap v3 deployment coming soon. I find it hard to believe that institutions would prefer a system parachain with a bespoke substrate based dex implementation to Curve or Uniswap.

(4) There is a security concern on Moonbeam based on governance attacks. I admit, I understand that this could be a legitimate criticism and concern. Just based on economic value, it is much harder to governance attack a system parachain vs a parachain like Moonbeam. That being said I feel that there are solutions that could be found. The polkadot treasury could obtain GLMR for voting purposes to participate in and influence opengov decisions on Moonbeam. Another I have been thinking of is this. What if DOT holders were allowed to participate in opengov on Moonbeam using DOT? What if there were key opengov tracks they could use to protect the system from governance attacks. Like veto power, for example. If this gave DOT holders more confidence in Moonbeam being a key place for asset issuance and defi, I think it could be interesting to explore. The thing is, DOT holders already have the power to shut down Moonbeam by removing it as a parachain from the relay side. So all this would be doing is providing more granular control to DOT holders within Moonbeam.

I hope we can find a way forward that bolsters and supports existing parachain teams on polkadot vs creating ever more competitive system parachain functionality.

6 Likes
14

Will the smart contracts deployed to the EVM pallet have the capability to interact with the substrate-native side of the chain?

2 Likes
15

I 100% agree with this.

The ecosystem flip flops between “Polkadot should do just one thing – provide secure blockspace” and “We need more things to do on Polkadot.” While there are fair reasonings for both stands, we as an ecosystem need to come to a unified consensus on one.

The above has to be THE GOAL of the ecosystem.
I see Parachain and Polkadot ecosystem as one. There might be a part of the ecosystem that disagrees with me but the most optimum route to making Polkadot’s vision come true and ensure value flows to DOT is to support parachain & application teams.

Higher adoption for Parachain teams will drive higher value for Polkadot.

It’s all linked.

2 Likes
16

This is an inevitable and accelerating consequence of the basic incentive design of the system to which you are a leading contributor.

The economic gravity of $DOT is steadily sucking air out of the room like a black hole at the centre of the ecosystem.

The ‘community’ stumble on the roadmap and then Parity/Fellowship absorbs the talent, resources and ideas into the singularity.

This is not a criticism of Parity, just an observation per the conclusion to The state of DotSama.

You can see this effect everywhere when you recognise the pattern - see Polkadot App for onboarding will have a similar effect due to scope creep on ‘community’ apps such as Nova.

The great irony is that this is the Web2 playbook playing out in the home of Web3 per Chris Dixon’s famous post “Why Decentralisation Matters”.

image
image1362×586 22.6 KB

Centralized platforms follow a predictable life cycle. When they start out, they do everything they can to recruit users and 3rd-party complements like developers, businesses, and media organizations. They do this to make their services more valuable, as platforms (by definition) are systems with multi-sided network effects. As platforms move up the adoption S-curve, their power over users and 3rd parties steadily grows.

When they hit the top of the S-curve, their relationships with network participants change from positive-sum to zero-sum. The easiest way to continue growing lies in extracting data from users and competing with complements over audiences and profits.

Where this leads

In the end, the incentives lead in only one direction… to all the air being sucked out of the room.

Unless it’s not obvious, long term this isn’t a good look for anyone.

Here’s a useful visual metaphor.

What can be done?

Acknowledging the issue is one thing, knowing what to do about it is another.

The two most powerful forces in existence are $DOT and Coretime Demand.

The ONLY thing that will mediate the crushing power of basic incentives will be a necessary resistance.

This will come from consolidating talent, resources and capital into something approaching a rebel alliance through a strategy known as “the enemy of my enemy is my friend”.

These groups will then play positive sum games related to driving coretime demand see Rethinking incentives with coretime bounties, collectives and recoupable loans

All else is rearranging deckchairs on the titanic.

The good news

On a positive note, in Web2, there is no way to achieve this balance at scale.

Nor is there any practical way to iterate towards this in Bitcoin or Ethereum.

In this ecosystem, with the tools, talent and resources at our disposal we have a chance to buck the trend… to do so is the ultimate validation of a Web3 thesis. There is a lot at stake.

3 Likes
17

@joepetrowski Thank you again for lowering the ED and treating RFC #62 with high priority.

Here is a different RFC #66:

Add EVM+ink! Contracts Pallets to Asset Hub for Polkadot by sourabhniyogi · Pull Request #66 · polkadot-fellows/RFCs · GitHub

This is not just about defi+NFTs but also about enabling a new class of customer – Polkadot Rollups from Blobchains on Polkadot and Kusama and prepping AssetHub for Coreplay.

Can I get you and the Polkadot Fellows to critique it?

18

@joepetrowski Here is another route ( seeing as RFC #66 is just so popular … ) to add EVM to AssetHub for the explicit purpose of enabling USDC via CCTP:

  1. make contract deployment / storage super expensive
  2. make gas fees super high

Adjust 1+2 to be high enough that Circle CCTP contracts would be deployable and that USDC transfers would be affordable (like << $2) but not so cheap that AssetHub would be used by anyone but this USDC case. What do you think?

19

Commented on the RFC

1 Like