Skip to main content

​
Security Architecture

delphAI’s security model is built on Trusted Execution Environments (TEE), ensuring that AI resolution happens in a secure, verifiable, and tamper-proof environment.

​
Trusted Execution Environment (TEE)

​
What is TEE?

A Trusted Execution Environment is a secure area of a processor that guarantees:

Code Integrity

AI resolution logic cannot be modified or tampered with during execution

Data Confidentiality

Data fetched from APIs and used in resolution is protected from unauthorized access

Isolation

AI processes run isolated from the host system and other applications

Attestation

Cryptographic proof that code is running in a genuine TEE environment

​
How delphAI Uses TEE

Key Security Features:
  1. Isolated Execution: AI agent runs in TEE, isolated from external interference
  2. Secure Data Fetching: API calls happen within TEE, protecting data integrity
  3. Verifiable Computation: Every resolution includes attestation proof
  4. Tamper-Proof: Impossible to modify AI logic or manipulate results
  5. Private Keys: Oracle signing keys never leave TEE

​
Security Guarantees

​
What TEE Protects Against

Even if the server operator is malicious, they cannot:
  • Modify the AI resolution logic
  • Tamper with data fetched from APIs
  • Fake resolution outcomes
  • Access private keys used for signing
The TEE ensures that only the verified AI code can execute.
Data fetched from external sources is protected:
  • API responses are processed within TEE
  • Cannot be intercepted or modified in transit
  • Cryptographic proofs ensure data authenticity
  • Source tampering is detectable
The AI resolution code is protected:
  • Verified before execution in TEE
  • Cannot be modified at runtime
  • Updates require new attestation
  • Users can verify which code version is running
TEE provides protection against:
  • Memory access attacks
  • Cache timing attacks
  • Power analysis
  • Other side-channel exploits

​
What TEE Does NOT Protect Against

Important Limitations:
  • Garbage Data In: If ALL data sources provide false information, TEE cannot detect this (oracle relies on source honesty)
  • Smart Contract Bugs: TEE protects resolution logic, not the oracle smart contract itself
  • Network Attacks: DDoS on data sources could delay resolution (fallback mechanisms help)
  • Hardware Vulnerabilities: Extremely rare, but TEE hardware could have undiscovered vulnerabilities

​
Attestation & Verification

​
Remote Attestation

Every resolution includes a remote attestation proving:
  1. Code Identity: Hash of the exact AI code that ran
  2. TEE Authenticity: Cryptographic proof of genuine TEE
  3. Execution Environment: No tampering or modifications
  4. Timestamp: When the resolution occurred

​
How to Verify

Anyone can verify a delphAI resolution: 
// Pseudo-code for verification
function verifyResolution(marketId, resolution) {
    // 1. Check attestation signature
    const attestation = resolution.attestation;
    const isValidTEE = verifyTEESignature(attestation);

    // 2. Verify code hash matches known AI version
    const codeHash = attestation.codeHash;
    const isKnownVersion = verifyCodeHash(codeHash);

    // 3. Check data source proofs
    const dataProofs = resolution.dataProofs;
    const areSourcesValid = verifyDataSources(dataProofs);

    return isValidTEE && isKnownVersion && areSourcesValid;
}

​
Transparency

Open Source AI Logic

AI resolution logic is open source and auditable by anyone

Public Attestations

All attestation proofs are published onchain for verification

Data Source Logs

Complete logs of data fetched during resolution are available

Reproducible Results

Anyone can verify that the same inputs produce the same output

​
Multi-Layer Security

delphAI implements defense-in-depth:

​
Layer 1: TEE Hardware

  • Intel SGX or AMD SEV secure enclaves
  • Hardware-level isolation and encryption
  • Attestation built into silicon

​
Layer 2: Smart Contract Security

  • Audited by leading security firms
  • Multi-signature for critical operations
  • Time-locks on upgrades
  • Emergency pause mechanism

​
Layer 3: Cryptographic Proofs

  • Every resolution cryptographically signed
  • Data sources include integrity proofs
  • Onchain verification of signatures

​
Layer 4: Operational Security

  • Redundant data sources
  • Automated monitoring and alerts
  • Regular security audits

​
Trust Model

​
What You Need to Trust

You must trust that Intel SGX / AMD SEV hardware works as specified.Mitigation: Multiple TEE providers can be used (Intel, AMD, ARM TrustZone)
You must trust that the specified data sources provide accurate information.Mitigation: Use multiple reputable sources; AI cross-verifies
You must trust the oracle smart contract (after audit).Mitigation: Contracts are audited, open source, and time-locked

​
What You DON’T Need to Trust

✅ Oracle operators - TEE ensures they can’t cheat ✅ delphAI team - Cannot manipulate resolutions ✅ Server infrastructure - TEE protects even if servers are compromised ✅ Network intermediaries - Data integrity verified cryptographically

​
Threat Model

​
Attack Scenarios & Defenses

AttackHow TEE ProtectsAdditional Defenses
Operator modifies AI codeTEE verifies code hash before executionAttestation proves code integrity
Man-in-the-middle on API callsData fetched within TEE, encryptedTLS + cryptographic source proofs
Fake resolution submissionPrivate keys only in TEEOnchain signature verification
Reorg attack on blockchainResolution includes block heightMultiple confirmations required
Data source compromiseMulti-source verificationReputation system for sources
TEE vulnerability discoveredDistributed across TEE typesCan migrate to new TEE tech

​
Best Practices for Integrators

Platforms integrating delphAI should:
Always verify the TEE attestation proof before trusting resolution results
Specify multiple reputable data sources in resolution criteria
Only accept resolutions above a certain confidence score
Allow users to dispute resolutions with stake (reduces false positive acceptance)
Set up alerts if attestation patterns change or become suspicious

​
Next Steps

Audits

Review security audit reports

Best Practices

Learn integration security best practices

Oracle Contract

Understand the smart contract security

FAQ

Common security questions answered
⌘I