DeFi app
A lending market lets users supply ETH on Arbitrum as collateral. Supplying requires holding native ETH on Arbitrum specifically — not ETH on mainnet, not a wrapped or staked derivative.
The friction
"Acquire the exact collateral asset first" is a prerequisite step that lives entirely outside your app. Every user holding the wrong asset, or the right asset on the wrong chain, has to leave — to a CEX, a bridge, a swap — and find their way back before they can supply a single dollar. Most of that drop-off never returns.
The integration
The deposit dialog becomes the funding step of your "Supply" flow. asset.symbol here is a native coin — the Kit settles native and ERC-20 home assets the same way:
import { StridgeProvider, useDeposit } from "@stridge/kit"
import { DepositDialog } from "@stridge/kit/deposit/dialog"
function FundCollateralButton() {
const { open } = useDeposit()
return (
<button type="button" onClick={() => open()}>
Get ETH to supply
</button>
)
}
export function SupplyPanel({ userWallet }: { userWallet: `0x${string}` }) {
return (
<StridgeProvider
gatewayKey={process.env.NEXT_PUBLIC_STRIDGE_GATEWAY_KEY!}
// Collateral asset — a native coin. 9001 = Arbitrum One.
asset={{ networkId: "9001", symbol: "ETH" }}
flows={{ deposit: { destination: { address: userWallet } } }}
>
<SupplyForm />
<FundCollateralButton />
<DepositDialog />
</StridgeProvider>
)
}What the user does
A user wants to supply collateral but holds USDT on BNB Smart Chain — the wrong asset on the wrong chain.
They tap the funding button, pay with the USDT they hold, and the deposit dialog routes it.
Stridge swaps and bridges; the user's own wallet ends up holding native ETH on Arbitrum.
The supply transaction runs against the exact asset the market expects — no detour, no wrong-chain mistakes.
The same integration covers withdrawals and repayments. Add a withdraw flow so a user can pull supplied collateral or loan proceeds out to any chain and asset — see the Web3 trading app example for the two-flow provider.
How they tend to customize
DeFi apps live or die on trust signals — the Kit has to read as "part of the same app", not as a third-party dialog. Three moves typically:
- Skin (theming) — match the lending market's accent and radius so the funding step feels like an extension of the supply panel. Both are driven by CSS variables; pass them on
appearanceand they propagate everywhere. The skin tier is the lightest-weight customization in the Kit — no compound, no headless, just CSS. - Data attributes & slots — when the global tokens aren't granular enough, restyle individual sub-parts (asset tile, breakdown row, success state) without forking. Every meaningful element carries a stable
data-stridge-slot="<name>", so[data-stridge-slot="deposit-method"] { … }is a valid escape hatch. - Internationalization — DeFi user bases skew global. Pass
i18n.localematching your app's locale and the Kit auto-derives direction (RTL forar/fa/he/ur); usedefineMessagesto override copy for unsupported locales.
The result
Supplying collateral becomes a single in-app step. A user funds straight from whatever they already hold, the lending action runs against the asset it expects, and the "go acquire the right token first" detour — and the drop-off it causes — disappears.
Next
- Usecases — the pattern and the other examples.
- Prediction market — funding a position.
- Web3 trading app — funding margin and cashing out.
- Gateway Kit — overview of the three integration tiers.
- Data attributes & slots — host-side CSS targeting.
- Internationalization — locales, RTL, message overrides.