Passkey Smart Wallets on Stellar: How They Work

Passkey wallets by the numbers (October 2026)

Stellar has verified secp256r1 signatures natively since 18 June 2024. OpenZeppelin's smart-account rules allow up to 15 signers and 5 policies each. The passkey and policy-builder projects SCF funded in rounds #44 and #45 received $470,000 worth of XLM between them.

• Protocol support: CAP-51 (secp256r1 verification) shipped in Protocol 21, mainnet 18 June 2024; CAP-71, delegated authentication for smart accounts, shipped in Protocol 27 on 8 July 2026. See Stellar's protocol upgrades.
• Audit: OpenZeppelin's Stellar Contracts RC v0.7.0 audit (2–19 March 2026) covered smart accounts, including WebAuthn verifiers: 0 critical, 1 high (resolved), 6 medium (5 resolved), 9 low (7 resolved), 5 notes.
• Funding: SCF #44 awarded Passkey UI $95,000 and three policy builders $98,000, $125,000 and $55,000; SCF #45 awarded Haven, a passkey smart-account neobank, $97,000.
• Real-world use: SDF says more than 1,000 Meridian 2025 attendees used Meridian Pay, a passkey smart wallet, for claims and payments at the event.

How to choose

• You want a wallet without a seed phrase: a passkey smart wallet fits, provided you add a second signer or use synced passkeys before funding it.
• You want spending limits or shared control: smart-account policies (thresholds, spending limits, session keys) do things a classic account cannot.
• You deposit to and withdraw from exchanges often: keep a classic account for that; contract accounts are currently incompatible with memo-based exchange transfers.
• You are a developer: Smart Account Kit wraps OpenZeppelin's audited contracts; Passkey Kit is the more customisable, hands-on option.

Soroban smart accounts — the account is a contract

A Stellar smart account is a contract with an address starting with C. It holds balances like any account, but when something needs its approval, Soroban calls the contract's __check_auth function, which can apply any rule the contract encodes instead of checking one Ed25519 signature.

Stellar's documentation lists the signers such a contract can accept: passkeys, Ed25519 keys, policy signers, session keys, hardware keys or custom logic. That flexibility is the point. A classic account (a G-address) offers native multisig with weights and thresholds, which is powerful but fixed; a contract can add rules such as "this key may only spend 100 USDC a day" or "this session key expires in an hour". For the architecture behind it, see Soroban smart contracts.

Two limitations come with being a contract. Stellar's docs state that contract accounts cannot pay their own transaction fees and cannot be a transaction source, so another account must submit for them. And their payments move through the Stellar Asset Contract as muxed transfers, which makes them incompatible, for now, with exchanges that expect memo-tagged deposits from G-addresses.

secp256r1 — why Protocol 21 mattered

Passkeys implement WebAuthn, which most authenticators use with the secp256r1 (P-256) curve. Stellar's native keys use Ed25519. CAP-51, in Protocol 21, added a host function that verifies secp256r1 signatures, making on-chain passkey checks cheap enough to run.

The CAP's authors explain why it had to be native: ECDSA secp256r1 verification written as contract code costs more instructions than the network allows in one transaction. With the host function in place, a passkey flow works in three steps. At registration, the browser or phone creates a key pair and the wallet stores the public key in the contract. When you approve an action, the device produces a WebAuthn signature over the payload. The contract's __check_auth verifies it, then applies any policy checks. SDF announced passkey support on mainnet on 27 June 2024, nine days after the upgrade.

One distinction is worth keeping. Some wallet apps use passkeys only to log in to their own service, while the Stellar account underneath is still a normal key the app stores. A passkey smart wallet is different: the passkey signature itself is what the network checks.

OpenZeppelin smart accounts — rules, signers, policies

OpenZeppelin's stellar-accounts package structures a smart account as context rules. Each rule names an operation scope, up to 15 signers, up to 5 policy contracts and an optional expiry, and every action must name the rule it is authorised under.

The three parts do separate jobs. Signers prove identity: either a delegated Stellar address or an external key checked by a shared verifier contract, which is how passkeys (WebAuthn) and Ed25519 keys plug in. Context rules scope authority, for example "any call", "calls to this DEX contract only" or "deploying this contract code". Policies enforce business logic when a rule is used: OpenZeppelin lists admin access, spending limits, multisig thresholds, session policies and recovery as examples, and Smart Account Kit ships clients for threshold, weighted-threshold and spending-limit policies.

A practical consequence is that a wallet can give a dapp a session key limited to one contract and a spending cap, valid for a day, while the passkey stays the master key. The framework's own documentation flags the sharp edges. If you remove signers after installing a threshold policy, the threshold can become unreachable; if you add signers without raising it, a 3-of-3 silently becomes 3-of-5. And if the last rule that authorises calls to the account itself is removed or allowed to expire, nothing can ever change the account again.

The audit's single high-severity finding fits this picture: rule IDs were not bound to the signed payload, so a fee sponsor could swap in a weaker rule after signatures were collected. It was fixed by binding the chosen rules into the signed digest. Two medium findings were acknowledged rather than fixed.

Tooling and the SCF RFPs

