FHESTATE

FHESTATE is live. Confidential state execution for public blockchains using fully homomorphic encryption. Encrypted state persists. Computation runs on ciphertext. No plaintext during execution. Everything is public: Website → fhestate.org/ Docs → docs.fhestate.org Roadmap → fhestate.org/roadmap GitHub → github.com/fhestate Building encrypted state as infrastructure.

FHESTATE // Governor Confidential governance is now entering the agent runtime. We’ve added Governor, the fifth confidential agent in FHESTATE, built specifically for Dark DAO governance on Solana Devnet. Governor handles a simple but important flow: CAST BALLOT → REQUEST TALLY A YES/NO vote becomes an encrypted step in Governor’s isolated hash chain. The tally cannot be requested until the ballot step exists. No ballot. No tally. Governor never decrypts individual votes, never stores plaintext ballots, and does not modify the underlying on-chain tally logic. It operates under the same manifest contract as the rest of the fleet, with explicit missions, prerequisites, and isolated memory. Sentinel · Auditor · Coordinator · Treasurer · Governor Five specialized agents. One consistent confidential execution layer. Building FHESTATE.

FHESTATE adds its fourth confidential agent: Treasurer. As confidential applications start handling more treasury logic, one problem becomes important: How do you enforce spending policy without giving an agent the power to move funds? That is the role of Treasurer. Treasurer is designed as a treasury guard, not a wallet operator. A simple flow: Shield Intent → Spend Check The agent can record a spend intent and verify it against its declared policy, but it cannot transfer lamports, unshield assets, or execute a TEE transfer. Daily spending caps are validated at the SDK layer, while mission prerequisites are enforced by the runtime. No plaintext amounts enter agent memory. Only hashes, URIs and mission IDs move through the execution flow. Treasurer now joins: Sentinel · Auditor · Coordinator · Treasurer Four confidential agents. One consistent policy framework. Building the boundaries before giving agents more power. $FHESTATE

This is exactly the direction we’re building for. Confidential execution shouldn’t be an afterthought on Solana, it should be part of the base financial stack. Faster execution + scalable privacy + confidential DeFi is a powerful combination. We’re building toward it with FHESTATE. 🟢

Phase 6 // MCP Runtime Integration The Agent Manifest already existed in the FHESTATE SDK. The next problem was making it work outside the SDK itself. Our MCP server was running an older package, and every tool call started with a fresh memory state. That meant a real workflow like: Compliance Scan → Seal Record couldn't work reliably. The scan would disappear before the next call. We fixed both pieces. MCP now uses the same manifest catalog as the SDK, including: • Schema 1.0.0 • Sentinel, Auditor & Coordinator • Mission prerequisites • Agent dependencies • Policy validation We also added session-level memory inside the MCP process. Now an agent maintains its own hash chain across a session. So the workflow becomes: Auditor: Scan → Seal Record ✅ Coordinator: Route Intent before Sentinel ❌ Sentinel → Route Intent ✅ Invalid agents, out-of-range values, and skipped prerequisites return the manifest error cleanly instead of crashing the server. And the output remains what we want from a confidential runtime: Hashes. URIs. Mission IDs. Not plaintext state. This means the same policy layer can now move from the TypeScript SDK into an actual MCP workflow. The runtime is starting to behave like one system—not a collection of disconnected components. Building FHESTATE.

FHE + blockchain = 1,000,000x overhead. We read that as a design constraint. So we started building it anyway. Now we’re here. $FHESTATE

Phase 6 // Manifest Enforcement We introduced the FHESTATE Agent Manifest. Now we're taking it one step further: the manifest is locked into the TypeScript SDK and enforced by the runtime. A confidential agent is no longer just a name or configuration. One manifest defines its: • Identity & Solana cluster • Allowed FHE operations • Maximum daily spend • Required keys • Missions • MRENCLAVE requirements The SDK rejects invalid schemas, unknown fields, illegal operations, and malformed measurements before the first blind step executes. Then the runtime enforces those rules at every step. For example: Auditor → Seal Record Cannot execute unless Compliance Scan already exists in encrypted memory. Coordinator → Route Intent Cannot execute unless the required Sentinel step has already been committed. Market Signal Can execute on an empty chain when its mission permits it. Sentinel, Auditor, and Coordinator now use the same manifest contract. So a third-party developer can define an agent once, validate it through fhestate-sdk, and enter the same policy-enforced execution pipeline as the native fleet. The agent sees encrypted state. The runtime sees the policy. Nothing executes outside the declared boundaries. This is Phase 6 being built from the inside out. Building FHESTATE. $FHESTATE

