**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.

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