Quex is an Oracle network that enables RWA projects to access, compute, and validate any Web2 data with hardware-level cryptographic security for on-chain use across any blockchain.

Problem

Smart contracts frequently rely on oracles, where an off-chain authority retrieves data from specific external sources and inputs it into dedicated smart contracts. Due to their inherent consensus protocols, blockchains hosting these smart contracts are unable to natively interact with external systems. Despite the maturity of the data oracle ecosystem, boasting a market cap of approximately $15 billion in oracle tokens (https://coinmarketcap.com/view/oracles/), price manipulation within oracles remains a significant threat to DeFi protocols. Since 2021, the annual financial impact of price oracle manipulation attacks is estimated to be no less than $400 million, with one in every three attacks on DeFi protocols in 2023 related to this issue (https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2024/, https://www.chainalysis.com/blog/oracle-manipulation-attacks-rising/).

https://lh7-us.googleusercontent.com/docsz/AD_4nXfkNjBPfiT9CgkyB5SwD8eueA3CUl0oYH3G1RLf4XUHlUTmFJVv2BIYc69qpCIpaEMxyLagT1CscVoDT4S-UtAb04qhK2FY4ro6shVA_XszaewNdwKqBQ8PhvcEFeEG6o1rOCE2a1Ul8kdY_maT0_JwPand?key=IU-OO3DtylreS4r7Ue054Q

A key vulnerability of oracles stems from the ever-increasing demand for data publication on-chain by emerging decentralized applications, particularly within the rapidly expanding real-world asset (RWA) sector. Expected to reach a valuation of $16 trillion by the end of the decade, the RWA sector still heavily relies on trust, lacking mechanisms to verify restrictions on tokenized real estate or to provide on-chain data about underlying asset prices. In response, some networks have begun to implement capabilities for direct HTTPS outcalls to external HTTP-based data sources. For example, the Internet Computer Protocol (ICP) recently introduced this feature, enabling developers to utilize it for a variety of applications such as obtaining real-time cryptocurrency exchange rates, weather data for decentralized insurance, sports scores, stock prices, and more, enhancing integration with other blockchains (https://medium.com/dfinity/beyond-oracles-direct-https-outcalls-from-canister-smart-contracts-on-the-internet-computer-2e4a5bcbee43). It is also a powerful idea for integrating with other blockchains by communicating with multiple corresponding HTTP-based cloud nodes.

However, some intriguing uses of oracles, such as the use of credential-dependent APIs, require that an oracle do considerably more than just transmit data. It may need to manage credentials, log into accounts to scrape data, and so forth. This challenge remains unresolved, but addressing it would extend the capabilities of smart contracts far beyond simple data access. It would enable them to interact with the external world by performing activities typical of Web2 applications, such as sending push notifications, emails, executing transactions on other chains, and more.

Quex oracles

Quex capitalizes on Trusted Execution Environment (TEE) technology by employing CPUs that are equipped with a unique private key to establish secure enclaves. These enclaves represent a cryptographically isolated space within the CPU and its memory, guaranteeing that programs operate within a safeguarded environment. This architecture ensures heightened security and integrity for data processing and verification.

To allow smart contract developers to access arbitrary HTTPS data, we do the following preparations:

1. Generate a private key within the enclave. Leveraging the enclave's hardware-based secure source of randomness, we generate a fresh private and public key pair, which is then encrypted and stored securely within the enclave. This ensures that all cryptographic operations are rooted in a secure environment.
2. Place an HTTPs client within the same enclave. To prevent the possibility of receiving tampered data, the HTTPS client resides within the same secure enclave. This configuration ensures that HTTP responses are genuine and have not been altered, by signing them with the initially generated private key before they exit the enclave.
3. Place an HTTPs server within the same enclave. Although not essential for security, positioning an HTTPS server inside the enclave is necessary for operational reasons. It serves as an endpoint that accepts tasks for the HTTPS client. This arrangement enables the full HTTPS request to be directed to this server, where it is then processed by the HTTPS client and executed securely. The resulting data is signed with the freshly generated private key, ensuring the authenticity of the information transmitted from the enclave.
4. Add remote attestation on-chain.We utilize the TEE's remote attestation feature to confirm that outputs originate from a trusted execution environment. This process involves generating an attestation report that includes the hash of the program running within the enclave and the new public key. Although the generation of this attestation necessitates an SGX processor, its verification is carried out entirely on the blockchain using the Automata-V3-DCAP repository, a specialized Solidity library for such verifications. This verification typically needs to occur only once per oracle node.
5. Verify individual responses. An additional verification contract is used to ensure that each response from the TEE-based oracle node is correctly signed with the newly generated private key. This step is crucial for maintaining the reliability and security of the data, thereby mitigating risks associated with incorrect response verifications.

With these steps implemented and the necessary contracts deployed, it becomes feasible to acquire on-chain verifiable data—simply by sending an HTTPS request to a Quex oracle node, receiving the response, and validating the signature chain within the smart contract.

It is important to note that this description pertains to a pull-based oracle system, where data is requested on demand and not continuously pushed to the blockchain at every update. From the developer's perspective, interaction with the Quex oracle is analogous to modern oracle systems like https://pyth.network and https://redstone.finance. However, for applications that require a steady stream of on-chain data feeds, developers can set up an additional relayer service. This service can be configured to push new data at predefined intervals or based on more complex conditions, ensuring continuous data availability as needed.

Quex oracles network

Quex distinguishes itself through its use of hardware-level cryptography, which offers robust security guarantees that allow a single node to fetch and deliver data from a web source with verifiable accuracy. This means that theoretically, one node alone could handle all requests and provide responses that third parties can verify as unmanipulated.

However, this model presents limitations for two main reasons. Firstly, while a node may not alter the results, there is no guarantee it will always provide a result. To mitigate this risk and enhance the reliability of our oracles, we deploy a network of TEE-based oracles. This setup allows any node within the network to fulfill data requests, thereby implementing a 1-out-of-N security model, where the system continues to function correctly as long as at least one node remains operational.

Secondly, although Quex efficiently handles the availability of public data, accessing APIs that require credentials poses additional challenges. Fortunately, enclaves serve as secure encrypted storage, allowing us to store API keys within them and append these keys to HTTPS requests during execution. This capability makes the Quex oracle network heterogeneous: while some nodes access data from public sources, others, equipped with specific API keys, can access protected data sources. For instance, a node possessing OpenAI keys could securely interface with ChatGPT, facilitating the integration of AI-based logic within smart contracts, thereby expanding the functional scope and capabilities of Quex oracles.