Phase 6 // Introducing the Agent Manifest One of the first things we're building for Phase 6 is a standardized way for confidential agents to declare exactly what they're allowed to do. Introducing the FHESTATE Agent Manifest. Before an agent can interact with confidential state, it will carry an explicit policy describing its execution boundaries. For example, a DAO Governance Agent might be allowed to: submit_dao_vote() check_spending() read_proposal_state() But not: vault_withdraw() vault_shielded_swap() The manifest can also define: • FHE tool permissions • Daily spending limits • Required prerequisite keys / state • Execution constraints The important part is that these aren't just instructions for the developer to follow. The manifest becomes a machine-readable policy surface that the SDK can validate before the agent is allowed to execute. That gives us a much cleaner model for third-party confidential agents: Declare → Validate → Attest → Execute We're building the foundation for agents that aren't simply autonomous, but policy-bound and verifiable by design. Phase 6 is starting to take shape. $FHESTATE

Building confidential agents shouldn't require confidential hardware. Today, developing confidential applications often means waiting for access to Intel SGX, AMD SEV, or cloud enclaves just to test a single workflow. We're changing that. Introducing the FHESTATE Confidential Agent Sandbox (Coming in Phase 6). Think of it as With the sandbox, developers will be able to: 🛠️ Build and test confidential agents locally. 🔐 Simulate encrypted execution and memory chains. ✅ Dry-run spending guards and policy validation. 🛡️ Verify attestation flows before deployment. 🚀 Move from local development to production enclaves with the same execution model. No specialized hardware. No cloud enclave required during development. Just build, iterate, and deploy with confidence. The goal is simple: Make building confidential applications as seamless as building traditional software—without compromising verifiability or privacy. Coming in Phase 6. Building FHESTATE.

Dev Session // Build Log The most important engineering work often happens before execution even begins. Today's focus was on making objective processing more secure, predictable, and resilient against invalid inputs. Here's what changed: 🛡️ Description Sanitization If someone creates an objective with unexpected HTML or JavaScript in the description, it is now sanitized before being stored or rendered, reducing the risk of basic XSS attacks. Example: "<script>alert('test')</script>" becomes safe, sanitized content instead of executable code. 🆔 Objective ID Validation Every objective request is now validated before reaching the execution pipeline. Malformed or unknown IDs are rejected early instead of creating inconsistent state or unnecessary processing. 🎯 Target Symbol Validation Objectives must now reference supported assets. For example: ✅ BTC ✅ SOL ✅ USDC ❌ Random or invalid symbols This prevents invalid objectives from being created before execution even starts. ⚙️ Shared Processing Utilities Refactored common objective logic into reusable helper utilities, ensuring objective creation, updates, and execution all follow the same validation and processing flow. These aren't flashy features. They're the engineering improvements that make the runtime more secure, more reliable, and easier to scale as the platform grows. Building FHESTATE. $FHESTATE

A major milestone in the FHESTATE journey. Today, we're unveiling the first complete walkthrough of the FHESTATE Portal our privacy-first interface for confidential finance on Solana. This walkthrough brings together months of engineering into one seamless experience: 🔐 Connect & Encrypt Generate encryption keys locally in your browser. 👛 Dual Portfolio View and manage both public and shielded assets. 🏦 Confidential Vaults Shield assets and control them through encrypted state. 🔄 Private DeFi Execute confidential swaps and automate recurring DCA strategies. 🗳️ Confidential Governance Participate in DAO voting without revealing individual ballots. 💸 Private Payments Create payment links, QR codes, and batch transfers with privacy by default. 🤖 AI Copilot Manage your confidential wallet through natural language. This is more than a wallet. It's the first step toward a confidential execution layer where users, developers, and autonomous systems can securely interact with on-chain assets without exposing sensitive financial information. As we prepare for Phase 6, this walkthrough marks another major milestone in bringing the FHESTATE vision to life. Watch the full walkthrough below. Building FHESTATE. $FHESTATE

