Security Model
Protecting user funds and privacy through hardware-enforced isolation and cryptographic verification
Threat Model
Cylend is designed to resist the following adversarial scenarios:
Malicious Node Operators
Even if a node operator on Sapphire has physical access to the server, they cannot read the memory of the TEE enclave. This prevents them from seeing user positions or front-running trades.
Network Snooping
An adversary monitoring network traffic cannot decipher the loan details because the payload is encrypted client-side before transmission.
Security Guarantees
Confidentiality
Data inside the LendingCore contract is encrypted at rest and in transit. It is only decrypted ephemerally inside the CPU enclave for processing.
Integrity
State transitions are verifiable. While the data is private, the proof of execution ensures that the protocol correctly followed its logic (e.g., collateral was actually deducted).
Access Control
Strict onlyOwner and role-based access control prevents unauthorized entities from calling sensitive system functions, such as price updates.
Safe-Guards
- Health Factor Validation: Every withdraw or borrow action atomically checks HF > 1.0 inside the TEE before authorized.
- Price Staleness Checks: The oracle system rejects action processing if price feeds are older than a safe threshold, protecting against flash crashes.
- Circuit Breakers: Emergency pause functionality on the Ingress contract can halt deposits/withdrawals in case of detected bridge anomalies.
This security model allows Cylend to be trustless regarding the operator but requires trust in hardware (Intel SGX), a standard trade-off for TEE-based privacy.