Ethereum’s transparency has long been one of its greatest strengths, but it has also become a structural limitation for many real-world applications. From MEV transaction inefficiencies to data breaches in DeFi, gaming, and AI-driven workflows, the assumption that everything must be public to be verifiable is increasingly being questioned.
The TEN protocol is built on a different premise: that calculations can remain provably correct without forcing users, developers, and companies to reveal sensitive inputs, strategies, and logic to the entire market.
In this cryptoprune Q&A, the team behind the TEN protocol explains its “Trusted Computing” concept and why they believe privacy-first execution is the missing fundamental element in Ethereum’s scaling roadmap.
Rather than launching a separate privacy ecosystem, TEN is designed as a complete EVM environment built on Ethereum payments and liquidity, allowing developers to pick and choose what should be done publicly and what should be done privately.
In this discussion, we explore how this hybrid model reshapes the user experience, reduces MEV, enables sealed bidding markets and hidden order flows, and unlocks new categories of applications, from verifiable AI agents to proven fair iGaming.
We also discuss the security and governance trade-offs when using a trusted execution environment, and how TEN’s architecture is designed to make failures detectable, contained, and recoverable rather than silent and catastrophic.
Our Q&A details how selective secrecy can redefine trust, composability, and usability across the Ethereum ecosystem. 
How can you easily explain to readers who are new to the TEN protocol what “trusted computing” means and how TEN actually solves problems that the existing Ethereum L2 doesn’t?
At its simplest, “computing with trust” means being able to use your dapp without broadcasting your intentions, strategy, or sensitive data to everyone monitoring the chain.
Transparency is the default in most Ethereum L2s today. It shows every transaction, its parameters, intermediate execution steps, and often even the “why” behind the action. While this level of openness is powerful for validation, it poses very real problems in practice. Trades can be ahead or in between. Wallets and dapps leak behavioral and economic data. Games and auctions struggle to maintain both fairness and privacy. And many real-world and enterprise workflows simply cannot work if their design requires exposing inputs and logic.
This is the core structural limitation that TEN addresses. Ethereum is built on the premise that in order for data to be verifiable, it must be visible. TEN keeps verifiability intact, but removes the idea that the data itself needs to be made public. With the right privacy technology, you can prove that your calculations are correct without revealing the underlying inputs or logic.
What it actually means is confidence. Confidence that node operators cannot get ahead of themselves. The game is not secretly rigged. Bids are not copied in real time. Competitors are not spying on your strategy. Dapps do not extract or monetize users’ personal input.
You still get Ethereum-grade security and validation. You don’t need to display everything.
There are other privacy-focused and TEE-oriented projects in cryptocurrencies. What exactly is different about TEN’s architecture and threat model compared to privacy L1, rollup with off-chain proofs, MPC-based approaches, etc.?
TEN is built not as a parallel ecosystem, but as a privacy-first Ethereum execution. The goals are very narrow and very intentional. This means running EVM-style applications with selective secrecy while maintaining payment, composability, and liquidity locked into Ethereum itself.
This design choice is what really sets TEN apart.
Privacy When we look at L1, we often ask developers to move into a new world. New tools, new execution semantics, and different assumptions about composability are common. TEN takes the opposite approach. It is not intended to replace Ethereum, but to feel like Ethereum. Developers maintain access to EVM, the standards they already use, and existing liquidity while ensuring confidentiality only when it really matters.
Although ZK-based private execution provides very strong privacy guarantees, these guarantees typically come with trade-offs for general-purpose applications. Circuit complexity, performance constraints, and developer friction can make everyday app development more difficult than it needs to be. TEN uses TEE instead and targets general purpose sensitive computing with a very different performance and developer experience profile.
The MPC-based approach eliminates the need to trust hardware vendors. Although this is a great advantage, MPC-based approaches present their own challenges. Throttling overhead, delays, and operational complexity can quickly degrade the user experience for regular applications. TEN embraces the assumption of trust rooted in hardware and focuses on mitigating it through governance, redundancy, and rigorous security engineering.
The essential differentiator is this hybrid model. What should be public remains public, such as finality, auditability, and settlement. Anything that needs to be private remains confidential, such as inputs, order flow, strategy, secret state, etc.
You talk about how TEN makes cryptocurrencies feel like “regular apps” to end users, private, simple, and trusted. What is that like from a UX perspective, and how is the experience of a TEN-powered dapp different from the experience of a typical Ethereum dapp today?
At the user level, the constant feeling that everything you do is visible and can be exploited is removed.
With TEN-powered dapps, this manifests itself in small but meaningful ways. You won’t have to worry about menpooling or watch your trades get pinched in real time. Intents are private by default, whether they are bids, strategies, or execution thresholds. Users don’t have to rely on defensive workarounds like private RPC or manual slippage hacks to use the app securely.
What remains is a cleaner mental model, closer to Web2. Assume that the inputs and business logic of the application are not exposed automatically, as most software does not.
The changes themselves are subtle, but fundamental. Privacy will no longer be a bolt-on feature or an advanced setting understood only by power users, but simply a core product primitive that exists by default.
A trusted execution environment introduces a different type of trust assumption: hardware vendor dependency and enclave security. How do you address concerns about side-channel attacks, backdoors, or vendor-level failures in your security and governance model?
That’s exactly the right kind of skepticism. TEN’s position is not that TEE is magic or without risk. It’s important to be clear about your threat model and design your systems so that a breach doesn’t go silent with catastrophic consequences.
TEN assumes that enclaves provide confidentiality and integrity within defined bounds, and builds on that assumption rather than pretending they don’t exist. The goal is to make failures detectable, contained, and recoverable rather than invisible.
From a security perspective, this appears as defense in depth. There are strong remote authentication requirements, controlled code measurements and reproducible builds, and strict key management practices such as sealed keys, rotation, and strictly scoped privileges. The attack surface of the enclave is intentionally minimized, and the privileged code running inside is kept to a minimum.
Redundancy and fail-safe design are equally important. TEN avoids architectures where one enclave effectively dominates the system. Where possible, rely on multi-operator assumptions and build protocols such that even a compromised enclave cannot rewrite history or forge payments on Ethereum.
Once governance and operational readiness are complete, the picture is complete. Security is not just about encryption. Also important is how quickly and transparently the system can respond. This includes patching, revocation, enclave version locking, and clear incident playbooks that can be executed without ambiguity.
Importantly, TEN does not ask users to “trust nothing.” It is about reducing the substantial trust that needs to be placed in operators and trading partners, and focusing what remains of trust in a much narrower, auditable area.
On the DeFi side, how do sealed bid auctions, hidden order books, and MEV-resistant routing actually work in TEN? And how can users and regulators gain trust in a system where the core trading logic and order flow is intentionally encrypted?
Broadly speaking, TEN works by changing what is published by default.
Consider a sealed bid auction. Instead of broadcasting bids in clear text, users submit bids in encrypted form. The auction logic runs within the TEE, so individual bids are never exposed during execution. Depending on how the auction is designed, bids may be published only at settlement, or not at all, with only the final result being published on-chain. This one change eliminates the bid sniping, copy trading, and strategic leaks that plague today’s public auctions.
The same idea applies to hidden order books. Instructions are not visible to others so that they can reconstruct your intentions and strategies in real time. Traders are protected from systematic copying and abuse, while the system produces execution results that can be verified after the fact.
MEV-tolerant wiring is a natural inheritance from this model. The classic MEV pipeline of reference, copy, and sandwich does not exist because the user’s intent is never broadcast to the public memory pool. There is nothing to move forward in the first place.
Naturally, this raises questions about reliability. If the core logic and order flow are encrypted, how can users and regulators be sure that the system is working correctly?
The answer is that TEN separates input privacy and result verifiability. Even if the input is private, the rule is not. Anyone can verify that the matching engine follows published algorithms, that liquidation prices are calculated correctly, and that there are no hidden priorities or manipulations.
In addition to that, there are clear audit aspects and mechanisms for selective disclosure. Regulators and auditors can be granted access under defined conditions, while the public can still see encrypted commitments and on-chain proof of correct execution.
The result is a rare combination in DeFi today: confidentiality of order flow and accountability of results.
Verifiable AI agents are one of the main use cases. Can you provide a concrete example of an AI agent running on TEN? What is private and what is publicly verifiable on-chain? And why is it better than running the same agent completely off-chain?
A simple way to think of this is the protocol’s AI-driven financial rebalancer.
When that agent runs on TEN, many of the features that make it valuable remain hidden by design. In many cases, there is no need to expose the model weights or prompts, which are core intellectual property. Proprietary signals and paid data feeds remain confidential. Internal risk limits, intermediate reasoning, and decision-making logic are never leaked to the market. Even the execution intent remains private until the moment it is committed.
At the same time, there is a clear set of publicly verifiable on-chain. Through attestation, anyone can verify that the authorized code actually executed. You can verify that the authorized policy module enforced the relevant constraints and that the resulting actions respected the defined invariants. The final state transition and settlement will take place openly on Ethereum, as always.
This combination makes it meaningfully better than running the same agent completely off-chain. Off-chain agents ultimately ask users to trust logs, operators, or unverifiable claims that “the bot followed the rules.” TEN removes that blind trust. This allows agents to keep competitive dynamics private while proving to users, DAOs, and trading partners that they acted strictly within the scope of their mandate.
iGaming has historically been plagued by trust issues, bots, and opaque RNG. How will TEN be able to certify fair gaming while keeping RNG seeds, anti-bot logic, and gaming strategies private? And how do you think this fits into the existing regulatory framework for online gaming?
iGaming has always been built around a fundamental contradiction. Transparency is necessary to prove fairness, but confidentiality is essential to protect RNG systems, security controls, and anti-bot logic. Too much exposure will game the system. If you hide too much, trust will be destroyed.
TEN resolves that conflict through selective confidentiality. Sensitive components remain private, but rules and results remain provable.
Regarding randomness, this allows “provably fair” to be literal rather than aspirational. Games can use commit-public and verifiable randomness schemes. Randomness is pre-committed, results are independently verifiable by players, and RNG seeds remain private until it is safe to publish or only partially published. Players gain confidence in fairness even if the attacker does not obtain a usable blueprint.
The same principles apply to anti-bot and risk management. This is important because although bot detection heuristics and fraud systems are run in secrecy, sophisticated attackers quickly adapt once these mechanisms are exposed. Keeping them private maintains their validity while allowing the system to produce verifiable results.
More broadly, this allows for provable game integrity. Players can verify that the game follows the published rules and that the results have not been manipulated, without exposing sensitive internal information such as security logic, thresholds, and strategy parameters.
From a regulatory perspective, this corresponds clearly to the existing framework. Regulators are typically concerned with auditability, ensuring fairness, and enforceable controls, rather than forcing the disclosure of all internal mechanisms. TEN’s model of verifiable outcomes combined with selective disclosure is a natural fit with these requirements.
What does building “selective private” smart contracts on TEN look like from a developer’s perspective? How do you mark a function for TEE execution, and how do you test and debug logic that can’t just logout to a public memory pool?
From a developer’s perspective, the simplest way to think about TEN is that it’s built using two execution zones.
There is a public zone and this feels like regular Ethereum development. Composable contracts that work as expected with standard EVM logic, public state, and any L2.
Then there’s the sensitive zone. Here, some specific functionality and state is performed within the TEE, input is encrypted, and disclosure is tightly controlled.
In reality, developers explicitly decide what needs to be done “in private” and what should remain exposed. On the confidential side, you put things like trade matching, RNG, strategy evaluation, or secret storage, but everything else remains exposed for configuration and settlement.
The changes in workflow are most noticeable in testing and debugging because you can’t treat the public memory pool as an always-on debugging console. Instead, testing and debugging typically relies on a local Devnet with enclave-like execution, deterministic test vectors, and controlled debugging modes during development. It also validates behavior through verifiable commitments and invariants, rather than relying on public logs, and proves that the system stayed within the rules even when inputs are private.
The key change is to move away from mempool introspection as a debugging point and design for provable correctness from the beginning.
We emphasize composability between private and public components as a key differentiator. What new application patterns do you expect to emerge from this hybrid model, and how can existing Ethereum protocols integrate TEN without completely rewriting the stack?
TEN’s hybrid model unlocks application patterns that are very difficult or simply impossible with chains that are transparent by default.
One clear pattern is private enforcement with public payments. Sensitive logic such as trade matching, strategy evaluation, RNG, and risk management can be performed in secret, but the end results are still determined publicly on Ethereum. You can ensure privacy where it matters without giving up verifiability or composability.
Another area is protected price discovery and dark liquidity. Sealed bidding, hidden order books, and private routing make it possible to operate a fairer market while producing verifiable results on-chain. Markets gain completeness without converting the intentions of all participants into public data.
Games and AI agents are also a natural fit. The internals of a hand, strategy, prompt, or model can remain private, but fairness, accuracy, and settlement remain provable. This combination is very difficult to achieve in a completely transparent execution environment.
In addition, selective disclosure applications are also emerging. Identity, reputation, compliance, eligibility checks, etc. can remain private, while simultaneously enforcing public rules and producing auditable results.
The unique thing about TEN is that you don’t have to give up your Ethereum. TEN is a complete EVM, so existing Ethereum smart contracts can be deployed to TEN as-is and work as developers expect. The difference is that you immediately have the option to run some of your logic covertly.
For many protocols, integration is easy. Teams can deploy the same contract on TEN in parallel with Ethereum, keep the public version unchanged, and gradually enable confidential execution where it adds the most value.
This naturally creates two adoption paths. Some teams choose the least effort route by deploying without changing their existing contract and obtaining both public and confidential instances with little additional effort. Other companies take a progressive approach, selectively moving high-value flows such as order flow, auctions, games, and agent logic to confidential execution over time.
Importantly, TEN does not force developers to choose between composability and confidentiality. This allows us to maintain Ethereum’s ecosystem, liquidity, and tools while making privacy a top-of-the-line feature rather than an afterthought.
Who will run the enclaves and infrastructure that powers TEN, how will we avoid centralization to a few operators, and what will be the roadmap for decentralizing the network, bootstrapping the ecosystem, and attracting the first breakout apps on TEN?
Like most new networks, TEN begins with a practical bootstrap phase. Initially, this will mean a smaller, more selective set of operators and infrastructure with a real focus on reliability and security. The goal at this stage is not to achieve maximum decentralization from day one, but to ensure that the system behaves predictably and securely when developers start building real applications on top of it.
Architecture and incentives are really important to avoid long-term centralization. This roadmap is built around onboarding non-privileged operators, combined with strong authentication requirements so operators can prove they are running the right code in the right environment. Economic incentives are designed to encourage many independent operators rather than small cartels, with a clear emphasis on geographic and organizational diversity. On top of that, performance and security standards are transparent, and the protocol itself is structured to prevent a single operator from dominating execution.
In terms of how the roadmap unfolds, the first phase is about reliability and bootstrapping developer tools. Once that foundation is solid, the focus will shift to shipping flagship applications that truly require confidentiality, such as iGaming, secured DeFi workflows, and verifiable AI agents. From there, operator participation will grow, governance will be decentralized, more value will flow through the network, and security postures will continue to strengthen as risks increase.
That’s what sets up the flywheel of the ecosystem. Builders don’t come to TEN just because it’s another EVM. They’re here to offer features you can’t get anywhere else.
The theory of breakout apps is simple and straightforward. The first truly successful TEN native application will not be able to exist or compete on a chain that is transparent by default. In that case, confidentiality is not a checkbox feature. It’s the product itself.