The next phase of FHESTATE is about opening confidential execution to every developer on Solana. Until now, confidential execution has been limited to native FHESTATE components. With Phase 6, developers will be able to build their own confidential autonomous agents that execute on encrypted state inside Trusted Execution Environments while leveraging Fully Homomorphic Encryption for privacy-preserving computation. Imagine building: • A DAO Governance Agent that can submit encrypted votes. • A Treasury Manager that verifies spending policies before approving confidential payments. • A Compliance Auditor that scans encrypted transactions without exposing underlying data. • A Multi-Party Settlement Router coordinating private execution across multiple participants. To support this, we've finalized the technical specification for the Phase 6 Third-Party Agent SDK and Onboarding Protocol. This introduces the core developer infrastructure required to safely open the confidential runtime: • Standardized Agent Manifest contracts defining immutable execution permissions. • Local execution simulators for developing and testing confidential agents without requiring Intel SGX or AMD SEV hardware. • Hardware attestation and MRENCLAVE registration to cryptographically verify every production agent before it can interact with confidential state. Opening confidential execution isn't simply about allowing anyone to deploy code. It's about ensuring every agent is verifiable, permissioned, and cryptographically trusted before it becomes part of the network. This is the first step toward an ecosystem where developers can build verifiable confidential applications on top of FHESTATE. Over the coming days, we'll be diving deeper into each component of the Phase 6 architecture. Building FHESTATE.

We've been quieter than usual after our X account was flagged. We've appealed it, received clarity, and are ready to get back to building in public. Behind the scenes, we've continued making steady progress on the foundations of Phase 6 from secure enclave attestation and third-party agent onboarding to permissioned execution and developer tooling. Over the next few days, we'll be sharing these engineering updates one at a time as we move toward the next phase. $FHESTATE

FHESTATE Build Session Continuing work on the confidential policy runtime. Today we expanded the provisioning flow that securely prepares policies before they're ever executed inside a trusted environment. Current progress includes: ▸ Trusted enclave registration ▸ Confidential policy provisioning ▸ Homomorphic policy material preparation ▸ Cryptographic commitment generation ▸ Authenticated governance state updates The goal isn't simply to execute encrypted policies. It's to ensure only trusted runtimes receive the correct policy material, every update is cryptographically verifiable, and governance remains the source of truth throughout the lifecycle. There's still more work ahead, but each iteration moves the policy engine closer to a production-ready confidential runtime. Today's build session attached. $FHESTATE Private by default.

Under the Hood // Confidential DAO Tallying A confidential DAO can't decrypt every ballot just to count votes. That would defeat the purpose of private governance. Over the past few days, we've been implementing the dao-tally-vote pipeline inside the FHESTATE runtime. The architecture works like this: • Every YES or NO vote is encrypted locally inside the browser using WASM. • The runtime performs homomorphic addition directly over ciphertexts, updating the encrypted tally without ever revealing an individual ballot. Enc(TallyNew) = Enc(TallyOld) + Enc(Vote) • Throughout the voting period, the network only stores and updates the encrypted tally. No validator, executor, or observer can determine: 💠who voted, 💠how they voted, 💠or the current vote distribution. Only after the proposal closes is the final aggregated tally decrypted inside an attested execution environment. The outcome becomes public. Individual ballots never do. Confidential governance isn't just about hiding votes. It's about designing an execution pipeline that never requires revealing them in the first place. Building Consistently. $FHESTATE

Under the Hood // Private Claims Privacy isn't just about hiding transactions. It's about making sure they can only be claimed once and only by the intended recipient. Imagine Alice wants to privately send 100 USDC to Bob. On a traditional blockchain, everyone can see: Who sent it Who received it How much was transferred With FHESTATE, none of that is public. Instead, here's what happens. 1. Private Commitments Alice creates a cryptographic commitment on-chain instead of publishing Bob's wallet or the transfer amount. Only Bob can discover the pending transfer using his private view key. To everyone else, it's just an unreadable commitment. 2. Replay & Double-Spend Protection Bob claims the transfer. The runtime settles the commitment and permanently marks it as claimed. Now imagine someone tries to replay the exact same transaction. Instead of processing it again, the runtime immediately responds: alreadyClaimed = true No duplicate settlement. No balance mutation. No double spend. 3. Recipient Verification Now imagine Charlie copies the commitment and tries to claim Alice's transfer. Before any state changes occur, the runtime verifies cryptographic ownership. Charlie fails verification. Execution stops with a: WRONG_RECIPIENT assertion. The transfer never leaves the vault. The result: ✔ Alice's transfer remains private. ✔ Only Bob can discover and claim it. ✔ Replay attacks fail. ✔ Double-spend attempts are rejected. ✔ Unauthorized wallets can never extract the funds. Confidential payments shouldn't just hide information. They should guarantee that the right recipient gets paid exactly once. Building $FHESTATE.

