This document describes technical details of the security architecture and cryptographic design of Foundation, a high-security backup service for self-custody of cryptocurrency seed phrases.

Foundation is designed to give strong guarantees for confidentiality, durability, and control. It ensures that only the account owner—or, when explicitly configured, a designated legacy member—can access the encrypted contents of an account. All encryption, decryption, and key generation happen on the customer’s personal device, using secure hardware. The Foundation service never holds or derives the encryption keys required to access a vault.

This document is intended for security engineers, cryptographers, compliance reviewers, and technically engaged customers. It describes how Foundation enforces device-bound access, prevents unauthorized recovery, and minimizes trust in the server infrastructure. Our goal is to provide transparency and clarity into how Foundation protects sensitive key material—without requiring blind trust in us.

Foundation is built on a single principle: the only way to access your encrypted account information is using your registered devices, under your control.

To achieve this, Foundation enforces the following design commitments:

These principles are not theoretical. They shape every part of Foundation’s cryptographic architecture and operational policy. The remainder of this document details how they are implemented in practice.

Foundation consists of five key components. Each plays a distinct role in safeguarding encrypted backups while minimizing trust in centralized infrastructure:

This is the cryptographic center of Foundation. It is responsible for generating encryption keys using platform-secure hardware (iOS Secure Enclave or Android Keystore), and it is the only device that performs any encryption and decryption. No seed phrase ever leaves this device unencrypted. Every access, recovery, or transfer ultimately depends on a mobile device being in the loop.

The account owner is the individual who controls access to all secure account information. They authorize mobile and recovery devices, configure optional legacy transfer settings, and authenticate with MFA to manage their account. While the account is necessary to access ciphertext, decryption can only occur on mobile devices they’ve explicitly enrolled.

A recovery device is a FIDO2 security key registered using the WebAuthn PRF extension. It derives a hardware-bound cryptographic seed, gated by the device owner’s PIN. If the original mobile device is lost, a registered recovery device—combined with account authentication—can rederive the necessary keys to decrypt account information. Recovery always requires both possession of the device and knowledge of the PIN.

An optional, pre-authorized device belonging to a designated legacy contact. After a configurable period of inactivity by the account owner, the Foundation service releases encrypted account information that can be accessed on this device. Like recovery, decryption is only possible with the physical legacy device and successful authentication.

The Foundation service handles ciphertext storage, enforces access and policy rules, and verifies device identity, account status, and inactivity timers. It does not generate encryption keys or decrypt vaults. The service acts as a policy gate and high-durability ciphertext storage—never as a trusted decryption endpoint.

This section walks through how data moves through the system—from input to encryption, storage, access, recovery, and legacy transfer. It’s where you show how Foundation functions end-to-end, emphasizing where encryption happens (device), where ciphertext lives (server), and what’s required to access or recover encrypted information.

The account owner must be authenticated to their Foundation account and use a registered device. This is necessary to have access to the hardware bound encryption keys required to encrypt (or decrypt) seed phrases. The account owner enters their seed phrase directly on their registered mobile device. The device generates the encryption key and encrypts the seed phrase on the device using authenticated encryption. The account owner satisfies a device biometric challenge to access encryption keys and exercise the platform secure encryption hardware (either iOS the Secure Enclave or Android Keystore). The encrypted seed phrase is uploaded to the Foundation service where it is stored as ciphertext. The encryption keys never leave the device, and the plaintext seed phrase is never transmitted or stored by Foundation.

To access encrypted account information, the account owner must authenticate to their Foundation account from a registered mobile device. This involves credential authentication—either an email and passphrase or login via Google or Apple account—and multi-factor authentication using TOTP. Foundation does not support email- or SMS-based MFA, which are excluded due to their vulnerability to interception and account takeover.

The Foundation service verifies account credentials, device registration, software integrity, and inactivity policy before releasing encrypted data to the device. Encrypted account information is never stored locally and is only transmitted after these checks are satisfied.

If the account owner's mobile device is lost, damaged, reset, or unavailable, they can regain access using a pre-registered recovery device. Recovery devices are FIDO2 hardware authenticators that support the WebAuthn PRF extension. During registration, the device derives a cryptographic seed that is bound to the physical authenticator and gated by the owner’s PIN.

This seed is used to generate an encryption key, which encrypts sufficient account information to enable recovery. The encrypted recovery payload is stored by the Foundation service and is only released after successful account authentication and multi-factor verification. Recovery requires account authentication, possession of the registered hardware device, and knowledge of the PIN—anything less is insufficient to recover the account.

Account owners may designate a trusted contact as a legacy member, who can access encrypted account information after a defined period of inactivity. The process begins when the account owner sends a secure invitation code to the legacy contact, who must create a Foundation account with multi-factor authentication and register a secure device. As part of enrollment, the legacy contact’s public key is provided to the account owner.

