Whitepaper · Draft 0.1

Valtu Wallet: custody built on attested enclaves

Valtu Wallet is custodial wallet infrastructure for fintech companies. Private keys are created and used only inside AWS Nitro Enclaves, whose code is measured, reproducible and checked by the key service before any secret is released. Every request to use a key is signed by its sender, checked against policy inside the enclave, and recorded. This paper describes how the system is built, what it protects against, what it relies on, and what is not finished yet.

1. Principles

1. Keys never leave hardware isolation. Seed material exists in plaintext only inside an enclave's memory. Operators, cloud administrators and the hosts that run the enclaves see only ciphertext.
2. Verify, don't trust, the code. Enclave images are built reproducibly. The key service releases secrets only to an image whose measurement matches the published release.
3. Every request is signed. Requests are authenticated with asymmetric signatures over the exact request, not shared secrets or bearer tokens that can be replayed.
4. Deny by default, fail closed. If no policy allows an action, or a policy can't be evaluated, the action is refused.
5. Two people for anything that matters. Changes to keys, policies, networks and operator access need a second person's signed approval.
6. Say what isn't done. Limits are documented here and in the product, not discovered by customers.

2. System overview

The coordinator is an ordinary service: it stores data, runs approval workflows, builds transactions, watches chains and delivers webhooks. It is treated as untrusted for key custody: it never holds key material in plaintext, and the enclave re-checks everything the coordinator asks it to sign.

The enclave applications are written in Rust and run inside Nitro Enclaves:

3. Key management

3.1 Wallets and derivation

Each customer workspace is its own enclave organization with its own wallet seeds (BIP-39). Addresses are derived with BIP-32 on secp256k1 for EVM networks, Tron and Bitcoin (BIP-84 native SegWit), and SLIP-0010 on ed25519 for Solana. Derivations are tested against public vectors from common wallets. A wallet in the product is a derivation index within a seed, so one wallet has one address per network family.

3.2 Sealing

Seeds are stored in the database only in sealed form: encrypted with HPKE (X25519, HKDF-SHA256, ChaCha20-Poly1305) to the deployment's quorum key, with the organization and wallet bound as associated data, so a sealed seed copied into another organization's row can't be opened. Only the signer, inside the enclave, holds the quorum key.

3.3 Key ceremony and backup

The quorum key and one identity key per enclave role are created in a key ceremony. Their public keys are written to an anchors file that is compiled into every enclave image, so they are covered by the image measurement. A backup of the quorum key is split with Shamir secret sharing (k of n) and each share is sealed to a separate key holder. Recovering the key needs k holders together.

3.4 Attested provisioning

At boot, an enclave creates a temporary key pair, obtains a signed attestation document from the Nitro hypervisor that includes its image measurement (PCR0), and asks AWS KMS to decrypt its secrets for that attested recipient. The KMS key policy allows decryption only when the attested measurement equals the released image's, and explicitly denies decryption to everyone else, including cloud administrators and the account root. The host relays the encrypted exchange but can't read it. The enclave then checks the decrypted secrets against its built-in anchors and refuses anything that doesn't match.

3.5 Reproducible releases

Enclave images are built with pinned toolchains so that an independent rebuild from the same source produces the same measurement. A release publishes the image, its measurements and the source revision. The enclave host refuses to start an image whose measurement differs from the expected value.

4. Authenticating requests

Webhooks to customers are signed twice: HMAC-SHA256 with a per-endpoint secret, and Ed25519 with a per-workspace key whose public half customers can check without storing a secret.

5. Authorizing a transfer

A payout passes through two layers of control.

5.1 The customer's controls

Each workspace sets its own rules: expressions over the request (value in USD, destination saved or not, wallet type, outflow in the last hour or day, who asked, day and hour) with an effect of block, require approval from a group, or skip approval. A group's approvals are passkey-confirmed. Rules are evaluated when the transfer is requested, at each approval, and again immediately before signing, so a rule change or a velocity limit reached in the meantime still applies. Changing the rules themselves needs the approval of the workspace's default group.

5.2 The enclave's controls

Inside the enclave, the organization's policies decide which signers may use which wallets. For customer workspaces, the policy allows the workspace's service identity to sign transactions for that workspace's wallets only: it can't sign for another workspace's keys, and it can't change the organization's users or policies. Every signature request is decoded by the enclave's parsers, so the transaction that is signed is the one that was evaluated.

