**Thesis:** Non-custodial wallets are becoming a baseline. The real shift is next: a world where you can change wallet vendors, infra, and smart account implementations **without** re-onboarding users or migrating keys.

For the last wave of products, the big decision was:

> “Custodial or non-custodial?”

If you cared about trust, regulation, and user ownership, you chose non-custodial. Seedless onboarding, smart accounts, account abstraction — all of that helped make it realistic to give users real control over their assets without wrecking UX.

But even in the non-custodial world, something subtle happened:

* Apps picked a single embedded wallet / key infra vendor
* All wallets for all users were provisioned and managed through that one system
* Recovery, device management, and risk logic were deeply tied to that vendor’s stack

You weren’t locked into a **custodian** anymore. You were locked into a **non-custodial vendor**.

If they change pricing, deprecate features, get acquired, or just stop shipping what you need, you’re back at square one: migrating critical keyPath logic across providers while your product is live.

Non-custodial was a step forward. Vendor-neutral non-custodial is the next one.

That’s the world [OpenSigner](https://opensigner.dev/) is built for.

Embedded wallets, passkey logins, 4337/7702 smart accounts — they’re all racing to become standard. More vendors, more SDKs, more “one line to create a wallet.”

That’s good: competition pushes the wallet UX layer to improve. But when products standardize around “this vendor’s SDK = our wallet,” you quietly lose something:

* You can’t experiment with multiple providers for different user segments
* You can’t gradually migrate without painful key transitions
* You can’t easily move sensitive parts on-prem while keeping cloud bits you like
* You can’t treat key management as **your** architecture — you inherit someone else’s

Custody concentrated _power in platforms_. First-gen non-custodial concentrated _power in vendors_.

OpenSigner is about putting that power back in the architecture of the app — and in the hands of the teams and users who depend on it. Non-custodial is the “what.” Vendor-neutral is the “how.” OpenSigner is where those two finally meet.


OpenSigner exists to make possible the creation of non-custodial wallets, vendor-neutral key management, and the freedom to evolve your stack without asking users to start over.

opensigner.png

OpenSigner: Vendor-Neutral Key Management


### A single control plane for any signer, any smart contract, and every transaction lifecycle

When we first started Openfort, our ambitions were modest. We weren’t building a platform — we were simply trying to understand what was happening inside our own system. We created a small dashboard to track the transactions moving through our smart accounts. It was scrappy, internal, and absolutely essential. That dashboard helped us see which user had triggered a transaction, how it executed, and where something might have stalled. It wasn’t meant to be a product. It was how we stayed sane while figuring things out.

Two years later, the ecosystem looks nothing like it did back then. Embedded wallets have matured. Smart contract wallets are no longer experimental toys — they’re production-ready. And new standards like **EIP-7702** have fundamentally changed how delegated execution works. Developers are assembling stacks that didn’t exist when we wrote our first lines of code.

This evolution is a sign of maturity, but it also revealed a new problem: as teams mix and match signers, wallets, and smart contracts from different providers, the visibility across the whole system disappears. Developers jump between dashboards, logs, RPC traces, and random monitoring tools just to understand a single user action. The complexity didn’t go away — it moved deeper into the stack.

So today, we’re opening up something that used to be just for us:

> **Openfort Orchestration — a unified platform that lets you monitor, debug, and coordinate activity across *any signer* and *any smart contract*.**
> Yes, including 7702-based contract delegators.


## The reality of today’s onchain architecture

Modern applications don’t have “a wallet provider” anymore. They have a constellation of components:

You might authenticate users with one embedded wallet SDK, send transactions through a separate smart contract architecture, and rely on various forms of delegation or account abstraction to power your UX. It’s flexible, but it leads to a fragmented view of what’s happening.

When something goes wrong, you often end up reconstructing a transaction journey from scratch:
“Which signer approved this? Which contract executed it? Which delegate took over? Why did this action get stuck?”

**Orchestration** solves that.

It rebuilds the entire lifecycle into a single, coherent picture — regardless of which vendor or component each step uses. It gives you a control plane: a place where the signer, the smart contract, the chain, and the final result all come together in one understandable flow.

This is not about replacing your stack. It’s about making it work together.


## Openfort, but modular

One of the biggest shifts with today’s launch is that Openfort is no longer tied to “the Openfort wallet.”

You can now use our platform as a modular layer — plugging into only the parts you want, without committing to a vertically integrated stack.

For example, you can keep your existing embedded wallet provider. If you’ve invested heavily in a specific onboarding flow or signer SDK, you don’t need to rewrite anything. You simply continue using that signer and then delegate to an Openfort smart account when you’re ready. Throughout this flow, Orchestration gives you complete visibility over what’s happening — from the moment the user signs to the moment the contract executes.

Or you may want the opposite: using the Openfort embedded wallet for its UX and security, while executing through third-party smart contract architectures like Calibur from Uniswap or any other 7702-based delegator. In this world, the Openfort signer lives inside your application, the execution logic lives in someone else’s contracts, and Orchestration ties it all together into a unified lifecycle.

And in many cases, teams don’t want Openfort to manage wallets at all. They simply want a reliable visibility layer for their existing signers and contracts. Orchestration becomes that layer — a clear, structured view of everything happening onchain, even when all underlying components belong to other providers. You can treat Openfort purely as an observability and coordination system.

This is the core idea:
**Openfort is no longer “a wallet.” It’s the control plane for whatever wallet architecture you already have — or will have.**


## What “any signer, any smart contract” unlocks

![diagram-orchestration.png](https://blog-cms.openfort.io/uploads/diagram_orchestration_a4be00a8ac.png)

The orchestration platform accepts signers from anywhere: embedded wallets, passkey flows, or fully external key management setups. It also works with every smart contract type — account abstraction wallets, custom execution frameworks, and all 7702-compliant delegators.

This means you don’t need to reshape your product around our technology. Instead, Openfort adapts to the stack you’ve already built. The orchestration layer pulls together all of these moving components into a single narrative for each user and each transaction.

It’s a simple promise:
**Wherever a transaction starts and wherever it lands, you can follow its entire journey through Openfort.**


## Life with orchestration feels different

The biggest change is psychological. Instead of jumping across multiple tools trying to figure out “what happened,” you finally get a clean, unified story.

- You see the signer that initiated the action.
- You see the contract that executed it.
- You see how gas was handled, what delegator was involved, and how the final receipt resolved.

Debugging goes from detective work to simply reading a timeline.
Upgrades become less risky because you can track changes across the whole chain of components.
And as you adopt new standards — like 7702 — you can do so without adding yet another layer of guesswork.

Most importantly, you maintain optionality. If your architecture changes, your orchestration layer doesn’t need to. You can switch signers, swap smart contracts, experiment with different delegation models — and the visibility stays intact.


## Who we’re building this for

The orchestration platform is designed for teams who are already mixing infrastructure from different providers, and for those transitioning toward more advanced delegation or smart account patterns. It’s for developers who care about having a clear mental model of their system, who want to understand their users' onchain actions without wrestling scattered logs or black-box dashboards.

It’s for any builder who doesn’t want to be locked into a single wallet system, who wants flexibility without losing visibility, and who understands that transparency is the only reliable way to scale.


## Start using Openfort Orchestration

You don’t need to swap your stack. You don’t need to migrate your users. You don’t even need to use an Openfort wallet.

We're rolling this out to our current clients and doing manual onboarding to developes that are already using other providers and would like to try it out. Feel free to jump to our [Developer Group](https://t.me/openfort) and send us a message there to get started. 

_Keep your architecture. Gain visibility._


Openfort Orchestration — a unified platform that lets you monitor, debug, and coordinate activity across any signer and any smart contract.

orchestration-platform.png

Orchestration Platform: Manage Signers and Contracts


**TL;DR**: Openfort now takes advantage of **[EIP-7966](https://eips.ethereum.org/EIPS/eip-7966)** (`eth_sendRawTransactionSync`) on endpoints that support it. When available, your send becomes a **single call** that returns a **receipt**, a **typed timeout (pending)**, or a **real error**—no DIY polling loops. That means **faster perceived UX** and fewer edge cases for wallets, games, agents, and paymasters. If the endpoint doesn’t support 7966, Openfort automatically falls back to the classic `send + receipt` flow. 

## What 7966 is (and why it helps Openfort users)

Traditionally, apps submit a tx with `eth_sendRawTransaction`, then **poll** `eth_getTransactionReceipt` until confirmation. EIP-7966 introduces **`eth_sendRawTransactionSync`**—a single RPC that submits the signed tx and waits briefly (node-configured; the EIP recommends a small default, e.g. ~2s) to return the receipt, a timeout (meaning “not included yet”), or a clear error. This collapses round-trips and **reduces submission-to-confirmation latency** on low-latency chains. 

> Key point: 7966 is an **Interface EIP in Draft** and **optional**. Support varies by provider/chain; that’s why Openfort negotiates it per connection and falls back seamlessly. 

## How Openfort implements it

* **Auto-detect + route**: If the connected RPC exposes `eth_sendRawTransactionSync`, Openfort uses it; otherwise we use our hardened send-and-receipt path. **No code changes** needed in your app. 

* **Three explicit outcomes** your UI can trust:

  * `confirmed` → standard receipt object (same shape as `eth_getTransactionReceipt`)
  * `pending_timeout` → clearly “not yet included,” not a failure
  * `error` → meaningful error (e.g., nonce/underpriced/revert)
* **Safer UX defaults**: Treat `pending_timeout` as pending (no double-submit). Openfort will continue background tracking as usual if you choose. 


## What you should expect (performance & claims)

* **Latency/throughput**: The **EIP’s goal** is to reduce end-to-end latency by ~50% on suitable networks by removing the extra RPC round-trip. Real-world gains depend on the chain, sequencer, and your RPC’s implementation. 
* **Timeouts**: The spec **recommends a small node-configured default (≈2s)**; providers may choose different windows (some expose longer caps). Openfort forwards these semantics while letting you keep your own UI timers. 

## Why this matters for *wallet UX*, not just infra

* **Instant, trustworthy feedback**: Users see “confirmed” faster, “pending” when appropriate, and useful errors instead of ambiguity.
* **Fewer “did it go through?” tickets**: Cleaner states cut support load.
* **Less glue code**: Remove custom polling/retry utilities and race-condition bandaids—**one code path** across chains. 

## FAQs

**Is 7966 replacing normal sends?**
No. It’s additive and **optional**. Nodes without it return “method not found,” and Openfort falls back to the standard flow automatically. 

**What timeout should I show users?**
Treat node timeouts as **“still pending”**, not a failure. Keep your **UX timer** small (e.g., spinner + “pending” badge) and let Openfort follow up in the background if you choose. 

**Which chains/providers support it?**
Support is expanding. Some providers already expose `eth_sendRawTransactionSync` (often branded as “synchronous send”) on major L2s; Openfort will use it automatically when your endpoint has it. 

Openfort now supports EIP-7966: get one-call transaction status—receipt, pending, or error—no polling. Faster, cleaner UX for wallets, games, and agents

eip7966.png

Support for Synchronous SendTransaction

We’ve just made it a lot easier for your app to understand **what your users actually own**.

If you’re building with embedded wallets today, asset discovery is probably a mess: Custom token lists per chain, indexers to maintain, partial balances depending on which RPC you hit, etc.

Most of this isn’t a product problem. It’s a **standards problem**. Today, we’re aligning Openfort with the ecosystem’s answer to that: **[ERC-7811](https://eip.tools/eip/7811): Wallet Asset Discovery**

## From ad-hoc indexers to a standard call

Until now, most apps checked balances by: Calling RPCs chain by chain, inferring assets from onchain activity or patching gaps with allowlists, heuristics, or 3rd-party indexers.

It “worked,” but:

- You only see what’s obvious on a specific chain.
- You miss assets that wallets know about but that aren’t easily discoverable from a single node.
- Every team reinvents the same infra.

**ERC-7811** proposes a fix: a standard JSON-RPC method — `wallet_getAssets` — that lets wallets share a user’s assets with dapps across supported chains and asset types, in a structured way.

## What ERC-7811 does

At its core, **ERC-7811** introduces: `wallet_getAssets` → “Wallet, tell this app what this user owns.” It supports: native assets (e.g. ETH), ERC-20 tokens (e.g. USDC), ERC-721, and extensibility for future asset types.

Instead of guessing or scraping, apps get a **clean, wallet-sourced view** of a user’s assets in a consistent format. No proprietary API. No one-off JSON shape. An open standard implementations can align on.

## Helping builders

If you’re maintaining your own asset discovery stack today, ERC-7811 support in Openfort means:

- **Less glue code**. No more stitching multiple APIs per chain just to show balances.
- **Fewer edge cases**. Fewer “this token isn’t showing” bugs and manual hotfixes.
- **Cleaner abstractions**. Treat `wallet_getAssets` as the canonical read for embedded wallet assets.
- **Future compatibility**. As the ERC-7811 standard evolves and adoption grows, your app already speaks the right language.

Read our docs to [implement it](https://www.openfort.io/docs/products/embedded-wallet/react/wallet/assets)


Openfort adds ERC-7811 wallet_getAssets support so developers can fetch accurate, multi-chain asset lists from embedded wallets via an open standard—no more custom indexers or missing balances.

ERC7811.png

Support for Wallet Asset Discovery

We’ve just made your wallet widget do a lot more work for you.

Until now, teams using the Openfort UI leaned on the wallet modal mainly for connecting, showing balances, and — for many of you — using our ConnectKit-based flow plus account linking to bridge embedded wallets with users’ existing self-custodial wallets. That got you smooth onboarding and a consistent UX layer, but there was still a missing piece:

once users *had* an embedded wallet, it wasn’t straightforward enough for them to fund it, move assets, or cash in directly from the same interface.

We’ve fixed that.

This update turns the Openfort wallet widget from a passive viewer into an **actionable money console** — without you rebuilding flows from scratch.


## From “Connect & View” to “Connect, Fund & Move”

The first version of our wallet UI was built around three core ideas: give you embedded wallet UX out of the box, plug into ConnectKit so users could connect their own wallets with a familiar flow, and expose link account functionality so you could associate an existing EOA with the embedded wallet behind the scenes.

That combination worked well for onboarding and identity. Users could log in with your auth, automatically get an embedded wallet, optionally link a wallet they already trust, and start interacting with your app without dealing with seed phrases or clunky redirects.

But as teams went to production, the same practical questions kept coming up:
how do you let users top up their embedded wallet without sending them through a maze of screens?
Can they send assets directly from the same modal they already trust?
Can you plug in onramps without building and maintaining a separate UI for each provider?

This release is our answer.


## What’s new in the wallet widget

### Send assets directly from the wallet modal

Users can now send assets from inside the Openfort wallet widget itself — no new pages, no extra context switching.

From the same modal they already use to view balances, a user can open their wallet, tap “Send”, choose an asset like USDC, ETH, or your in-game token, select or paste a recipient address, and confirm the transaction. That’s it.

Under the hood, nothing in your architecture needs to change. You keep using the same policies and orchestration you’ve already set up with Openfort: paymasters, sponsored gas, embedded wallets, smart accounts, and whatever routing you’ve already wired into your app. The widget becomes the front door for money actions, while all the rules and logic remain fully under your control.

If you’re already running embedded wallets and account abstraction with Openfort, this should feel like adding one more capability to your existing setup, not starting a new integration.


### Receive assets: external wallets and onramping built in

Funding is where most teams quietly lose users. We’ve pulled the two most common funding paths into the wallet modal so you can keep people in one place.

For users who already have assets elsewhere, the widget now exposes the embedded wallet address clearly, with copy and QR options, and guides them to the right network so they don’t mis-send. Everything lives inside the same UI they already trust, so “send tokens here” becomes a natural part of their experience instead of a separate flow you have to explain.

For users coming in with fiat, you can connect Coinbase or Stripe-powered onramps directly from the wallet widget. The flow is simple: the user opens the modal, hits an “Add funds” entry point, chooses the onramp, goes through the provider’s payment flow, and ends up with funds sitting in the embedded wallet you control at the infra level.

You decide which providers to enable per environment, market, or chain. The widget takes care of the UX and wiring so it all feels like one coherent flow. You don’t need to design a custom “Deposit” section or maintain one-off integrations for each provider — you just configure your options and let the widget handle the rest.


## How it fits with the Openfort React SDK and linked accounts

![send-deposit-widget.png](https://blog-cms.openfort.io/uploads/Group_48096528_1_523ffc5bc2.png)

If you’re already using our React SDK with ConnectKit and link account features, this update is an extension of that stack, not a replacement.

The linked wallet can still act as a familiar anchor for power users who want to bring their own EOA. The embedded wallet remains your programmable, upgradeable, policy-driven account under the hood. And the Openfort widget becomes the shared surface where those worlds meet: users can view balances, link accounts, send assets, and receive funds via external transfers or onramps, all in one place.

On your side, you still control which chains and tokens are available to send, whether gas is sponsored or user-paid, which onramp providers appear, and how the whole flow ties into your auth and account model. The goal is simple: minimal configuration, maximum effect.


## Why this matters

For developers and product teams, this cuts down the surface area you have to maintain. Instead of separate UIs for “Balances,” “Deposit,” and “Send,” you configure a single, consistent widget. All those flows run through the same infra stack — your rules, your paymasters, your monitoring — so you don’t end up with fragmented policies or duplicated logic. And when you want to experiment, you can turn providers or flows on and off without redesigning core UX.

For users, it creates a much clearer mental model: this is my wallet inside this app, and this is where I see, fund, and move assets. They get one familiar interface for money actions, fewer redirects, and fewer unknown brands in the middle of what should be a simple transaction.

For your roadmap, this release lays the groundwork for richer embedded wallet interactions: streaming payments, in-app marketplaces, cross-chain flows, and agent-triggered actions can all slot into the same wallet surface instead of spawning new, disconnected experiences.




This update turns the Openfort wallet widget from a passive viewer into an actionable money console—without you rebuilding flows from scratch.

send/receive.png

Send and deposit assets with Openfort UI

We're excited to announce a major upgrade to **Global Wallets**: built-in funding capabilities. This makes it simpler than ever to add onramps to your apps, letting users fund their wallets directly — whether from another wallet or straight from fiat.  

With this update, anyone using Global Wallets via the **Ecosystem SDK** can set up funding flows with just a single RPC method. No more piecing together third-party integrations or handling complex state yourself.  

![funding_example.svg](https://blog-cms.openfort.io/uploads/funding_example_caf6e59a8f.svg)

Today, we're rolling out:  
- **Wallet-to-wallet funding** for seamless transfers  
- **Fiat-to-crypto onramps** built right in  

These features are designed to reduce friction in your user onboarding, so your app can go from zero to funded in minutes. We've built this on top of our existing wallet infrastructure, ensuring it's secure, scalable, and developer-friendly.  

If you'd like early access or want to beta test these funding flows, sign up [here](https://dashboard.openfort.io/auth/login).

This is the first step toward making Global Wallets a complete end-to-end solution for on-chain interactions. Soon, you'll be able to trace funding events, analyze transaction performance, and troubleshoot issues all within Openfort.  

## Wallet-to-Wallet Funding  
Transferring funds between wallets has always been a core part of crypto, but integrating it smoothly into your app often meant custom code and error-prone handling. Now, with Global Wallets, you can enable **wallet-to-wallet funding** with one straightforward RPC call.  

This lets users:  
- Send assets from an external wallet to their Global Wallet  
- Handle confirmations and updates automatically  
- Get real-time status notifications  


The SDK manages the transaction lifecycle, including gas estimation and retries, so you can focus on your app's UX instead of blockchain plumbing.  

## Built-in Fiat-to-Crypto Onramps  
Bringing new users into crypto means making fiat entry points as easy as possible. We've embedded **fiat-to-crypto onramps** directly into Global Wallets, powered by trusted providers under the hood.  

Users can:  
- Fund their wallet using credit cards, bank transfers, or other fiat methods  
- Convert to crypto in a single flow  
- See funds reflected instantly in their Global Wallet balance  

No need to redirect to external sites or manage KYC yourself — it's all handled via the same RPC method.  


This integrates seamlessly with your app's flow, whether you're building a mobile dapp, game, or DeFi tool. We've also added support for multiple currencies and tokens to keep things flexible.  


## TL;DR  
The new funding capabilities in **Openfort Global Wallets** bring:  
- 🚀 **Wallet-to-wallet transfers** via a single RPC  
- 💳 **Fiat-to-crypto onramps** built-in  
- 🔧 Easy setup through the Ecosystem SDK  

This makes it simpler than ever to add onramps to your apps, letting users fund their wallets directly — whether from another wallet or straight from fiat.  

Funding.svg

Introducing Funding in Global Wallets

We’ve just released the **Openfort Swift SDK**, bringing seamless wallet integration and account abstraction **natively** to iOS. You 

With this update, you can:

- ✅ Manage **multiple accounts** effortlessly  
- ✅ Use **developer‑friendly Swift APIs** to interact with wallets  
- ✅ Integrate **native Apple and Google authentication flows**  
- ✅ Build faster with a ready‑to‑run sample app  

This launch is part of our mission to make **Openfort a first‑class citizen on every platform**. Now, iOS developers get the same high‑level features as our web and React Native SDKs — but written for Swift.

- [Documentation](https://www.openfort.io/docs/products/embedded-wallet/swift)
- [Sample](https://github.com/openfort-xyz/swift-example)

![swift_example.svg](https://blog-cms.openfort.io/uploads/swift_example_850008c342.svg)


## Multi‑Account Support  
Managing more than one wallet in a mobile app used to be tedious — juggling state, switching active accounts, and updating UI.  
The Swift SDK now ships with **multi‑account support built‑in**.

Your users can:  
- Connect multiple wallets to their profile  
- Switch between them instantly  
- Have session state fully persisted

The SDK takes care of persistence, so you can focus on building features, not state management.

## Swift‑First Wallet APIs  
We’ve mirrored the philosophy of our web and React Native hooks, but designed for Swift.  

The APIs handle:  
- Connecting and disconnecting  
- Retrieving wallet metadata  
- Executing transactions  
- Handling errors gracefully

All type‑safe, leveraging Swift’s strong typing to prevent runtime issues.

## Native Apple & Google Auth  
Authentication flows are fully **native** — no webviews or redirects.  

- **Apple Sign‑In** is deeply integrated with the SDK for smooth onboarding on iOS.  
- **Google Sign‑In** works natively on iOS with a guided setup.

This gives you:  
- Instant, familiar login for users  
- A shorter path from auth → wallet actions  
- Fewer platform edge cases to debug


## Example iOS App You Can Run Today  
We’ve published a sample project to get you going immediately.  
It demonstrates:  
- Setting up the SDK in a Swift project  
- Connecting multiple wallets  
- Integrating Apple / Google auth  
- Switching active accounts  

📂 [Openfort Swift Auth Sample](https://github.com/openfort-xyz/swift-example)


### TL;DR  
**Openfort Swift SDK** gives you:  
- 🚀 Multi‑account wallet management  
- 🔗 Native Swift APIs for wallet actions  
- 🍏 / 🤖 Native auth flows (Apple + Google)  
- 📦 Example iOS app to start building today


We’ve just released the Openfort Swift SDK, bringing seamless wallet integration and account abstraction natively to iOS.

swift_sdk.svg

Introducing Swift SDK

We’ve just released the **Openfort React Native SDK**, making it easier than ever to integrate wallet functionality and account abstraction into your mobile apps — all with a smooth native experience on both iOS and Android.

With this update, you'll be able to:  

- ✅ Manage **multiple accounts** in the same app  
- ✅ Use **react-native-ready hooks** to interact with wallets  
- ✅ Enable **native Apple and Google authentication flows**  
- ✅ Build faster with examples and a starter repo ready to clone  

This release is part of our ongoing mission to make **Openfort work seamlessly on every platform** — and mobile is a big part of that.  

- [Documentation](https://www.openfort.io/docs/products/embedded-wallet/react-native)
- [Sample](https://github.com/openfort-xyz/react-native-auth-sample)

## Multi‑Account Support  
In the past, working with more than one wallet per user required a lot of manual state handling. The new SDK ships with **multi‑account support** out of the box.  
This means your users can:  

- Connect multiple wallets  
- Easily switch between them  
- Keep everything in sync across sessions  

Behind the scenes, the SDK manages the account list and session state for you — no custom Redux boilerplate required.


## Wallet Hooks for React Native  
We’re bringing over all the best hooks you’ve come to love from our web SDK, now optimized for React Native.  

For example:  

```ts
const { connectWallet, disconnectWallet, wallets } = useWallet();
```

These hooks handle:  

- Connection  
- Disconnection  
- Retrieval of wallet metadata  
- Transaction execution  

They’re fully typed with TypeScript, so you'll get completion hints and error checking as you build.

## Native Apple & Google Auth  
Authentication on mobile should *feel* native — so instead of browser redirects and awkward webviews, the SDK integrates directly with **Apple Sign‑In** (iOS) and **Google One Tap** (Android & iOS).  

That means:  

- Faster login times  
- Better UX for your users  
- Fewer auth edge cases to handle  

And because auth is deeply integrated with Openfort’s session system, you can go straight from sign‑in to wallet actions without extra round trips.


## Example App You Can Clone  
To get you started quickly, we’ve published a complete example:  

[Openfort React Native Auth Sample](https://github.com/openfort-xyz/react-native-auth-sample)  

It covers:  

- Setting up the SDK  
- Handling wallet connections  
- Implementing Apple / Google native auth  
- Switching between accounts  

Just clone it, install dependencies, and run it on your simulator or device.

## Next Steps  
You can check out the full documentation here: **[openfort.io/docs](https://openfort.io/docs)**

We see this release as the foundation for **mobile-first account abstraction**. We're already working on:  

- In-app transaction signing flows  
- Offline session support  
- Deeper React Native hook integration  


We’ve just released the Openfort React Native SDK, making it easier than ever to integrate wallet functionality

reactnative_sdk.svg

Introducing React Native SDK

Today, we're releasing the Openfort React SDK, which provides tools for managing authentication UI elements from the Openfort kit, along with React hooks and TypeScript types for embedded wallets.

This SDK is designed for React applications that need to handle user authentication and wallet interactions. **It includes optional UI components, but can also be used in a headless mode without them.** Additionally, it comes with [Playground](https://playground.openfort.io), a development toolkit that offers suggestions for methods, status updates, and response previews in a single interface.

- [Open-source React SDK](https://github.com/openfort-xyz/openfort-react)
- [Documentation](https://www.openfort.io/docs/products/embedded-wallet/react)
- [Sample](https://github.com/openfort-xyz/create-openfort)

## Openfort in React Applications
Openfort provides building blocks for authentication and embedded wallets. The core kit handles user sessions, logins, and wallet integrations with blockchain networks.

With React being a common choice for frontend development, we've created this SDK to better support it. It includes UI components for elements like login forms and wallet connectors, which can be customized or omitted entirely for a headless setup. This flexibility allows developers to choose between pre-built UI or fully custom implementations.

The SDK also introduces React hooks, such as useWallet, useAuthSession, and useTransaction, for managing state, errors, and updates. These are typed with TypeScript to help catch issues early. For embedded wallets, the hooks simplify tasks like initialization, funding, and interactions, while following security practices.

Overall, this can lead to cleaner code and more efficient development in React environments.

## Limitations of Traditional Approaches
Integrating authentication and wallets in React has often involved combining various libraries, handling state manually (e.g., with Redux), or working with untyped APIs that risk errors at runtime. This can create inconsistencies and potential security issues, especially for sensitive tasks like wallet operations.

Embedded wallets require precise handling to protect private keys and session data. Without tailored tools, developers might build custom solutions, which can vary across projects.

The React SDK offers a consistent layer over the Openfort kit, aligned with React conventions like hooks and context. It supports async operations and includes testing features like mocking.

Compared to our existing JavaScript SDK, this version is optimized for React: it leverages hooks for better state management, provides TypeScript types for improved reliability, and integrates more naturally with React's ecosystem. The JavaScript SDK remains a solid general-purpose option, but the React SDK reduces boilerplate and enhances usability for React-specific workflows. It builds on lessons from tools like React Query and Wagmi, adapted for Openfort.

### Start Using the React SDK Today  
The Openfort React SDK is available now as a public package. You can install it via npm or yarn and start integrating it into your projects immediately. No major overhauls required – it's designed to complement your existing Openfort setup.  

We've made the onboarding process straightforward and reversible, so you can experiment without risking your current workflows. 

 Add it to your project with a simple command:  
 
   ```bash  
   npm install @openfort/react  
   ```

This pulls in all the necessary dependencies, including UI components and hooks. These hooks include TypeScript types for props and returns, making your code more predictable.  

## Exploring with Playground

![react-playground.svg](https://blog-cms.openfort.io/uploads/react_playground_d23ceb036d.svg)

Playground is a toolkit for working with the React SDK and Openfort APIs. It provides an interface for method suggestions (e.g., recommending useTransaction after wallet connection), real-time status, and response views.

Accessible from the Openfort dashboard, it supports component previews and is useful for prototyping or troubleshooting. It's based on community feedback and can be used independently of the SDK.

## Maximizing the SDK's Value
The React SDK helps create more maintainable code by reducing custom implementations and improving integration. It's compatible with other Web3 libraries and frameworks like Next.js.

For those using the JavaScript SDK, transitioning to the React version can simplify wallet management through hooks, especially in React apps. We plan to add features like UI theming and more specialized hooks based on ongoing feedback. Explore the documentation for detailed examples.

This new SDK brings seamless integration with Openfort Kit (authentication UI elements), along with dedicated React hooks and TypeScript types for handling embedded wallets.

Openfort blog

OpenSigner: Vendor-Neutral Key Management

OpenSigner: Vendor-Neutral Key Management

Orchestration Platform: Manage Signers and Contracts

Support for Synchronous SendTransaction

Support for Wallet Asset Discovery

Send and deposit assets with Openfort UI

Introducing Funding in Global Wallets

Introducing Swift SDK

Introducing React Native SDK

Introducing React SDK