Every public swap broadcasts your trading strategy before it executes. Suppose you want to swap 100 SOL → USDC. The moment your transaction enters the mempool, anyone can see: • Your wallet • Your trade size • Your target liquidity pool • Your execution timing That's enough information for MEV searchers. They can front-run your transaction by buying before you, pushing the price higher. They can sandwich your trade by buying before it and selling immediately after, extracting value directly from your execution. The result? Higher slippage. Worse execution. Lower returns. FHESTATE changes the execution model. 1. Shielded Vault Assets are deposited into a confidential vault where balances become encrypted and individual holdings are no longer publicly visible. 2. Encrypted Trading Rules Swap amounts, DCA schedules, allocation targets, and execution parameters are encrypted locally and stored as confidential commitments. 3. Blind Swap Execution When it's time to execute, the FHESTATE runtime interacts with public AMMs on behalf of the vault. The swap settles publicly. The trading intent does not. 4. Confidential State Updates Resulting balances are updated homomorphically inside the vault without exposing wallet balances, strategy changes, or portfolio allocations. To the outside world... They only see the vault interacting with liquidity. They don't see: ✕ Who initiated the trade ✕ How much they're buying ✕ Their DCA schedule ✕ Their portfolio allocation ✕ Their updated balances No visible trading intent. No opportunity to target individual users. Public settlement. Confidential execution. That's the future of on-chain trading. Building $FHESTATE.

Dev Session // Build Log One of the biggest challenges in bringing Fully Homomorphic Encryption to Solana isn't computation. It's transaction size. Every Solana transaction is limited to 1232 bytes, while FHE ciphertexts are often orders of magnitude larger. Embedding encrypted payloads directly into instructions simply doesn't scale. Today's work focused on solving that bottleneck. Instead of coupling encrypted data with transaction execution, FHESTATE separates the two. Architecture • FHE ciphertexts are stored outside the transaction path and referenced through a content-addressable identifier. • On-chain instructions carry only a compact SHA-256 commitment and a retrieval reference, keeping every transaction lightweight and deterministic. • During execution, the runtime resolves the encrypted payload and dynamically dispatches computation through: Coordinator-backed FHE execution for homomorphic operations. SPL Memo transport for lightweight and compatibility workflows. Why this matters 🔷Separating ciphertext persistence from transaction execution allows confidential computation to scale without being constrained by transaction size. 🔷The blockchain verifies and settles the state transition. 🔷The runtime performs the confidential computation. This architecture keeps transaction overhead low while preserving cryptographic integrity and enabling large encrypted workloads to execute efficiently. Another step toward building the confidential runtime. Building $FHESTATE.

FHESTATE Dev Diary // Week 30 Every week changes the way we think about confidential infrastructure. Some ideas become features. Some features become architecture. This week was a bit of both. Alongside our daily live build sessions, we continued the Internet Stack series—breaking down the building blocks behind confidential applications, from Shielded Vaults and the Confidential Financial Layer to how these pieces fit into the future of on-chain systems. On the engineering side, every stream pushed the runtime a little further. ▸ Threshold Decryption & Quorum Validation ▸ Distributed Ciphertext Reconstruction ▸ Runtime-Selectable TFHE Parameters ▸ Hierarchical Key Management ▸ Deterministic Cryptographic State ▸ Homomorphic Performance Benchmarking ▸ Parallel Runtime Execution One thing we've learned while building FHESTATE is that confidential computing isn't just about encryption. It's about making encrypted systems predictable, verifiable, recoverable, and fast enough for developers to actually build on. That's where most of our time went this week. Not polishing interfaces. Not chasing hype. Just solving the engineering problems that sit underneath confidential applications. We'll keep shipping. See you in Week 31. $FHESTATE Private by default.

FHESTATE Dev Session // Build Log Every confidential transaction needs more than encryption. It needs a trusted way to evolve state without breaking consistency or exposing sensitive information. Today's work focused on that foundation. Implemented a cryptographically versioned state transition engine that advances application state through policy-driven execution while maintaining verifiable integrity across every update. This introduces: • Versioned state snapshots • Atomic homomorphic updates • Monotonic version synchronization • Merkle-based state commitments • Policy-aware audit reports • Persistent execution history What this means: Every successful operation now creates a new cryptographically committed state version. Each version is linked to the previous one, producing a complete execution chain that can be verified without revealing the underlying data. This architecture helps eliminate conflicting updates, preserves execution order, and strengthens auditability while keeping application data confidential throughout the execution lifecycle. Another building block toward a production-ready confidential runtime. $FHESTATE.