As we enter 2026, Secret Network continues to be a leader in the confidential computing space.
This is our regular 6-month roadmap update, covering achievements from the second half of 2025 and our development priorities for 2026. The past six months tested our network's resilience and demonstrated the strength of our community. The TEE industry faced significant security challenges with the wiretap.fail, tee.fail, and Battering Ram exploits published by research teams. 

Secret Network responded swiftly with changing the network model to semi-permissioned, and we will continue to improve the security of the chain in 2026, as seen below.

Our roadmap is divided into two main streams: Secret Network and SecretAI/SecretVM.

Strategic Focus

Our strategic focus continues to be dual - improving the Secret Network infrastructure and also heavily investing in the SecretAI/SecretVM expansion.

The two streams are tied together along several points - both technologically and economically, and their development is going in parallel.

Secret Network Roadmap

What was achieved in 2025

First, let’s review what was achieved in Secret Network development in the second part of 2025, compared to the planned roadmap:

In the second half of the year, we primarily worked on the following items:

On-Demand Seed Rotation

On-demand network seed rotation was successfully implemented in v1.21.6. Now, any network upgrade can include optional rotation of the network seed. 

One of the challenges with this feature is that the Enclave must be able to also decrypt older data encrypted with previous seeds, and we had to implement it in an efficient and secure way.

Obviously, any functionality related to the network seed and enclave identity is very high risk and requires lots of rigorous testing and evaluation. 

Governance-based Contract Migration

An important step toward decentralization,  Governance-based Contract Migration was implemented in v1.21.6. Now, developers get an opportunity to deploy their contracts in such a way, that any upgrade requires a governance vote. 

SCRT Labs moved all the SNIP contracts that were previously under our control to such governance-based migration.

Wiretap.fail Mitigations

In late September, Wiretap.fail exploit was published.The exploit essentially allows an attacker with physical access to a machine running 3rd Generation Intel Scalable CPU to forge any attestation, leading to an ability to access the network seed. A follow-up tee.fail exploit expanded the vulnerability to 4th and later generations of Intel Scalable CPUs.

As an immediate mitigation strategy, the network was changed to a fully permissioned mode in release v1.22. 

In release 1.23, the fully permissioned mode was relaxed to semi-permissioned, allowing new validator nodes to be added through governance. Also, any Microsoft Azure nodes can be added to the network without limitation.

More work in this area is planned for 2026, including integration with ProofOfCloud

Additional Modules

CRON module was integrated in 1.22, but will be fully enabled in Q1 2026.

Additional modules like Gas Lanes, Fee Market and Fee Abstractions were integrated, but it turned out that those modules are not supported anymore by the original teams, and we decided to forego them for the time being.

Gramine and EVM

After evaluating the tradeoffs, we decided to pause both Gramine migration and EVM compatibility. While prototypes were explored, the cost-to-benefit ratio did not justify continued investment at this stage.

Plan for 2026

In 2026, we will continue strengthening the security and scalability of the network.

The following main development vectors are planned, as shown on the diagram below:

• Network Security

• Scalability

• Decentralization

Each of the items is discussed below.

Deprecation of EOL CPUs

We will release version 1.24 that was originally planned for December 2025 by mid Q1 2026. That version will include blocking of EOL machines (Xeon E-22xx), as well as other older platforms.

Integrating Proof of Cloud and other proof-of-location methods

As the Proof of Cloud initiative matures, we will consider requiring Proof of Cloud verification for Intel Xeon Scalable machines joining the network. That will ensure that those machines are located in secure data centers and that the physical access is effectively prevented. 

As Intel’s recent Platform Ownership Endorsements starts seein some adoption on by cloud service providers, we will be integrating it to Secret Network as well, allowing machines with such Endorsement to join Secret Network without restrictions.

MPC for Network Seed

We are also considering developing an MPC scheme whereby Secret Network nodes will not store the full network seed in their sealed files, but rather parts of it. 

The goal is to significantly raise the bar for attacks targeting sealed storage.

It should be noted that this solution does not provide full  protection from physical attacks described in Wiretap.fail/tee.fail.

SGX Decoupling

SGX decoupling is a big topic for Secret Network development in 2026. Essentially, it will allow running Secret Network nodes, and later on - validator nodes, without having to use SGX-enabled hardware.

SGX decoupling reduces hardware constraints and improves network accessibility.

In this setup, the network will have two types of nodes - SGX nodes and non-SGX nodes.

SGX nodes will execute the encrypted transactions normally, and store all the side effects (i.e. change to the network state and in the encrypted storage) in a local database. 

Non-SGX nodes will be able to download those changes and “replay” it locally, reaching the same state of the network.

Naturally, non-SGX nodes won’t be able to decrypt the encrypted network state (an SGX enclave which they don’t have is required for that).

At the first stage, the non-SGX nodes will not be able to validate the network, but rather serve as RPC nodes. This may be most useful for centralized exchanges who essentially only care about the non-encrypted state of the network, such as SCRT transfers, governance voting, etc.

At the second stage, we will consider allowing the use of non-SGX nodes as network validators.

This will require changes in tokenomics, so that a certain percentage  of the inflation is designated for non-SGX validators. Any transition to non-SGX validators and tokenomics changes would require explicit community approval.

Additional Decentralization Features

In release 1.24, we will be removing the MRSIGNER restriction in the network enclave code, effectively allowing 3rd party developers to build their versions of the enclave without involvement of SCRT Labs.

After passing to MRENCLAVE, the MRSIGNER requirement served more as a limiting factor rather than a security measure, and thus we will be dropping it as redundant and unnecessarily centralizing.

