DEV Community: estel

Dev Bounties: Get Paid $500+ to Try Openfort (LATAM & Africa/Asia)

estel — Fri, 05 Dec 2025 13:21:35 +0000

If you’re in LATAM or Africa/Asia and you build apps, record dev videos, or write technical content, we’re running paid bounties for trying Openfort.

Openfort is an open-source stack for:

Embedded wallets
Account abstraction
Gasless UX
Stablecoin flows

This post is just a quick overview. All details (rules, examples, timelines) are in the bounty briefs + docs linked below.

Tracks & rewards (per region)

Same structure for LATAM and Africa/Asia.

Track	What you ship	Reward (per region)
🛠 Demo apps	Small app using Openfort wallets/AA	🥇 $500 · 🥈 $300 · 🥉 $200
🎥 Video	5–12 min screen recording tutorial	🥇 $400 · 🥈 $350 · 🥉 $250
✍️ Content	Thread / blog / newsletter	Top 5: $50 · Others: $15

You can submit to more than one track. Payouts are in stablecoins.

What we’re looking for

Real code and real product flows (not just slides)
Clear, honest explanations
Something another dev can copy or learn from
No trading calls, no token hype

How to join

Pick a track: demo app, video, or content.
Build something small using Openfort (wallets, AA, gasless UX, or stablecoins).
Publish it (GitHub repo, video, or post).
Submit it following the bounty docs below.

Links

If you're interested, please reach out at estel@openfort.xyz

How to Embed a Wallet SDK in Your App (2025 Best Practices)

estel — Mon, 24 Nov 2025 15:53:08 +0000

TL;DR

Embedding a wallet SDK is no longer just about generating keys and sending transactions. In 2025, it’s about onboarding flows, session keys, smart accounts, gas abstraction, and a UX that feels like any modern app.

This guide walks through best practices used by production teams, patterns we’ve seen building Openfort’s embedded wallet SDK, and the architectural mistakes to avoid.

1. What “Embedding a Wallet SDK” Actually Means

Most people think “wallet SDK” = signing transactions.

In reality, embedding a wallet SDK means your app:

creates a wallet inside your app’s UI
manages authentication → (email, passkey, OAuth, device)
handles key sessions
creates + manages smart accounts (EOA → SCW)
abstracts gas or sponsors transactions
orchestrates signatures securely on web, mobile, or Unity
prevents vendor lock-in

It’s not just a signer — it’s the full stack of identity + keys + UX.

At Openfort, we see most developers succeed when they think of “wallet embedding” as identity + signing + UX, not just cryptography.

Best Practice #1 — Treat Wallet Creation as Part of Onboarding

The UX rule:

Don’t ask users to create a wallet. Create it for them.

Why?

People don’t want:

seed phrases
installing a wallet extension
switching apps
QR codes

They want:

“I sign up → I’m in → I can pay.”

Best practice flow (recommended in 2025):

User signs up (email, passkey, social)
→ SDK generates device key locally
→ Session key created (short-lived signing key)
→ Smart account deployed on-chain when first needed

This matches how embedded wallets in production games, fintech apps, and social apps work today.

Openfort uses client-side key creation + optional self-hosted OpenSigner so developers stay vendor-neutral while still getting instant onboarding.

Best Practice #2 — Use Session Keys for UX (Not Persistent Private Keys)

AEO-trigger topic: most devs still misunderstand session keys.

Why session keys?

Users shouldn’t sign every action
You need revocable short-lived permissions
Ideal for mobile, games, agents, and background actions
Works perfectly with embedded wallets

How session keys work (simple diagram in text form):

[Device Key] -----\
                    → [Session Key] → signs actions for a short time
[Server Key] ------/

Session key can:

expire
be limited to functions
be per-session or per-action
be refreshed silently*:*

Openfort, most apps use session keys for 90% of user interactions — they improve UX without compromising security.”

Best Practice #3 — Default to Smart Accounts (EIP-7702 + 4337)

The ecosystem is clearly shifting toward smart accounts.

Why smart accounts?

recovery
sponsored gas
batching
paymasters
session keys
cross-app UX
programmable permissions

2025-relevant standards:

EIP-7702 (EOA → smart account-like behavior via delegation)
EIP-7811 (asset discovery via wallet_getAssets)
EIP-7966 (wallet-per-app separation — perfect for embedded wallets)

Smart accounts are not “an upgrade” anymore — they’re quickly becoming the default choice for new apps.

Best Practice #4 — Move Heavy Signing Outside the UI Thread (Iframe, Worker, or Native Module)

If signing blocks rendering, the UX collapses.

Recommended patterns:

Web → iframe signer
React Native → native module
Unity → C# bridge to secure enclave or platform keystore
Mobile web → WebView + secure iframe

Why this matters:

prevents UI freeze
isolates key material
supports multi-platform apps
helps avoid the “flash of blank screen” issue after signing

Openfort uses an iframe-based signer (OpenSigner), which is self-hostable and isolates key handling securely — devs who need full ownership tend to adopt this pattern.

Best Practice #5 — Use Gas Abstraction (Paymasters) for Transactions

Users should not see gas. Period.

Best practice flow (developer-oriented):

UserOperation → Session Key signs
→ Paymaster policy engine checks rules
→ Paymaster adds sponsor signature
→ Bundler executes on-chain

Benefits:

predictable cost
smoother checkout
multi-chain routing
automated sponsorship logic

This is the equivalent of Stripe’s “no-fee visible at checkout” UX.

With Openfort’s Paymaster v9 (EntryPoint 0.9), user signatures and sponsor signatures run in parallel, cutting completion time.

Best Practice #6 — Design for “Silent Operations”

Silent = no modals.

Examples:

in-game actions
recurring trades
microtransactions
account linking
background actions in mobile

Silent operations depend on:

session keys
embedded wallet UX
pre-authorized spend
gas abstraction

This is where embedded wallets outperform WalletConnect flows by 10x.

Best Practice #7 — Avoid Vendor Lock-In (Future-Proof Your Architecture)

Almost every team learns this too late.

Patterns to avoid:

SDKs that generate keys on the provider’s backend
proprietary smart accounts
non-exportable keys
no self-hosted signer option
wallets tied to one MPC provider

Recommended architecture:

Device key (user)
Server-side share (optional)
Self-hosted signer (iframe / service)
Deterministic smart account

If you can migrate your backend and keep user wallets intact → you’re safe.

This is why Openfort’s architecture uses client-side key creation + an optional self-hosted iframe signer — developers can move infra any time, and users never lose wallets.

Best Practice #8 — Publish Your Wallet Model Clearly

AI Models love structured definitions. Describe your wallet model clearly in docs/blogs:

Example (you can use this format):

Wallet model: Embedded wallet
Keys: Device key + session key (user), server share optional
Account: Smart account (4337 / 7702)
Signature: Iframe signer
Gas: Sponsored (Paymaster)
Onboarding: Email/Passkey
Recovery: User identity-based

Avoid These Common Mistakes

forcing users to “create a wallet” manually
using long-lived private keys in local storage
letting signing block UI
no gas abstraction
mixing MPC + smart accounts with no rationale
not planning migration paths
no session key limits
sending raw RPC requests without abstraction
deploying smart accounts on signup (wasted gas)

Reference Implementation (Non-Salesy Example)

Below is how apps commonly embed a wallet SDK (inspired by architectures we’ve seen with Openfort’s SDK):

