1) Intro
TrustNet is a research firm and TEE hardware manufacturer proposing customized TEEs to significantly enhance security and fairness in MEV capture.
TLDR:
1. BNB lacks infrastructure for MEV value capture. Its unique consensus mechanism (PoSA) makes direct migration of Jito’s solution infeasible.
2. Inspired by Flashbots and Jito’s BAM, we believe BNB could skip liquid staking and MEV-Boost, jumping straight to integrating TEE as a fundamental block building process in the MEV Supply Chain.
3. Existing TEE hardware from Intel and ARM can’t handle blockchain’s high concurrency needs—we must design and produce specialized TEE hardware for blockchain.
Thus, the prototype of this project was born: TrustNet—Eliminate MEV with customized TEE.
TrustNet leverages self-designed and manufactured TEE hardware SPU (Secured Processing Unit) to secure the block building process at scale, enforcing fair ordering of transactions and preventing front-running, effectively neutralizing extractive MEV behaviors.
TrustNet proposes an architecture that allows validators to commit to blocks within TEE enclaves, ensuring that block construction remains confidential and tamper-proof until finalization, without being constrained by current TEE hardware limitations such as side-channel attacks and TPC bottlenecks.
2) TEE: The Final Solution for Eliminating MEV
Over 30% of data processing on Apple phones
More than 50% of credit cards rely on TEE hardware for payment protection.
In Ethereum, as of October 2025, over 40% of blocks are built via TEE
Solana launched its TEE block-building program, BAM, in July this year, encrypted txs until execution, and generated cryptographic attestations of transaction ordering tailored for the different needs of users. (BAM)
From Flashbots’ Transparency Report, we see that MEV is expected to decrease as the proportion of TEE blocks increases.
More blocks built by TEE, fewer the MEV
The conclusion is simple: TEE is the only scalable, trustless MEV elimination primitive.
2.1) Integrating TEE to the MEV supply chain
· Secured Block Engine: In-enclave MEV capture, sorting, and packing—tamper-proof against validator collusion.
· Verifiable MEV Allocation: Pro-rata distribution to stakers, attested via remote verification (e.g., by trusted third parties).
· Enhanced Security: Mitigates insider threats; aligns with Secret Network’s TEE privacy computations for MEV applications.
[Users/Searchers] → [Encrypted Tx/Bundles] → [TrustNet Relay (Anonymity Set >10k tx/s)]
↓
[SPU Cluster: Decrypt | Simulate | Auction | Sort]
↓
[Encrypted Inclusion List + Remote Attestation]
↓
[PoSA Validator: Merge | Finalize | Propose]
↓
[BNB Chain: On-Chain Verify | Execute]
2.2) Integrating TEE to the MEV supply chain
i. Oblivious Mempool Protocol
1. Submission: Tx encrypted:
C=EncKSPU(tx∥timestamp∥nonce)C=EncKSPU(tx∥timestamp∥nonce)C=EncKSPU(tx∥timestamp∥nonce)
2. In-Enclave Processing: Decrypt in SPU; simulate state,
ΔS=f(Si,tx)ΔS=f(Si,tx)ΔS=f(Si,tx)
generate Merkleized trace
RT=Merkle([ΔS1,…,ΔSn])RT=Merkle([ΔS1,…,ΔSn])RT=Merkle([ΔS1,…,ΔSn])
3. Fair Ordering: Sort by
k=H(timestamp∥nonce∥sender)k=H(timestamp∥nonce∥sender)k=H(timestamp∥nonce∥sender);preventsmanipulation.
contract TrustNetVerifier {
struct Attestation {
bytes quote;
bytes signature;
bytes32 merkleRoot;
uint64 slot;
}
function verify(
Attestation calldata att,
bytes calldata inclusionList
) external view returns (bool) {
require(keccak256(inclusionList) == att.merkleRoot, "Root mismatch");
require(SPU.verifyQuote(att.quote, att.signature), "Invalid quote");
return true;
}
}
ii. Vickrey Auction Mechanics (sealed-bid second-price auction)
Compared to First-Price auction results in a monopoly at block builders further, or FCFS, causing spam transactions and eventually latency wars. TrustNet uses Vickrey because it’s the only auction that turns TEE’s privacy into economic fairness — not just security theater.
Case Study: Early MEV-Boost (2022)
First-price auction → searchers shaded bids by 40–60% → underpaid validators → centralized to top 3 builders who could afford bid calibration infra.
A quick example of how Vickery works
1. Searchers (e.g., Tony bids 1 BNB; Janice bids 2 BNB) submit sealed bundles to the TEE-private mempool.
2. Bids blind: No leakage of competitors’ strategies.
3. Winner (Janice) pays second-price (1 BNB); enters Fast-Lane (immediate inclusion)
4. Loser (Tony) delayed 200 ms for standard processing (time lock → enforced fairness)
fn process_bids(sealed_bids: Vec<EncryptedBid>) -> (Winner, ClearingPrice) {
let bids = decrypt_in_tee(sealed_bids); // TEE-decrypted
let (winner, second_highest) = vickrey_auction(bids); // Second-price payment
(winner, second_highest)
}
iii. Incentive model based on TEE auction (tips)
The incentive model from the Validators will shift from MEV and staking reward to Base fee + TEE Tips + Auction proceeds.
It eventually means Higher Rewards for Validators/Builders, Using Flashbots MEV-Boost on Ethereum as benchmark:
Stakers yield uplift projection
· Delivered 60% additional revenue to validators
· Generated ~$450M in profits for searchers
· Total shared value between validators and searchers: ~$700M
However, the current TEE solution has its limitations when integrating with the blockchain execution environment.
3) Customized TEE
Industry-standard TEE solutions typically rely on off-the-shelf hardware from Intel (SGX), ARM (TrustZone), or cloud providers offering “TEE-as-a-Service.” This introduces two critical problems:
1. Non-transferable root of trust — Private keys generation and storage is now unconditional trust in hardware vendors.
2. Misaligned use cases — COTS TEEs are designed for iPhones, automotive, etc., where data flows don’t involve billions of dollars, and efficiency > security for end users.
There’s no TEE built for Blockchain, until now.
3.1) Why customized TEE? Scability
Off-the-shelf hardware, particularly the limited memory capacity (EPC), is fundamentally inadequate to meet the high concurrency demands of blockchain.
Every 12 seconds, a Builder must complete state simulation, sorting, and packaging for thousands of transactions within 200ms. If SGX directly runs the MEV Builder, the per-slot delay reaches 1.8 seconds, resulting in a 90% slot miss rate. This issue becomes even more critical for BNB, especially after its block interval has been significantly reduced to 0.45 seconds.
Taking SGX (EPC < 512MB) as an example, a single TEE hardware serving as a Block Builder can experience delays of over 1 second even without considering spam transactions, and actual delays tend to be even higher. Such latency is unacceptable for BNB, where the block interval has already been shortened to 0.25 seconds.
The inability of hardware to support horizontal scaling, along with the potential latency introduced after integration, are key reasons why many believe on-chain TEE applications have a long way to go.
However, since TrustNet’s Customized TEE is not embedded within the CPU, it supports horizontal expansion by adding multiple TEE modules and memory sticks (hardware expansion), thereby scaling memory EPC and I/O capabilities. Without the concept of EPC, it is no longer constrained by the CPU’s inherent I/O bandwidth limitations, making its application in high-concurrency blockchain environments imminent.
Additionally, we have developed the SPU-G, a heterogeneous AI confidential computing co-processor that extends confidential computing capabilities to GPU and other computational acceleration devices. When used in conjunction with the SPU, it enables end-to-end heterogeneous AI confidential computing across CPUs and GPUs, laying the hardware foundation for future large-scale TEE adoption on the blockchain—such as Dex(PerpDex) with dark pools and decentralized AI.
3.2) Enhanced Security
TEE.fail successfully recovered the nonce used in an ECDSA signature via an Interpreter attack, thereby inferring the ECDSA private key of the SGX Quoting Enclave. This undermines the trust chain that relies on SGX remote attestation.
Yannik’s tweet also sparked extensive discussion among blockchain TEE developers, but the focus remained on how to preserve Intel’s existing trust chain — rather than rebuilding the trust model from scratch or pursuing hardware-level solutions.
The SPU adopts a standalone expansion card architecture. Its only interface with the General-purpose computing environment is the PCIe bus, and it shares no microarchitecture or computing resources with the General-purpose computing environment.
Consequently, it is inherently immune to current software-based side-channel attacks that exploit shared microarchitecture and resources. Furthermore, the SPU incorporates a tamper-resistant hardware version (certified by BCTC), providing robust protection against physical attacks such as drilling, laser intrusion, and chemical solvent etching.3.3)
The first testnet node deployed on an SPU TEE machine successfully packed and submitted the first TEE-built block on BNB Chain’s testnet earlier this year (June 26, 2025).
https://testnet.bscscan.com/tx/0xc42c2e552e55dbcf246d421c278ca49ea4b1f8d885274a9270ce883618ede519
Mainnet testing is scheduled to begin in December this year, with Phase 1 strategic partners including
Fourmeme as DApp and Hash Global as Validator.
4. Why BNB
Obvious reason: Only three L1s host real high-value transactions: ETH, Solana, BNB.
· ETH: Flashbots (mature)
· Solana: Jito (mature)
· BNB: Blank slate for MEV capture and solutions
Moreover, MEV on BNB Chain is worse than on other chains:
· I recommend newcomers like my cousin start with Binance Alpha, but newbies swapping 0.5–1 BNB routinely lose >50 USDT to sandwiches — >5% slippage — deterring them at their first web3 experience.
Previous BNB MEV exploration directions are questionable:
· PBS: Makes small MEV searchers unprofitable; further entrenches 48club monopoly in block building
· Benevolent alliances: Only soft constraints on searchers → sandwich bots still frontrun at block height –2 or backrun in countless ways;
Challenge of building TEE on BNB:
· PoSA allows validators to build blocks directly (unlike Ethereum’s reliance on external builders)
· Successfully routing a portion of transactions into TEE requires deep validator participation