Two TypeScript kits dominate: Passkey Kit, SDF's original and highly customisable SDK, and Smart Account Kit, now under the Stellar GitHub organisation, which wraps OpenZeppelin's contracts. SCF #44 funded RFPs for a passkey UI layer and for AI tools that write least-privilege policies.

Stellar's 20 August 2026 developer meeting framed the choice: Passkey Kit lets you "build any kind of transaction, run your own relayer, customize everything", while Smart Account Kit sits on audited contracts with multi-signer support and policies maintained upstream. Smart Account Kit's README is candid that the SDK, demo, relayer proxy and indexer integration are unaudited, and that its deployed contracts use a later revision than the audited one.

The SCF #44 recap (24 July 2026) lists the RFP winners:

• Passkey UI ($95,000 in XLM) for the "Passkey UI" RFP: a usage-pattern guide, a cross-platform compatibility matrix, a minimal SDK and reference components for create, sign and recover flows, intended for stellar-wallet-kit.
• OZ accounts policy builder, an MCP server plus agent skill that turns an observed transaction into a minimal OpenZeppelin policy: Gateway.fm ($98,000), CredioLabs.AI ($125,000) and Policywright ($55,000).

The policy-builder RFP points at agents: an AI agent paying for services, as in x402, is safer holding a session key limited to exactly what it needs. For how SCF rounds work, see the Stellar Community Fund.

Wallets and apps using passkeys

Passkey smart wallets on Stellar are still mostly app-embedded rather than standalone consumer wallets. Meridian Pay, SDF's event wallet, is the largest documented deployment; SCF-funded products such as Haven are building on smart accounts; Stellar's docs list several open-source examples.

• Meridian Pay: a browser smart wallet with passkey sign-in and fee sponsorship through Stellar's fee-bump mechanism. SDF says more than 1,000 attendees used it at Meridian 2025, with recovery via a synced passkey or an event-specific email mechanism.
• Haven (SCF #45, $97,000): a privacy-focused neobank on Soroban smart-account wallets with passkey authentication and on-chain recovery. Funded, not yet shown as live.
• Reference projects: Stellar's docs list community examples including Zafegard (stateful policy signers), Super Peach (a multi-signer passkey account) and a passkey demo from Soroban by Example, with a warning to review and test before reusing them in production.

The big general-purpose wallets covered in the best Stellar wallets remain built around classic accounts. Check each wallet's current documentation before assuming it can hold or sign for a C-address.

Recovery

A smart account can be recovered only if you planned for it. The options are synced passkeys, extra signers such as a second device or a regular Stellar key, and recovery policies that let a guardian or a time-delayed rule rotate keys.

• Synced passkeys: Stellar's docs note passkeys can stay on one device or sync across devices through cloud providers. Syncing protects against a lost phone but makes your platform account part of your security.
• A second signer: add a passkey on another device, a hardware key, or a delegated G-address with its own backup. A rule with no policies requires all its signers, so use a threshold policy if you want any one of several keys to work.
• Recovery policies: OpenZeppelin lists recovery as a policy use case, and Protocol 27's delegated authentication was expected by SDF to make social recovery practical.

Risks

The main risks are losing every signer, misconfiguring rules, depending on a relayer, and running new, partly unaudited software. None is unique to passkeys, but smart accounts add configuration risk that a seed phrase does not have.

• Domain binding. A WebAuthn passkey belongs to the relying-party domain that created it. If that app disappears and you have no other signer, using the account becomes much harder.
• Relayer dependence. Because contract accounts cannot pay fees, a relayer must submit transactions. If it goes down, you need another submitter.
• Configuration errors. Threshold drift and deleting the last admin rule can lock an account permanently, as OpenZeppelin's README warns.
• Unaudited layers. The contracts are audited; the client SDKs, relayer proxies and indexers mostly are not. Smart Account Kit's own README says "Do not store or control assets you cannot afford to lose." See what an audit covers.
• Shared deployer key. Smart Account Kit's default deployer key is deliberately public and shared; it never controls wallets, but must never be funded.

For a wider list of failure modes, see DeFi risks.

How these fit together

The stack runs from protocol to product. Protocol 21 made passkey signatures verifiable; Protocol 27 made delegated signing workable; OpenZeppelin supplied audited account, verifier and policy contracts; SDF's kits and SCF-funded UI and policy tools make them usable; relayers make them gasless. Products sit on top, and today they are mostly embedded in specific apps rather than general wallets.

The takeaway

Passkey smart wallets remove the seed phrase and add rules a normal account cannot enforce. They also move risk into configuration, relayers and young client software. If you try one, add a second signer before funding it, keep the balance modest, and keep a classic account for exchange transfers.

Sources: CAP-0051; Stellar docs, "Software Versions", "Contract accounts", "Smart wallets" and contract-account examples; SDF blog, passkey launch (27 Jun 2024) and "Building Meridian Pay"; OpenZeppelin stellar-contracts, packages/accounts README; OpenZeppelin, "Stellar Contracts RC v0.7.0 Audit"; stellar/smart-account-kit README; Stellar developer meeting notes, 20 Aug 2026; SCF #44 (24 Jul 2026) and #45 (23 Sep 2026) round recaps.