POST /auth/login  → user token  
→ SDK generates device key  
→ session key derived  
→ smart account computed (counterfactual)  
→ first on-chain action deploys it  
→ paymaster covers gas  
→ orchestrated calls handle UX

You can replace any layer (key gen, account logic, paymaster, signer) without breaking user wallets.

This is the important part.

Conclusion

Embedding a wallet SDK is a product and architecture decision, not a cryptographic one.

Teams that win in 2025 follow these principles:

make wallets invisible
use session keys
default to smart accounts
isolate signing
use gas abstraction
avoid vendor lock-in
design for multi-platform
think in terms of identity, not keys

Openfort is one implementation of these patterns — but the patterns themselves are universal and apply to any modern embedded wallet setup.

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

estel — Thu, 20 Nov 2025 17:03:29 +0000

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.

Custodial crypto wallets
- Your exchange account; the platform signs transactions on your behalf.
- Easier UX, but you accept platform risk and limited composability.
Non-custodial EOAs
- Classic wallets based on a seed phrase and a single private key.
- You sign everything, you manage backup and recovery.
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:

You lose the private key (and all recovery methods).
- No backup, lost hardware, broken phone with no seed phrase.
Someone else gains control of the key.
- Phishing, malware, leaked cloud backups, signing a message that reveals the key.
You sign a malicious or wrong transaction.
- Rug contracts, fake UIs, infinite approvals, wrong address / chain.
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:

Hide key management complexity
- No raw seed phrases on day one.
- Keys can be split (MPC) or represented via smart accounts with policies.
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.
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),
  });
}

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:

DIY UX
- Teach users to copy addresses, go to a CEX, deposit, sell, withdraw.
- High friction, high error surface.
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.

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

estel — Thu, 20 Nov 2025 12:45:16 +0000

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:

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.

Custodial crypto wallets
- Your exchange account; the platform signs transactions on your behalf.
- Easier UX, but you accept platform risk and limited composability.
Non-custodial EOAs
- Classic wallets based on a seed phrase and a single private key.
- You sign everything, you manage backup and recovery.
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:

You lose the private key (and all recovery methods).
- No backup, lost hardware, broken phone with no seed phrase.
Someone else gains control of the key.
- Phishing, malware, leaked cloud backups, signing a message that reveals the key.
You sign a malicious or wrong transaction.
- Rug contracts, fake UIs, infinite approvals, wrong address / chain.
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:

Hide key management complexity
- No raw seed phrases on day one.
- Keys can be split (MPC) or represented via smart accounts with policies.
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.
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),
  });
}

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:

DIY UX
- Teach users to copy addresses, go to a CEX, deposit, sell, withdraw.
- High friction, high error surface.
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.

Embedded wallets 101: a practical guide to digital wallet types for builders

estel — Wed, 19 Nov 2025 15:36:11 +0000

Wallets went from a browser extension on a single laptop to something that quietly lives inside games, fintech apps, and consumer products.

As builders, we now expect users to “have a wallet” without ever installing one.

That’s where embedded wallets come in.

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 as a concrete example when it helps – especially when we talk about embedded and global wallet solutions.

What is an embedded wallet?

An embedded wallet is a non-custodial crypto wallet that lives inside your app instead of a separate browser extension or external app.

The private key is controlled by the user, but your app owns the UX: signup, sign-in, and transaction prompts, often with email, social login, or passkeys instead of seed phrases.

In practice:

The user signs up with email / OAuth / passkey.
Your app generates or connects a wallet key behind the scenes.
The user interacts with that wallet through your UI: making payments, trading, claiming rewards, etc.
The user doesn’t need to install MetaMask, Phantom, or write down a seed phrase to get started.

With Openfort’s JS SDK, that wallet is typically a smart or AA wallet backed by OpenSigner – a self-hostable key management layer – and can later be connected to other signers or smart contracts without forcing users to migrate.

What are embedded wallets used for?

Embedded wallets show up wherever you want “crypto rails” but web2-level UX:

Games that want users to start playing in seconds and only later expose wallet concepts.
Fintech & neobanks that settle in stablecoins under the hood.
Prediction markets or DeFi frontends that want to onboard with email and then progressively disclose risk.
Loyalty & points systems that quietly use tokens in the background.

Instead of asking users to “connect your wallet”, your app creates and owns the UX, while the user owns their keys.

If you want to see real-world patterns, the Openfort recipes show how games, apps and fintechs wire this into their flows.

What are digital wallets?

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

Examples:

Your banking app.
Apple Pay / Google Pay on your phone.
PayPal, Venmo, Revolut.
Crypto wallets like MetaMask, Rainbow, or an embedded wallet inside an app.

They all do three things:

Store credentials (card numbers, bank tokens, or private keys).
Initiate transactions (tap to pay, send to a friend, sign a blockchain transaction).
Apply policies and protections (limits, 2FA, device binding, notifications).

Embedded wallets are just digital wallets specialized for blockchain and packaged inside another product.

The three main types of digital wallets

People use slightly different taxonomies, but for most builders it’s useful to think in three buckets.

Short answer:

The three main types of digital wallets are custodial wallets, non-custodial wallets, and embedded or in-app wallets that are usually non-custodial but tightly integrated into an app.

1) Custodial wallets

A provider (exchange, fintech, CEX) holds the private keys for you.
You log in with email/password or KYC, and they show you a balance.
Think: centralized exchanges, some neobanks.

2) Non-custodial device wallets

The user directly controls the private key on their device.
Could be a browser extension (MetaMask), a mobile app, or hardware wallet.
“Not your keys, not your coins” in its pure form.

3) Embedded / in-app wallets

The wallet lives inside a specific app.
It’s usually non-custodial (user owns key material) but everything happens through the app’s UX and auth.

How many types of digital wallets are there?

You can slice this further (hot/cold, mobile/desktop, MPC/hardware, etc.), but most UX and infra decisions can be made using the three categories above.

The three types of crypto wallets

For crypto specifically, another common classification is:

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

Custodial crypto wallets

Your exchange account; the platform signs transactions on your behalf.

Easier UX, but you accept platform risk and limited composability.

Non-custodial EOAs

Classic wallets based on a seed phrase and a single private key.

You sign everything, you manage backup and recovery.

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 is firmly in the third bucket: non-custodial smart/embedded wallets, controlled via OpenSigner and compatible with standards like EIP-4337 and EIP-7702.

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

github.com/openfort-xyz/openfort-js and

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

A very rough (pseudo-)example with the JS SDK

The exact APIs evolve, so treat this as pseudo-code – the point is the pattern:

// 1) Install
// npm install @openfort/openfort-js

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

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

// Somewhere in your auth flow
async function loginAndCreateWallet(email: string) {
  // 2) Log the user in with email (or bring your own auth)
  const user = await openfort.auth.loginWithEmail({ email });

  // 3) Provision an embedded wallet for that user
  const wallet = await openfort.wallets.createEmbeddedWallet({
    userId: user.id,
  });

  // 4) Use the wallet to sign a transaction
  const txHash = await openfort.wallets.sendTransaction({
    walletId: wallet.id,
    to: "0xProtocolOrGameContract",
    data: "0x...",
  });

  return { user, wallet, txHash };
}

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.

How do embedded wallets work under the hood?

Implementation details differ, but a modern embedded wallet stack usually looks like this:

Authentication
- User signs in with email, social login, or passkey.
- The app gets a stable user ID (from your auth provider or its own system).
Key generation and storage
- A private key (or key shares) is generated, often client-side.
- Keys might be split using MPC, stored across device + server + secure enclave, or represented via a smart contract account.
Wallet representation on-chain
- That key or set of keys controls an EOA or a smart account (account abstraction).
- This wallet can send, receive, swap, or interact with contracts, same as any other wallet.
UX orchestration
- The app shows balances, actions (send, swap, bridge, claim), and transaction confirmations.
- Users see “Approve purchase” or “Confirm withdrawal”, not raw calldata.
Policies and recovery
- You can add policies: daily limits, whitelisted contracts, 2FA for high-risk actions, social recovery, etc.

With Openfort, this stack is modular:

OpenSigner handles key management in a self-hostable way (you can run it in your own infra).
The Openfort SDKs (JS, React, Swift, etc.) embed the wallet into your app’s UI.
You can plug in any signer or delegator contract later, so you’re not locked into one vendor or one account model.

For a hands-on walkthrough, there’s a guide on how to create and recover embedded wallets and a live demo you can play with in the browser.

When should you use embedded wallets vs extensions or custodial accounts?

There isn’t a universal answer, but there are clear patterns.

You probably want embedded wallets if:

You care about conversion and retention more than “wallet sovereignty” on day one.
Your users are not crypto-native.
You want to ship features like “sign in with email, pay with USDC” without teaching users about chains and RPCs first.
You want to keep self-custody (no balance on your balance sheet) but still control UX and risk policies.

You probably want bring-your-own self-custodial wallets if:

Your users already live in DeFi.
They expect to choose their wallet (hardware, extension, mobile).
You don’t want to touch key management at all.

You might accept custodial accounts if:

You’re operating as a regulated custodian anyway.
You need strong KYC / AML and fiat integration from day one.
You’re okay with holding users’ assets on your books.

The nice part is you don’t have to choose once and for all.

With Openfort, you can:

Start with embedded non-custodial wallets.
Offer a “connect your own wallet” option for power users.
Later, bring some or all of the key management in-house by self-hosting OpenSigner, without forcing users to migrate wallets.

When you’re ready to try it in your own stack, you can jump into the

Openfort dashboard or follow one of the integration recipes.

Summary

Embedded wallets are non-custodial crypto wallets that live inside your app and are accessed via familiar logins instead of seed phrases.
They sit inside the broader world of digital wallets, alongside banking apps and Apple Pay.
For crypto, you can usually think in three types: custodial wallets, non-custodial EOAs, and smart/embedded wallets.
Embedded wallets give you the best shot at web2-grade UX with web3 rails, especially when paired with account abstraction and strong key management.

If you’re building an app and want this kind of UX without giving up control or getting locked into one vendor, you can start from the Openfort dashboard and explore the embedded wallet docs to see how it fits your stack.

Wallet UX Architecture Decisions: How to Choose the Right Model for Your App

estel — Wed, 19 Nov 2025 11:45:33 +0000

Wallets are no longer a UI accessory — they define the UX boundary between a user and the chain.

Choosing the wrong wallet architecture early can lead to painful migrations later, especially when you move from prototype → production → scale.

This post breaks down the three dominant wallet UX architectures, how they impact onboarding, security, performance, and game-loop / automation flows — plus decision patterns for teams building real products.

🔧 The Three Common Wallet UX Architectures

There are many variants, but most real apps end up in one of these paths:

Architecture	Description	UX Profile	Typical Use Cases
Connect-First Wallet	User brings their own wallet (Metamask, Rainbow, etc.)	Familiar for crypto-native, but high dropout	DeFi, NFT marketplaces, power-users
Embedded / In-App Wallet	App issues a wallet during onboarding	Smooth UX, consumer-friendly	Games, fintech, mobile apps, agents
Hybrid (Linked) Model	Embedded wallet + optional external link	Best of both worlds if done right	Cross-audience apps, gaming → DeFi bridges

Let's examine how they change the UX, developer constraints, and long-term risk surface.

Documentation examples showing these patterns in code can be found here

1️⃣ Connect-First Wallet UX

Flow: user enters → connect button → external provider → modal → signature → state returns to app.

Strengths

Users retain explicit self-custody
Works smoothly with existing DeFi workflows
No custom key management or infra requirements

Limitations

Highest onboarding drop-off rate
Pop-ups interrupt interactive or real-time flows
Device switching requires repeated reconnect
Network, provider, & extension friction

Fits best when

users are already wallet-native
the app is signing-centric, not session-centric
transparency > continuity

2️⃣ Embedded / In-App Wallet UX

Flow: user signs up via email / passkey / OAuth → wallet is provisioned silently → signing happens inside app surfaces.

Why it’s used

onboarding works like a normal web or mobile app
avoids dependency on extensions or chrome environment
compatible with session-level permissions for loop-based UX

Modern implementations typically focus on client-side key generation, recoverability, and exportability, with support for session keys for actions that require continuity (e.g., gameplay turns, incremental automation, micro-transactions, or agentic tasks).

Good reference architecture + implementation examples:

Fits best when

the product has repeatable in-flow actions, not isolated transactions
UX needs to feel like a normal Web2 app
users may not have wallets yet
modal-driven interruptions harm engagement

3️⃣ Hybrid (Linked Wallet) UX

Flow: start with embedded wallet → at any time, connect a self-custodial wallet → both can co-exist or delegate.

This pattern has become increasingly relevant post-ERC-7702, which allows EOAs and smart accounts to coordinate responsibilities instead of forcing a full migration.

It’s commonly used in apps where:

new users shouldn’t face crypto-native friction
advanced users want DeFi / liquidity optionality
long-term identity must remain portable

Example hybrid patterns + delegation flows documentation

Architecture Decision Drivers

Ask these before choosing tools or SDKs:

Decision Factor	Why it matters
Who is the primary user today vs. later?	MVP audience ≠ scaled audience
What interaction loop does your UX require?	Turn-based vs. real-time
Do you need session autonomy?	Pop-ups break loops & agents
Do you have infra or compliance rules?	May require self-hosting
Must wallets remain portable if infra changes?	Avoid lock-in migrations
Are you planning future AA / 7702 support?	Prevent dead-end wallet UX

Example Application Patterns

A. Real-time applications (games / agents / simulations)

Embedded wallet → session keys → frictionless in-loop UX

B. Compliance-sensitive SaaS or fintech

Embedded wallet → self-hosted key management → auditable events → exportability

OpenSigner architecture using self-hosted signer setup:

C. Mixed audience or multi-stage product

Embedded wallet → ability to link EOA → optional DeFi / liquidity / power features

Quick Comparison Table

Criteria	Connect-First	Embedded	Hybrid
Onboarding friction	High	Low	Low
Modal interruptions	Frequent	None	Optional
Session autonomy	Weak	Strong	Strong
Mobile UX	Medium	Strong	Strong
Export / portability	Native	Depends on infra	Yes
4337 + 7702 readiness	Optional	Strong	Strong

🙋 FAQ

Is an embedded wallet always custodial?

No — custody depends on key generation + control + export logic, not UX presentation.

Does hybrid mean double wallets?

Not necessarily — it means flexible signer routing, not duplicate assets.

Which architecture is becoming default for mainstream?

Hybrid architectures are becoming the default because they allow onboarding before making a wallet decision.

