Passkey-native wallet pattern

The embedded, non-custodial wallet you fully own.

Ship a passkey-powered Ethereum wallet experience that is secure by design, easy for users, and entirely under your control. Your app derives wallet keys from WebAuthn PRF, runs signing in an isolated iframe, and keeps private keys out of your backend forever.

  • No extensions
  • No vendor lock-in
  • No custody risk
No dependencies needed, just install the skill
npx skills add 1Shot-API/skills/webauthn-prf-wallet
Architecture
Client · secure zone
  1. Passkey
    Face ID · Touch ID · PIN
  2. PRF output
    HMAC-SHA-256 · per credential
  3. secp256k1 key
    HKDF → valid EVM key
  4. Iframe signer
    Isolated · same-origin
Out: signatures only · keys never leave the iframe
Server zone
Challenge
Verify signature
No private keys. No PRF output. No derived material. Ever.
Skill-driven integration

Install the 1Shot PRF skill, then tell the agent what to ship.

The skill gives the agent the sharp edges up front: PRF derivation, iframe isolation, platform gating, and the stablecoin checkout wiring your product needs.

View Docs
ghost terminal
alice@1shot
$ npx skills add 1Shot-API/skills/webauthn-prf-wallet
┌ skills
│
◇ Source: https://github.com/1Shot-API/skills.git (webauthn-prf-wallet)
│
◇ Repository cloned
│
◇ Found 1 skill
● Skill: webauthn-prf-wallet
alice prompt
Add the prf passkey wallet to my store,let the user create a stablecoin walleton their profile page and prompt them to add USDT.Give them a 3% discount if they purchaseusing thier stablecoin wallet
Coding agent
I'll implement the wallet, found skill, reviewing iframe pattern...
Why teams choose this approach

The passkey-first wallet pattern

Everything you get without handing your users — or your wallet stack — to someone else.

No 3rd-party wallet software

Users sign in with native passkeys instead of installing extensions or external wallet apps. Onboarding finishes in one biometric tap.

100% source-code ownership

Implement directly in your stack and control every line of client and server logic. No SDK black boxes, no usage metering, no dashboards that own your user.

Fully non-custodial

Your server never receives private keys, PRF output, or derived key material. The only thing leaving the client is a signature.

Embeddable across products

Expose wallet capabilities through an iframe so third-party applications can integrate your wallet UX without inheriting custody.

Modern auth UX

Biometric and passkey prompts replace seed-phrase friction for everyday users. Face ID in, signed transaction out.

Security-forward architecture

Key material stays in an isolated same-origin iframe context, shrinking the blast radius of any XSS or supply-chain compromise in the parent app.

How it works

Four steps from passkey to signature

No seed phrases, no server-side keys, no vendor in the middle. Just deterministic client-side cryptography.

01

Passkey authentication

User completes a WebAuthn ceremony — Face ID, Touch ID, fingerprint, or PIN — on the device they already own.

02

Deterministic key derivation

WebAuthn PRF output is transformed via HKDF-SHA-256 into a valid secp256k1 private key, on-device, every time.

03

Isolated signing runtime

The key exists only in a same-origin iframe context and signs through a narrow, typed RPC interface — never exposed to the parent app.

04

Embeddable wallet interface

Third-party apps consume wallet actions through iframe embedding. They get signatures and addresses — and never touch keys.

Native EVM, out of the box

A real EVM key — not a smart-wallet workaround.

Most passkey wallets hand you a P-256 key — which forces you into a smart-contract wallet, on-chain signature validation, and per-user deployments just to send a transaction. The PRF pattern instead derives a native secp256k1 EVM private key on-device. Exactly what MetaMask, hardware wallets, and every EVM tool already speak.

The result is a standard EOA that works everywhere — including 1Shot's public relayers, out of the box. Sign a transaction in the iframe, hand the signed payload to a relayer, and it lands on-chain like any other EOA tx.

  • Standard EOA — no per-user smart-contract deploy on first transaction
  • Signatures verify natively in any EVM contract, on any chain
  • Drop-in with 1Shot's public relayers, public RPCs, and any wallet connector
  • No account-abstraction bundlers, no P-256 precompile dependencies, no custom validation contracts