The account owner reviews and confirms the enrollment, including metadata such as the legacy contact’s email, geolocation, and device type. Both parties are shown a safety code that allows them to verify—out of band—that the Foundation service has not tampered with key material. When the account owner confirms, their mobile device encrypts a recovery payload using the legacy contact’s public key and uploads it to the Foundation service.

When the inactivity period expires, Foundation releases this encrypted recovery payload to the legacy contact’s device. As with all other access, decryption requires MFA, secure hardware, and physical possession of the registered device. The encryption model is identical to standard account access—no shortcuts.

Foundation’s architecture enforces strict separation between encrypted data, cryptographic keys, and access policy enforcement. Each component is constrained by design:

Holds all decryption keys, derived locally from platform-secure hardware. Devices perform all encryption and decryption operations. Neither the decryption keys nor the decrypted account information ever leave the device, and decryption is impossible without biometric or PIN authentication enforced by the operating system.

Hold cryptographic seeds derived using the WebAuthn PRF extension, gated by a PIN. These seeds are used to derive encryption keys that are used for account recovery. As with mobile devices, decryption can only occur with physical possession of the registered device.

Stores encrypted account data and enforces policy—device registration, inactivity monitoring, software version validation, and multi-factor authentication. It cannot generate, access, or decrypt any encrypted material. All cryptographic operations occur on devices the account owner controls.

Account owners control device enrollment, recovery and legacy authorization, and inactivity policy. Legacy members cannot access encrypted information without pre-registration, confirmation, and eventual policy fulfillment. Foundation facilitates communication and key exchange, but cannot enroll legacy members or access decrypted account information.

Foundation is built around a set of unbreakable constraints that define what must always be true, regardless of platform, policy, or infrastructure state:

All key generation, encryption, and decryption operations occur exclusively on the customer’s registered mobile devices. Foundation uses platform‑provided cryptographic libraries and device secure‑hardware modules for cryptographic operations.

Device keys are hardware-bound cryptographic keys (asymmetric key pairs) used to encrypt the customer’s vault key. The vault key is used to encrypt vault records (customer-entered seed phrases).

All keys are P-256 ECDH keypairs and all encryption is single-shot ECIES-P-256-HKDF-SHA-256- AES-GCM-128 with sender/receiver keypairs and the ciphersuite bound to ciphertexts via the HKDF info. This is the same public key encryption scheme used in Station70’s institutional backup product, Bunker, and has been audited by Trail of Bits.

Customers can regain access to encrypted account information by presenting a pre‑registered hardware authenticator—Foundation currently supports Yubico devices on both iOS and Android.

Account owners can optionally designate a trusted contact as a legacy member, enabling post‑humous or fallback access to encrypted account information after a defined period of verified inactivity.

All account activity in Foundation begins with strong account authentication, this includes viewing account information, accessing secured records, adding or modifying information, or making account or legacy member changes. Because ciphertext is stored only on the Foundation service and not on client devices, successful authentication is a required first-step in every workflow. This also prevents access to account information if devices are lost, stolen, or compromised.

Account owners sign in with either an email + passphrase credential pair or a federated identity from Google or Apple. Foundation uses time-based one-time password (TOTP) MFA. SMS and e-mail 2FA are intentionally unsupported because they are commonly hijacked through SIM-swaps, phishing, or mailbox compromise.

Foundation only operates on recent versions of mobile device operating systems (iOS and Android). Limiting the app to very recent versions means every device benefits from the latest vendor patches and runtime hardening and sharply reduces exposure to known jailbreak or rooting techniques. It also guarantees access to up-to-date Secure Enclave (iOS) and StrongBox (Android) features and the most recent cryptographic libraries, so all cryptography uses the strongest primitives offered by the platform.

Once credentials and MFA (or federated identity) are validated, Foundation returns a cryptographically-signed session token that proves the caller’s identity. All tokens include a fixed-length expiry and are presented with every subsequent API request; the service accepts a request only after verifying the signature, timestamp, and account status. Token expiry is critical and tokens are never refreshed automatically (no “forever session”), so Foundation requires periodic re-authentication, including MFA.

Communication between Foundation client and service is carried over the most recent TLS version ( currently TLS 1.3) with a restricted set of secure cipher suites, uses mutual TLS (using client certificates), and endpoints sit behind a zero-trust edge network designed to absorb volumetric DDoS attacks, enforces rate-limits and bot filtering, and screen out malformed or policy-violating packets, The result is encrypted, integrity-checked traffic, bound to an authenticated application, with upstream shielding that preserves availability under adversarial load.

Foundation’s safeguards are verified through independent, point-in-time assessments:

These third-party evaluations provide objective confirmation that the Foundation design and implementation meet the high standards outlined in this document.