.png)
TVC Verifiable State will be ready for Alpha development partners starting November 13, 2026. Alpha access is subject to breaking changes and we anticipate a stable Beta in January 2027.
A Trusted Execution Environment, or TEE, is a protected computing environment designed to isolate an application’s code and in-memory data from the machine’s operator. But an application rarely runs only once. It needs to save data, restart, and continue from where it left off.
That creates a gap: the application may execute inside a TEE, while its disk remains under the control of the host. The TEE can be verifiable. The host’s disk is not.
TVC Verifiable State exposes a persistent filesystem for applications running in TEEs. It gives the application a disk whose reads and writes are verified, while allowing it to use standard Linux filesystems and software. The host stores the data, but cannot change it or roll it back without detection.
Turnkey’s enclave stack
Turnkey Verifiable Cloud (TVC) lets customers run their own code and binaries on the same verifiable enclave infrastructure that powers Turnkey’s wallet platform. Anyone can check that the enclave is running verified code.
The security model assumes that everything outside the enclave may be hostile. That includes the host, which controls the machine, disks, and network, as well as insiders, including Turnkey. Turnkey cannot access customer keys, and rollback attacks are prevented cryptographically.
Historically, the TEE security boundary covered the processor and memory, leaving every application to build its own solution for persistent, encrypted, rollback-protected storage. Each one could get it wrong, and most weren’t performant. TVC Verifiable State adds a persistent filesystem for those applications: a storage area the application can use to read and write files, with data that survives restarts and upgrades.
Why persistent state needs protection
A disk can be encrypted and still be vulnerable to rollback. Many TEEs today use a LUKS-encrypted disk, which keeps data private but does not prove that the application is looking at the newest version. An operator could present an older copy of the data instead.
That can change what the application decides. If an AI agent has already spent its full $100 limit, an insider could restore yesterday’s disk and let the agent spend the $100 again. If a service checks whether an API key has been revoked, stale data could make a revoked key appear valid. If a wallet application tracks balances, stale data could make it credit a balance that no longer exists.
Verifiable State is designed to prevent this. The application sees its latest data. Each read is verified inside the enclave. If the application detects tampering, it fails closed: it stops rather than continuing with data it cannot trust.
How Verifiable State fits into Turnkey Verifiable Cloud (TVC)
TVC provides the environment for running applications inside TEEs. Verifiable State gives those applications a way to keep data between runs, so they can use persistent databases, files, and records rather than relying only on data held in memory.
The feature also works alongside QuorumOS, which governs code upgrades and core secrets through a quorum. Together, QuorumOS’s quorum governance and Verifiable State’s protected storage make it easier to build private, non-custodial TEE applications using Web2 technologies like PostgreSQL or SQLite. Data can be encrypted inside the enclave to the Quorum Key, so nothing outside the enclave can read it, and any attempt to modify or roll it back is detected.
Verifiable State capabilities
Applications using Verifiable State get:
- Persistent disks: A mounted filesystem whose data survives restarts and upgrades.
- Integrity checks: Every read is verified inside the enclave. Tampered state is detected, and the application fails closed.
- Rollback protection: The application sees its latest data. An operator cannot present older data.
- Non-custodial encryption: Data can be encrypted inside the enclave to the Quorum Key, proving that nothing outside the enclave can read or write to state.
- Standard software: Existing databases and file-based software can run on the filesystem.
- Automated failover: If an enclave stops, another enclave can continue from the latest data.
- Multiple stateful enclaves: An application can run several enclaves, each with its own disks.
- Backups and restore: Long-term backups can be kept in separate storage, with the ability to restore from them.
What developers can build
Verifiable State is useful wherever applications need durable data that remains trustworthy.
Databases and agent memory
Applications can run PostgreSQL, SQLite, and similar databases inside enclaves. AI agent systems can keep vector databases, embeddings, and documents as persistent memory.
A verifiable agent harness can also keep its memory, tool state, and logs with integrity.
Wallets, policies, and accounting
Wallet applications can maintain balances, budgets, nonces, and policy state that must not roll back. Applications can store sensitive policies so they cannot be rolled back or otherwise modified in an unauthorized way. These capabilities support decisions that depend on up-to-date state, such as whether a transaction fits within a budget or whether a policy is still current.
Counters, limits, and audit logs
Rate limits, usage quotas, and sequence numbers depend on counters that stay current. Verifiable State can provide persistent storage for that state. It can also support audit logs that cannot be altered or rolled back without detection.
Privacy protocols and private transactions
Developers can use Verifiable State to build privacy protocols, private transfers, and confidential ledgers. By keeping sensitive state inside verifiable enclaves, applications can protect transaction data while maintaining verifiable execution and supporting compliance requirements.
Building beyond computation
Turnkey Verifiable Cloud lets customers run code inside verifiable enclaves. Verifiable State extends that foundation with persistent storage. Combined with QuorumOS’s quorum governance of code upgrades and core secrets, it enables applications to maintain private, durable state without compromising verifiability.
Alpha opens to development partners on November 13, 2026.
.png)
.png)