Why Secure Hardware
AI inference for financial execution operates in a high-value adversarial environment. The outputs of the inference layer — trade signals, execution decisions, position management recommendations — directly control on-chain transactions of real economic value. This creates a clear incentive for sophisticated attackers to attempt to manipulate the inference process. Software-based security measures are necessary but not sufficient. A sufficiently privileged attacker — one who has compromised the operating system, the hypervisor, or the cloud infrastructure underlying the inference nodes — can bypass software-level protections. They can read model weights, extract signing keys, intercept inference inputs, or substitute inference outputs. Secure hardware addresses this threat by providing isolation that is enforced by the CPU itself, below the level of the operating system. Code and data inside a secure enclave are protected even from privileged software on the same machine, including the host OS and cloud provider infrastructure. The hardware becomes the trust anchor, and the security guarantees of the hardware extend to the software running inside it.Trusted Execution Environments (TEEs)
SURCHI’s AI inference nodes run inside Trusted Execution Environments (TEEs) — hardware-isolated execution contexts that protect code and data from unauthorized access or modification. The TEE implementation used in SURCHI’s architecture is based on Intel SGX-class enclave technology, which provides:Model weight protection
Model weight protection
AI model weights — the parameters that encode the intelligence of the sentinel models — are loaded into the enclave at initialization and never exit it in plaintext form. An attacker who gains full access to the host machine cannot extract or alter the model weights. Model integrity is guaranteed by the hardware, not by software access controls that can be bypassed.
Signing key isolation
Signing key isolation
The cryptographic keys used by the Execution Sentinel to sign on-chain transactions are generated inside the enclave and never exported in any form. Key material exists only within the hardware-protected enclave memory. Even the protocol operators cannot extract signing keys from a running enclave — the hardware enforces this boundary absolutely.
Attestable inference results
Attestable inference results
Every inference result produced inside the enclave is accompanied by a cryptographic attestation: a hardware-signed statement that the result was produced by an authentic, unmodified version of the inference code, running on genuine TEE hardware. This attestation can be verified by any observer — users, auditors, or external verification services — without trusting the protocol operators.
Tamper-evident execution
Tamper-evident execution
Any attempt to modify the enclave’s code or data — by the host OS, by other processes, or by physical hardware attacks — causes the enclave to terminate. Tamper attempts are detected and logged. The enclave does not produce corrupted outputs; it stops producing outputs entirely, triggering the Sentinel Core’s failure handling procedures.
Remote Attestation
Remote attestation is the mechanism by which users and external verifiers can cryptographically confirm that the SURCHI inference layer is running on authentic, unmodified TEE hardware and executing genuine, unmodified protocol code. The attestation process works as follows:Enclave measurement
At initialization, the TEE hardware computes a cryptographic measurement (hash) of all code and data loaded into the enclave. This measurement is unique to the exact code version and configuration — any modification, however small, produces a different measurement.
Hardware-signed quote generation
The TEE generates an attestation quote: a signed statement containing the enclave measurement, the TEE hardware identity, and the current enclave state. This quote is signed by a hardware key that is unique to the physical CPU and is verifiable against Intel’s attestation service.
On-chain publication
Attestation quotes are published on-chain at regular intervals and upon any enclave restart or update. The on-chain record creates a publicly verifiable, timestamped history of which code versions have been running in the inference layer and when.
Key Management
The Execution Sentinel requires cryptographic signing keys to submit transactions on behalf of users. These keys are the most sensitive cryptographic material in the protocol. Their management is designed with defense in depth: Enclave-side key generation: Signing keys are generated inside the TEE enclave at protocol genesis using the enclave’s hardware-provided random number generation. Keys are never generated outside the enclave and never imported from external sources. No-export policy: The enclave is configured with a strict no-export policy for signing keys. There is no API, no administrative backdoor, and no recovery procedure that allows key material to leave the enclave in plaintext form. If an enclave is destroyed — due to hardware failure or deliberate decommissioning — the associated keys are permanently lost and new keys must be generated in a new enclave. Multi-signature thresholds: For execution events above configurable value thresholds, the Execution Sentinel requires multi-signature authorization across multiple independent enclaves. This ensures that compromise of a single hardware instance cannot enable unauthorized high-value transactions. Sealed key backup: Enclave sealing — TEE’s mechanism for encrypting data to a specific enclave identity — is used to create hardware-bound backups of key material. Sealed backups can only be unsealed by an enclave with the identical measurement on the identical hardware platform, providing recovery capability without creating extraction risk.Secure hardware integration is part of SURCHI’s Phase 2 rollout. See the roadmap for deployment timelines.