From a Call to Action to Engineering: Passkey-Native Accounts and Wallet Design
In Crypto Can’t Go On Like This, I called for the industry to improve its infrastructure together. We are starting with wallets: publishing the native Passkey account foundation we have built and the next-generation wallet design we are refining. This is our first step from a call to action to engineering work.
I hope other wallet and blockchain builders can take useful methods from it: reduce the application’s access to private keys, give each signature limited authority, and help users protect their assets after a device breaks, a frontend is compromised, or a service disappears. Each team can choose its own implementation.
Our direction is to bring mature authentication technology into blockchain while redesigning authorization, execution, and recovery. Passkeys are a starting point. A complete wallet must also answer what happens after a signature.
ArcBlock added native Passkey account support in v1.19.x. The upgrade documentation records that work. We have continued building multisignature support, transaction validation, and account protection on that foundation. The next-generation wallet product is still in development. This article distinguishes existing foundations, implemented components, and further design work. Existing software-key, seed-based, and hardware-wallet paths remain supported, so users can choose when and how to move forward.
Wallets Are Complicated Enough. How Much Must Users Manage?
I have used different hardware wallets. One recurring frustration is another update, with another reminder to check the recovery backup before proceeding. A wallet is supposed to give peace of mind. Instead, I find myself asking: where is the backup? Does it still work? What if this update goes wrong?
Trezor’s firmware update guide explicitly tells users to have their wallet backup ready and explains that a failed update could erase device memory, requiring recovery from the backup.[1] For a vendor, this is a responsible warning. For the user, the weight of recovery still rests on their shoulders.
Then look at how we back things up. We write the seed phrase on paper, worry about the paper, and engrave it on steel. Cryptography has come all this way, and the user is still guarding a slip of paper or a metal plate like a treasure map. I find that picture a little absurd.
Paper and steel have real uses. Offline backups avoid remote attacks. Steel can improve resistance to fire, water, and physical deterioration. But they preserve a recovery secret. They do not solve mistaken authorizations, deceptive signing requests, or a key with too much power. Users must still plan for theft, loss, separate storage, and recovery if something happens to them.
Security engineering can keep improving without requiring users to spend their lives as backup administrators.
Paper and steel protect a recovery secret. Storage, updates, and recovery still require the user’s work. Conceptual illustration, not a product interface.
Software wallets: what happens when it is time to sign?
A typical software wallet encrypts its seed or private key at rest, then signs in software after unlocking. Where and when key material appears depends on the implementation. Some use JavaScript or application memory, some isolate a signing process, and some use an operating-system key service. Software wallets are not all built the same way.
The questions are concrete. Can the application obtain the raw signing key? Can a malicious dependency, extension, or same-origin script reach it? If an attacker copies the key, will future signatures still require the user? Can the account limit that key’s authority?
A copied key and a key that remains in place but is called by an attacker are two different failures. The first calls for tighter control of key material. The second also needs tighter authorization and spending boundaries. Better encryption at rest does not answer all of those questions.
Hardware wallets: the key is isolated, but intent and recovery remain
Hardware wallets made an important contribution: keeping the signing key in a separate device and providing a confirmation path that can be independent of the host. A trusted display is valuable, especially when it accurately shows what will actually be signed.
Can the device fully interpret the transaction supplied by the host? Do the amount, recipient, and permission changes on its display match the execution payload? Does a complex authorization still leave users approving bytes they cannot understand? Those questions determine how far the protection reaches. Backup storage and access are another boundary when the device breaks. Hardware wallets also offer different recovery designs. Trezor, for example, supports threshold recovery shares; it would be wrong to describe every product as depending on one 24-word backup.[2]
Firmware updates deserve a serious assessment too. A signing algorithm may remain stable while its implementation, communication protocols, parsers, and security boundaries need repairs. Authenticators have lifecycles as well. Yubico uses non-upgradable firmware, yet its security advisories still describe hardware risks requiring assessment and action.[3]
What I want to borrow from chip cards, enterprise authenticators, and security keys is a more stable division of responsibilities. Business systems should be able to evolve without making users handle their root keys for every business change. Keep the authentication root small and stable, put change in the layers suited to change, and design replacement and recovery for when something fails. That is the peace of mind we want a wallet to provide.
How Does a Passkey Become a Blockchain Account?
A Passkey is a public-key authentication credential. WebAuthn defines the browser calls and authenticator assertion format. This article focuses on our ES256 path: ECDSA over P-256. WebAuthn itself can negotiate other algorithms.[4]
An ordinary wallet sends transaction data to a signing algorithm. WebAuthn adds a structure around the operation. The application supplies a challenge, the browser creates clientDataJSON containing the challenge, origin, and other information, and the authenticator signs:
authenticatorData || SHA256(clientDataJSON)A blockchain verifier must understand that structure. It cannot treat the response as just another elliptic-curve signature. It also needs to know what the assertion is authorizing.
ArcBlock’s existing path derives a did:abt: account identifier from the Passkey’s public key, then recognizes its signature type in transaction validation. A Passkey can therefore correspond directly to an on-chain account and participate in transaction signature verification without first deploying a wallet contract for that account. This puts part of authentication in the protocol and gives protocol maintainers the corresponding compatibility and upgrade responsibilities.
“Native” describes where a capability lives. It does not establish that an implementation is safer or remove protocol upgrade costs. Other systems are advancing too. Safe already has Passkey signers, and Ethereum’s EIP-7951 defines a P-256 verification precompile. Contract accounts and EVM systems cannot fairly be described as unable to support Passkeys or necessarily requiring extremely expensive verification.[5][6]
Our concern is the division of responsibility between an application, an authenticator, and a blockchain: who verifies each fact, and who enforces each permission?
Design target: authentication, readable intent, authorization, and asset execution have separate responsibilities. Native Passkey accounts are supported today. The complete wallet shown here is still in development.
Five Common Misconceptions About Passkey Wallets
These assumptions sound reasonable, but they mix guarantees from different layers. Before designing the wallet, we need to separate them and decide which layer is responsible for each protection.
Misconception 1: “A Passkey means the private key stays inside one hardware chip forever”
Synced Passkeys reduce the difficulty of losing one device. Device-bound credentials concentrate availability in a particular authenticator. Their recovery mechanisms and trust dependencies differ. One blanket statement that “the private key never leaves the chip” does not describe both.
WebAuthn’s BE flag indicates backup eligibility; BS indicates the current backup state. Eligible for backup does not mean already backed up. Nor does BE=0 alone prove the use of a particular secure chip. A policy that depends on specific hardware guarantees also needs attestation and a trusted authenticator policy at registration. UP and UV indicate user presence and user verification. They do not prove that the user understood the transaction, and verification may use a device PIN.[7]
The design should let users choose everyday convenience and protection for sensitive authority separately. A synced credential might serve everyday identity, with an independent authenticator or additional delay for critical administration. “Independent” must refer to an actual compromise boundary. The same credential synced to two devices cannot simply be counted as two independent multisignature factors.
Misconception 2: “If the key never enters webpage memory, a compromised frontend cannot steal assets”
Ordinary WebAuthn does not specify a display of the amount, recipient, and operations represented by its challenge. An operating system can confirm an authentication action without the user knowing which blockchain transaction it will produce. W3C Secure Payment Confirmation addresses trusted transaction display for payments, but it is not a ready-made confirmation scheme for arbitrary blockchain transactions.[8]
We therefore need readable intent: network, asset, amount, recipient, permission scope, fee boundaries, and expiry, all bound to the actual execution data. Sensitive operations also need an independent confirmation channel. If both display and signing are controlled by the same compromised frontend, an attractive confirmation page cannot independently establish what the user saw.
Challenge domain separation matters. It should bind the protocol purpose, chain, signer, and transaction digest so a signature from one context is not misused in another. But an attacker controlling a legitimate frontend may still construct a correctly formatted malicious transaction. Readable intent and asset constraints each need to hold on their own.
Misconception 3: “Multiple addresses require using PRF to derive private keys”
The WebAuthn PRF extension can supply pseudorandom output to a client, for uses such as encrypting or unlocking data. The question is what happens to that output next.
If the application treats it as a seed and derives long-lived transaction signing keys, the application is handling signing secrets again. The authenticator protected the upstream operation, but the derived keys still face software-environment risks. On our chain’s Passkey root-signing path, we want to avoid that outcome: let the authenticator sign directly and let public information handle account addressing, rather than create another set of application-readable private keys just to obtain multiple addresses.
One design being refined is SubAccountSalt. A canonical public key, a public subaccount identifier, and explicit domain-separated encoding would derive an account address. The protocol would then verify the binding between the root key and subaccount. It derives an address, not a private key.
That defines its limits too. Different addresses can organize account state and policies separately. When they share a root key, compromise of that root may affect every subaccount. Public keys and salts do not automatically provide anonymity. This needs protocol implementation and compatibility verification; it is presented here as further design work.
Misconception 4: “Without a seed phrase, losing the device makes recovery impossible”
A seed phrase is not the only recovery mechanism. Synced credentials, independent backup authenticators registered in advance, and credential replacement under explicit rules can all contribute to a recovery design. But being seedless does not by itself establish reliable recovery. We want users to register multiple credentials and define the conditions for everyday use, administration, and recovery. Losing a device should permit credential replacement without asking the user to write down another secret that controls everything.
The design must handle both compromise and loss of availability. What if the cloud account is taken over? What if the backup authenticator is gone too? If the wallet service stops, can the original relying party (RP) domain still be used? Can the user start recovery from an independent client and verify the result? Possessing a device does not guarantee the availability of its domain, service, and broadcast path.
Recovery also involves governance. Weakening protections, adding a powerful credential, or replacing the controlling root should require independent authorization and an observable waiting period. Emergency tightening can have different conditions. The right to veto recovery must also be explicit. If a compromised everyday credential can indefinitely block legitimate recovery, the protection itself can lock the user out.
Misconception 5: “A biometric prompt for every operation is the safest design”
The number of prompts is not a security measure. Repeated biometric checks do not establish that the user understood each request. Undifferentiated confirmations may also create approval fatigue, burying important permission changes among routine prompts. We want to concentrate confirmation on granting authority, expanding permissions, and critical asset operations, while limited session authorizations handle everyday small operations and agent automation.
A session key, however, does not become trustworthy simply because it is described as non-exportable.
WebCrypto’s extractable:false prevents raw private-key export through the export API. It does not guarantee hardware backing or prevent a same-origin script with the handle from calling sign(). In a minimal experiment, a non-exportable P-256 key rejected export but still signed and verified normally. That is the API’s intended boundary.[9]
Account execution rules must therefore continue to constrain the session: what it may do, with whom, using which assets, for what cumulative amount, until when, and how it can be revoked. The maximum remaining budget an attacker could consume after a session key is compromised is a more useful security measure than “we used a non-exportable key.”
Protect Execution After the Signature
Our design has four layers. The authenticator holds the root credential. The wallet turns a transaction into readable intent. Sessions carry limited authority. The account’s execution layer enforces policy. Recovery and policy changes span those layers and need their own authorization conditions.
AccountGuard is the declarative account-protection approach we are building on that foundation. Rules express per-operation thresholds, rolling budgets, permitted destinations, credential authority, waiting periods, and emergency-stop conditions. Those rules participate in execution decisions. We have an implementation foundation for the DSL and policy engine. The complete wallet still needs to connect authentication, persistent state, and consensus, and enforce these rules at every asset execution entry point.
Convenience for small operations, explicit conditions for larger ones
The following is an illustrative design, not the defaults of a released product:
- An everyday credential can pay only approved recipients, use specified assets, and operate within a rolling cumulative budget.
- An operation with sufficient authority but above the immediate-execution threshold enters a waiting queue. An operation outside the grantable authority is rejected. Waiting does not make it authorized.
- Raising limits, changing critical destinations, or replacing the administration root requires independent authorization and a delay. The everyday credential cannot disable its own protection.
- Before actual execution, a credential with predefined emergency authority can submit a veto. Execution still rechecks the current policy, revocation state, expiry, and budget.
The delay is before asset execution. A veto transaction must reach confirmation in time. This mechanism cannot roll back a transfer that has already reached final settlement.
A timelock creates a response window. It cannot guarantee that a user receives a notification, is online, or gets an emergency request confirmed before an attacker’s operation. A product also needs independent notifications, available emergency submission paths, fee arrangements, and rehearsals under pressure. A “Veto” button is not a promise that assets can always be saved.
Budgets must withstand combined attacks. Does a queued operation already reserve its amount? Can concurrent requests each see the same remaining balance? Does accounting remain consistent across window boundaries, restarts, and retries? Checking the amount of one transaction on a page is nowhere near enough.
Cover every entry point that can change control over assets
Transfers are the most visible entry point. Allowances, contract calls, NFT transfers, batches, delegation, multisignature configuration, account migration, and software upgrades can also change who can dispose of assets.
A protection layer needs a defined coverage boundary and explicit exceptions. If an everyday key cannot transfer a large amount but can lower the multisignature threshold or grant another address unlimited spending authority, the limit has another route around it. Changes to the protection rules themselves deserve scrutiny comparable to spending.
We favor small, explicit rules for account security conditions, reducing the state space that needs to be understood. Declarative rules can still have bugs. Their interpreter, integer precision, persistent state, and version upgrades all become part of the security boundary and need independent review.
What Exists, and What Still Needs Work?
An engineering article must distinguish a completed design, an implemented component, and a feature users can already use. The current stage is:
| Layer | Foundation today | Status in this article |
|---|---|---|
| Native Passkey accounts | Public v1.19.x documentation describes account and transaction support | Existing capability under continued development |
| Multisignature and transaction validation | Per-signature WebAuthn metadata, transaction canonicality checks, and signature-independent deduplication have implementations | Protocol components, dependent on actual versions and activation configuration |
| Account policies | Declarative rules, cumulative budgets, and waiting-queue policy-engine foundations exist | Implemented components, not a complete wallet execution path |
| Subaccounts, verification versions, and key replacement | Public-information address derivation, purpose binding, anti-downgrade, and controlling-root migration designs | Being refined; status follows implementation and verification |
| Next-generation wallet and recovery experience | Organizing those capabilities into everyday use, administration, emergency stops, and recovery | Product still in development |
| External-chain control | Reusing signatures accepted by the target chain and established account mechanisms | Further exploration requiring chain-specific design and verification |
Several protocol questions deserve particular attention in the next stage.
Public-key encoding must be stable. The same elliptic-curve point can have different external representations. If an address is derived from public-key bytes, the protocol needs clear rules for valid points, encoding, field sets, and normalization. Existing addresses must be preserved rather than reinterpreted during an upgrade.
Signature wrapping must not arbitrarily change transaction identity. ECDSA signatures can be malleable, and WebAuthn adds assertion data. Deduplication needs to identify the actual authorized operation. Signature normalization is only one layer. Participants, authority, and the business payload must still be committed correctly. Removing signature data must not also remove authorization meaning.
New verification rules need explicit activation and anti-downgrade semantics. Historical replay, continued operation of existing accounts, and attempts to delete fields to downgrade an upgraded account all need protocol definitions. An “upgraded” badge in a wallet interface cannot replace on-chain state.
A replacement key must be proven usable. Proof of possession, checks that the user can operate the new credential, and recovery rehearsals can reduce accidental lockout. Keeping an old address, redirecting it to a new one through a migration relation, and replacing control at the original address are different protocol semantics. We will describe the mechanism actually implemented, rather than call them all a “lossless upgrade.”
Cross-Chain Security Must Respect Each Chain’s Verifier
Bringing the same account principles to other chains is a direction we are considering. Signature and execution differences are easy to underestimate.
A WebAuthn P-256 signature cannot be treated as the secp256k1 Schnorr signature required by Bitcoin Taproot. Safe’s Passkey support depends on the relevant verifier. Squads is a program running on Solana. Reusing established implementations can reduce new custom logic, but does not remove contracts, adapters, or the target chain’s verification requirements.[10][11][12]
Any further cross-chain design must answer, chain by chain: who holds which type of key? Which bytes does the target chain verify? How does a policy co-signing service bind its approval to the actual execution payload? How does its confirmation become an authorization that the other chain accepts? How can the user exit if the service stops?
A plain 2-of-3 example shows the tradeoff. Suppose A is the user’s everyday key, B is a policy co-signer, and C is an offline recovery key:
| Available pair | What it can provide | Boundary to acknowledge |
|---|---|---|
| A + B | Everyday operations approved by both user and policy | Depends on policy-service availability and correct binding to the actual transaction |
| A + C | A possible recovery path when the policy service is unavailable | Also a path around B; C needs independent protection |
| B + C | Meets an ordinary any-two-keys threshold | May not require A; the user must understand and accept that |
A design cannot require B for every spend while also claiming that A+C can withdraw immediately at any time. Delayed recovery must use time conditions and signature paths the target chain actually enforces. A timelock is not another key.
This still needs chain-specific engineering verification. We will favor existing mechanisms and state the new trust assumptions, recovery conditions, and failure modes explicitly.
Compatibility Gives Existing Users a Voluntary Path Forward
Making Passkeys the primary entry point for a new wallet does not make old wallets and accounts obsolete. We want to preserve existing key types and usage paths so users can choose according to their needs.
Compatibility has at least four meanings: existing accounts remain operable; historical transactions are validated under their corresponding rules; developers know which APIs or protocols need an upgrade; and users choosing migration understand how addresses, asset relationships, and credential references are handled. The early v1.19 documentation records some APIs becoming asynchronous when Passkey support was added. Supporting another signature type also requires a clear developer migration guide.
We want the new default experience to reduce seed-phrase burdens while giving existing users a migration process they can inspect and rehearse. Control of the account, asset references, and recovery relationships must all be established before replacing old credentials. A product direction should not force every user to reorganize their assets at once.
Compare Wallets by These Capabilities
This compares approaches and design targets. A particular product may combine several approaches. The entries for our wallet describe what we are building toward, not a released guarantee.
Does the application handle signing secrets?
| Approach | Capability and boundary |
|---|---|
| Software-key wallets | Depends on implementation; it may handle an unlocked seed or key |
| Traditional hardware wallets | The device normally signs without giving the host the raw key |
| Passkey contract accounts or custody/co-signing approaches | Depends on direct assertions, MPC, or what happens after PRF output |
| Our native Passkey wallet direction | Root signing does not give the application the raw private key; sessions have separate boundaries |
Does the user know what is being signed?
| Approach | Capability and boundary |
|---|---|
| Software-key wallets | Depends on parsing and a trustworthy display |
| Traditional hardware wallets | A separate display is valuable; parsing coverage still matters |
| Passkey contract accounts or custody/co-signing approaches | WebAuthn alone does not supply general transaction-detail display |
| Our native Passkey wallet direction | Readable intent bound to actual data, with independent confirmation for sensitive authority |
How much can a valid signature authorize?
| Approach | Capability and boundary |
|---|---|
| Software-key wallets | Depends on account permissions; limits are not automatic |
| Traditional hardware wallets | Device isolation does not automatically limit account authority |
| Passkey contract accounts or custody/co-signing approaches | Can use guards, session keys, recovery, or service policies |
| Our native Passkey wallet direction | Combine scoped authority with execution constraints and verify coverage |
What if a device fails or becomes unavailable?
| Approach | Capability and boundary |
|---|---|
| Software-key wallets | Depends on backups, other credentials, or recovery services |
| Traditional hardware wallets | Depends on backups, shares, or other recovery arrangements |
| Passkey contract accounts or custody/co-signing approaches | Depends on the recovery design and service/contract availability |
| Our native Passkey wallet direction | Multiple credentials, rotation, delays, and independent recovery rehearsals |
Everyday use and agent automation
| Approach | Capability and boundary |
|---|---|
| Software-key wallets | Software can sign automatically; compromise needs a bounded impact |
| Traditional hardware wallets | Often requires an additional authorization or session layer |
| Passkey contract accounts or custody/co-signing approaches | Different session and delegation approaches already exist |
| Our native Passkey wallet direction | Infrequent root administration, with limited-duration, budgeted authorizations for routine work |
Hardware wallets’ trusted displays are worth learning from. So are mature contract wallets’ recovery, session, and permission modules. We choose native accounts to organize those responsibilities more clearly within our own protocol. Implementation and adversarial testing must ultimately show the result.
Make the Work Testable by Others
Publishing this article opens our own work to others. For wallet and chain builders to benefit, the protection conditions also need to become repeatable acceptance scenarios.
We think at least the following scenarios and their results should gradually be made public:
| Compromise or failure | What must be demonstrated |
|---|---|
| The frontend displays an expected recipient but substitutes the actual request | Independent confirmation identifies the actual intent, and account policy limits unauthorized execution |
| Malicious script calls a session key | Execution still enforces scope, destinations, expiry, and cumulative budget |
| An attacker splits transfers, submits concurrently, or accumulates queued operations | Total exposure stays within policy; queues, retries, and restarts do not release budget twice |
| An everyday credential tries to raise limits or replace an administrator | Predefined independent authorization and delays are required; the credential cannot remove its own protections |
| A phone is lost, sync is unavailable, or a hardware authenticator breaks | Recovery works under predefined conditions, with a usable new credential and treatment of old authorizations |
| The wallet service or RP domain disappears | Independent clients and recovery paths work as promised, or their limitations are stated explicitly |
| A protection service stops, delays, refuses to co-sign, or approves incorrectly | The account follows the agreed failure behavior, and exit does not depend on a last-minute act of goodwill |
| Old accounts upgrade, historical blocks replay, and new rules activate | Compatibility is verifiable and upgraded accounts cannot fall back to disallowed verification rules |
These are the engineering checks we are willing to face. We will publish results for the work actually completed, and hope to turn these scenarios into shared specifications, vectors, and tests.
When the next wallet incident happens, I do not want our industry’s answer to remain “Did you write down your seed phrase?” Users deserve better tools and a clear understanding of how far those tools protect them.
Native Passkey accounts give us a starting point. The next task is to connect signing, intent, authority, execution, and recovery into a system that can be examined seriously. Writing down the approach so others can discuss, challenge, adopt, and independently implement it is the first step we are prepared to take now.
References
- Trezor: Update Trezor firmware. Backup preparation and recovery after update failures. ↩
- Trezor: What is Shamir backup?. Threshold backups and their recovery boundaries. ↩
- Yubico: Security Advisory YSA-2024-03. Authenticator firmware, device risks, and lifecycle tradeoffs. ↩
- FIDO Alliance: Passkeys. Passkeys and synced versus device-bound credentials. ↩
- Safe: Safe and Passkeys. Passkey support through contract verifiers. ↩
- Ethereum: EIP-7951: Precompile for secp256r1 Curve Support. P-256 verification precompile specification. ↩
- W3C: Web Authentication Level 3, particularly authenticator data, backup state, and assertion verification. ↩
- W3C: Secure Payment Confirmation. Ordinary WebAuthn versus trusted payment-detail display, within the specification’s scope and implementation requirements. ↩
- W3C: Web Cryptography API. Key storage, security considerations, and
extractablesemantics. ↩ - Safe: Smart Account Concepts. Owners, thresholds, modules, and transaction verification. ↩
- Squads Protocol: v4. The multisignature program and its authority and recovery conditions. ↩
- Bitcoin: BIP 340: Schnorr Signatures for secp256k1. The signature scheme underlying Taproot. ↩