2022-10 - Grant Proposal - Swidge Defi Wrapper

Project Overview Swidge DeFi Wrapper Biz Dev


For this proposal, we’ll be reaching out to a set of bridges and liquidity providers to apply for grants in order to fund the development of protocol specific wrappers in order to integrate them into Swidge and increase the ecosystem’s awareness of Polywrap.

Project Details

Polywrappers will be written in Rust, compiled to WASM and deployed to IPFS so they can be consumed by the JS SDK by any developer. The wrappers of the different protocols will initially be taken care of by us, with the possibility of anyone to become maintainer in the future, or anyone to create wrappers for new protocols as things grow.

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.

dApp builders can benefit from our SDK, initially in JS and later on in more languages, so they wouldn’t need to learn how to interact with specific protocols and how to move assets to different chains in order to execute transactions against those protocols.

  • Who is your target audience?

The initial target is to give service to the Swidge.xyz platform, which is an any-to-any swap service provider and acts as a showcase and way for us to develop new user experience workflows. 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.

  • What need(s) does your project 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 yours 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.

On top of that, 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.


Team members

  • Fabian Weber
  • Sandro Puig


Proposal Justification

Starting business development to add new DeFi wrappers and expand the Polywrap ecosystem. Goal: obtain grant funding for building new DeFi wrappers.

Development Roadmap

Requested Grant

Wallet Stablecoin WRAP
swidge.eth $4.305,00 0

Milestone 1 - Protocols outreach

  • Estimated duration: 1 month
  • In FTE: 1 Business developer
  • Costs: $4,305
Number Deliverable Description
1 Wormhole proposal Described below
2 cBridge proposal Described below
3 Stargate proposal Described below
4 Axelar proposal Described below
5 1inch proposal Described below
6 OpenOcean proposal Described below
7 0x proposal Described below
Steps for each proposal:
  • Working through the documentation of the protocol
  • Prepare a detailed proposal with the roadmap of implementation
  • Coordinate with the Polywrap team to make proposal, supply possible requirements and receive feedback of the application

Estimated costs

Task Description Story Points
Wormhole proposal Working through documentation 1
Wormhole proposal Prepare proposal 0.3
Wormhole proposal Apply and coordinate proposal demands 0.2
cBridge proposal Working through documentation 1
cBridge proposal Prepare proposal 0.3
cBridge proposal Apply and coordinate proposal demands 0.2
Stargate proposal Working through documentation 1
Stargate proposal Prepare proposal 0.3
Stargate proposal Apply and coordinate proposal demands 0.2
Axelar proposal Working through documentation 1
Axelar proposal Prepare proposal 0.3
Axelar proposal Apply and coordinate proposal demands 0.2
1inch proposal Working through documentation 1
1inch proposal Prepare proposal 0.3
1inch proposal Apply and coordinate proposal demands 0.2
OpenOcean proposal Working through documentation 1
OpenOcean proposal Prepare proposal 0.3
OpenOcean proposal Apply and coordinate proposal demands 0.2
0x proposal Working through documentation 1
0x proposal Prepare proposal 0.3
0x proposal Apply and coordinate proposal demands 0.2
Total 10.5

Team Members

Role Commitment Rate Cost/SP
Software developer 0.5h/SP $100/hr. $50/SP
Business analyst 4h/SP $80/hr. $360/SP
Total per SP $410


By submitting this proposal, I understand that the DAO and my sponsor will be evaluating whether my work meets the acceptance criteria. If it does not, the DAO will determine what percentage of the proposal cost to pay, if any.

I also understand that I may not begin work until it is confirmed that the Snapshot proposal has passed.

[ X ] I agree


This is really exciting, but I worry that integrating new protocols is too easy / quick of a task that it might not require an entire grant from a given project.

@Kris @Dr.Manhattan can you comment on this?

I agree with @dOrgJelli’s remarks that integrating a new protocol isn’t a big enough task that would require an additional grant from a project If the idea is just to implement the new asset resolver with the given defiwrapper interface and implementation templates.

But if you want to make changes to the defiwrapper interface to serve your need better then it would be a more complicated and time-consuming process that might require additional grants.

To better evaluate this proposal and the need for the grants, I’d request @Fabbaist to answer whether they want to implement the new protocol implementations for the defiwrapper in its current form or would want to suggest changes to the interface while implementing the implementations. if you’d want to request changes to the interface itself, please describe the reasons and objectives of the proposed changes.

let me jump in.

So how i see it right now, what we would need is to create new wrappers for each of the protocols we’ll implement, something in the middle between the integrations you have made for uniswap v2/v3 and the defiwrapper’s asset-resolvers.

The reason behind it is that, for each protocol implementation, we would like to quote the swap estimated price/output from the protocol itself instead of fetching prices from coingecko. We also would need to implement each of the protocol’s calldata generation logic for the swaps. That’s for liquidity protocols.

Regarding bridge wrappers we would have to implement all the required logic to check if the bridge is enabled for X and Y chain, fetch accepted assets, maybe check thresholds, etc. We would also add methods to directly execute transactions on bridges, even though we wouldn’t be using that feature for Swidge.

Interfaces are yet to be defined, and the following examples are oversimplified, but it would be along these lines:


