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

large_opensigner.png

medium_opensigner.png

small_opensigner.png

thumbnail_opensigner.png

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.

large_orchestration-platform.png

medium_orchestration-platform.png

small_orchestration-platform.png

thumbnail_orchestration-platform.png

orchestration-platform.png

Orchestration Platform: Manage Signers and Contracts

 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 

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

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

 architecture — you inherit someone else’s

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: Vendor-Neutral Key Management

Sign up for Openfort