# Contracts on AssetHub Roadmap

**URL:** <https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513>\
**Category:** Tech Talk\
**Created:** [August 6, 2024, 4:30pm UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513 "2024-08-06T16:30:32Z")\
**Posts on this page:** 13\
**Page:** 4

<div class="post-metadata">

**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\
**Post date:** [December 26, 2024, 12:09pm UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/62 "2024-12-26T12:09:36Z")

</div>

> [@bruno](#):
>
> **Do cross-contract interactions** (instantiation, calls)
> 
> - Is this already possible? Can you share an example?

This is possible. Cross contract calls can be done using the normal Solidity syntax.

> [@bruno](#):
>
> Do Polkadot cross-chain calls

This will become possible through an XCM pre-compile that will allow executing, sending, and receiving XCM messages. At first, we will implement XCM. We can also look at other protocols or allow a more low level transport where other protocols can be built upon.

> [@bruno](#):
>
> Polkadot infrastructure on the Ethereum side

Agreed. We should have an Ethereum compatible DEX. We will have something similar to Moonbeam’s XC20 that allows interacting with AssetHub assets as if they were ERC20 contracts.

> [@bruno](#):
>
> **Precompiles to access underlying runtime features**
> 
> - Polkadot Hub runtime
> - a wrapper for smart contract developers to interact with Polkadot Hub pallet methods that are whitelisted

We will built pre-compiles for all relevant runtime features. Just exposing dispatchables won’t work because they can’t return data. They are also not stable enough and it is cumbersome to use them. Having pre-compiles for each API will make it easy to consume.

> [@boboski](#):
>
> is smoldot support polkavm？or json rpc api proxy？

As of right now PolkaVM is part of the runtime. So Smoldot supports it out of the box.

The RPC proxy is a different story. We made sure that its endpoints don’t become part of the client spec to not increase the burden of implementations like Smoldot. If you run Smoldot locally on your computer you can run the RPC proxy and connect it to Smoldot already just as if it was a full node. However, when you run Smoldot in the browser that is not possible out of the box. It will require some work to compile the proxy for the browser and incorporate it with substrate connect.

---

<div class="post-metadata">

**Author:** ![bruno](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bruno/32/4244_2.png) [@bruno](https://forum.polkadot.network/u/bruno)\
**Post date:** [December 28, 2024, 6:01am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/63 "2024-12-28T06:01:39Z")

</div>

Thanks for the quick response Alex.

Polkadot’s two main tenants: shared security and interoperability.

However, as we have learned, there are limitations to what can be built regarding synchronicity for dApps that want to leverage a cross-chain solution. JAM aims to alleviate this. I do believe it makes sense for certain operations to leverage cross-chain interactions and others simply do not scale in terms of composability. Developers will have to find a sweet spot for this or we, as stewards in Polkadot, should give them a clear and effective pathway to build decentralized applications in a multi-chain, multi-service world.

---

<div class="post-metadata">

**Author:** ![bruno](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bruno/32/4244_2.png) [@bruno](https://forum.polkadot.network/u/bruno)\
**Post date:** [January 5, 2025, 6:50am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/64 "2025-01-05T06:50:31Z")

</div>

I recently watched this [excellent video](https://youtu.be/GPuTt10dxKI?si=qCcem_PWz8u_2R_L&t=929) and there is mention of moving functionality from the Relay chain to Asset Hub:

 ![](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/0/0a0839a62a5ebfa37c5b2aba96f0b291669388b7.jpeg)

 ![](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/f03ff808a2d702bca47c593a5863b2a518fd9fe9.jpeg)

Since I am developing a project on this, do we have a roadmap of when this will happen?

---

<div class="post-metadata">

**Author:** ![Cyrill](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/cyrill/32/7339_2.png) [@Cyrill](https://forum.polkadot.network/u/Cyrill)\
**Post date:** [January 6, 2025, 7:41am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/65 "2025-01-06T07:41:09Z")

</div>

We [expect this to complete in Q3](https://forum.polkadot.network/t/asset-hub-migration-2025/11129). If it isn’t a one-shot we can add individual pre-compiles as soon as the corresponding functionality gets migrated. Out of curiosity, what is the project you are working on?

---

<div class="post-metadata">

**Author:** ![bruno](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bruno/32/4244_2.png) [@bruno](https://forum.polkadot.network/u/bruno)\
**Post date:** [January 6, 2025, 11:01am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/66 "2025-01-06T11:01:29Z")

</div>

I am part of a PBA alumni DAO working group.  
We are looking at creating a DAO for PBA.

At first, we will go with the standard multisig/proxy approach:

 ![PBA Voting DAO Multisig](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/d/d2b3f9cf658287eace620103c2f6bd1eedab5f96.png)  
Thanks to Leemo for the [above setup](https://www.youtube.com/watch?v=SYnpgcgfDsA)!

But with the advent of Solidity running on _native_ Polkadot, we are exploring the possibility of creating a Solidity smart contract for the DAO, to deliver a true Web3 experience. However, we are constrained to what is technically available.

I would love to have your team’s feedback on this! (and find alignment) Perhaps this could be the first real-world use case that could drive the first set of features for the Polkadot Hub.

Here are the different approaches I see:

 ![PBA DAO v1](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/6/6fd359f6f9eb610b1227d4dced75a7ede5f691c3.jpeg)  
The above is under the premise that:

- XCM is not available to use with Solidity
- OpenGov is not on Polkadot Hub
- There are no precompiles that could help build a more trustless solution

 ![PBA DAO v2](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/4/4c3240cfb53ee1da7a27613de549df4b54c9aefa.jpeg)  
The above is under the premise that:

- there is no XCM to use with Solidity
- OpenGov is on Polkadot Hub
- There is a precompile to work with OpenGov

 ![PBA DAO v3](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/c/cf9301097911f9ce04e94672b8c9f56669b62614.jpeg)  
The above is under the premise that:

- XCM is available to be used with Solidity
- OpenGov is on the Relay chain

---

<div class="post-metadata">

**Author:** ![Miles](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/miles/32/8423_2.png) [@Miles](https://forum.polkadot.network/u/Miles)\
**Post date:** [May 18, 2025, 12:29am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/67 "2025-05-18T00:29:08Z")

</div>

> [@Alex](#):
>
> Known gotchas are basically contracts which modify contract code. This is not supported in Solidity but requires dropping down to YUL assembly. Examples would be factory contracts specialized to deploy other contracts as cheaply as possible. This pattern wouldn’t work and have to be implemented differently (in a much easier way).

Is there a known solution for this? Just tried to deploy on Westend hub, my dapp depends on it and would love to launch on hub when it comes to Kusama or Polkadot. Is there an issue link I can follow? I’m pretty motivated to get this working, and hopefully it is an easier way.

---

<div class="post-metadata">

**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\
**Post date:** [May 18, 2025, 9:32am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/68 "2025-05-18T09:32:05Z")

</div>

> [@Miles](#):
>
> Is there a known solution for this?

Yes. Since we have on-chain constructors this pattern is simply not necessary. You can just do the customization in your constructor. When compiling a Solidity contract with our compiler it will not embed the actual code into the contract which contains the `create2` call. It just embeds the hash. So even when the contract you are deploying is big it will be still gas efficient.

---

<div class="post-metadata">

**Author:** ![Miles](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/miles/32/8423_2.png) [@Miles](https://forum.polkadot.network/u/Miles)\
**Post date:** [June 30, 2025, 12:21am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/69 "2025-06-30T00:21:31Z")

</div>

Do you have an example of this?

---

<div class="post-metadata">

**Author:** ![Ser.Otto](https://avatars.discourse-cdn.com/v4/letter/s/bb73d2/32.png) [@Ser.Otto](https://forum.polkadot.network/u/Ser.Otto)\
**Post date:** [June 30, 2025, 12:17pm UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/70 "2025-06-30T12:17:48Z")

</div>

> [@Miles](#):
>
> > [@Alex](#):
> >
> > Known gotchas are basically contracts which modify contract code. This is not supported in Solidity but requires dropping down to YUL assembly. Examples would be factory contracts specialized to deploy other contracts as cheaply as possible. This pattern wouldn’t work and have to be implemented differently (in a much easier way).
> 
> Is there a known solution for this? Just tried to deploy on Westend hub, my dapp depends on it and would love to launch on hub when it comes to Kusama or Polkadot. Is there an issue link I can follow? I’m pretty motivated to get this working, and hopefully it is an easier way.

Hello Miles, just checking if you’ve seen [this post](https://forum.polkadot.network/t/major-milestone-for-solidity-smart-contracts-first-part-of-the-preview-release-now-live-on-kusama/13506/14)? It’s the latest comms on the status of solidity smart contracts so might have some info you are after.

There’s also links in there to [log bugs and issues directly](https://github.com/paritytech/contract-issues/). I saw on another forum post you mentioned specific functionality you need, please feel free to log there to get it in the official “queue”. 🙂

---

<div class="post-metadata">

**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\
**Post date:** [July 2, 2025, 12:33pm UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/71 "2025-07-02T12:33:25Z")

</div>

You would just use the normal factory pattern. Solc will include the whole `Child` contract into `ChildFactory`. This is why people mess around with `EXTCODECOPY` in order to stitch together the constructor: `ChildFactory` will be too big otherwise. Our resolc compiler will only include the hash of `Child` into `ChildFactory`. As long as one version of `Child` is already on chain this will just work. This is because we keep the constructor of `Child` on chain. Upcoming versions of our tooling will make sure that the code of `Child` is already on chain when deploying `ChildFactory`.

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/// @title A simple contract whose instances we’ll deploy via a factory
contract Child {
    uint256 public value;
    address public creator;

    event ValueSet(address indexed setter, uint256 newValue);

    /// @param _value Initial value to store
    constructor(uint256 _value) {
        creator = msg.sender;
        value = _value;
        emit ValueSet(msg.sender, _value);
    }

    /// @notice Update the stored value
    function setValue(uint256 _value) external {
        value = _value;
        emit ValueSet(msg.sender, _value);
    }
}

/// @title Factory that creates new Child contracts
contract ChildFactory {
    /// @notice All deployed Child instances
    Child[] public allChildren;

    event ChildCreated(address indexed childAddress, uint256 indexed initialValue);

    /// @notice Deploys a new Child with the given initial value
    /// @param _initialValue The value passed into the Child constructor
    function createChild(uint256 _initialValue) external {
        // Deploy a new Child contract
        Child newChild = new Child(_initialValue);

        // Track it
        allChildren.push(newChild);

        emit ChildCreated(address(newChild), _initialValue);
    }

    /// @notice How many Child contracts have been deployed
    function childrenCount() external view returns (uint256) {
        return allChildren.length;
    }

    /// @notice Get the address of a deployed Child by index
    /// @param index Position in the allChildren array
    /// @return childAddr Address of the Child contract
    function childAt(uint256 index) external view returns (address childAddr) {
        require(index < allChildren.length, "Index out of bounds");
        return address(allChildren[index]);
    }
}

```

---

<div class="post-metadata">

**Author:** ![Miles](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/miles/32/8423_2.png) [@Miles](https://forum.polkadot.network/u/Miles)\
**Post date:** [July 10, 2025, 4:14am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/72 "2025-07-10T04:14:44Z")

</div>

Thank you for that explanation, that makes sense. I’ll give it a go on Westend.

---

<div class="post-metadata">

**Author:** ![Miles](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/miles/32/8423_2.png) [@Miles](https://forum.polkadot.network/u/Miles)\
**Post date:** [July 10, 2025, 4:43am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/73 "2025-07-10T04:43:52Z")

</div>

Do you know if any tests have been done for OpenZeppelin upgradeable contracts? They use an initialize function in place of a constructor. Maybe you’re talking about a different constructor? Thanks!

---

<div class="post-metadata">

**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\
**Post date:** [July 15, 2025, 9:46am UTC](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/74 "2025-07-15T09:46:11Z")

</div>

The OZ test suite passes: [GitHub - paritytech/evm-test-suite](https://github.com/paritytech/evm-test-suite)

The OZ upgradeable pattern dooes work on our platform in the same way. Even though we have on-chain constructors you still need to use the initialize function when using this pattern: Reason is that the proxy delegate calls the implementation contract in order to initialize the storage inside the proxy. It is an unrelated issue.

The storage of the implementation contract is never used and hence never initialized. A constructor doesn’t make sense here.

[Previous page](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513.md?page=3)