TEE Contracts

• The TEE Runtime is responsible for securely ingesting encrypted data, decrypting it inside the enclave, enforcing authorization, and managing execution.
• The TEE Contract executes the application logic (e.g., check credit score, sign a transaction, issue a verifiable credential) on the decrypted data and returns the result to the runtime for re-encryption and delivery.

​

Execution Flow & Data Inputs

TEE contract processing

1. User Request: Contains arguments for the function call (e.g., amount, recipient).
2. Storage Retrieval: The node fetches the user’s encrypted private state associated with the contract.
3. TEE Runtime Processing: The TEE Runtime decrypts inputs inside the enclave, enforces authorization, and prepares the execution context.
4. Contract Execution (WASM Sandbox): The TEE Contract runs on plaintext data in a WASM sandbox environment.
5. Result: The TEE Runtime encrypts the result inside the enclave and returns the encrypted output to the TEE node for delivery.

1. Isolation: Contracts execute in a sandboxed environment with no access to the host file system and no ability to reach arbitrary network endpoints.
2. Privacy: Sensitive data is decrypted and processed only inside the hardware-backed enclave; all inputs and outputs remain encrypted outside the enclave boundary.
3. Verifiability: Contracts are registered on-chain using immutable content identifiers (CIDs), allowing users to cryptographically verify that the exact code they authorized is being executed.

​

Capabilities & Host API

• HTTP Requests: Perform GET and POST requests to explicitly whitelisted external APIs (e.g., airline booking systems or credential submission endpoints). Contracts cannot access arbitrary URLs.
• Crypto Operations: Generate digital signatures and verify cryptographic proofs using keys derived and held exclusively within the enclave.
• Ephemeral Key-Value Store: Read and write temporary execution state scoped to the contract invocation. Stored data exists only for the lifetime of the execution and is not persisted beyond it.

​

Example Contract Logic (Conceptual)

// A hypothetical TEE contract function
pub fn book_flight(user_data: UserProfile, flight_id: String) -> Result<BookingConfirmation, Error> {
    // 1. Validate user has a passport
    if user_data.passport_number.is_empty() {
        return Err("No passport found".into());
    }

    // 2. Call external airline API securely
    // The API sees the passport number, but the node operator does not.
    let response = host::http_post(
        "https://api.airline.com/book",
        json!({ "passport": user_data.passport_number, "flight": flight_id })
    )?;

    // 3. Return confirmation
    Ok(response.confirmation)
}

​

Security & Sandboxing

• Fuel-Based Execution: Each contract invocation is assigned a bounded computation budget (“fuel”), preventing infinite loops and mitigating Denial-of-Service (DoS) attacks.
• Memory Constraints: Hard limits are enforced on memory allocation to prevent resource exhaustion and ensure predictable execution behavior.
• Network Whitelisting: Contracts may only issue network requests to endpoints explicitly authorized in the user’s permission grant or declared in the contract’s manifest. Access to arbitrary URLs is not permitted.

​

TEE Contract Registry

1. Off-chain Storage: The contract’s WebAssembly (WASM) binary is stored off-chain storage (e.g., IPFS).
2. On-chain Registry: TEE Contract Registry maps a human-readable contract identifier tee_contract_name (e.g., booking-contract-v1) to the contract’s immutable Content Identifier (e.g., IPFS CID).
3. Resolution & Verification: Upon receiving an execution request, a TEE node resolves the CID via the registry, retrieves the WASM binary (if not already cached), and cryptographically verifies its integrity before loading it into the enclave for execution.

​

Comparison: Smart Contract vs. TEE Contract