0x cross chain functionality - Swidge MVP

📜 Treasury Grants
1

0x cross chain functionality - Swidge MVP

Overview

We apply for support from 0x treasury to build out Swidge MVP, the first fully decentralized omni-chain aggregation protocol. Swidge is a future proof, decentralized omni-chain liquidity aggregation protocol.

The Problem

  1. No cross-chain functionality
  2. There is no open source provider for cross-chain aggregation infrastructure
  3. Bridge/DEX aggregation → Causes 0x protocol costs in the long run

The 0x Protocol currently has no cross-chain functionality that would connect the different chains and the liquidity aggregation 0x protocol offers. 0x’s Mission is to build infrastructure for the emerging crypto economy, connecting liquidity across chains is therefore a core building block of reaching that vision. With Swidge we aim to extend 0x protocols functionality by allowing the routing through bridges and one click cross-chain any-to-any swaps.

With other bridge and DEX aggregators, 0x would need to trust their route building and can not execute cross-chain swaps with their own proprietary logic. This approach limits functionality and composability for 0x. Swidge provides the full functionality with maximum composability, acting as an open source building block for the 0x protocol.

0x Protocol & Swidge

  1. Open Source cross-chain aggregation protocol
  2. Allowing maximum composability among bridges/DEX/ecosystems
  3. Runs on the client side, fully decentralized

Together with 0x we would like to create the new standard for cross-chain aggregation and decentralized & free value flows. Initially we will focus on aggregating the interoperability layer, which at this point in time is not a part of the 0x protocol.

In the future the Swidge Protocol aims to be the open-source standard for interacting with Web3 liquidity. This approach aims to allow developers and users a safer and less centralized way to interact with aggregated liquidity and enables future proof aggregation by opening up a path for protocols and ecosystems to aggregate themselves. We aim to decentralize aggregation infrastructure and make it available to protocols like 0x, which are building business structures on top of this.

Swidge is building a decentralized open-source aggregation protocol, allowing proprietary logic to be executed against all aggregated protocols. The MVP version we will focus on aggregating message passing bridges (Options: Wormhole, cBridge, Axelar, Stargate), allowing 0x to connect the current cross-chain deployments and enable 1-click any-to-any swaps while staying decentralized.

0x Integration & Support:

  • Meeting with the 0x Labs team to gather feedback on the solution and technical integration
  • We’d like to present the tool and the underlying infrastructure on podcasts and other media channels that the 0x ecosystem is partnered with.

What Swidge does:

  • Abstract Web3 complex liquidity flows for developers, by build a liquidity middleware layer for developers to interact with, from any programming language
  • Lay a decentralized foundation for widespread DeFi adoption
  • Simplify developer experience 100x when interacting with Web3 and help make Web3 more secure, leveraging WebAssembly and Polywrap

How Swidge does it:

  • Integrate all liquidity providers in a decentralized manner, chain and programming language agnostic
  • Enable client side execution of the Swidge core functionality by deploying all code to IPFS

Team

Team members

  • Fabian Weber
  • Sandro Puig

Contact

Team’s experience

Swidge team has been dedicated to building a liquidity aggregation solution for the past year. We built a working product by integrating every other existing aggregation solution as also some of the main liquidity providers and bridges.

This experience has allowed us to get a good feel of the different solutions out there, and to realize the need for something better.

We are supported by the Polywrap DAO team. Polywrap’s technology is the underlying infrastructure that enables Swidge to build this decentralized aggregation protocol. (Polywrap - Enter the Composable Future)

Development Roadmap

Requested Grant

Wallet Stablecoin
swidge.eth $30.000
  • Total Estimated Duration: 3-4 Weeks
  • Full-Time Equivalent (FTE): 2 Dev
  • Total Costs: $30.000
  • Start Date: ASAP

Milestone 1 - 0x MVP

  • 0x Polywrapper: Polywrapper in Rust that enables the Swidge core Wrapper to interact with the 0x protocol capabilities.
  • 0x contract integration: Implementation that will enable the core on-chain router to communicate with the 0x system.
  • Bridge Polywrapper: Polywrapper in Rust that enables the Swidge Core wrapper to interact with the bridge protocol capabilities.

This milestone is scoped and all components are understood, we don’t foresee any blockers or dependencies at this point in time.