5.3 From request to chain

1. The request is authenticated, validated (address format, coin minimum, available balance, network fee) and checked against the customer's rules.
2. Approvals are collected if required.
3. The transaction is built with a reserved nonce (or chosen coins, on Bitcoin) and checked against the wallet's balance and the exact fee.
4. The enclave verifies, evaluates and signs.
5. The coordinator broadcasts to a healthy node, bumps fees if the transaction is slow (EVM), and tracks it to the network's confirmation depth.

6. Deposits and the chain

Each network is watched by an indexer that follows the chain head with a per-network confirmation depth. A deposit is reported as pending when seen and confirmed after that depth. If a chain reorganization removes a block, deposits in it are marked orphaned and customers are told. Networks are served by several nodes; the system picks the healthiest by priority and lag, and fails over when one stops responding. A node's network identity (genesis or chain id) is checked before it is used, so a misconfigured node can't feed data from the wrong network.

7. Data protection

• Key material: sealed to the enclave quorum key (section 3.2).
• Workspace service keys (the enclave identities used to request signatures): encrypted at rest with AES-256-GCM under a key-encryption key held in the cloud secret store, with the workspace bound as associated data.
• Organization state: signed by the notarizer, so tampering in the database is detected.
• In transit: TLS to clients and to the database (certificate verified); enclave traffic over vsock.
• Outbound webhooks: sent only to public HTTPS addresses; private and internal addresses are refused to prevent server-side request forgery.
• Audit: an append-only log of operator and customer actions, with actor, key and source address.

8. Operations

Infrastructure is defined in code. Hosts run without SSH and are reached only through the cloud provider's audited session manager. The enclave host is allowed to reach only the key service. Metrics cover indexer lag, node health, job health and API errors, with alerts to the on-call channel. Adding a chain, node or coin, pausing or retiring a network, and changing operator access are maker-checker actions in the operations console, and customers get advance notice and webhooks when a network or coin is being retired.

9. Threat model

10. Current status and limitations

Valtu Wallet runs on mainnet in a limited release. The following are known and being addressed. Customers should size their exposure accordingly.

• Customer approvals are enforced by the coordinator, not inside the enclave. The enclave limits each workspace's signing identity to that workspace's wallets, but the approval rules and passkey confirmations are checked outside it. Until approvals are verified inside the enclave, the security of customer approvals depends on the coordinator and its operators. This is the most important item on the roadmap.
• Root authority. Each workspace's enclave organization has Valtu custody officers as its root quorum, used to activate workspaces and upgrade their signing rules. This is a custodial service: Valtu operates the keys on the customer's behalf.
• No external audit yet. The enclave applications, the coordinator and the deployment have not been reviewed by an independent security firm. An audit is required before the service holds significant customer funds.
• Single enclave host. Production currently runs one combined enclave host. The design supports one host per role across availability zones; capacity is being added.
• Rollback window. Someone with direct database administrator access could roll an organization's signed state back to an earlier signed version within a 24-hour window. The fix is a monotonic counter or an append-only signed log.
• Operator keys. Operator console keys are non-extractable browser keys, not hardware-backed; key holders' backup shares are files rather than hardware tokens.
• KMS key administration. Account-level guardrails (service control policies, multi-person approval and alerting on key-policy changes) are needed so that no single cloud administrator can change who may decrypt.
• Indexing gaps. Value moved by contract-internal calls on EVM networks is not detected without a tracing node.

11. Roadmap

1. Enclave-verified approvals: customer team members' passkey signatures checked by the policy engine, with the workspace's approval rules compiled into enclave policy, so that neither a compromised coordinator nor Valtu staff can move customer funds without the customer's quorum.
2. External security audit of enclave code, coordinator and infrastructure, with the report summary published.
3. High-availability enclaves: one host per role in at least two availability zones.
4. Hardware-backed operator keys (passkeys or security keys) and hardware tokens for key holders.
5. Monotonic state to close the rollback window, and daily spending caps enforced in the enclave.
6. Remote attestation for customers: a public endpoint that returns the enclave's attestation document, so customers can verify the running code themselves.
7. SOC 2 controls and report.

Glossary