Skip to main content

Why trusted hardware appears in DerivaDEX

DerivaDEX uses trusted-hardware execution boundaries because the platform needs fast off-chain sequencing and matching without exposing order flow before it is processed. The trusted-hardware layer supports confidentiality for incoming requests until they cross the sequencing and execution boundary.

What problem trusted hardware is solving

Trusted hardware does not make the whole platform trustless. It addresses a narrower problem:
  • private write-path requests need to stay confidential before sequencing
  • clients need a reason to believe the intended execution boundary is the one handling those requests
  • the fast path needs a stronger boundary than “send plaintext to an ordinary server and hope”
The enclave boundary covers request confidentiality and execution identity in the fast path. It is only one part of the overall trust model.

What guarantees the model is meant to provide

At a high level, the trusted-hardware model is meant to support:
  • request confidentiality before sequencing
  • attestable execution identity for the operator boundary
  • deterministic processing paired with checkpointed state commitments
These guarantees are useful only when paired with the rest of the system: signing, encryption, matching rules, risk checks, and on-chain checkpoint anchoring.

What trusted hardware does not prove

Trusted hardware does not, by itself, prove:
  • that every business rule is economically desirable
  • that every risk-control parameter is correct
  • that governance and upgrade decisions are safe
  • that later settlement anchoring is unnecessary
SGX-style execution identity is narrower than a whole-platform trust guarantee.

What the model does not replace

Trusted hardware does not replace:
  • public risk controls such as margin rules and liquidation safeguards
  • on-chain checkpointing for settlement anchoring
  • explicit public/private boundary labeling for restricted APIs
The trusted-hardware layer is one part of the trust model, not the whole trust model.

How this should change reader expectations

ReaderCorrect expectation
TraderRequest confidentiality and sequencing-boundary trust matter, but they do not remove the need to understand margin, liquidation, and settlement rules
BuilderEnclave assumptions matter for signing and encryption flows, but client correctness still depends on lifecycle, error, and reconciliation handling
Governance or diligence readerThe trust story is layered: trusted hardware, cryptography, governance, and checkpoint anchoring each cover different concerns

Sources

Move to adjacent routes

Last modified on April 13, 2026