Number Deliverable Description
0a. License GPLv3
0b. Documentation We will provide both inline documentation of the code and a basic tutorial that explains how a user can interact with the wrapper
0c. Testing guide Core functions will be fully covered by unit and e2e tests
1. 0x Polywrapper - Write graphql schema for protocol actions:
- check if the channel between Token A and B is enabled
- quote if amount X of token A is swappable to token B
- Compute the output amount and the address
- Make transaction
- Implement graphql schema methods in Rust using Polywrap Http and Ethereum plugin
- Write unit tests suite for the core behavior
- Deploy polywrapper to IPFS
2. 0x contract facet - Write contract facet for on-chain infrastructure to be able to communicate with the protocols contracts & deploy on every live EVM chain
3. Bridge Polywrapper - Write graphql schema for protocol actions:
- check if the channel between Token A and B is enabled
- quote if amount X of token A is swappable to token B
- Compute the output amount and the address
- Make transactio
- Implement graphql schema methods in Rust using Polywrap Http and Ethereum plugin
- Write unit tests suite for the core behavio
- Deploy polywrapper to IPFS

Estimated costs

Task Description Story Points
protocol contract facet Write the contract facet 2
protocol contract facet Deploy to EVMs 2.5
0x protocol Polywrapper Write graphql schema 1.5
0x protocol Polywrapper Implement schema methods 4
0x protocol Polywrapper Deploy to IPFS 0.3
Bridge protocol Polywrapper Write graphql schema 1.5
Bridge protocol Polywrapper Implement schema methods 4
Bridge protocol Polywrapper Deploy to IPFS 0.3
Smart Contract Upgrade Upgrade the SC 0.7
Total 16.8

General Ecosystem Fit

  • Where and how does your project fit into the ecosystem?

Swidge enables any developer to use cross-chain liquidity in a safe and abstracted way, while having the certainty that every piece of the system is decentralized. This is a core feature in tomorrow’s interconnected DeFi ecosystem.

  • Who is your target audience?

The Swidge protocol is created to be a substantial piece of infrastructure that any developer can use to move any asset and interact with any protocol across any chain. The Swidge Protocol will provide its Core Wrapper SDK (Swidge SDK) to protocols for B2B integrations. This allows them to interact with all aggregated protocols in a decentral manner as Swidge does not run any centralized backend.

  • What need(s) does Swidge meet?

Swidge meets the needs of dApp developers who want a simple way to integrate different liquidity protocols from a variety of chains into their dApps. With our SDK developers will be able to interact with any protocol in an abstracted manner, simply executing standardized methods on the SDK.

  • Are there any other projects similar to Swidge in the ecosystem?

There are many projects trying to solve interoperability of liquidity protocols across chains, but so far everyone is relying on centralized logic in order to take decisions on which is the best route, and in many cases even to encode the transaction for the on-chain contracts, which is a huge liability and a single point of failure on what should be part of a decentralized financial infrastructure.

Swidge comes to solve this issue by giving the user ownership of the last piece of the system, the transaction encoding process. With Polywrap wrappers holding the logic of the algorithm that checks the possible paths and generates the calldata required for the contracts, we eliminate any single point that could be risky and exploitable at a big scale. Additionally, thanks to the nature of WebAssembly, being sandboxed and safer than other runtimes on the browser, it adds a layer of security to these delicate steps where transaction generation could be spoofed with different receiving addresses.

2 Likes
2

Hello @Fabbaist - Please see initial questions below:

  1. The proposal references integration with 0x Protocol, but can you clarify whether the integration you are proposing is at the core protocol contract level (github link) or is it with the API (github link)?

  2. If it is the API, would you need an enterprise API key and have you factored in any potential associated costs? (Note: We are unaware of there currently being a cost, but if there is one now or in the future, would you need to request additional funds to pay for it?) Alternatively, would you expect to run your own instance of the API?

  3. Reference “Bridge/DEX aggregation → Causes 0x protocol costs in the long run”
    Please explain/elaborate on what you mean by this.

  4. Reference “0x Integration & Support: Meeting with the 0x Labs team to gather feedback on the solution and technical integration”
    Generally we have treated any reliance on support from 0x Labs as a risk factor when evaluating grant proposals. Since you appear to be asking for support from 0x Labs, is there an arrangement already in place that would be a mitigating factor here? If not, please explain in more detail the type and level of support you expect to need and we would also ask for someone from Labs to weigh in as to whether they would agree to provide the support requested.

  5. If I understand it correctly, you are proposing to integrate 0x technology into your SDK via a wrapper, enabling developers to source black box liquidity from Swidge “as a service” where 0x would be one of many liquidity sources. Is this correct? If so, does this mean that any existing 0x integrators would not have access to the cross-chain functionality, i.e., that the functionality would only be available via your SDK?

  6. Please provide information on other Swidge and/or Polywrap integrations already complete or in progress.

  7. Bridges introduce security risks. It isn’t clear how your solution addresses security risks. Please describe any potential security risks associated with an integration and mitigation steps.

  8. Reference “Development Roadmap” - Your proposal calls this “Swidge MVP” and refers to “Milestone 1 - 0x MVP”. If this is an MVP, would the work you are proposing represent a complete integration or would there be additional work that would require additional funding in the future?

