On-device execution

On-device execution enables wallet operations to occur directly on the user's device. This approach provides enhanced security through isolation and exceptional performance with signing speeds under 100ms.

Execution environment

Openfort's on-device execution uses browser-isolated environments via iframes. This architecture provides multiple layers of security:

• Hardware-level memory protection: The iframe operates in a separate browser process with completely isolated memory.
• Browser process separation: Full segregation from the host application.
• Strict origin validation: Frame ancestor validation prevents unauthorized embedding.
• Content Security Policy (CSP) controls: Restricts resource loading and script execution.

The iframe's isolated environment ensures that sensitive cryptographic operations occur in a protected context, completely separated from your application code.

Key sharding architecture

Openfort never stores private keys in their complete form. Instead, Openfort implements a distributed key sharding model using Shamir's Secret Sharing (SSS). This model splits keys across three shares.

Share types

Security properties

• 2-of-3 threshold: Any two shares can reconstruct the private key.
• No single point of compromise: Neither Openfort nor any single share holder can access wallets independently.
• Temporary reconstruction: Keys exist in memory only during signing operations.

Create a wallet

When you create a new wallet, the system performs the following process within the isolated iframe:

1. Generate the private key.
2. Shard the private key using SSS.
3. Distribute the encrypted shares:
   • Device share to browser storage.
   • Auth share to Openfort (encrypted).
   • Recovery share to Shield (encrypted).

┌─────────────────────────────────────────────────────────────┐
│                    Wallet Creation Flow                     │
├─────────────────────────────────────────────────────────────┤
│   1. Generate private key                                   │
│                    ↓                                        │
│   2. Shard private key using SSS                            │
│                    ↓                                        │
│   3. Distribute encrypted shares                            │
│      • Device share → Browser storage                       │
│      • Auth share → Openfort (encrypted)                    │
│      • Recovery share → Shield (encrypted)                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

The system immediately discards the original entropy and private key after sharding. They never persist to storage.

Sign a transaction

Signing flow

1. Your application passes transaction data via the SDK.
2. The iframe validates the user's authentication state.
3. Retrieve shares: Device share locally and auth share from Openfort.
4. Reconstruct the private key temporarily in isolated iframe memory.
5. Sign the transaction using the reconstructed key.
6. Clear key material immediately from memory.
7. Return only the signature to your application.

Security guarantees

• No key exposure: The private key never leaves the iframe's isolated memory.
• No key persistence: Keys exist only for the duration of the signing operation.
• Minimal attack surface: Only the signature returns to your application.

Recovery mechanisms

On-device wallets support multiple recovery methods for when users need to access their wallet on a new device.

Automatic recovery

The system uses a 2-of-2 secret sharing model. To ensure the system remains non-custodial, separate entities hold the two halves of the master key (entropy):

• Share A (cold storage): Managed by the cold storage service.
• Share B (developer share): Secured by the developer (never exposed on the client side).

Using standard authentication, users can provision their wallet on new devices:

1. User authenticates on new device.
2. Retrieve auth share with valid credentials.
3. Decrypt recovery share using configured recovery method. The developer must create a secure backend endpoint that acts as a bridge to Shield. This endpoint creates an encryption session with the developer share.
4. Generate and store new device share locally.

To prevent recovery without active user interaction, enable OTP (SMS or email). Shield pauses the recovery process and requires a code sent to the user. This ensures that even if both shares are available, the system cannot reconstruct the master key without the user's consent.

User-managed recovery

For enhanced security, users can manage their own recovery share encryption:

Domain binding (passkey-based recovery)

Passkeys use WebAuthn, which binds credentials to a specific domain (the Relying Party). This is a security feature that prevents phishing attacks—credentials created for one domain cannot be used on another domain.

Important implications:

• Credentials created for example.com only work on that domain and its subdomains.
• Users cannot transfer their passkey wallet to other applications.
• The passkeyRpId configuration must match your production domain exactly.

If your product spans multiple domains, consider using automatic recovery instead.

Recovery flow

┌──────────────────────────────────────────────────────────────┐
│                    Device Recovery Flow                      │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│   Lost Device Scenario:                                      │
│                                                              │
│   1. User authenticates on new device                        │
│                    ↓                                         │
│   2. Retrieve auth share (valid authentication)              │
│                    ↓                                         │
│   3. Decrypt recovery Share                                  │
│                    ↓                                         │
│   4. Reconstruct private key temporarily                     │
│                    ↓                                         │
│   5. Generate new device share                               │
│                    ↓                                         │
│   6. Store new device share in browser                       │
│                                                              │
│   Result: Wallet fully operational on new device             │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Security boundaries

The on-device architecture maintains strict separation between security domains:

What your application cannot access

• Private keys or key shares
• Mnemonic phrases or entropy
• Internal iframe state or memory
• Cryptographic operations directly

What your application receives

• Public addresses
• Signed transactions and messages
• Authentication state
• Wallet metadata

Open-source cryptography

The key sharding implementation uses Openfort's open-source Shamir's Secret Sharing library. Third-party security firms have audited this library extensively. Millions of wallets have battle-tested it. Openfort publishes it under an open-source license for transparency.

Learn more at OpenSigner.

Best practices

When you integrate on-device wallets:

1. Trust the iframe boundary. Don't attempt to access iframe internals.
2. Handle signatures only. Your application works with returned signatures.
3. Implement proper error handling. Network issues can affect share retrieval.
4. Use secure contexts. Always serve your application over HTTPS.
5. Configure CSP appropriately. See Content Security Policies for guidance.