NewL1 TEE Gateway: Trusted Ordering, SubBlock Streaming, and Low-Latency Block Production
The TEE Gateway places encrypted transaction ingress, deterministic ordering, SubBlock generation, and final block packaging inside an attestable, VM-based trusted execution environment (TEE). Each validator selects a primary and a standby Gateway off-chain, both in the same region. The primary continuously supplies SubBlocks and the final block package, without SubBlock auctions. On-chain rules observe TEE-backed block production and penalize validators that bypass the TEE.
00. Core Proposal
- The Gateway is an attestable ordering and packaging service, not a new consensus role. It receives transactions inside the TEE, applies public rules, generates a continuous SubBlock stream, and produces the final block package at the end of the slot. The validator verifies, signs, and proposes the block.
- Transactions are private by default; MEV is exposed only within user-authorized boundaries. Protected transactions remain hidden from operators, validators, and searchers before ordering. Opt-in transactions may expose their unsigned contents and receive refunds through competition for after-ref backruns.
- Validators select a primary and a standby Gateway off-chain, in the same region. Only the primary supplies the continuous stream during normal operation. The standby stays synchronized and does not bid for SubBlocks. If the primary fails, the validator activates the standby at an explicit tick boundary.
- Consensus only observes TEE adoption. Blocks with compliant TEE proof settle normally. Blocks without proof remain valid to preserve liveness, but an additional 30% of the validator’s revenue from that block is burned.
01. Goals and Boundaries
| Goal | Principle | Design |
|---|---|---|
| G1 · Privacy | Hidden before ordering | Transaction plaintext exists only inside an attested VM, removing the information advantage required for frontrunning and operator self-dealing. |
| G2 · Fairness | Public, replayable rules | The same frozen input set, ruleset version, and random salt must produce the same order. |
| G3 · Latency | A fast SubBlock path | Direct, same-region Gateway–validator connectivity keeps authentication, ordering, and signing within one tick. |
| G4 · Revenue | Internalize beneficial MEV | Users may authorize intent disclosure, allowing after-ref backruns to return value to order flow and the network. |
| G5 · Liveness | TEE failure does not halt the chain | If both Gateways fail, the validator may build locally and incur an explicit economic cost. |
| G6 · Evolution | Separate proofs from policy | Platform, workload, and ruleset are versioned separately, leaving interfaces for heterogeneous TEEs, plugins, and ZK. |
02. TEE Selection
VM-based TEEs Fit the Workload
The Gateway runs a complete Linux guest, full node, ordering engine, simulator, and high-frequency networking stack, with a working set on the GB/TB scale. A process-based SGX design would encounter EPC capacity, paging, and ocall boundaries. VM-based TDX and SEV-SNP can run existing node software without restructuring it into enclaves.
2.1 Intel TDX and AMD SEV-SNP
TDX is the first choice; SNP expands coverage and trust diversity.
| Dimension | Intel TDX | AMD SEV-SNP | Implication |
|---|---|---|---|
| Execution model | Full guest; MRTD / RTMR measurements | Full guest; launch digest / attestation report | Neither requires splitting node software into enclaves. |
| Code attestation | RTMR can measure firmware, kernel, rootfs, and application configuration in stages. | Primarily initial-image measurements; application versions are incorporated into the launch digest / host data. | TDX provides a more direct runtime measurement path. |
| Performance | Low CPU/memory overhead; high-I/O paths require measurement. | Comparable overhead; results depend on CPU generation. | Real workload benchmarks matter more than paper comparisons. |
| Ecosystem | Azure, GCP, and bare metal; more existing builder deployments. | Azure, GCP, and AWS; coverage in non-Intel data centers. | Prefer TDX, with SNP as a replaceable backend. |
| Security boundary | Does not fully cover memory-bus attacks by adversaries with physical access. | Does not fully cover memory-bus attacks by adversaries with physical access. | Add location assurance, short-lived keys, primary/standby redundancy, and auditing. |
2.2 Additional Security Layers
Research such as TEE.fail, WireTap, and Battering RAM shows why TDX and SEV-SNP memory encryption should not be described as protection against every physical bus attack. A valid attestation does not mean that the runtime environment will remain trustworthy forever. The design therefore adds Proof of Cloud or equivalent host attestation, short-lived keys, primary and standby deployments in separate failure domains, and deterministic replay.
| Layer | Rule | Purpose |
|---|---|---|
| Location and provider | Named cloud providers, Proof of Cloud, or hosted bare metal with an attestable host stack; separate failure domains for primary and standby. | Raise the barrier to physical attacks. |
| Reproducible images | Publish source code, build scripts, image hashes, and expected workload measurements. | Establish which code an attestation represents. |
| Short-lived keys | Rotate enclave signing and TLS keys by epoch. | Limit the exposure window after a leak. |
| Deterministic replay | Recompute input commitments, rulesets, payloadHash, and salt-dependent results. | Detect ordering violations or fabricated outputs. |
| Standby and fallback | Same-region hot standby; local block production with a burn if both fail. | Separate security failures from chain liveness. |
03. Overall Architecture
Transaction Ingress, Trusted Ordering, and Block Production
The Gateway reuses the engineering structure of a builder while removing builder discretion. Inputs are decrypted inside the TEE, a versioned workload fixes the rules, and TEE signatures bind outputs to a slot, tick, and parent SubBlock. The validator retains final signing authority.
Figure 1. The validator retains final block-production authority. A Gateway produces output only under the current active term. The primary and standby form a single-active replication pair, with no bidding between them.
3.1 Core Components
| Component | Sole Responsibility | Key Outputs |
|---|---|---|
| Encrypted ingress | Keep transactions visible only to the TEE before ordering. | Receipts, encrypted WAL, input commitments. |
| Classifier | Select the protected path, opt-in path, or a dedicated lane. | Routing decisions and fields permitted for disclosure. |
| Deterministic ordering engine | Apply public rules to the frozen input set. | Ordered payload; lane and atomic-group boundaries. |
| SubBlock generator | Bind output to slot, tick, parent hash, and TEE identity. | SubBlock + payloadHash + enclaveSig. |
| Block packager | Assemble the final block candidate in acknowledged order. | Block package + proof summary. |
| Validator adapter | Maintain terms, validate, acknowledge, and switch Gateways. | ACKs, activation tokens, signed blocks. |
| On-chain observation and settlement | Identify TEE coverage and apply revenue sharing or burns. | Adoption metrics, settlement, and fallback records. |
3.2 Data Boundaries
Every SubBlock binds at least gatewayId, workloadId, rulesetVersion, term, slot, tick, parentSubBlockHash, inputCommitment, payloadHash, and enclaveSig.
The final package may concatenate SubBlocks only in acknowledged order. A validator cannot remove, insert, or reorder transactions and still claim the result is a TEE-backed block.
04. Ordering Engine
20 ms Ticks, a 100 ms Opt-in Window, and Deterministic Ordering
4.1 Ordering Primitives
| Path / Primitive | Rule | Purpose |
|---|---|---|
| Protected path | Default; no hints and no after-ref references; enter the next available tick. | Eliminate advance visibility. |
| Opt-in delayed path | Authorize disclosure of the unsigned transaction body or a summary; default delay of 5 ticks. | Give searchers 100 ms to simulate and submit. |
| Lane segments | Process dedicated maker, payment, oracle, and other flows according to on-chain templates. | Preserve application semantics and isolate capacity. |
| General | Sort by effective fee rate; break ties using H(txHash || salt). |
Keep ordering simple, deterministic, and replayable. |
| Atomic bundles | Keep members contiguous; if any member fails, exclude the entire group. | Preserve bundle atomicity. |
| After-ref | Permit placement only immediately after the target; no before-ref; compete on committed tips. | Allow backruns while prohibiting structural frontrunning. |
| Guaranteed-inclusion tail | Admit remaining transactions by receipt window and arrival order. | Provide an inclusion path for ordinary transactions. |
Figure 2. The 20 ms tick is an engineering target. Validate P50/P99 on real TEE, networking, and storage configurations in the target region.
4.2 Hint Contents: The Unsigned Transaction Body
The default hint for an opt-in transaction is the complete transaction contents without its signature, rather than a vague amount range. Inside the TEE, the Gateway verifies the signature and creates a target commitment, then simultaneously publishes the unsigned transaction body to all subscribers. The transaction signature remains inside the TEE and never enters the hint stream.
Without the signature, these contents cannot be broadcast as a valid transaction, replace the original transaction, or reveal the user’s private key. They still expose the sender and exact transaction intent, however. Full hints therefore require explicit opt-in, while common AMM swaps remain protected by default.
Senders may instead select field-level summaries that disclose only the contract, function selector, pool, direction, and size range. The trade-off is less accurate searcher valuation and shallower bidding.
Target references: Searchers submit after-ref bundles using the Gateway-generated targetCommitment, rather than the still-private signed transaction hash. At final placement, the TEE verifies that the commitment corresponds to the target transaction whose disclosure was authorized.
4.3 Deferred Execution and Simulation
Executed state trails the ordered prefix by D slots. P1 uses limited simulation on the latest executed state: ordinary transactions receive static checks only, while bundles and after-ref submissions receive revert-protection and tip-affordability checks. Simulation assists ordering and is not used as a basis for penalties.
| Strategy | Accuracy | Cost | Stage |
|---|---|---|---|
| Full speculative state | High | High; requires overlays, rollback, and reorganization handling. | Optional future capability. |
| Static checks | Low | Minimal. | Fallback / overload protection. |
| Limited simulation on D-lagged state | Medium | Bounded; simulate only high-value atomic groups. | P1. |
4.4 Plugins: Extension Points for Ordering and Transaction Optimization
Capabilities that distinguish existing builders can become plugins in the ordering function, rather than ad hoc operator decisions. Plugins run only inside the active Gateway’s TEE. The primary and standby must load the same plugin set and parameters, and all output remains subject to the same ruleset. Plugins extend application policy without changing the deployment model: one primary, one standby, and a continuous stream from a single active Gateway.
| Plugin Type | Hook | Capabilities | Typical Uses |
|---|---|---|---|
| Ordering | Lane ordering; atomic-group scoring in the General segment. | Maker priority, oracle-update priority, batch auctions, FIFO, fee-rate ordering, deduplication of quotes for the same market. | Market-maker quotes, oracles, payments, and application-specific lanes. |
| Disclosure and optimization | After ingress classification, before freezing the input set. | Hint levels, delay windows, revert protection, combining consecutive transactions, order-flow refund policies. | MEV-Share-style hints, transaction optimization, wallet-specific protection. |
| Bidding and placement | Scoring after-ref candidates and placing them after their targets. | Fixed tips, pricing as a share of realized profit, per-target backrun limits, executability checks. | Backruns, liquidations, and CEX–DEX arbitrage. |
All plugins obey the following constraints:
| Constraint | Rule | Consequence |
|---|---|---|
| Determinism and replayability | Depend only on the frozen input set, on-chain configuration, authorized hints, submitted bundles, and public random salt. No uncommitted external data. | Identical inputs must produce identical outputs. |
| Data isolation | Ordering plugins must not read protected transactions to influence other transactions. Disclosure plugins may expose only sender-authorized fields. | A violation disqualifies the workload from the allowed set. |
| Placement semantics | No before-ref, splitting atomic groups, bypassing lane admission, or bypassing guaranteed-inclusion rules. | These engine-level constraints cannot be overridden. |
| Identity neutrality | No hidden information or secret ordering priority based on searcher, operator, or order-flow identity. | Identity-based commercial revenue sharing must occur outside the ordering outcome. |
| Code and parameters | P1 uses compile-time Rust traits. Plugin code changes update workloadId. Fee floors, windows, and limits enter the ruleset and may change within governance windows. | Code upgrades require new attestation; parameter changes update only rulesetVersion. |
| Primary/standby consistency | Both Gateways run the same codeVersion, rulesetVersion, plugin set, and parameter snapshot. | Failover preserves ordering semantics. |
From Phase 2 onward, some plugins may move to governance-approved deterministic WASM modules. Their hashes, interface versions, and gas/CPU limits become part of the ruleset. Regardless of implementation, plugins must not create a second hidden ordering path or reintroduce SubBlock bidding between Gateways.
05. MEV Protection
Hide Targets, Constrain Placement, and Open Beneficial Competition
- Private by default. Operators, validators, and searchers see only ciphertext before ordering. Bundles cannot reference protected transactions.
- User-selected disclosure. Only explicit opt-in permits publication of unsigned transaction bodies or summaries, with a bounded backrun window.
- Structural filtering. There is no before-ref. Bundles are rejected if they reference protected transactions, break atomicity, or violate lane rules.
- Public auditing. Ruleset versions, input commitments, and payloadHash support post-hoc replay.
| Behavior | Policy | Mechanism | Residual Risk |
|---|---|---|---|
| Frontrunning / sandwiching | Prohibited | Private by default; no before-ref; no references to protected transactions. | A blindly submitted, high-fee front leg may coincidentally succeed. |
| Ordering-operator self-dealing | Prohibited | Operators cannot see plaintext; rules contain no identity-based discretion; output is replayable. | Short-lived keys and auditing must limit the impact of physical compromise. |
| Censorship / delay | Constrained | Receipts, inclusion windows, failover, and public adoption metrics. | P1 primarily relies on accountability and contract termination. |
| Backruns / liquidations | Allowed | Public events or after-ref placement after opt-in targets. | Valuations are affected by D-lagged state. |
| Spam | Neutral treatment | Gas costs and quotas keyed by request-signing identity. | Requires capacity monitoring. |
5.1 Default AMM Policy
Common AMM routers, pools, and aggregator entry points use the protected path by default and do not automatically enable full hints. A dApp that wants backrun refunds should explicitly opt in and publish its policy, rather than interpreting the absence of a user choice as consent to intent disclosure.
06. Searchers
Keep Existing Workflows and Add Controlled Order Flow
Searchers do not need on-chain registration or staking. Their request-signing keys serve as identities. The additional TEE requirements focus on connection authentication and signed results.
| Interface | Purpose | Constraints |
|---|---|---|
gw_subscribeHints |
Subscribe to targetCommitment, expiry tick, and sender-authorized complete unsigned transaction bodies or field-level summaries. | Simultaneous same-region publication; no exclusive feed; signatures never enter hints. |
gw_call |
Read-only calls against the available state baseline. | Limited to contracts involved in the bundle and public targets. |
gw_simulateBundle |
Check reverts, gas, and tip affordability. | D-lagged results are advisory only. |
gw_sendBundle |
Submit atomic groups, afterRef, valid ticks, and tips. | No beforeRef; a request signature identifies the submitter. |
6.1 TEE Connections
Connections use RA-TLS. The TLS private key is generated inside the TEE; clients verify the attestation and expected workload, then reuse persistent connections. Ordinary wallets may connect through a trusted RPC provider. Order-flow providers requiring end-to-end verification can use a lightweight CLI, a local proxy, or Rust/Go primitive libraries.
07. Validators and Deployment Suggestion
Same-region Primary and Standby, with a Single Active Stream
Each validator selects target Gateways off-chain. All node must be in the same region; the Gateways should use different providers or failure domains. The validator maintains a monotonically increasing active term and accepts output from only one Gateway for the current term at any time.
| Deployment Rule | Requirement | Reason |
|---|---|---|
| Same region | Validator, primary, and standby must share a region. | Avoid consuming a 20 ms tick with intercontinental RTT. |
| Separate failure domains | Prefer different providers, data centers, or platforms for the primary and standby. | Reduce correlated failures. |
| Single active term | Accept only the current term; terms increase monotonically. | Prevent simultaneous output sources. |
| Hot synchronization | Synchronize encrypted WAL, receipt commitments, and acknowledged checkpoints. | Resume from an explicit parent hash. |
| Separate fast and slow paths | Keep SubBlocks within a region; transaction pre-forwarding may cross regions. | Combine reach with low latency. |
| Off-chain SLA | Contractually specify latency, availability, attestation-failure rate, and failover time. | Gateways have no on-chain collateral. |
08. Consensus and Revenue Sharing
Retain Only Option A: On-chain Observation and Validator Economic Incentives
The design leaves voting and fork choice unchanged and does not make Gateway availability a hard condition for block validity. On-chain logic checks only the final block’s TEE proof coverage and applies settlement or burns accordingly.
| Block Status | Validity | Economic Outcome | Observed Metrics |
|---|---|---|---|
| TEE — valid proof | Normal voting and finalization. | Normal settlement for the validator and Gateway. | gatewayId, workload, covered ticks. |
| DEGRADED — no proof | Still valid, preserving liveness. | An additional 30% of the validator’s distributable revenue is burned; Gateway share is 0%. | Fallback rate, consecutive duration, region. |
No complex fault attribution: A genuine Gateway failure, network partition, and deliberate validator bypass all appear as the absence of valid TEE proof and trigger the same outcome. The rule is simple to verify and keeps Gateway availability from becoming a prerequisite for consensus liveness.
8.1 Revenue Split
| Recipient / Case | Starting Share | Rule |
|---|---|---|
| Validator | 75% | Settled from TEE-generated priority fees and tips; the protocol fixes a minimum share. |
| Gateway | 25% | Paid to the active Gateway identified in the proof; order-flow refunds are negotiated within this share. |
The protocol does not fix order-flow refunds. Gateways compete on order-flow volume, refunds, latency, availability, and SLAs, rather than competing for ordering rights on every tick.
09. Attestation and Auditing
Attest Code Identity and Audit Ordering Behavior
Without specifying complex registration details, the design retains three public facts: which workloads are allowed, which enclave key each Gateway uses during the current epoch, and which ordering inputs and rules produced the final block.
| Object | Public Information | Verifier |
|---|---|---|
| Workload | Platform, image measurements, codeVersion, rulesetVersion, build hash. | Governance, validators, clients. |
| Gateway identity | gatewayId, enclavePubKey, valid epoch, region, status. | Validator fast path, using the active identity snapshot. |
| SubBlock | term, slot, tick, parentHash, inputCommitment, payloadHash, signature. | Validators and full nodes. |
| Final block | SubBlock proof summary and TEE coverage. | Execution-layer revenue sharing and burn logic. |
| Replay data | Frozen-set commitments, rule parameters, random salt, final order. | Independent auditors. |
9.1 Versions and Keys
- Routine upgrades use a one-epoch window in which both versions are accepted; emergency revocation may take effect immediately.
- A full attestation quote binds the short-lived enclave key to the workload; each tick verifies only a compact signature.
- Missing active identity, version mismatch, or signature failure is treated as absence of TEE proof.
- The primary and standby may use different platforms, but must implement the same ruleset and pass the same replay test vectors.
10. Future Extensions
Preserve Interfaces Without Putting Research Projects into P1
| Direction | Extension | Invariant |
|---|---|---|
| Heterogeneous TEEs | Add platform verifiers, such as Arm CCA. | Accept only allowed workloads and short-lived enclave keys. |
| WASM plugins | Replace compile-time modules with approved deterministic WASM. | No unauthorized transaction access, no before-ref, and replayability. |
| Co-built blocks | Combine payloads from multiple authenticated Gateways through a deterministic merge function into a single order. | A future mode; the current primary/standby pair does not bid. |
| MCP semantics | Use the union of multiple Gateway payloads as multi-proposer input. | Validators cannot reorder freely; the merge function becomes part of the ruleset. |
11. Roadmap and Open Questions
Deliver in Phases with Verifiable Exit Criteria
| Phase | Deliverables | Exit Criteria |
|---|---|---|
| Phase 0 · Single machine | TDX/SNP image, RA-TLS, deterministic ordering, compile-time plugin interfaces, SubBlocks, block packages, replayer. | Matching cross-platform vectors; verifiable attestation; target peak throughput. |
| Phase 1 · Primary/standby | Active terms, encrypted WAL, ACKs, hot failover, opt-in unsigned-transaction-body hints, built-in ordering/optimization plugins, on-chain proofs, 75/25 split, and 30% burn. | P99 fits the tick budget; failover creates no dual sources; preconfirmed order matches the final block. |
| Phase 2 · Multi-region | APAC/EU/NA, pre-forwarding, wallet/RPC integration, searcher interfaces, refund records. | Regional failures do not propagate; stable adoption; zero replay discrepancies. |
| Phase 3 · Extensions | WASM plugins, heterogeneous proofs, threshold decryption/ZK; separate review for co-building. | Preserve determinism, primary/standby behavior, settlement, and liveness. |