DEV Community

Cover image for Can I lose my crypto with a non-custodial or embedded wallet? A risk & UX guide for builders
estel
estel

Posted on

Can I lose my crypto with a non-custodial or embedded wallet? A risk & UX guide for builders

#web3 #blockchain #webdev #programming

Non-custodial and embedded wallets are having a moment.

They let you ship “sign in with email, pay with USDC” while keeping assets off your balance sheet. But they also raise a very real question that users (and PMs, and lawyers) keep asking:

Can I lose my crypto with a non-custodial wallet?

Short answer: yes. That’s literally the trade-off. But “how”, “how likely”, and “what you can do about it as a builder” is where it gets interesting.

Openfort in one line: Openfort is a wallet orchestration platform that gives apps embedded, non-custodial wallets plus self-hostable key management, without vendor lock-in.

This post is vendor-neutral, but I’ll use Openfort / OpenSigner as concrete examples when talking about risk controls and UX patterns.

Nothing here is financial, investment, tax, or legal advice – it’s a mental model for engineers & product teams.

What are digital wallets?

A digital wallet is software that stores payment credentials or cryptographic keys and lets a user initiate transactions from a phone or computer.

From a risk perspective, the key questions are:

  • Who can move funds? (user only, service provider, or both)
  • Who can block or reverse transactions?
  • Who is legally responsible if something breaks?

Whether it’s:

  • Your banking app
  • Apple Pay / Google Pay
  • PayPal / Revolut / Venmo
  • Or a crypto wallet like MetaMask or an embedded wallet inside your app

…you’re always trading off user freedom vs safety nets.

Crypto wallets just move more of the responsibility onto the user (or onto your infra, if you’re providing embedded non-custodial wallets).

What are the three types of wallets?

The three main types of wallets are custodial wallets, non-custodial wallets, and embedded wallets that usually live inside a specific app.

This is the simplest taxonomy I’ve found to make risk conversations concrete.

1) Custodial wallets

  • A provider (exchange, fintech, CEX) holds the private keys.
  • Users sign in with email/password / KYC.
  • The provider can freeze accounts, reverse certain operations, and is on the hook for a lot of operational risk.

Risk trade-off:

Users get less control but more safety nets: password resets, sometimes reimbursements, clearer regulatory recourse. As a builder, you take on more liability and compliance overhead.

2) Non-custodial wallets (EOAs, hardware, extensions)

  • The private key sits on the device (or hardware wallet).
  • The user signs every transaction.
  • If the key is lost or compromised, there is usually no “forgot password” button.

Risk trade-off:

Users get maximum sovereignty but also maximum ways to shoot themselves in the foot: losing seed phrases, signing malicious txs, falling for scams.

3) Embedded wallets (usually smart / AA wallets)

  • A wallet is created inside your app when a user signs up.
  • It’s typically non-custodial (user ultimately controls keys), but you control the UX and risk controls.
  • Think: smart accounts with policies, session keys, limits, recovery flows.

Risk trade-off:

You avoid holding users’ funds, but you do take on responsibility for key management, UX copy, and policy design. You become the one who can either protect users from common mistakes… or make them more likely.

With Openfort’s embedded wallet stack, this third category is implemented as non-custodial smart accounts controlled via OpenSigner, which you can run in your own infra.

What are the three types of crypto wallets?

The three main types of crypto wallets are custodial wallets, non-custodial EOAs (externally owned accounts), and smart or embedded wallets.

  1. Custodial crypto wallets
    • Your exchange account; the platform signs transactions on your behalf.
    • Easier UX, but you accept platform risk and limited composability.
  2. Non-custodial EOAs
    • Classic wallets based on a seed phrase and a single private key.
    • You sign everything, you manage backup and recovery.
  3. Smart / embedded wallets
    • Wallets implemented as smart contracts or account abstraction accounts.
    • They support policies: spending limits, session keys, social recovery, multi-signer setups, etc.
    • Embedded wallets are usually smart or AA wallets hidden behind web2-style UX.

Openfort sits squarely in this third bucket: non-custodial smart/embedded wallets wired into your app via SDKs and orchestrated by OpenSigner.

If you want to inspect the SDKs, the code is open at

github.com/openfort-xyz/openfort-react.

Can I lose my crypto with a non-custodial wallet?

Yes. You can lose crypto in a non-custodial wallet if you lose the key, someone else gains control of it, you sign a malicious transaction, or the underlying contract has a bug.

More concretely, funds are at risk when:

  1. You lose the private key (and all recovery methods).
    • No backup, lost hardware, broken phone with no seed phrase.
  2. Someone else gains control of the key.
    • Phishing, malware, leaked cloud backups, signing a message that reveals the key.
  3. You sign a malicious or wrong transaction.
    • Rug contracts, fake UIs, infinite approvals, wrong address / chain.
  4. The smart contract implementing your wallet has a bug.
    • Logic errors, upgradability vulnerabilities, misconfigured guardians.

The difference vs custodial:

  • There is usually no central party who can undo the loss.
  • Even if there is a team willing to help, cryptography and protocol rules limit what’s recoverable.

That’s scary for users. As a builder giving people non-custodial or embedded wallets, your job is to reduce the probability and impact of those failure modes.

How embedded wallets can actually reduce some risks

If you design them well, embedded wallets can be safer for mainstream users than “here’s your 12-word seed phrase, good luck”.