quote(tokenIn, tokenOut, amountIn) -> amountOut;
getSwapCalldata(tokenIn, tokenOut, amountIn) -> callData; // only returns calldata for custom execution
execSwap(tokenIn, tokenOut, amountIn) -> TxId; // directly executes with Ethereum/.. plugin


isEnabled(chainIn, chainOut, tokenIn) -> Bool;
execBridge(chainIn, chainOut, tokenIn, amountIn) -> TxId;

Since we want to create generalized wrappers that can later on be used by other parties to integrate any of the desired protocols, we’ll have to implement complete workflows for each protocol. That’s why we need to offer getCalldata as also exec functions.

At this point we see that we have to implement some new wrappers, and maybe modify or implement features on others too. Our language of choice is Rust, since defiwrappers is in AssemblyScript, we could create the new ones, but would have to either compromise in order to add the new features, or build specific separate wrappers. On the other hand, maybe we could work on building a new set of wrappers with slightly different features in Rust since the beginning.

Looking at this from a technical/business point of view, in your opinion, should we make defiwrappers grow or do we look at this as a new project?


This all sounds great to me @dna, I would love to support this development effort!

I would be in favor of this proposal if it used part of the budget for development, and part for looking for additional grants.

This sounds awesome! Thanks for explaining the requirements of the project in detail. I believe we need to properly define the scope of the project for this initial grant.

The first thing to work on would be specing out the MVP interface and a demo implementation for both dex and bridge aggregators as a POC. So instead of this being a business proposal, it should be a technical proposal with requirements being the development of the above interfaces and simple MVP.

After the successful MVP, you can create a new proposal with a similar structure as above for reaching out to more protocols for grants to implement more implementation wrappers.

1 Like

Hey @Fabbaist @dna, we talked about this today during the core devs call, and here are the general takeaways:

  • Everyone is super excited by this proposal, and wants to support it.
  • We don’t want you all to encounter needless friction / bureaucracy in order to get the initial support you’re seeking.
  • Feel free to structure the milestones however you see fit, and we’ll be there to help you reach your desired end-goals.
  • Our suggestions for ordering milestones (for your consideration):
    • Prototype: MVP Dex & Bridge Aggregation Interface
      • This could be built as a stand-alone aggregator, and added to the DeFi Wrapper as a dependency. Would defer to @Dr.Manhattan here.
    • Outreach: Reach Out To Protocols
      • See if they’d like to help sponsor your efforts in integrating their protocols to this new cross-chain & multi-language aggregator.
1 Like

If you’d like to make edits, you can simply edit the original post above, and then when finished we can post to Snapshot for final approval.

Can’t modify the initial post because I’m a new user apparently.
Can I get promoted please :pray:

The main proposal is modified now.
Looking forward to your repsonse.

Thank you for expanding on the technical side of things @Fabbaist! I see that the budget has gone from the initial 4k to 24k. This will require some more deliberation to come to a decision about. Will wait for others to add opinions before I state my own.

Also I think the first milestone is very ambitious (although I understand some may already be built). I’d recommend making the first milestone a bit smaller, I think this will help move the deliberation process along faster. The first version of this proposal at 4k was an easy “go”, but this is a bit harder, esp as a first proposal you’re making to Polywrap DAO.

hey @dOrgJelli, you’re right, we changed things from the initial proposal to the current one. I wish to add some context on why things went this way.

We’ve been working on this solution for a while, but with this new approach we wanted to validate the idea before we put our heads down. That’s around the time we came into contact with Polywrap, and someone from the team suggested we could send a proposal for some BD support. Our initial take was to get some support from you and then go knock other protocol’s doors to show some love, in the meantime I expected to focus on the MVP. Then you introduced the idea of proposing a technical approach with the expected roadmap to get a working product, and that is why we presented this.

I get that the sum now is far from what was proposed initially. I felt that since the milestone is titled “MVP” it made sense to put the entirety of the MVP on, so at the end of it we had something to really display. We will reduce the first milestone now by taking out the frontend and contract changes, as also the wrappers related to the token lists; those pieces aren’t core to the system and we can proceed to the outreach without them.

Interested to know what you think about this or how makes sense that we proceed. Also pleased if anyone else wants to add to the convo, or make suggestions to how we should amend the first milestone.

@dOrgJelli we have updated the proposal as @dna described.

@dna The proposed technical MVP is more of a fully speced version of the final wrapper interfaces which looks really good but you don’t need to go that far to validate the POC.

From my experience with defiwrapper, It can be trimmed a lot down to a monolithic POC wrapper and then can be scaled up to the proposed version once it’s fully functioning. By doing this, you may even get a better design for the proposed interfaces due to your experience building the MVP.

For your reference, this was how the defiwrapper was looking when I first released it: GitHub - defiwrapper/defiwrapper at v0.0.1 as you can see, it has come a long way since then and continue to improve.

Okay thank you for going back and forth a few times here. I like this proposal and would be happy to vote in favor of it!


Hey all, I think all of these developments sounds very interesting, and I’m excited to see them get built. But I do not think it’s sustainable for Polywrap DAO to directly fund the development of wrappers.

Typically, wrappers are built by the protocol teams themselves or by developer teams that get grants from those protocols.

1 Like

Thank you for the call yesterday everyone.
We have updated the proposal and went back to the Biz Dev only grant proposal as discussed.
Looking forward to starting the outreach from here.