Stani Kulechov shipped the first version of Aave in 2020 with protocol mechanics that redefined decentralized lending.
The smart contracts were — and remain — some of the most sophisticated in DeFi. The interface that sits on top of them was designed by engineers for engineers, and it shows in exactly three places.
Every DeFi product that has shipped since faces the same three moments. Almost none of them get all three right.
These are not hard design problems. They are ignored design problems.
Screen One: The Approval Transaction
What it is
Before a user can deposit, swap, or stake most ERC-20 tokens, they must sign an approval transaction. This transaction grants a smart contract permission to spend tokens from their wallet.
It costs gas. It takes time. It is not the thing the user came to do.
What most products show
Approve USDC
[Wallet popup opens with hex data]
Gas: ~$4.20
No context. No explanation of why this is happening before the actual action. No indication of whether this is a one-time cost or recurring. No information about what permissions are being granted.
Robert Leshner, the founder of Compound, has described the approval transaction as one of the most consistent drop-off points in DeFi onboarding. Users encounter a transaction they did not expect, do not understand, and cannot distinguish from a potential scam.
What the screen should do
✅ "First-time setup — one transaction required before you can deposit."
✅ "This approves the Aave contract to move your USDC. You will not be
charged again unless you revoke and re-approve."
✅ "Estimated cost: ~$4 · Takes about 20 seconds"
Three sentences. The drop-off rate is not a user behavior problem. It is a communication problem.
Screen Two: The Risk Display
What it is
DeFi products involve real financial risk. Liquidation thresholds, impermanent loss, variable interest rates, smart contract exposure — the risks are specific and consequential.
What most products show
⚠️ DeFi involves risk. Assets may lose value.
This disclaimer appears on approximately every DeFi product in existence. It communicates nothing specific. It is a legal hedge masquerading as user information.
Curve Finance, which routes billions in stablecoin liquidity, surfaces a risk disclosure that reads like a terms-of-service excerpt. The actual risk — that liquidity providers in certain pools have experienced impermanent loss exceeding their earned fees during volatile periods — is not communicated at the moment it matters.
The structural problem
Risk information in most DeFi products lives in one of two places:
| Where risk lives | Where users are when it matters |
|---|---|
| FAQ / docs | About to deposit |
| General disclaimer | Mid-transaction |
| Post-liquidation email | After the loss |
None of these are the right moment.
What the screen should do
✅ "At current ETH price ($2,847), your position will be liquidated
if ETH drops below $1,920."
✅ "Your current health factor: 1.8 — above the safe threshold of 1.0"
✅ "If ETH drops 30%, your estimated liquidation cost: ~$240"
Specific numbers. At the moment of deposit. Not buried in docs that users do not read because they are mid-transaction.
The counterargument — that specific risk numbers create false precision — is real. Prices move. Thresholds change. A number displayed at deposit time may not reflect conditions at the moment of liquidation.
The answer to "specific numbers create false precision" is not "show no numbers." It is to show numbers with appropriate uncertainty — ranges, not points. "Liquidation risk begins below approximately $1,800–$2,000 depending on market conditions" is more honest and more useful than a generic warning about DeFi risk.
Screen Three: The Failed Transaction
What it is
Transactions fail. Gas runs out. Slippage exceeds tolerance. Prices move between signature and confirmation. Smart contract conditions change.
Failure is a normal part of using DeFi.
What most products show
❌ Transaction failed
❌ Error: execution reverted
❌ Something went wrong
These three strings — in various combinations — appear across Aave, Uniswap, Curve, and most other major DeFi interfaces when a transaction fails. None of them tell the user what failed. None of them suggest what to do.
Why this is not an engineering problem
The Ethereum Virtual Machine returns specific revert reasons. When a transaction fails, the protocol usually knows why:
• Slippage tolerance exceeded → price moved too fast
• Insufficient liquidity → pool depth changed
• Approval expired → token permission was revoked
• Gas limit too low → transaction ran out of execution budget
The information exists. It is not surfaced.
The choice to show "Transaction failed" instead of "This transaction failed because the price moved more than your 0.5% slippage tolerance. Try again with a higher tolerance or a smaller amount" is a product decision. Not a technical constraint.
The cost of getting this wrong
| Failure message | User's next action |
|---|---|
| "Transaction failed" | Retry blindly · Contact support · Give up |
| "Price moved too fast. Retry with 1% slippage." | Retry correctly |
The second message reduces support load, increases successful transaction rate, and maintains user trust. It requires one engineer and one designer to agree that it matters.
The pattern across all three screens
These are not three separate problems. They share a cause.
DeFi products are built protocol-first. The smart contract is designed, audited, and deployed. The interface is built to expose what the protocol does. The user is assumed to understand the protocol.
That assumption produces:
- Approval transactions with no context (the protocol requires them)
- Generic risk warnings (the protocol cannot quantify user-specific risk)
- Raw revert errors (the protocol returned a string)
The interface that a non-developer user experiences is a direct consequence of what the protocol exposes, with minimal translation.
Hayden Adams has described Uniswap's earliest interface decisions as deliberately separating what the protocol does from what the user needs to know. The interface was a translation layer, not a protocol mirror.
Most DeFi products never made that distinction.
What this means practically
Audit your approval flow before your smart contract. The approval transaction is the first moment a user encounters unexpected friction. Every team knows their approval flow has a problem. Almost none fix it before launch.
Replace generic risk disclaimers with specific numbers. "DeFi involves risk" communicates nothing. "Your position can be liquidated if this asset drops 40%" communicates something a user can act on.
Own your revert messages. Get the list of conditions under which your smart contract reverts. Write a human-readable message for each one. This is a day of work that will permanently reduce support load.
Treat failure states as primary design surfaces. The transaction failure screen is not an edge case. In high-traffic periods, it is the most-seen screen in your product. Design it accordingly.
Test with someone who has never used DeFi. Hand a non-crypto person $20 and ask them to make a deposit. Watch what happens at the approval screen, the risk disclosure, and the first failed transaction. You will see all three problems in twenty minutes.
The protocols that power these products are genuinely remarkable pieces of engineering. The interfaces that sit on top of them fail at the same three moments, across the same products, year after year.
The engineers who built the protocols did not build the problems. The teams who decided the interface was secondary did.
I work as a Web3 creative director running interface audits for DeFi teams before users find these problems themselves. somaryuu.xyz
