Worked with · 07 of 12Tradingdefi.app
defi.app
I collaborated with the Defi App team on work around cross-chain execution, liquidity routing and the infrastructure that sits between users and fragmented DeFi markets.
Behind one swap
One of the main questions I spent time on was what actually has to happen behind a simple action like swapping one asset for another. From the user’s perspective, the transaction can look like a single trade. Underneath it, the system may need to choose between liquidity providers, move value across chains, account for gas and slippage, and decide which execution path has the highest probability of completing successfully.
Fig. 1What one swap asks of the system
- 01One actionSwap one asset for another
- 02LiquidityChoose between providers
- 03ChainsMove value across
- 04CostsGas and slippage
- 05PathThe one most likely to complete
Intents
Defi App uses an intent-based execution model for this. Instead of requiring the user to choose a bridge, DEX and route manually, the user specifies the outcome and the execution layer searches across different sources of liquidity. I looked at how that abstraction changes the way execution quality should be measured.
Execution quality
The cheapest quoted route is not necessarily the best route. Liquidity depth, gas, bridge costs, failure probability and the number of steps involved can all change the final result. This becomes particularly important when the trade crosses chains or when liquidity is fragmented between several venues.
Fig. 2What changes the final result
- Liquidity depth
- Gas
- Bridge costs
- Failure probability
- Number of steps
The wallet layer
I also spent time looking at the wallet layer. Defi App combines EVM smart accounts with Solana wallets and abstracts much of the signing and gas management from the user. That creates a very different experience from traditional DeFi, but it also means that wallet architecture, execution and routing need to work together. A failure in one layer can surface to the user as what looks like a simple failed trade.
Fig. 3Layers under one trade
- The userSpecifies the outcome
- Wallet layerEVM smart accountsSolana walletsSigning and gas
- Execution and routingSearches across sources of liquidity
- Venues and chainsFragmented liquidity
Outside infrastructure
Another part of the work was understanding the role of external infrastructure. Defi App does not operate as an isolated venue. Its execution layer connects to providers such as 1inch, Jupiter, Relay, deBridge and other liquidity and routing systems. Wallet infrastructure also depends on partners including Dynamic and Turnkey. I looked at these dependencies as part of the product rather than treating integrations as interchangeable APIs.
Fig. 4Dependencies that are part of the product
- 1inchLiquidity and routing
- JupiterLiquidity and routing
- RelayLiquidity and routing
- deBridgeLiquidity and routing
- DynamicWallet infrastructure
- TurnkeyWallet infrastructure
Yield
Yield aggregation created a similar problem. When several protocols offer yield on the same asset, comparing APY is only the first step. The route into the position, the underlying protocol, liquidity, withdrawal path and any asset conversion required on exit can matter as much as the displayed return.
What I took from it
The broader question throughout the collaboration was how much DeFi complexity can be hidden from the user without hiding the information that still matters for a financial decision.
That became the most useful way for me to think about Defi App. The product is not simply another interface on top of DeFi. It is an execution layer that has to turn fragmented wallets, chains, liquidity venues and protocols into a transaction that feels like one action to the user.
Materials
Public pages about the company and the programs around this work.
Screenshot, Oct 5, 2026
Defi App documentation
Intent-based swaps and execution
How the intent-based execution model routes a swap across chains and liquidity sources.
Further reading