1 Like
3

Hello Nikita,
Thank you for the initial questions.

  1. The integration is going to be on both the contract level as well as the API level.
  2. Yes, as we would like to use the API key. We would like to access the entire liquidity available, both on-chain and Market makers. Additionally, we are aiming to be a decentralized protocol and don’t want to use servers.
  3. Here we assume that aggregating bridges results in concrete costs (developers doing work), this cost could be offset by Swidge and a community building approach in the future.
  4. We rather not call this support, this should be called feedback from the 0x Labs team on the solution. This answer and the next one on Swidge “as a service” or Swidge as it’s own SDK are related.
  5. This is correct, we are integrating 0x and it is the main source of liquidity. Also existing 0x integrators would not have access to the cross-chain functionality initially and we believe this to be good for the MVP. In the future it would be possible for 0x to integrate Swidge SDK and offering cross-chain functionality on the 0x API, maintaining the current infrastructure and adding cross-chain functionality. This would allow the current protocol (smart contracts) to stay the same and Swidge creating the cross-chain interactions.
  6. This is the MVP of Swidge so there are no other integrations completed at this point.
    Polywrap has integrations with Substrate (Polkadot), NEAR, Tezos and EVM compatibility. There also is a Uniswap V2 and V3 wrapper (GitHub - polywrap/integrations: Polywrap Integrations)
  7. We address security risks by allowing the integrators to pick a set of bridges that they prefer on the SDK. Apart from that, we are able to monitor bridges in accordance to certain security frameworks from the likes of L2Beat.
  8. The answer to this is layered. The MVP is a complete integration of 0x, however there are many bridges out there that can be aggregated and it will require additional work to cover many/all of them. However the funding for this aggregation can potentially come from other sources, such as the ecosystems 0x is live in or the respective bridges that would like to be added to the solution.
1 Like
4

Thank you for your answers. Please see followup questions below.

  1. Can you please describe at a more granular level what specific technical integration is at the core protocol level and what is with the API? Have you already requested an API key from 0x Labs? If so, have you received one? If not, is your roadmap start date dependent on receipt of an API key?

  2. If your solution is dependent on feedback from 0x Labs, please describe your definition of feedback in more detail (for example, type, timing, format, etc.), and we ask for 0x Labs to answer as to whether or not they agree to provide it.

1 Like
5

Hello Nikita,

Apologies for the long response time.

  1. The integration on protocol level includes the routing smart contract that routes to the bridges SC that will be integrated on both the sending and receiving chain. The contract will talk to the 0x contracts on both chains.
    On the API level, we’ll need to quote the swaps on the endpoint of the chains that the user wants to swap from and to. This will be combined with the bridging process to create the calldata for the transaction.
    We have not requested an API key, will do that later this week. However the roadmap state is not dependent on the reception of the API key.

  2. I’d like to state that we are not dependant on feedback from 0x Labs. Our thought here is to give 0x Labs the opportunity to provide feedback on the solution. This could be a 15-30 min call with a PM or developer from 0x to talk about the technology and see which synergies can be created.

1 Like
6

Hello @nikita
I’m bumping this one.
Would love to know if we’ve been able to answer all the questions and see if we can start building cross-chain functionality for 0x.

7

Hello @Fabbaist :wave:
Generally, the next step would be to hold a temperature check snapshot vote, and if that is successful, it could be moved to an onchain treasury vote. However, there are a couple factors that you should be aware of first.

One, unfortunately there hasn’t been any other community engagement on this post, so it’s hard to determine how much community support there might be for your project if it were to go to a snapshot vote. Additionally, creating a snapshot vote requires holding 10k ZRX.

Two, last week there was an onchain treasury vote for another grant, and it failed to make quorum. It’s possible that this situation could change in the next few weeks via an experiment to improve governance participation, but it’s hard to say right now.