how we understand decentralized intents

decentralization always comes at a cost, and in many cases the cost is convenience.

the buildup

my brother fab and i spent a full year building a swap & bridge aggregator (swidge), born from the burning pain we felt while degening around the blockchain and moving assets from one chain to another.

we wanted to have a nice tool to allow us move assets from anywhere to anywhere in a single user transaction, and while some tools already existed, like bungee, rango, via or transferto (currently jumper), they were far from ideal, and the UX that we expected was not really there.

we thought: how hard can it be. and so, with all the, let’s say, ingenuity, that youth gives you, but also with all the energy, we went into the journey.

first steps

we spent a good year learning about bridges, designs, infrastructure, and ways to move assets from one chain to another. trying to unify the interaction of dex’s and bridges, as well as finding the optimal path to maximize return for the user.

the easiest and fastest way to solve a technical challenge is normally by centralizing the execution, and so initially we went that route. we accepted some centralization trade-offs in order to be able to achieve the goal, which was “to offer a great UX”.

but the more we built and refined the system, the more we realized we were no different from any other aggregator out there, and we started to understand very deeply the compromises they had made.
custody of funds in transit, trusted relayers, off-chain path computation that the user can’t really verify. all those became “the new normal”, and we felt like step by step we were losing the love for the solution. we didn’t want to build that product.

we then understood we were no longer building something “for the fun of it”, and building “a great UX” was no longer enough leverage. we were directly competing with well-established teams that had at least a year of advantage on us on building that product.

we had to be different. we had to create something fundamentally better, unshakeable. something the community would want to use over all these products. and that’s when our real journey began.

the moat

we wanted to build an unstoppable aggregator, something that users could trust, own and contribute to, something that couldn’t be stopped or interfered with.

beauty is the easy part, it can be achieved with a good design. what we were ready to sacrifice was speed, and efficiency to a certain extent.
we thought that enough people would care about centralization issues, and that those would be our users. on top of that, we believed that with time, censorship would make more people open their eyes to the need of decentralization.

by building our initial MVP, and by talking to everyone in the community, we learned what pieces were the most critical for the users, in terms of risks. those are:

• frontend: supply-chain attacks
• backend: centralization issues
• bridge infrastructure: centralized relayers and pausable contracts

so having the real pain points well identified, we went on trying to solve them.

the solution

one afternoon, chatting with some members of dOrg, they introduced us to Polywrap, a project they were building, that we thought was amazing and the perfect solution for many issues, among them, those specified above.

Polywrap is a toolchain that enables developers to build Wasm-modules (using any supported language), that get deployed into IPFS.

that enables projects to code their SDKs in any language, and allow anyone to run them by using any of the Polywrap clients, which will fetch the wasm modules from the IPFS network.

these modules are loaded by the user browser to execute immutable logic, and in this way the backend piece can be totally removed.

we thought this was amazing, because by doing that we could address two of the biggest problems: supply-chain attacks, by using CID-pinned modules; and backend centralization, by letting users run their own path computation logic on their own computer.

more info on how Polywrap works and some example of what can be done with it: Polysnap

the last part, “local path computation”, is where the loss of speed and efficiency is introduced.

explain that please

let’s break down the diagram to see how that would work.

Alice wants to send her ABC tokens on chain 1 to XYZ tokens on chain 2, but the bridge does not support ABC tokens, nor XYZ.

she needs to swap ABC into something the bridge accepts, do the bridging, and then swap that into XYZ tokens.

Alice does not want to do three transactions, so she comes to swidge.

the frontend is served to the browser, and it immediately loads a wasm module that will run in her browser, safe and isolated (1).

that wasm module will go on to fetch all the information needed from chain 1 and 2, assert that the supported dex’s actually allow the path, and create an intent (2) (3).

the intent basically says something like:

• convert this much ABC to ETH
• send that to chain 2
• the received amount of ETH in chain 2 must be converted to at least XYZ amount and sent to Alice’s wallet

the reason we don’t pre-compute the swaps for chain 2 beforehand is because we don’t know the exact final output of first swap + bridge, so we need to compute the final swap later, once the assets arrived to the chain.

but let’s continue on the flow.

Alice sends her intent to swidge proxy (which eventually will be DAO governed, or revoked) (4), and the first swap and bridge steps happen (5) (6).

the bridge picks the events and relays the assets to the queue of the next chain (7) (8), and the intent sits there for a moment until one of the executors of the Gelato network picks it up.

Gelato is working with Polywrap to integrate their solution, which enables Gelato network to offer off-chain executors where the user (Swidge) can control the logic that gets executed, because the executors load the modules from IPFS.

at this point, the executor network sees the event (9), loads the module (10) and computes the final swap and broadcasts the transaction onto chain 2 (11), which executes the last swap and sends the XYZ tokens to Alice’s wallet (12) (13).

clearing some points

unstoppability

in some sense, an aggregator can only be as unstoppable as the services it aggregates. obviously we can mitigate our own risks by using all this architecture, removing our backend and giving all the control back to the user, but if the swaps are still provided by 0x API and the bridging is done by Multichain, then unstoppability is questionable.

that’s why we like the local path computation approach. it’s up to the users to decide their risk model and the mode they want to use to compute their path.
we, and anyone in the community, can implement any new provider, that can then be appended into the list of available modules, and the user can decide which providers want to use.

in order to have a new provider added, the ENS our app loads its content from must update the reference to a new CID.
a DAO would be the owner of that ENS, and in this way the community can decide which providers should be enabled and which shouldn’t.

we assume the community would be pro-active and knowledgeable enough to keep out malicious code.

fee structure

the protocol would have no direct fees, and we would consider proposing to the community to keep any positive slippage as protocol revenue, either to incentivize members to integrate new providers, pay for maintenance costs like the ENS, or to simply distribute among the community.

gas on destination

the second transaction must be paid, and subsidizing it is not a sustainable option. there’s different ways to solve this, but we think having users attach an approximate amount on the first chain would suffice. internally we would have the system to rebalance this into the Gelato network executors.

if something goes wrong

if the last swap cannot be satisfied inside the slippage terms the user set, the bridge amount will simply be transferred to the user.

wrap up

so basically, for us, a decentralized intent is a signed declaration of a desired outcome, that the user generates without the need of any third-parties, and that can be executed without requiring involvement of any centralized parties.

x