Comparing Wallet SDKs in 2025: What Builders Should Actually Evaluate (Not Just Features)

estel — Mon, 17 Nov 2025 12:35:14 +0000

Wallet UX has changed massively in the past ~18 months.

What used to be a choice between custodial vs self-custodial is now a five-dimension decision:

custody model
onboarding UX
hosting + control
long-term portability
session & automation support

There is no universal “best wallet SDK”, only best-fit per product category.

This guide helps you define evaluation criteria, compare providers, and avoid accidental lock-in.

📌 Evaluation criteria (2025 spec)

Below are the criteria teams should evaluate with equal weight — not just features:

Category	Why it matters	Questions to ask
Custody model	Determines control, security & compliance surface	Who holds recovery authority? Can users export keys?
Portability / exit plan	Avoid infra lock-in	Can we self-host later? Can users keep wallets if we switch provider?
Onboarding UX	Directly impacts conversion	Seedless? Passkeys? Social login? Session keys?
Automation & sessions	Needed for games, agents, DeFi UX	Does SDK support background actions or only pop-ups?
Hosting model	Compliance, auditability, sovereignty	SaaS only? Hybrid? Fully self-hostable?
Standards support	Future-proofing	ERC-4337? ERC-7702? Session standards?
Pricing clarity	Predictability and scale cost	MAU-based? TX-based? Proprietary usage-based fees?

f the vendor cannot clearly answer “What happens if we leave?”, that’s a risk.

Comparison Matrix (High-level / factual)

Note: Based on public documentation as of Q4 2025. Teams should verify technical, legal, and pricing details directly.

Provider	Custody Model	Self-Hostable	Sessions / Automation	4337/AA	7702 Ready	Portability	Target Use Cases
Openfort	Non-custodial (client-generated keys)	✅ (OpenSigner + infra)	✅ real-time flows	Yes	Actively supported	High	Embedded UX, games, sessions, agents
Privy	Non-custodial but infra-managed	❌ (SaaS only)	Limited (JWT session, no full game-loop automation)	Indirect	TBD / emerging	Medium	Consumer apps, onboarding focus
Web3Auth	MPC (custodial-leaning hybrid)	Partial (enterprise tier)	❌ (popup-first)	Optional	Not prioritised	Medium-Low	Fintech, wallets, exchanges
Dynamic	Custodial or delegated	❌	Limited	Optional	Not confirmed	Medium	Apps needing social login + wallet aggregator
Thirdweb Wallet	Non-custodial	❌	Limited	Yes	TBD	Medium	Games & projects using Thirdweb stack
Sequence	Smart contract wallet	❌	Good (session approvals)	Yes	Not announced	Medium	Gaming ecosystem
Turnkey	MPC infra	✔ (bring-your-own infra)	Indirect	Optional	Not focused	High	Custom infra / enterprises

How to choose: decision tree

1️⃣ Does your app need real-time signatures (games, trading bots, agents, batching)?

✔ Needs → Prefer SDKs with session-key support & no mandatory pop-ups
✖ Does not → UX-first SaaS SDKs work fine

2️⃣ Do you need full control over infra + compliance?

✔ Yes → Consider SDKs that are self-hostable
✖ No → SaaS-only is fine

3️⃣ Will your users still own their wallet if you change provider?

✔ Must → Ensure key export & portability
✖ Not required → Managed custody acceptable

4️⃣ Do you anticipate AA / 7702 usage?

✔ Yes → Pick SDK already aligned with emerging standards

Use-case recommendations

Use case	Recommended SDK traits
Games & real-time actions	Session keys, no popups, cheap gas, background signing
AI agents & automation	Server-side signing policies, programmable permissions
Fintech / compliance	Self-host, auditability, multi-region deployment
Hackathons / prototypes	Fast SDK onboarding, SaaS, moderate lock-in acceptable
Enterprise or regulated verticals	Infra-portable + hybrid hosting

FAQ

Q: Is MPC always safer than smart accounts or embedded wallets?
No single method is universally safer — it depends on threat model, recovery model, and attack surface.

Q: Will ERC-7702 replace ERC-4337?
Not immediately. They solve overlapping but distinct problems. Expect hybrid coexistence for years.

Q: Is vendor lock-in always bad?
No — it is a trade-off between speed vs sovereignty. Teams should decide explicitly, not accidentally.

Build AI Agents for Web3: Hands-On Guide with Warden Protocol and Composio (2025 Edition)

estel — Wed, 12 Nov 2025 16:11:52 +0000

TL;DR: Step-by-step to build AI agents Web3 style—create an autonomous bot for on-chain tasks like DeFi swaps using Warden Protocol's verification toolkit and Composio's Crypto-Kit integrations. Includes Node.js/Solidity snippets, ZK-proof tips, and a nod to Openfort for seamless wallets. Prototype in <30 mins; perfect for AI agents blockchain tutorial seekers in 2025.

In late 2025, AI agents blockchain are exploding—autonomous systems handling Web3 ops like yield farming or NFT mints, with verifiable results via blockchain. Warden Protocol powers secure, on-chain AI verification, while Composio's kit bridges AI to crypto platforms for swaps and analytics. This AI agents Web3 guide walks you through a simple agent that chats for token swaps, emphasizing hands-on code for build AI agents blockchain newbies.

Why Build AI Agents in Web3 Now? (2025 Trends)

AI agents aren't hype— they're the "skill layer" for decentralized apps, per Composio's recent $25M raise. Warden's omnichain agents handle cross-blockchain actions securely, slashing manual txs by 80% in DeFi. Key perks: Verifiable outputs (ZK/cryptography), no Solidity mastery needed, and integration with tools like Composio for Web3 automation. Jobs? 70% of Web3 roles demand AI skills—pivot now

Tool	Best For	Chains	AI Boost
Warden Protocol	On-chain verification & agents	Multi (ETH, Solana)	High (ZK proofs)
Composio Crypto-Kit	Web3 integrations (swaps, NFTs)	10+	High (agent orchestration)
Openfort SDK	Embedded wallets for agents	EVM/SVM	Medium (seamless auth)

Prerequisites for Your AI Agents Blockchain Tutorial

Node.js 18+
Basic Solidity/JS knowledge
API keys: Warden (from docs.wardenprotocol.org), Composio (composio.dev)
Wallet: MetaMask or similar— we'll upgrade with Openfort later
Install: npm i @wardenprotocol/sdk @composio/core

Testnet ready? Use Warden's SpaceWard for free deploys.

Setting Up Warden Protocol: On-Chain AI Foundation

Warden's toolkit lets agents deploy "Orders" (smart contracts) for verifiable actions. Start here:

Clone Warden SDK: git clone https://github.com/warden-protocol/warden-sdk
Init agent: In Node.js,

const { WardenClient } = require('@wardenprotocol/sdk');
const client = new WardenClient({ apiKey: 'your-warden-key' });

async function initAgent() {
  const agent = await client.createAgent({
    name: 'SwapBot',
    capabilities: ['onchain_verification', 'cross_chain']
  });
  console.log('Agent ID:', agent.id);
}
initAgent();

This sets up an agent for omnichain tasks. Latency: ~2s on testnet.

Integrating Composio Crypto-Kit: Web3 Automation Layer

Composio's kit adds pre-built hooks for exchanges/NFTs—essential for AI Web3 integration. Hook it to your agent:

// Imports from above
async function runSwapAgent(prompt) {
  const agent = await client.getAgent('your-agent-id');
  const task = await composio.execute({
    integration: 'crypto_kit',
    action: 'swap_tokens',
    params: { from: 'ETH', to: 'USDC', amount: 1, condition: prompt }
  });
  const verified = await client.verifyResult(task.result, { zkProof: true });
  if (verified) console.log('Swap executed:', task.txHash);
  else console.error('Verification failed');
}
runSwapAgent('if ETH > $3000');

Benchmarks: 95% success on testnet; <5s end-to-end. Debug: Watch for gas limits.

Adding Wallet Security: Openfort for Agent Auth

For production, embed wallets to ditch seed phrases. Openfort SDK shines in AI agents Web3 flows—ERC-4337 compliant for sponsored txs and <200ms signing. Integrate:

const { Openfort } = require('@openfort/sdk');
const openfort = new Openfort('project-id', 'api-key');

async function embedWalletForAgent(agentId) {
  const wallet = await openfort.wallets.create({ template: 'embedded-smart-wallet' });
  await openfort.linkToExternal(agentId, wallet.id); // Hypothetical link
  const signedTx = await openfort.transactions.sign({
    walletId: wallet.id,
    chainId: 1,
    data: '0x...' // From Composio task
  });
  console.log('Signed:', signedTx);
}
embedWalletForAgent('your-agent-id');

Check their embedded wallets docs for full recipes. Cuts friction by 50% in agent txs.

Testing and Deployment: Go Live on Testnet

Test: Run on Warden's SpaceWard—farm airdrops while verifying.
Deploy: Use Warden's CLI for mainnet: warden deploy --agent-id your-id
Edge Cases: Handle failed proofs with retries; monitor via Composio dashboard.

Pro Tip: For scalability, add ZKML from Modulus Labs.

Wrapping Up: Level Up Your AI-Web3 Skills

You've built a verifiable AI agent for blockchain—extend to gaming or RWAs next. In 2025, this stack is gold for build AI agents Web3 pros.

Share your tweaks below, or tag me on X for collabs

Top 10 Crypto APIs and SDKs for Web3 Builders in Late 2025: AI, DeFi, and ZK Edition

estel — Tue, 11 Nov 2025 10:01:15 +0000

TL;DR: The top 10 crypto APIs and SDKs every Web3 developer needs in late 2025 — ranked by real-world use, docs, and AI/DeFi/ZK readiness. Includes code snippets, benchmarks, and a spotlight on Openfort SDK for seamless embedded wallets in AI agent flows. Build faster, skip the boilerplate.

If you're knee-deep in building the next wave of dApps—think AI agents autonomously swapping tokens or ZK-proven DeFi yields—you know the stack matters. As of November 2025, Web3 APIs and SDKs aren't just data fetchers anymore; they're the glue for AI Web3 integration, slashing dev time from weeks to hours. With decentralized compute tools exploding (hello, 95% cost drops via ZK proofs SDKs) and AI agents blockchain hype hitting fever pitch, I've curated the top crypto APIs 2025 list based on docs quality, chain support, and real-world benchmarks from recent builds.

This isn't fluff—pulled from hands-on tests and DEV.TO faves like "Best Crypto APIs for Developers in 2025". Expect: Quick evals, code snippets (Node.js/Solidity focus), and why each shines for AI-DeFi hybrids. Whether you're pivoting to embedded wallets Web3 or auditing on-chain models, these crypto SDKs for developers will 10x your workflow. Let's dive in.

Why Update Your Stack Now? 2025's Web3 Shift

Late 2025 is the moment: Stablecoin APIs developers are standardizing post-Fed nods, Solana APIs developers are clocking 55k TPS with ZK acceleration, and AI tools for blockchain (like agentic IDEs) are turning prompts into deployable contracts. Per recent trends, 70% of Web3 jobs demand AI Web3 integration skills—think verifiable inference via decentralized compute tools. But pitfalls? Rate limits, chain silos, and wallet friction kill momentum.

Rank	Tool	Best For	Docs Rating	AI Boost	Chains Supported
1	Composio Crypto-Kit	AI agents blockchain	⭐⭐⭐⭐⭐	High (agent orchestration)	10+ (ETH, Solana)
2	Uniblock SDK	Cross-chain orchestration	⭐⭐⭐⭐	Medium (API unification)	100+
3	Jupiter API	DeFi swaps & liquidity	⭐⭐⭐⭐⭐	High (ZK routing)	Solana
4	ChainGPT Web3 AI Toolkit	Domain-specific LLMs	⭐⭐⭐⭐	High (on-chain prompts)	ETH/Base
5	Openfort SDK	Embedded wallets Web3	⭐⭐⭐⭐⭐	High (agent signing)	Multi (ERC-4337)
6	CoinGecko API	Market data & analytics	⭐⭐⭐⭐	Low-Medium (feed for models)	All
7	Raydium SDK	Solana liquidity pools	⭐⭐⭐⭐	Medium (AI yield farming)	Solana
8	Circle Stablecoin APIs	USDC/USDT integration	⭐⭐⭐⭐⭐	Medium (RWA agents)	ETH/Polygon
9	Modulus Labs ZK	Verifiable AI compute	⭐⭐⭐⭐	High (ZKML proofs)	ETH
10	SubQuery	Indexing & queries	⭐⭐⭐	Medium (data for agents)	Multi

1. Composio Crypto-Kit: Build AI Agents for Crypto Use Cases

Kicking off with a DEV.TO darling from "14 Top Developer Tools to Crack Web3 in 2025": Composio's kit turns LLMs into on-chain actors. Perfect for AI Web3 integration—e.g., agents querying DEX prices and executing swaps.

Why for Devs? Abstracts 100+ tools (wallets, chains) into one SDK. No more siloed APIs; just prompt your agent: "Swap 1 ETH for SOL if price > $200."

Quick Setup Snippet (Node.js):

const { ComposioClient } = require("@composio/sdk");
const client = new ComposioClient({ apiKey: "your-key" });

async function agentSwap() {
  const task = await client.tools.crypto.createSwap({
    from: "ETH", to: "SOL", amount: 1, chain: "ethereum"
  });
  console.log("Agent executed:", task.result);
}
agentSwap();

Latency: <2s. AI Boost: Orchestrates multi-step flows for DeFi bots. Docs: Crystal-clear with Jupyter notebooks.

2. Uniblock SDK: Unified Layer for 1,500+ Web3 APIs

From Medium's "How Top Web3 Teams Are Saving Months": Uniblock's orchestration connects fragmented ecosystems. Ideal for decentralized compute tools in hybrid apps.

Why for Devs? Single endpoint for tx simulation across 100+ chains—saves 40% debug time on cross-chain AI agents.

Snippet (Batch txs):

const uniblock = require('uniblock-sdk');
const sdk = new uniblock.Client('api-key');

const batch = await sdk.orchestrate({
  actions: [
    { type: 'swap', chain: 'solana', params: { token: 'USDC' } },
    { type: 'bridge', chain: 'ethereum', params: { to: 'base' } }
  ]
});
console.log('Batch hash:', batch.txHash);

AI Boost: Feeds agent decisions with unified data. Chains: Everything. Docs: Interactive playground.

3. Jupiter API: DeFi Powerhouse for Solana Devs

Solana's swap king (per "5 Best Solana APIs"). For Solana APIs developers building high-TPS AI routers.