They let you:

  1. Hide key management complexity
    • No raw seed phrases on day one.
    • Keys can be split (MPC) or represented via smart accounts with policies.
  2. Ship opinionated policies out of the box
    • Daily / per-tx limits.
    • Whitelisted contracts or function selectors.
    • 2FA or out-of-band approvals on high-risk actions.
  3. Add structured recovery flows
    • Social recovery / guardians.
    • Email + device + extra factor, rather than one piece of paper.
    • Time-locked “escape hatches” if a device looks compromised.

With Openfort, those policies are implemented at the smart account + signer layer. For example:

  • The signer (OpenSigner) might enforce “this session key can only call this contract with an amount ≤ X”.
  • The smart account might require an extra guardian signature for large transfers.

You still stay non-custodial, but you give users fewer sharp edges.

A simple (pseudo) pattern with session keys

Here’s a sketch of how you might give a session key limited powers in your app using the Openfort JS SDK.

⚠️ API is pseudo-code – check the docs for the exact latest types.

// npm install @openfort/openfort-js

import { Openfort } from "@openfort/openfort-js";

const openfort = new Openfort({
  publishableKey: process.env.NEXT_PUBLIC_OPENFORT_PUBLISHABLE_KEY!,
});

// After user logs in with email / OAuth
async function createSafeSession(userId: string) {
  // 1) Create an embedded smart wallet for the user
  const wallet = await openfort.wallets.createEmbeddedWallet({ userId });

  // 2) Issue a session key with scoped permissions
  const sessionKey = await openfort.sessions.create({
    walletId: wallet.id,
    maxSpendPerTx: "50",            // e.g. 50 USDC
    allowedContracts: [
      "0xYourGameOrAppContract",
    ],
    expiresAt: Date.now() + 1000 * 60 * 30, // 30 min
  });

  return { wallet, sessionKey };
}

// Then use the session key for low-risk actions inside the app
async function makeInAppPurchase(sessionKey: string, amount: string) {
  return openfort.sessions.sendTransaction({
    sessionKey,
    to: "0xYourGameOrAppContract",
    data: buildPurchaseCalldata(amount),
  });
}
Enter fullscreen mode Exit fullscreen mode

In a real app, you’d likely use the React SDK with wagmi/viem, or follow one of the recipes to plug into an existing Next.js or Expo template.

The point is the pattern: session keys + limits + clear scopes lower the impact of a compromised key.

More recovery patterns are documented in the embedded wallet recovery guide.

Can I withdraw money from a blockchain wallet?

Yes. “Withdrawing money” from a blockchain wallet means sending crypto (often stablecoins) to an off-ramp or exchange, converting it to fiat, and paying out to a bank account or card.

From a product perspective you have two options:

  1. DIY UX
    • Teach users to copy addresses, go to a CEX, deposit, sell, withdraw.
    • High friction, high error surface.
  2. Embedded off-ramp
    • Integrate an on/off-ramp partner or your own rails.
    • Present it as: “Withdraw $X to bank” directly from your app.
    • Under the hood it’s just one or more transactions from the embedded wallet.

Embedded wallets make the second path much easier because you control the full flow. You can:

  • Pre-fill addresses and amounts.
  • Encode exactly the right contract calls.
  • Show clear fiat-equivalent values and fees.
  • Guard risky operations with extra confirmation steps.

With Openfort, this typically looks like:

  • Using the embedded wallet to call your off-ramp contract or a partner’s contract.
  • Tracking the withdrawal lifecycle through Openfort’s orchestration tools so users (and support) can see what happened.

Practical checklist: designing safer non-custodial & embedded wallets

If you’re giving users non-custodial / embedded wallets, here’s a concrete checklist:

1. Make risk copy brutally clear

  • Don’t hide that it’s non-custodial.
  • Spell out what happens if they lose access or sign bad txs.

2. Scope powers with smart accounts & session keys

  • Default to minimal powers for any key that isn’t strongly bound to the user.
  • Require stronger auth for large or unusual transfers.

3. Provide structured recovery, not just a seed phrase

  • Social / guardian flows.
  • Multi-factor recovery that doesn’t rely on a single PDF or screenshot.
  • Time-locked recovery or “escape hatch” contracts.

4. Treat signing screens as product, not afterthought

  • Show what’s happening in human language (“Send 20 USDC to X on Base”).
  • Highlight when a transaction is interacting with a new / risky contract.
  • Make “reject” as easy as “confirm”.

5. Instrument everything

  • Log which flows lead to failed txs or support tickets.
  • Watch for patterns: repeated wrong addresses, approvals to unknown contracts, etc.
  • Use that feedback to tighten limits or improve copy.

A lot of this is easier when you use an infra layer that’s designed for orchestration rather than just raw key management. That’s the niche Openfort tries to fill.

TL;DR

  • Yes, users can lose funds with non-custodial wallets — that’s the point.
  • The real question is how you, as a builder, can reduce the odds and the impact while keeping self-custody.
  • Thinking in three categories — custodial, non-custodial, embedded — helps structure the conversation with PMs, compliance, and users.
  • Embedded wallets + smart accounts + policies give you a lot of levers: session keys, limits, recovery, better signing UIs, smoother withdrawals.

If you want to experiment with this model, you can spin up a project in the

Openfort dashboard, read through the embedded wallet docs, and play with the live demo.

Top comments (0)