Deployment of 0x Protocol on additional chains

I am planning to deploy the 0x protocol on additional chains to explore potential opportunities, particularly considering Blast, which is set to launch its mainnet on February 29. Blast seems like a promising candidate due to its substantial Total Value Locked (TVL) of almost 2 billion and over 157,000 users. Additionally, they are offering an airdrop for mainnet dapps, presenting an opportunity for the 0x DAO to capture value and be a first mover on this upcoming Layer 2 (L2).

I have been seeking technical advice from 0x Labs on the best path to accomplish this. Currently, the technical documents available for deployment can be found here: link to documentation, and the migration scripts are available here: link to migration scripts. I have posted on Discord, but unfortunately, I haven’t received a response yet. Additionally, I aim to work closely to improve the documentation regarding how to deploy the protocol and identify the minimum requirements for it.

The minimal set of features that should be deployed includes:

  • Limit Orders
  • NFT orders
  • Fee feature
  • Uniswap feature

I am eager to receive feedback on this and would appreciate any assistance or guidance in this deployment process. Thank you.


There is a dedicated repository that has been opened by the labs team for deploying version 4 of the 0x Protocol on zkEVM. You can find it here: link to repo.

This repository should prove useful for deploying on other chains as well. However, I’d like to highlight some considerations regarding the features to include. For instance, there’s no standalone “Fee feature.” I believe what’s meant is the “AffiliateFeeTransformer,” which consequently requires deploying the “TransformERC20Feature” alongside it.

When utilizing these transformers, it’s essential to create a bridge adapter for the target chain. You can find examples for current chains here: link to bridge adapters.

While the provided script seems capable, it’s crucial to acknowledge potential risks. Deploying outside of the labs team’s expertise, especially given the intricate structure of the proxy, could lead to security vulnerabilities. The primary concern lies in potential approval exploits since the proxy holds user approvals.

Furthermore, there’s a question regarding ownership of the proxy. Thus far, Labs has managed this aspect. However, with an external deployment, we need to consider whether it can be deemed official and how governance will be handled.

I believe addressing these points will help ensure a smooth and secure deployment process.

Thanks for the link to that repo, I must missed out.

There is an issue with no answers from 0x Labs regarding their roadmap and which networks they want or will deploy. Essentially, they are like a black box that no one knows about. At least, as a delegate, I have no clue about their plans for the protocol moving forward.

Blast seems a good opportunity to 0x protocol get on first, so far no answers or neither help from 0x Labs folks on my questions regarding deployment on Discord, that’s why I moved the discussion here to the forum.

The optimal approach would be for the Governor contract to be held by the DAO. We can then create a mapping of good candidates for these deployments, establish a public roadmap, and define minimal metrics that a chain should meet to be considered for deployment.

You mentioned security reasons. It is highlighted that security issues could occur with a new type of transformers, and they should be carefully deployed to avoid impacting the other transformers. My plan is to deploy the ones that already exist and have proven to be secure so far.

Finally, I believe the best approach to this is to create a dedicated DAO team to assess these new deployments publicly. I can offer to be a member of this team.


In my opinion, if the goal is for this deployment to be recognized as an official 0x deploy, considerable time and planning will be necessary, especially if Labs is not involved in the process.

Currently, our governance structure remains unclear, and we’re eagerly awaiting the new governance migration. Even with that in mind, there’s uncertainty about how we’ll manage multi-chain instances of the protocol.

It’s important to note that deploying independently means you won’t obtain the same proxy contract address as on other chains. Only Labs has the capability to achieve this as they control the deployer wallet.

That being said, I believe you possess all the necessary tools to deploy the code and integrate it into your dapp. This allows you to make progress on your project while ongoing discussions about governance take place.

1 Like