We will also move all the SNIP contracts that are currently controlled by SCRT Labs to community governance. That means that any future code migration for those contracts will require a governance approval.

SecretAI/SecretVM Roadmap

During 2025, we built out a full suite of Confidential AI and Confidential VM services, complete with billing, Key Management System, and advanced features like Verifiable Message Signing, posting attestations on 3rd party chains like zkVerify and Automata, multiple AI models, and more.

Currently, our SecretAI and SecretVM suite is ready for prime time. Our focus in 2026 shifts from feature completeness to adoption, scale, and ecosystem growth. We will be actively seeking customers and partners for SecretAI and SecretVM, seeking out the use cases that provide most value.

As always, our roadmap will be fluid - some features may be cancelled or delayed, while others will be prioritized based on market demand.

In 2026, we will continue the drive along several key vectors:

• Infrastructure

• AI 

• Interoperability

• Economics

Each of the items will be covered in its respective section below.

SecretAI/SecretVM Infrastructure

AMD Support

In 2025, we started working on AMD SEV-SNP support, and we are planning to release full support of AMD-SEV-SNP to work along our original Intel TDX support.

In Q1, we will roll out the AMD support for CPU-only nodes, and in Q2 we will expand 

support to GPU instances running on AMD CPUs

AMD support reduces vendor lock-in, improves price/performance, and enables broader cloud availability.

SecretVM 2.0

SecretVM 2.0 is an evolution of the original SecretVM design. Driven by the primary goals of improving security, easing maintainability, and refactoring the core design, v2.0 will introduce a new architecture aimed at hardening the system against attacks and making it more flexible and easier to manage and maintain.

Templates

We will introduce standardized SecretVM templates to simplify deployment of popular services to ensure best practices, and reduce configuration errors for common workloads.

Multi-Cloud support

In 2026, we plan to add support for running SecretVM instances on major clouds, such as Azure (Intel and AMD), Google Cloud Platform (Intel and AMD), AWS (Currently AMD only) and potentially more. 

This will allow our customers to combine the power and flexibility of SecretVM with ubiquity, reliability and other features of major cloud providers. 

SecretVM Clusters

In Q2-Q3, we will be introducing SecretVM Clusters, i.e. the ability to run several copies of SecretVMs in parallel in different geographical locations for maximum availability and resilience. This will allow running critical production workloads with high availability, geographic redundancy, and attested failover.

Bring Your Own Hardware

The BYOH concept will allow users and partners to bring their own hardware, install SecretVM infrastructure on it and offer confidential computers either to their organization or to 3rd party users. 

BYOH directly enables decentralized supply and future revenue-sharing models., 

On the other hand, BYOH can help enterprises to run confidential workloads on their own hardware.

BYOH will be introduced in Q4, initially with specific partners.

Kubernetes Support

Kubernetes is the de-facto orchestration standard for modern infrastructure. Running confidential and verifiable workloads on Kubernetes enables cloud-native deployment, autoscaling, CI/CD integration, and standardized operations without sacrificing trust guarantees. We currently plan to start working on Kubernetes in Q4.

SecretAI 

In 2026, we plan to take SecretAI to the next level by offering the following features:

• Verifiable Message Signing -  allowing the user to cryptographically sign any response from an LLM and later prove its origin

• Confidential RAG - an ability to feed the model with confidential information in order to make inference using proprietary data. Confidential RAG ensures that embeddings, prompts, vector stores, and intermediate context remain confidential.

• Confidential Fine-Tuning - creating fine-tuned models based on confidential data. This can be especially useful for enterprises that are reluctant to share their private information with major players such as OpenAI, Google, etc.

Confidential RAG and Confidential Fine-tuning will make it possible for organizations to create highly specialized AI models based on confidential data, and then run inference on that data 

Interoperability

In continuation of the work started in late 2025, we will be developing interoperability with dstack, as well as integration with Proof of Cloud.

In late 2025, we started working on dstack KMS integration. This work will continue in Q1, and once the integration is ready, it will give our customers an option to choose the dstack key-management system, in addition to the currently available Secret KMS and Google KMS options (soon to be released).

Also, by running a dstack KMS node, we will strengthen the dstack KMS by increasing decentralization and redundancy

Later in the year, we will work on more interoperability with dstack by making the CLI and other surrounding tools of SecretVM compatible to dstack, later allowing users to deploy, manage, and migrate workloads seamlessly across SecretVM and dstack environments.

Another item is  raTLS - an extension of standard TLS binding the secure channel to a verified TEE identity. This allows clients and services to establish encrypted connections only with attested workloads, enabling secure and verifiable communication between different services and agents.

We will also work to integrate additional KMS (Amazon, Azure, Hashicorp etc.) based on customer demand.

Economics

Currently, the SecretAI portal only supports the pre-paid model, where users top-up their credit on the Portal. In Q1 we plan to integrate the post-paid model where users save their means of payment with the Portal and are charged monthly according to their usage.

We will also look to integrate x402 - the open payment standard developed by Coinbase. X402 is a decentralized payment protocol that enables on-demand micropayments using cryptocurrencies. 

With the rollout of BYOH / compute marketplace, we will introduce revenue sharing for hardware owners.

Conclusion

In 2026, we will continue strengthening the Layer 1 network, improving its security, scalability and decentralization.

We will also be heavily investing in the Confidential AI and Confidential VM ecosystem, positioning SecretAI and SecretVM as the default runtime for verifiable and confidential computation.

Together, these efforts reinforce Secret Network’s role as the trust layer for confidential compute and AI.