Why multiple cryptographic layers exist
DerivaDEX does not rely on one cryptographic primitive to secure the platform. Different layers solve different problems:- EIP-712 signing authenticates who authorized a request
- request encryption protects private request contents in transit to the operator boundary
- attestation binds trust in the trusted-execution boundary to a verifiable identity
- checkpointed commitments provide public state-verification anchors
One question per layer
The cleanest way to read the security model is by the question each layer answers:| Layer | Main question it answers |
|---|---|
| signing | who authorized this request? |
| encryption | who can read this request before execution? |
| attestation | what execution boundary is the request being sent toward? |
| checkpointed commitments | what public anchor exists after execution? |
Signing answers identity, not confidentiality
Request signing proves that the correct trader or delegated session authorized a request. It does not hide the request contents from intermediaries. That is why signing alone is not enough for a confidential trading path.Encryption answers confidentiality, not business validity
Encrypted submission protects request contents before sequencing, but encryption does not make a bad order valid. Unsafe prices, invalid sizes, unsupported markets, or margin violations still fail after decryption when the platform applies its ordinary validation and risk rules.Attestation answers trust-boundary identity
Trusted-hardware attestation is meant to let clients reason about the execution boundary they are sending encrypted requests toward. In public-doc terms, this matters because the confidentiality story depends on the intended operator boundary actually being the one processing the request.Checkpointing answers public verifiability
Public cryptographic commitments matter after execution as well as before it. Checkpoints and related state commitments provide a public anchor for settlement and later verification. They are the part of the cryptographic story that makes the system externally auditable rather than purely trusted.Why the layers are deliberately redundant in some places
Some readers expect one primitive to remove the need for another. DerivaDEX intentionally does not work that way:- signing plus encryption protects both authorization and confidentiality
- attestation plus encryption gives the confidentiality story a defined execution target
- checkpointing plus deterministic execution gives the system a later public anchor instead of leaving all trust inside the runtime
Why cryptography does not replace the rest of the trust model
Cryptographic safeguards still do not replace:- margin and liquidation controls
- governance and upgrade boundaries
- clear public versus restricted surface labeling
- operational support and escalation paths
Sources
- Request Signing Reference for signing, replay-window, and delegated-session terminology
- Request Encryption Reference for the public encrypted-submission contract
- Trusted Hardware and Security Model for enclave-boundary interpretation
- Consensus, Checkpointing, and Finality for later anchoring semantics
- Intel SGX Developer Guide for attestation and enclave vocabulary
- Intel SGX Explained for limits and tradeoffs of SGX-style trust assumptions