1inch vs 0x: Why We're Using Both (At Different Stages)
There's a lazy framing that treats 1inch and 0x as direct competitors — "pick one aggregator and stick with it." That framing misses the point of both protocols.
They solve different problems. Using the right one at the right stage is a product decision, not a tribal preference.
Here's what we're building with Capital Engine, how we thought through the choice, and where each protocol sits in the roadmap.
What they actually are
1inch is a DEX aggregator that splits trades across multiple liquidity sources to find the best execution price. Send a swap request, get back a route that might touch Uniswap, Curve, and Balancer in a single transaction. The user experience is a clean UI at app.1inch.io with a well-understood swap interface.
0x Protocol is liquidity aggregation infrastructure. Their Swap API covers the same ground as 1inch — query for a quote, get calldata back. But 0x has two products that 1inch doesn't:
- 0x Gasless API: meta-transaction swaps where a relayer pays the gas. The user signs an EIP-712 message; they never see a gas prompt.
- Permit2 integration: replaces the
approve()transaction (required before any DEX swap) with a signed message. One fewer popup, one fewer transaction, one fewer moment where users abandon the flow.
Those two additions change what's possible at the UX layer.
The problem we're solving
Capital Engine's north star is: your user thinks about the app, not the wallet.
Porto passkeys removed the seed phrase and extension install. Now the question is: what's left in the way between "I want to yield on my USDC" and "done"?
Without routing: the user has to manually find the right pool, switch to the right chain, figure out the token addresses, go to a DEX, set slippage, wait for the approve() transaction to confirm, then execute the swap. Every one of those steps is a dropout.
With routing, the gap shrinks. The question is how much of that gap you can close, and when.
Iteration 3: Why 1inch
Capital Engine's Iteration 3 is about showing routing intent, not executing it. The user sees a pool they want, clicks "Route via 1inch," and lands on 1inch with source token, target token, and amount already filled in.
Three reasons this is 1inch and not 0x:
1. Deep-link URL scheme
1inch has this:
https://app.1inch.io/#/1/simple/swap/0xA0b8.../0xae7a...?inputCurrency=500000000
Pre-fill source token, target token, amount in raw units. The user lands on a polished swap UI, sees the route, adjusts slippage if they want, and executes — all on 1inch's interface, not ours.
0x has no equivalent. Their protocol is infrastructure: you get quotes and calldata back, but you're responsible for the execution UI. If we used 0x at this stage, we'd need to build a complete swap execution interface before shipping a single line of routing logic. That's premature.
2. No API key required for intent
The 1inch deep-link is a URL. It doesn't require an API key. It doesn't require a server call. It doesn't require us to touch the 1inch API at all.
0x's Swap API and Gasless API both require API keys. At the intent stage — where we're showing "here's where you'd route this capital" without executing anything — there's no reason to introduce API key management, rate limits, or server-side quote fetching.
3. User familiarity
1inch is the most-used DEX aggregator by volume. When a user lands on app.1inch.io, they've probably been there before. The interface is familiar. That matters when you're handing off execution to a third party.
Iteration 5: Why 0x Gasless
In Iteration 5, Capital Engine moves from routing intent to actual on-chain execution. The allocation wizard graduates from "here's where you'd put your money" to "done — your capital is deployed."
That's when the 0x Gasless API becomes essential.
The friction math
Current friction for a USDC → Aave USDC deposit:
approve(USDC, amount)transaction — confirmation popup, gas fee- Wait for block
supply(USDC, amount, ...)transaction — second popup, second gas fee
With 0x Gasless + Permit2:
- Sign EIP-712 message (hardware-backed via Porto passkey, no popup on Face ID)
- Done. Relayer submits both operations, pays gas, deducts from output.
The user never sees the word "gas." They never pay for gas explicitly. The experience collapses from two on-chain transactions plus a permission approval to a single biometric confirmation.
Why this pairs with Porto session keys
Porto session keys (EIP-7702) let the user pre-approve a budget: "allow up to $500 of USDC deposits to approved Anchor pools for 24 hours."
Combine that with 0x Gasless:
- First deployment: one Face ID confirmation to set the session key
- Subsequent rebalances within the budget: zero user interaction
That's not a DeFi app anymore. That's a fintech app that happens to be running on a public blockchain.
The flow becomes:
User: "Deploy $500 to Anchor pools." App: does it. User: done.
No seed phrase. No extension. No gas. No approve transaction. No signing popup (within the session). This is the UX that doesn't exist anywhere in production DeFi today.
Permit2 is the detail that unlocks it
Permit2 (0x's implementation of ERC-2612 for non-native tokens) turns the approve() transaction into a signed message. EIP-712, hardware-backed, verified by the relayer.
Without Permit2, you still need a separate approve() on-chain transaction before every swap — even with gasless execution. The combo of Gasless + Permit2 eliminates the last remaining source of friction before execution.
The decision table
| 1inch | 0x | |
|---|---|---|
| Deep-link URL scheme | ✅ Yes | ❌ No |
| Routing intent (no execution) | ✅ Perfect | ❌ Overkill |
| API key required | Depends (deep-link: no) | Yes |
| Execution UI | External (app.1inch.io) | You build it |
| Gasless meta-transactions | ❌ No | ✅ Yes (Gasless API) |
| Permit2 integration | Partial | ✅ Native |
| Best for Iteration 3 | ✅ | |
| Best for Iteration 5 | ✅ |
What this signals architecturally
This isn't a "we'll migrate later" decision. It's a deliberate two-phase architecture:
Phase 1 (Iteration 3): routing intent layer. The app becomes a discovery and planning tool. Users learn what 1inch is and how routing works. We collect zero routing state — it's entirely client-side, no backend.
Phase 2 (Iteration 5): execution layer. We integrate 0x Swap API for calldata generation, 0x Gasless for meta-transaction submission, and Permit2 for tokenless approvals. This adds a server component (relayer coordination, transaction status tracking), but by then the user has already bought into the product.
The transition is clean: RouteButton today opens app.1inch.io. In Iteration 5, RouteButton calls /api/execute, which calls 0x Gasless, which submits to chain. The component interface doesn't change — only the destination.
A note on 1inch Fusion+
1inch has its own answer to gasless execution: Fusion+, their intent-based swap protocol. Resolvers compete to fill orders; the winning resolver pays gas.
Worth watching. But Fusion+ introduces resolver dependency (your trade needs a resolver to pick it up), and the order model is more complex to integrate than 0x's relayer. At the current stage — where we want something auditable, well-documented, and straightforward to integrate — 0x Gasless is the cleaner choice.
If Fusion+ matures and the resolver network deepens, revisiting is reasonable.
The bottom line
Use the right tool for the moment you're in.
1inch for routing intent: it's a URL and a well-known interface. Zero backend, zero API key, zero execution risk. Users get a professional swap UI for free.
0x Gasless for execution: it's the only production-ready path to meta-transaction swaps with Permit2. Combined with Porto session keys, it closes the last mile of UX friction — the gas prompt and the approve transaction — and turns Capital Engine from a read-mostly tool into something that actually moves capital without asking for permission twice.
Both are necessary. Neither is a compromise.
Capital Engine is live at web3.hyperdrift.io. The routing integration (Iteration 3) ships this week. Iteration 5 execution layer is on the roadmap.
Get weekly intel — courtesy of intel.hyperdrift.io