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.

large_wallet-asset-discovery.png

medium_wallet-asset-discovery.png

small_wallet-asset-discovery.png

thumbnail_wallet-asset-discovery.png

ERC7811.png

Support for Wallet Asset Discovery


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

large_eip7966.png

medium_eip7966.png

small_eip7966.png

thumbnail_eip7966.png

eip7966.png

Support for Synchronous SendTransaction

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.

large_send/receive.png

medium_send/receive.png

small_send/receive.png

thumbnail_send/receive.png

send/receive.png

Send and deposit assets with Openfort UI

- [From ad-hoc indexers to a standard call](#from-ad-hoc-indexers-to-a-standard-call)
- [What ERC-7811 does](#what-erc-7811-does)
- [Helping builders](#helping-builders)

We’ve just made it a lot easier for your app to understand 

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 

. Today, we’re aligning Openfort with the ecosystem’s answer to that: 

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](#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.

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.

 proposes a fix: a standard JSON-RPC method — 

 — that lets wallets share a user’s assets with dapps across supported chains and asset types, in a structured way.

**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](#what-erc-7811-does)

 → “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.

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 

 of a user’s assets in a consistent format. No proprietary API. No one-off JSON shape. An open standard implementations can align on.

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.

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

. No more stitching multiple APIs per chain just to show balances.

**Less glue code**. No more stitching multiple APIs per chain just to show balances.

. Fewer “this token isn’t showing” bugs and manual hotfixes.

**Fewer edge cases**. Fewer “this token isn’t showing” bugs and manual hotfixes.

 as the canonical read for embedded wallet assets.

**Cleaner abstractions**. Treat `wallet_getAssets` as the canonical read for embedded wallet assets.

. As the ERC-7811 standard evolves and adoption grows, your app already speaks the right language.

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

Support for Wallet Asset Discovery

From ad-hoc indexers to a standard call

What ERC-7811 does

Helping builders

Sign up for Openfort