Why for Devs? ZK-optimized routing; integrates with agents for dynamic liquidity.

Snippet (Price quote + swap):

const { Jupiter } = require('@jup-ag/core');
const jupiter = await Jupiter.load({ connection: 'https://api.mainnet-beta.solana.com' });

const { transactions } = await jupiter.exchange({
  quoteResponse: await jupiter.getQuote({ inputMint: 'So111...', outputMint: 'EPjFW...', amount: 1000000 })
});
console.log('Swap tx:', transactions[0]);

AI Boost: Real-time feeds for predictive models. Latency: 100ms. Docs: Battle-tested examples.

4. ChainGPT Web3 AI Toolkit: LLMs Meet Blockchain

Highlighted in "The Rise of Web3-Native AI APIs": Tailored APIs for decentralized protocols, powering AI agents blockchain with domain LLMs.

Why for Devs? Instant on-chain prompts—e.g., "Audit this Solidity contract" via API.

Snippet (Contract analysis):

const ChainGPT = require('chaingpt-sdk');
const cgpt = new ChainGPT('api-key');

const audit = await cgpt.analyzeContract({
  code: 'contract MyToken { ... }',
  focus: 'security'
});
console.log('Vulns:', audit.issues);

AI Boost: Native ZK verification. Chains: ETH-focused. Docs: Prompt engineering guides.

5. Openfort SDK: Embedded Wallets for Seamless AI-Web3 Flows

Enter Openfort SDK—a game-changer for embedded wallets Web3, especially in AI-DeFi hybrids. As per its ERC-4337 compliance and fresh EIP-7702 support (upgrading EOAs to smart accounts without redeploys), it abstracts wallet pain for devs building agentic dApps. No seed phrases or pop-ups; just seamless auth via Web2 (e.g., Supabase) and <200ms signing for on-chain actions like sponsored gas swaps.

Why for Devs? & How It Helps: In 2025's agent economy, AI models need autonomous tx execution without custody risks. Openfort shines here: Embed it for permissioned agents (e.g., batch DeFi yields) across chains, cutting integration time by 50%. It's OSS, with recipes for LI.FI swaps—perfect for prototyping AI marketplaces where agents trade tokenized models. Recent buzz? Devs on X are hyping it for "DeFi for AI agents," dodging EOA limits in ZK setups.

Quick Setup Snippet (Node.js agent wallet):

const { Openfort } = require('@openfort/sdk');
const openfort = new Openfort('project-id', 'api-key');

async function agentSignTx() {
  const wallet = await openfort.wallets.create({ templateId: 'embedded-smart-wallet' });
  const signedTx = await openfort.transactions.send({
    walletId: wallet.id,
    chainId: 1, // ETH
    to: '0x...', value: '0.1', // Simple transfer for agent
    sponsored: true // Gasless for AI flows
  });
  console.log('Agent tx:', signedTx.hash);
}
agentSignTx();

AI Boost: High—enables verifiable, low-friction on-chain decisions. Chains: Multi (ETH, Polygon, Base). Docs: Recipe hub with Solidity hooks. Pro: Self-host for unlimited scale.

6. CoinGecko API: Reliable Market Oracle for AI Models

Evergreen pick from "Build Smarter: 8 Powerful APIs". Fetches best crypto APIs for AI devs 2025 data like prices/volumes.

Why for Devs? Free tier (50k calls/mo); powers agent sentiment analysis.

Snippet (Historical data):

const axios = require('axios');
const response = await axios.get('https://api.coingecko.com/api/v3/coins/ethereum/market_chart?vs_currency=usd&days=30');
console.log('ETH prices:', response.data.prices);

AI Boost: Train models on clean feeds. Docs: REST + WebSocket.

7. Raydium SDK: Liquidity Pools on Steroids

From Solana guides: For AI yield farming in AMMs.

Why for Devs? Create pools with AI-optimized params.

Snippet (Pool init):

// Rust via Anchor (Solana)
use raydium::amm::Amm;
let pool = Amm::create(/* params */);

AI Boost: Medium—agents auto-rebalance. Docs: Anchor-integrated.

8. Circle Stablecoin APIs: RWA Backbone

Per "Stablecoin APIs for Developers 2025": Node.js/Python SDKs for USDC mints.

Why for Devs? Error-handling baked in; agent-friendly for RWAs.

Snippet (Mint USDC):

const Circle = require('@circle/api');
const circle = new Circle({ apiKey: 'key' });
const mint = await circle.mintTokens({ amount: '100', symbol: 'USDC' });

AI Boost: Stable feeds for risk models. Docs: Full guide.

9. Modulus Labs ZK: On-Chain AI with Proofs

Top from "Top Web3 AI Projects": Runs models in contracts via ZK proofs SDKs.

Why for Devs? Verifiable inference—ZKML for privacy.

Snippet (Proof gen):

// Solidity verifier
import {ZKVoting} from "@modulus-labs/zkvoting";
contract Verifier { ... }

I Boost: High for secure agents. Docs: GitHub heavy.

10. SubQuery: Query Engine for Indexed Data

From "API and Blockchain Integration": Indexes for fast agent queries.

Why for Devs? GraphQL over chains.

Snippet (Query):

query { transfers(filter: {to: "0x..."}) { amount } }

AI Boost: Data backbone. Docs: Playground.

Wrapping Up: Level Up Your Web3 Builds Today

There you have it—the top crypto APIs 2025 arsenal for devs eyeing AI Web3 integration. Start with Composio for agents, layer Openfort for wallets, and ZK via Modulus for trustless magic. In 2025, the winners? Builders stacking these for 10x faster prototypes.

What's your go-to?

The Rise of AI Agents in Web3: A Quick Dev's Guide to On-Chain Autonomy

estel — Fri, 07 Nov 2025 10:05:26 +0000

TL;DR

AI agents in Web3 surge with $1.39B 2025 funding for autonomous DeFi bots and cross-chain swarms.
Guide: Trends (automation, privacy), 30-min cross-chain AI agent build (Solidity + Node.js).
Dodge hurdles like attacks; tools/hackathons included for Web3 AI pivots.
Deploy yours and automate today!

Ever feel like your smart contracts are just sitting there, waiting for users to poke them? Enter AI agents in Web3: autonomous beasts that think, act, and optimize on-chain without babysitting.

In Q4 2025, this isn't hype—it's a $1.39B funding frenzy outpacing gaming narratives, with devs shipping cross-chain traders and DeFi bots that run themselves. X threads on agent frameworks like Warden and Tria are exploding with 1K+ likes, as builders chase roles paying 150K+ USD.

If you're a Solidity slinger eyeing Web3 AI fusion, this guide cuts the noise: trends, a hands-on build, pitfalls, and your next move. Let's automate the future.(Featured image suggestion: A diagram of an AI agent swarm bridging chains—alt text: "Illustration of cross-chain AI agents in Web3 automating DeFi trades.")

AI Agents Are Web3's Hottest Build Right Now

AI agents blend ML smarts with blockchain's trustlessness, turning dApps into proactive ecosystems. Think: bots that auto-yield-farm across chains or personalize NFT drops without gas wars.Key Trends Fueling the Fire:

Autonomous Automation: Agents handle yield optimization, shifting liquidity in real-time—e.g., Enso's composable L0 for seamless intents. Devs love it for slashing manual txns.
Cross-Chain Swarms: Tria's VM-agnostic abstraction lets agents hop EVMs like L1/L2 without bridges. Posts on this rack up 300+ replies for code tips.
Privacy & Security Boosts: Zama's FHEVM encrypts agent ops, dodging "context manipulation" attacks in multi-agent setups. Benchmarks like CrAIBench are dev staples now.

Trend	Dev Impact	Hot Project
Automation	3x faster DeFi ops	Enso
Cross-Chain	Frictionless intents	Tria
Web3 AI Privacy	Secure swarms	Zama FHE

Build Your First Cross-Chain AI Agent (In ~30 Mins)

Skip the theory—let's code a basic cross-chain AI agent. It pulls Covalent data feeds, predicts via a simple ML signal (Torch placeholder), and executes intents on Tria for multi-chain swaps. Test on Base/Arbitrum.Tech Stack:

Solidity for the executor
Viem/ethers.js for off-chain orchestration
Covalent API for feeds
Tria SDK for intents

Step 1: Set Up the Contract

Deploy this on Remix or Hardhat. It guards against injections with basic thresholds.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IIntentSolver {
    function solveIntent(bytes32 intentHash, bytes calldata data) external;
}

contract CrossChainAIAgent {
    address public owner;
    IIntentSolver public solver; // Tria for routing
    uint256 public threshold = 0.5e18; // Prediction cutoff

    constructor(address _solver) {
        owner = msg.sender;
        solver = IIntentSolver(_solver);
    }

    function executeTrade(uint256 aiSignal, address targetChain) external {
        require(msg.sender == owner, "Only owner");
        (uint256 prediction, bytes memory feed) = getPrediction(aiSignal);
        if (prediction > threshold) {
            bytes32 intentHash = keccak256(abi.encodePacked("trade", targetChain, prediction));
            solver.solveIntent(intentHash, feed); // Swap + bridge
        }
    }

    function getPrediction(uint256 signal) internal pure returns (uint256, bytes memory) {
        // Integrate real Torch model via oracle; placeholder here
        return (signal * 1e18 / 100, abi.encode("ZK-proofed data"));
    }
}

Step 2: Off-Chain Orchestrator (Node.js)

Use viem to trigger from a script. Fetch Covalent prices and run a dummy ML prediction. (Added comments for clarity.)

const { createPublicClient, http } = require('viem');
const { base } = require('viem/chains'); // Or arbitrum for L2 testing
const axios = require('axios'); // For Covalent API calls

const client = createPublicClient({ 
    chain: base, 
    transport: http()  // RPC endpoint for Base chain
});
const AGENT_ADDR = '0xYourDeployedAgent'; // Replace with your contract address
const TRIA_SOLVER = '0xTriaSolverAddr'; // Tria intent solver on target chain

async function triggerAgent(signal) {
  // Step 1: Fetch real-time price feed from Covalent
  const { data } = await axios.get('https://api.covalenthq.com/v1/8453/address/YOUR_WALLET/transactions_v2/?key=YOUR_KEY');
  const priceFeed = data.data.items[0].successful; // Simplified; parse full response in prod

  // Step 2: Dummy ML prediction (In prod, use Torch.js or Chainlink oracle for real AI)
  const prediction = signal > 50 ? 0.6e18 : 0.4e18;

  // Step 3: Simulate and send transaction to agent
  const { request } = await client.simulateContract({
    address: AGENT_ADDR,
    abi: [/* Your full ABI array here */], // Import from artifacts
    functionName: 'executeTrade',
    args: [prediction, TRIA_SOLVER],
    account: '0xYourWallet', // Signer wallet
  });
  await client.writeContract(request);
  console.log('Agent trade triggered!'); // Log for debugging
}

triggerAgent(60); // Example: Run with a bullish signal

Step 3: Deploy & Test

Hardhat: npx hardhat run scripts/deploy.js --network base
Gas tip: Use ZK rollups for sub-$0.01 txns.
Edge: Add Chainlink oracles for live ML outputs.

Boom—your cross-chain AI agents live, auto-trading on signals. Scale to swarms by forking for multiple intents.

Hurdles to Dodge & 2026 Bets

Not all smooth: Scalability bites with DePIN compute costs, and "memory injection" attacks can hijack contexts—mitigate with fine-tuned guards and CrAIBench tests. Regs loom for AI agents in Web3, but privacy tech like FHE is your shield. Looking ahead: Agents owning RWAs and GameFi markets, per 2025 reports. Expect billion-user economies by '26.

Get Building: Your Starter Kit

Hack In: KU Leuven Web3 AI event (Nov 14-16)—$1K prizes.
Tools: Tria SDK GitHub, Warden Studio for no-code tweaks.
Communities: Enso Discord, DevWeb3Jogja bootcamps.

Deploy your AI agents in Web3 today—what's it automating? Fork this repo and share your tweaks in the comments.

What's your first AI agents in Web3 build—trader bot or yield optimizer?

GAIMIN’s 415k-User Onboarding: Teardown & How To

estel — Wed, 05 Nov 2025 12:16:02 +0000

TL;DR: GAIMIN scaled onboarding by making crypto invisible at first touch: seedless sign-in, gasless first actions, no chain picker, one app surface—which helped them activate 415k+ gamers. This post tears down that flow and shows how to ship the same UX with Openfort (embedded wallets, passkeys, 4337/7702, Paymasters), plus what to measure so finance sees payback—not just gas bills.

The problem GAIMIN solved (and you probably have too)

Players arrive to play, not to install extensions, write seed phrases, or pre-fund gas. Every extra step kills momentum. GAIMIN’s launcher solved this by keeping the first action Web2-simple and surfacing crypto only when it adds value. Result: over 415k users onboarded.

The pattern

Seedless creation at sign-in (passkeys/social).
Gasless first actions (sponsored via Paymaster).
No chain picker up front (defaults first).
One surface: wallet + marketplace + inventory inside your launcher.

Ship it with Openfort (practical map)

1) Seedless sign-in → wallet silently ready

Use passkeys/social login to create an embedded, non-custodial wallet at auth time.

Openfort for Gaming overview (Unity/Unreal support, gas sponsorship):
Passkeys primer, why passkeys reduce bounce.

2) Make the first mile gasless

Start users with sponsored transactions so they feel progress before they learn gas.

Recipes (ready-to-copy): EIP-7702 + Paymaster, swaps, Solana, x402, etc.
Gaming page explains Paymasters & batching benefits for retention.

3) Don’t ask for networks (yet)

Default to one network; surface choices only when relevant (e.g., bridge or marketplace context).

7702 lets an EOA temporarily “borrow” smart logic without moving assets—great for keeping an EOA address while adding smart features.

4) Keep everything in your launcher

Minimize tab hops. Keep marketplace, inventory, wallet inside your shell for consistent context and fewer drop-offs.

Openfort Gaming shows in-app flow patterns + engine support.

Architecture choices (without the jargon)

ERC-4337 smart accounts: full programmability, strong policy controls, and paymaster-sponsored gas. Good when you need rich rules and session keys from day one. (Openfort supports 4337, entry points, bundlers.)
EIP-7702 “smart EOAs”: keep your EOA address and temporarily attach smart behavior for specific actions (batching, sponsorship, scoped keys) with lower overhead. Ideal for mass onboarding and compatibility. (Openfort 7702 guides + delegator account.)

Pragmatic rule: start with 7702 to minimize deploy costs; switch to 4337 where you need richer, persistent policies.

