Verifiable Foundations

The foundation of 0xkey is a separation between software that can be hardened in the usual way and software that must be verifiable. Edge services, databases, queues, caches, and dashboards can fail or be compromised without gaining direct access to private key material. The trusted computing base is reserved for code that authenticates requests, authorizes activities, protects state integrity, processes sensitive credentials, and produces signatures.

That trusted base is built around AWS Nitro Enclaves and QuorumOS concepts: isolated execution, no direct network, no persistent disk, hardware-signed attestation, operator-approved manifests, quorum key material, and reproducible build paths that connect source code to running artifacts.

A Trusted Execution Environment gives sensitive code a smaller and better-defined world. In the Nitro model, an enclave is created by a host machine but runs as a separate virtual machine. It has isolated CPU and memory resources, communicates through a virtual socket, and relies on the Nitro Security Module for hardware-backed entropy, time, and attestation.

The important property is not that the surrounding system disappears. The host, gateway, orchestration layer, and database still exist. The property is that the enclave can be treated as the place where sensitive decisions become cryptographic evidence. If a request is altered in transit, the stamp no longer verifies. If state is rolled back, the notarization chain no longer matches. If a ruling is forged, downstream enclaves reject it.

QuorumOS provides the boot and provisioning discipline for running application code inside enclaves. It connects a measured runtime, a manifest that describes what should run, and quorum-controlled key material that is only released when the enclave proves the expected identity.

This design moves trust away from an individual machine or operator. A running application should be accepted because its measurement, manifest, and quorum approval line up, not because it sits behind a familiar URL or was deployed by a trusted person.

Attestation is strongest when a verifier can connect a measurement back to human-reviewable source code. Reproducible builds give independent parties a way to compile the same source tree and arrive at the same artifact digest. That digest can then be compared with the measurement reported by the enclave.

The point is not to claim that every user will reproduce every build. The point is to make verification possible for auditors, operators, customers, and ecosystem participants who need stronger assurance than a private compliance report can provide.

Many wallet workflows require more than signing a public transaction. Importing a private key, exporting a recovery bundle, exchanging an OAuth code, or verifying an OTP can involve secrets that should not be visible to an ordinary server. 0xkey models these interactions as endpoint-to-enclave secure channels.

The surrounding application can carry ciphertext, metadata, and signed results, but it should not need plaintext access. This pattern is especially important for embedded wallets and agent workflows, where user experience often depends on web-native authentication while security depends on keeping the credential exchange inside the trusted boundary.

0xkey treats signed evidence as an interface between components. Attestations describe what is running. Rulings describe authorization decisions. Notarizations describe state integrity. Fetch proofs describe externally fetched data. Signature results describe the output of key usage. Each proof narrows what the next component has to trust.