Key-type comparison
Typical passkey wallet
P-256 · smart wallet
  1. 1Passkey ceremony → P-256 key
  2. 2Deploy smart-contract wallet
  3. 3On-chain P-256 signature validation
  4. 4Bundler + paymaster → tx lands
PRF wallet · this pattern
secp256k1 · EOA
  1. 1Passkey → PRF → secp256k1 EOA key
  2. 2No contract to deploy
  3. 3Native ECDSA signature — verifies anywhere
  4. 41Shot relayer → tx lands
Same key works with 1Shot relayers. No bundler middleware, no contract upgrades, no chain-by-chain P-256 precompile guesswork.
Trust boundary

Where keys live — and where they don't

One diagram tells security reviewers everything they need to know.

Client · secure zone
  • Passkey ceremony
  • PRF output · HKDF
  • secp256k1 private key
  • Transaction signer
Boundary
public key
Server zone
  • Challenge generation
  • Signature verification
Not present
private keys · PRF output · seed material

Security positioning

  • Private key derivation and signing stay client-side.
  • Backend is limited to WebAuthn challenge generation + signature verification.
  • No key export to server, logs, analytics pipelines, or third-party custody layers.
  • Same-origin iframe isolation and CSP hardening improve defense-in-depth.
No third-party dependency

How it compares

Three wallet models, side-by-side.

Extension wallet
MetaMask-style
Hosted custodial
SaaS wallet vendor
Embedded PRF
This pattern
User install required
Yes — browser extension
No — hosted
No — native passkey
Key custody
User (extension vendor)
Vendor holds keys
User — client-only
Source-code control
Vendor-controlled
Vendor-controlled
Full ownership
Iframe embeddable
No
Limited · custody-bound
Yes · same-origin isolation
Server key exposure
None
Full custody
None
Sequence flow

Registration & signing at a glance

A swimlane for technical buyers and security reviewers: who talks to whom, and what the payload actually is.

User
Parent App
Wallet Iframe
Server
  1. Click sign-in
  2. Request options
  3. Challenge + PRF salt
  4. signIn(username)
  5. Face ID / PIN prompt
  6. Biometric OK
  7. HKDF → secp256k1
  8. Auth response
  9. Session
  10. Ready · address only
Compatibility & fallback

PRF-first, with a path for every user

PRF is the happy path. For platforms that don't support it yet — we ship a graceful LongBlob + recovery-phrase fallback so no user is left out.

Primary

PRF-first flow

Chrome · Safari · Edge · Android (Chrome) · macOS · iOS 17+
  • Deterministic HKDF → secp256k1 derivation
  • One passkey = one wallet, per credential
  • Zero client-side secrets persisted
Fallback

LongBlob + recovery phrase

Firefox-for-Android · in-app webviews · legacy authenticators
  • 32-byte key stored inside the credential via credBlob / largeBlob
  • Multiple passkeys can share the same wallet
  • AES-256 recovery phrase encrypts a server-side backup ciphertext
Built for control and interoperability

Grow distribution without handing over your wallet.

You don't have to choose between ownership and ecosystem compatibility. Keep full control over wallet logic, policies, and source code — and still let external apps integrate your wallet through a clean embedded interface.

Grow distribution without handing core wallet infrastructure to a third-party provider.

Ideal use cases
  • Embedded wallets for consumer apps
    Add a native wallet to your product without a wallet browser extension.
  • Passkey-first onboarding
    Replace seed-phrase onboarding with a single biometric tap for Web3 products.
  • Browser-native wallets
    Wallet-as-a-pattern: absolutely no user limits or dependencies on external providers.
  • Partner portals with delegated access
    Secure, policy-bound wallet access for partners who should not hold keys directly.
  • Developer platforms with wallet features
    Expose wallet actions to customer apps via iframe — without inheriting their custody risk.
See it in action

Ship a wallet your users — and your security team — can trust.

We're pairing with a small set of launch partners building consumer apps, white-labeled wallets, and delegated-access portals. Let's talk.

No dependencies needed, just install the skill
npx skills add 1Shot-API/skills/webauthn-prf-wallet
Read the quickstart