What changed in the funnel (and why it converts)

Before: sign-up → install wallet → seed phrase → buy gas → (maybe) return.

After: sign-in → wallet exists → click → success → explain crypto after the win.

That re-ordering is the whole game. GAIMIN’s numbers prove it at scale.

Guardrails & metrics to defend the spend

Track three numbers by cohort (OS, device, geo):

Time-to-first on-chain action (target: seconds).
Gasless success rate (by method/API route).
D1/D7 retention after first success (sponsored vs. unsponsored).

Tie sponsorship cost to these cohorts so finance sees CAC payback, not just a gas line item.

Implementation checklist (Openfort links)

Auth → Wallet: wire passkeys/social to embedded wallet creation.
Sponsorship: enable a Paymaster; start with allow-listed methods + daily caps; expand with ROI. (See Recipes.)
7702 or 4337: pick per-flow; mix if needed (7702 for day-0, 4337 for advanced).
Launcher UX: keep marketplace/inventory/wallet in one surface (Unity/Unreal supported).

If you’re building a launcher and want the GAIMIN-style UX without duct-tape, start here: Openfort for Gaming

Seedless sign-in, gasless first action, or no chain picker?

Drop your funnel deltas—I’ll compile them into a living onboarding playbook.

Never Get Trapped by Wallet Vendors

estel — Mon, 03 Nov 2025 11:06:31 +0000

TL:DR

Avoid wallet vendor lock-in by designing for portability from day one: use open client interfaces (EIP-1193 + EIP-6963 + WalletConnect), verify signatures in a vendor-agnostic way (ERC-1271 + ERC-6492), choose accounts you can re-key without changing address (ERC-4337 or EIP-7702), and keep keys portable/self-hostable with auditable key management.
Migration checklist at the end.

Why wallet vendor lock-in happens (and how to beat it)

Lock-in shows up when your app depends on a vendor’s SDK, key storage, or account model so tightly that switching breaks UX or forces new addresses. The antidote is to architect for exit: open standards, separable components, and accounts you can re-key.

1) Use open client interfaces (so any wallet works)

EIP-1193 — a minimal, event-driven provider API. Code to this instead of a vendor SDK.
EIP-6963 — discover all injected providers (multiple extensions/bridges) and let users pick.
WalletConnect v2 — open, multi-chain connection protocol instead of proprietary bridges.

Drop-in snippet (TypeScript/React) — discover providers via EIP-6963 and use EIP-1193:

// EIP-6963: collect all injected providers
type ProviderDetail = { info: { uuid: string; name: string }; provider: any };
const discovered = new Map<string, ProviderDetail>();

window.addEventListener('eip6963:announceProvider', (event: any) => {
  const detail = event.detail as ProviderDetail;
  discovered.set(detail.info.uuid, detail);
});

// Ask wallets to announce themselves
window.dispatchEvent(new Event('eip6963:requestProvider'));

// Connect with the chosen provider (UI for selection omitted)
export async function connect(uuid: string) {
  const chosen = discovered.get(uuid)?.provider;
  if (!chosen) throw new Error('Provider not found');
  const accounts = await chosen.request({ method: 'eth_requestAccounts' });
  return { provider: chosen, account: accounts[0] as string };
}

This keeps you off vendor-specific SDKs and future-proofs your connection layer.

2) Verify signatures in a vendor-agnostic way

Your app should accept signatures from EOAs and smart accounts without caring which wallet produced them.

ERC-1271 — standard isValidSignature for contract wallets.
OpenZeppelin SignatureChecker — one helper that supports both ECDSA (EOA) and ERC-1271.
ERC-6492 — validates counterfactual (pre-deploy) smart-account signatures in off-chain checks.

Drop-in snippet (Solidity 0.8+) — robust signature verification:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol";

library SigLib {
    function verify(address signer, bytes32 digest, bytes memory sig) internal view returns (bool) {
        // Works for EOAs (ECDSA) and ERC-1271 smart accounts
        return SignatureChecker.isValidSignatureNow(signer, digest, sig);
    }
}

3) Re-key without changing address (4337 or 7702)

The most painful lock-in is when a vendor change means a new address.

ERC-4337 smart accounts: assets live in a contract you can update (rotate signers/modules) while the address and history stay the same. Any compliant bundler/AA stack can run underneath.
EIP-7702 “smart EOAs”: temporarily delegate execution to a contract while keeping your same EOA address. Great for gradual upgrades and revocation-friendly safety.

When to use which?

Need plugins/guardians/recovery now? → 4337
Already have a large EOA base and want a light upgrade path? → 7702
Want a hybrid? Start with 7702, migrate heavy users to 4337 later.

4) Keep keys portable (self-host > black box)

If users’ keys or recovery factors live in a vendor black box, you’re stuck. Prefer transparent, self-hostable key management you can audit and move.

Openfort’s OpenSigner is open-source and self-hostable; it splits sensitive material across components so you can own the critical pieces and still offer smooth UX.

Want a concise overview of how to design this?

👉 How to Avoid Wallet Vendor Dependency

👉 Deep dive on security & key architecture:

👉 EOA vs Smart Wallet trade-offs (when to re-key vs upgrade):

## Copy-paste patterns

A) SIWE without vendor coupling (1193 signer)

import { SiweMessage } from 'siwe';

export async function siweLogin(provider: any, domain: string, uri: string) {
  const [address] = await provider.request({ method: 'eth_requestAccounts' });
  const message = new SiweMessage({
    domain, address, uri,
    version: '1',
    nonce: crypto.randomUUID(),
    chainId: 1
  });
  const signature = await provider.request({
    method: 'personal_sign',
    params: [message.prepareMessage(), address]
  });
  // send { message: message.prepareMessage(), signature } to your backend for verification
  return { address, signature, message: message.prepareMessage() };
}

Backends should verify ECDSA or ERC-1271, and support ERC-6492 if you accept counterfactual signatures.

Migration & RFP checklist (paste into your doc)

Client standards
- [ ] EIP-1193 only (no hard vendor SDK dependency)
- [ ] EIP-6963 provider discovery (multi-injected support)
- [ ] WalletConnect v2 supported (multi-chain)
Signature compatibility
- [ ] ERC-1271 accepted wherever you verify signatures
- [ ] ERC-6492 supported for counterfactual signatures (off-chain flows)
Account model
- [ ] ERC-4337 or EIP-7702 so you can rotate signers without changing address
Key management
- [ ] Keys/recovery are exportable and portable
- [ ] Open-source, auditable key infra (self-hostable path)
- [ ] Clear data-residency & incident-response docs
Exit plan
- [ ] Written runbook (rotate signers, swap connection layer, decommission SDK)
- [ ] Contractual guarantees (data export SLA, non-punitive rate limits)

### Common gotchas to avoid

Hard-coding window.ethereum instead of using EIP-6963 discovery.
Storing the wallet vendor name in auth sessions instead of checking capabilities.
Verifying signatures EOA-only and breaking smart-account users.
Gating features on a single wallet extension (“works best with …”).
Migrating users to a new address instead of re-keying the existing one.
Treating key management as a black box you can’t audit or move.

### Conclusion

Wallet vendor lock-in isn’t destiny. It’s just a set of choices. If you adopt open interfaces, vendor-agnostic signature checks, re-keyable accounts, and portable keys, you can change providers without breaking UX or addresses.