Risk
First surface
Health, liquidation proximity, and oracle assumptions stay visible.
All product concepts
Product concept
Making lending protocol activity clearer to participants
This use case illustrates how on-chain lending logic, wallet interactions, and portfolio information can become one coherent product experience.
Protocol risk concept
Health first
Multi-chain protocol and dashboard concept
A representative concept exploring workflows, system boundaries, and product decisions. It does not claim a named client or performance result.
Solidity
React
Ethers.js
AWS
Domain context
On-chain lending protocol interface context
Motive
How this concept solves the motive
Participants sign actions while network, allowance, and health-factor consequences stay opaque until after the wallet prompt.
Lending UX must make protocol preconditions and failure modes visible before capital moves—and keep recovery honest after settlement lag.
A participant dashboard where protocol truth, signing context, and risk stay legible through the full action loop.
- Move 01
Preconditions first
Show network, wallet, and allowance context before any action that commits capital.
- Move 02
Explain consequences
Make health factor and liquidation risk consequential controls, not decorative badges.
- Move 03
Model failure states
Treat pending, reverted, and indexer-lag paths as first-class UI so recovery is productized.
Product principles
- Make network and wallet context visible before any capital-moving action.
- Explain consequences—especially health factor and liquidation risk—before the wallet prompt.
- Treat failure and recovery as first-class states, and keep surfaces ready for security review.
Blockchain actors
Who touches protocol state
Borrowers, suppliers, operators, and reviewers interact with the same on-chain positions through different lenses. The dashboard must keep network, risk, and settlement context honest for each of them.
Borrowers
- Need
- Clear collateral requirements, health factor meaning, and consequences of repay or withdraw actions before signing.
- Friction today
- Risk appears only after a failed transaction or as an unexplained metric that does not map to next steps.
- Success signal
- Borrowers can explain what keeps a position safe and which action restores headroom without leaving the flow.
InterfaceConnects wallet and network first, then borrows or repays only after health-factor and allowance consequences are visible.
System shape
Protocol read/write topology
Contracts and indexers meet wallet and RPC paths; oracle and risk inputs inform a participant dashboard before and after actions.
ActorServiceStoreExternalClient
Technology map
Suggested stack shape
Why these layers show up in the concept—not a shopping list of logos. Browse the full catalog.
- Layer 01
Protocol
Market, collateral, and liquidation rules belong on-chain; the UI must never invent parallel protocol math.
- Layer 02
Clients
Wallet, network, and signing flows stay close to the dashboard so preconditions appear before the click.
- Layer 03
Reads
Separate indexer freshness from settlement truth so pending and lag states stay honest.
- Layer 04
Infrastructure
Hosting and monitoring for read paths and operator tools should make degradation visible during incidents.
- AWS
- Observability
Design signals
What this concept is sized to clarify
Illustrative product targets for planning conversations—not measured client results.
On-chain
Source of truth
Dashboard reads protocol state—it does not invent parallel balances.
Alert
Actionable only
Noise is filtered so operators act on real threshold breaches.
Audit
Decision trail
Parameter and risk changes leave a reviewable history.
Hidden liquidation risk
Before
After
Oracle assumption opacity
Before
After
Alert noise
Before
After
Parameter change fog
Before
After
The operating problem
Positions feel trustworthy until the next transaction
Most DeFi lending dashboards look complete until a user tries to borrow, repay, or withdraw under live network conditions. Wallet state, allowance, network identity, oracle freshness, and health factor often live in separate mental models, so the UI implies safety while the protocol is still evaluating constraints the user cannot see.
When those preconditions surface only as a revert, users lose capital to gas and lose trust in the product. Support then spends time reconstructing what the wallet, RPC, and indexer each believed at the moment of the click. The product problem is not missing charts. It is missing a shared, time-aware picture of protocol truth before irreversible actions.
The product approach
Design the action path around protocol preconditions
Treat supply, borrow, repay, withdraw, and liquidation awareness as one product contract. Every action screen should declare network match, wallet readiness, allowance, collateral headroom, and data freshness before the user signs. Failure classes such as pending, dropped, reverted, and out-of-gas become first-class states with recovery copy rather than spinner timeouts.
Separate indexed display views from settlement truth. Mark stale reads, never claim a position is settled until confirmation criteria are met, and keep role-specific dashboards aligned to the same event model. That approach lets borrowers, suppliers, and operators reason about risk without inventing side tools to reconcile balances.
Product judgment
Lending UX fails when protocol state stays opaque
Borrowers and lenders act under uncertainty. The product must surface network context, position risk, and transaction progress before users commit capital or gas.
01
Show preconditions before the click
Wallet, network, allowance, and collateral headroom belong in the action path, not in post-failure error text.
Users decide under time pressure and gas cost. If the product waits until a revert to reveal that the wallet is on the wrong network or the allowance is insufficient, the failure feels like a product defect even when the contracts behaved correctly. Surface each precondition as a checklist with a clear blocked or ready state. Let the primary action stay disabled until the path is valid, and explain what still needs to change.
02
Treat each chain as a product surface
RPC behavior, confirmation depth, and asset identity differ by network, so multi-chain support is a UX contract.
A toggle that switches chain IDs is not a multi-chain product. Confirmation expectations, explorer links, wrapped asset naming, and oracle deployments all change the meaning of balances and risk. Design network context into headers, transaction receipts, and position cards so users never sign against the wrong deployment. Prefer shipping one network thoroughly before abstracting shared patterns across chains.
03
Model failure as a first-class state
Pending, dropped, reverted, and out-of-gas outcomes need recovery copy and safe retry rules.
Generic loading states hide the most expensive moments in lending UX. Map known wallet and protocol failure classes to plain-language explanations that preserve the attempted action. Offer retry only when it is safe, and block retry when a pending transaction may still confirm. Keep the original inputs visible so users do not rebuild a complex borrow or repay form after a drop.
04
Separate protocol truth from display truth
Indexed views can lag, so the dashboard must mark stale data and avoid premature settlement claims.
Dashboards often blend RPC reads, indexed events, and cached rate cards into one confident number. That confidence is misleading when the indexer is behind or an oracle update has not landed. Label freshness explicitly, show last-updated context on critical fields, and reserve settled language for confirmation criteria the product has defined. Borrow and withdraw flows should warn or block when critical inputs fall outside the agreed freshness window.
05
Make health factor consequential, not decorative
Risk metrics only help when users can connect them to repay, withdraw, and liquidation outcomes.
A health factor without consequence teaching becomes wallpaper. Pair the number with plain-language explanations of what worsens it, what improves it, and which actions are blocked at the current level. Simulate the effect of a proposed borrow or withdraw before signing so users see the post-action risk, not only the current snapshot. Escalate warning severity as liquidation proximity increases instead of using one generic caution state.
06
Keep signing context attached to the position
Transaction prompts should restate asset, amount, network, and purpose in product language before the wallet modal.
Wallet modals show hex and method fragments that most participants cannot interpret under stress. The product layer should preview the human meaning of the signature first: which position changes, which asset moves, and what remains reversible afterward. Persist that same summary in the pending and confirmed states so users can audit what they approved without leaving the dashboard. This reduces mistaken approvals and shortens support investigations.
Participant flow
From wallet connect to a legible live position
A coherent lending dashboard guides participants through readiness, action, confirmation, and ongoing risk monitoring without switching mental models.
Flow at a glance
Step 01
Connect and verify network context
The participant connects a wallet and immediately sees whether the active network matches a supported deployment, with clear remediation when it does not.
ArtifactNetwork readiness banner with switch guidance
Step 02
Inspect markets and position headroom
Supply and borrow markets present rates, liquidity, collateral factors, and oracle freshness before any action form opens.
ArtifactMarket and risk overview with freshness markers
Step 03
Prepare a guarded action
Allowance, collateral headroom, and health impact are validated in-product before the wallet prompt appears.
ArtifactAction checklist with simulated post-trade health
Step 04
Track settlement honestly
Pending, confirmed, rejected, and failed states stay visible with recovery options that respect possible in-flight transactions.
ArtifactTransaction timeline tied to the affected position
Step 05
Monitor and adjust the live position
The dashboard reunites supplied, borrowed, and collateral balances so repay, withdraw, or top-up decisions start from one coherent picture.
ArtifactUnified position panel with next-safe actions
Layer decisions
Architecture layers and the decisions they force
01
Smart contract core
Modular supply, borrow, collateral, and liquidation actions with explicit permissions and comprehensive tests.
- Define market, position, and liquidation boundaries as separate modules with clear invariants.
- Make permissioned admin actions explicit and reviewable rather than hidden behind broad roles.
- Require scenario tests for repay, withdraw, and liquidation edge cases before UI integration.
02
Indexing and reads
Event indexing and RPC reads that reconcile on-chain state into dashboard-friendly position views.
- Choose hosted indexing, self-hosted pipelines, or hybrid reads based on freshness needs.
- Expose last-indexed block and stale markers to the client instead of silent lag.
- Reconcile indexed projections against RPC reads for critical borrow and withdraw screens.
03
Wallet interaction layer
Network-aware signing, allowance flows, and transaction status tracking with defensive validation.
- Validate chain ID and deployment address before assembling calldata.
- Treat allowance as a product step with revoke and increase paths, not a hidden side effect.
- Track transaction hashes with timeout and replacement rules that avoid double submission.
04
Participant dashboard
Role-aware views for positions, rates, available actions, and plain-language transaction feedback.
- Share one position model across borrower and supplier views to prevent conflicting balances.
- Localize risk copy to action consequences rather than protocol jargon alone.
- Keep explorer deep links secondary to in-product timelines for everyday monitoring.
Traps to avoid
Common anti-patterns that weaken this product shape
Revealing network or allowance errors only after signing
Post-revert discovery burns gas and trust. Preconditions belong in the ready state of the action, not in the failure toast.
Presenting indexer balances as final settlement
Lagging projections that look definitive cause users to act on stale headroom. Mark freshness and reserve settled language for confirmed state.
Shipping multi-chain before one network is trustworthy
Shared abstractions without a solid single-chain path multiply asset identity bugs and support load. Earn the second network after the first is legible.
Treating health factor as a badge instead of a control surface
If risk metrics do not change available actions or simulated outcomes, participants cannot convert warning into safer behavior.
How we would approach it
A practical build path for this concept
Phase 1
Protocol and risk contract
Lock market mechanics, permission boundaries, and the minimum risk disclosures the product must explain.
- Market and collateral parameter sheet
- Liquidation and health factor explanation model
- Permission and upgrade surface map
Phase 2
Read path and freshness rules
Establish how RPC, indexer, and oracle inputs become dashboard truth with explicit stale behavior.
- Position projection schema
- Freshness thresholds per critical field
- Stale-state UX rules for borrow and withdraw
Phase 3
Guarded transaction flows
Implement supply, borrow, repay, and withdraw with precondition checklists and honest settlement states.
- Action readiness checklist components
- Wallet preview and status timeline
- Failure-class copy and retry policy
Phase 4
Operator and review hardening
Add monitoring views and audit-friendly event mapping once participant flows are trustworthy.
- Operator utilization and oracle monitors
- Event-to-UI claim traceability notes
- Security review packet for permissions and upgrades
Conceptual outcomes
What success looks like when the concept works
These are product outcomes to design toward, not claimed client results.
Legible positions
Supplied, borrowed, and collateral state read as one coherent picture instead of disconnected balances.
Honest transaction progress
Users understand pending, confirmed, rejected, and failed states without guessing what the wallet or network did.
Network-aware actions
Chain context stays explicit so users do not sign against the wrong deployment or asset.
Review-ready surfaces
Contract events, permissions, and UI assumptions are structured for independent security review.
Discovery checklist
Questions worth answering before you build
- 01Which networks and asset identities must the first release support without ambiguity?
- 02What confirmation depth and freshness windows define settled versus provisional position state?
- 03Which risk disclosures are mandatory before a user may borrow against collateral?
- 04How should pending, dropped, reverted, and out-of-gas failures map to recovery actions?
- 05Who owns indexer operations, and what happens in the UI when projections lag RPC truth?
- 06What operator monitors are required on day one versus later analytics expansions?
Decision guide
When this concept is worth exploring
01
Single-chain first or multi-chain from day one
Decide whether early scope locks one network thoroughly or invests in shared abstractions across deployments.
02
Indexer ownership model
Choose hosted indexing, self-hosted pipelines, or hybrid reads based on freshness needs and operational burden.
03
Liquidation and risk disclosure depth
Agree how much risk math and warning severity the product must explain before users can borrow.
Common questions
Frequently asked questions
Answers about this blockchain product concept and how SolveMotive approaches similar work.
Is this a named client case study?
No. It is a representative product concept showing the workflows and engineering considerations SolveMotive can discuss. It does not claim a client identity, completed engagement, or performance result.
What would a production DeFi engagement include?
Scope depends on the protocol, but commonly includes threat modeling, contract design and testing, application development, monitoring, deployment planning, and coordination with independent security reviewers.
Can the interface support more than one network?
Yes. The architecture can account for network-specific contracts, assets, confirmations, RPC behavior, and user switching while keeping the current context explicit.
How should wallet and protocol errors be presented?
Map known failure classes to plain-language explanations, preserve the attempted action context, and offer a safe next step. Avoid dumping raw revert strings as the only message.
When should oracle and rate data be considered stale?
Define freshness thresholds per data source and surface them in the UI. Borrow and withdraw actions should block or warn when critical inputs fall outside the agreed window.
What belongs in the first release versus later iterations?
Prioritize correct position reads, safe transaction flows, and core supply and borrow actions. Advanced analytics, multi-chain expansion, and governance tooling usually follow after the trust path is solid.
Still stuck on a specific constraint? Book a scoping call →
Related services and industries
- Service
Blockchain Development
Smart contracts and decentralized applications for use cases with a genuine trust requirement.
- Industry
Fintech Software Development
Clear, dependable financial product experiences for teams operating in a high-trust environment.
- Insight
Beyond the Hype: Where Blockchain Actually Makes Business Sense
A grounded look at which industries benefit from decentralized tech and which ones are better off without it.