Driving Demand for Enterprise Smart Contracts Using the Trusted Computation Framework and Attested Oracles via Chainlink

Co-authored by Eugene Yarmosh, Intel Systems Architect and TCF Technical Lead, and the Chainlink Labs team.

Blockchains can greatly enhance their capacity to meet enterprise requirements around privacy and scalability by using Chainlink oracles to route transactional computation off-chain to the Trusted Computation Framework (TCF).

To better understand the importance of this new design pattern as featured in Intel’s recent blog post entitled “New Confidential Computing Solutions Emerge on the Hyperledger Avalon Trusted Compute Framework“, we discuss the advantages and limitations of public blockchains, as well as outline the TCF architecture and how attested oracles via Chainlink can enable bi-directional connectivity between on-chain and off-chain environments. To demonstrate how this system works, we detail three industry uses cases in finance, insurance, and global trade in which TCF, Chainlink, and underlying blockchains can work in unison to improve backend business processes and reduce costs for both enterprises and consumers.

Advantages and Limitations of Distributed Computing on Public Blockchain Networks

Ethereum smart contracts are reinventing the infrastructure that powers multi-party transactional contracts. They offer a shared computational platform that stores, maintains, executes, and settles the contract for all parties involved. Participating parties can neither decommit from their obligations nor tamper with the process once the contract is set in motion on the blockchain.

Rather than trust the counterparty or rely on a trusted third party for manual verification of contractual events, smart contracts transform the contract terms into computer code that trigger based on data input. For example, smart derivatives contracts can be automatically triggered by market data, while trade payments can be contingent on IoT sensors confirming the safe arrival of goods. Data-driven smart contracts provide one of the best solutions to automating external business processes involving multi-party workflows by reducing human and cross-network friction.

Public blockchains provide great operational transparency and tamperproof execution, but have clear limitations when it comes to privacy and scalability. These two limitations severely stifle blockchain development and adoption, especially at the enterprise level where high throughput and transactional privacy are mandatory from both an internal and legal standpoint.

Another major problem is connectivity — blockchains can only provide computation on data that’s already stored within the blockchain. Using the Ethereum blockchain as a central database to store the mass amounts of data needed to power global economies is an impractical solution. There are on-chain scaling proposals aimed at expanding the network’s speed and lowering costs, but many are currently in development and still leave major questions about their ability to satisfy enterprise demand.

Rather than trying to solve these problems on-chain, it is advantageous to look towards off-chain solutions. One such proposal is off-loading transactional computing off-chain into the TCF and using Chainlink oracles in a Trusted Execution Environment (TEE), through its implementation of Town Crier, to act as a trusted two-way bridge for communication between on-chain and off-chain environments.

Introducing the Trusted Compute Framework and Its Value Proposition

Trusted Compute Framework (TCF) addresses blockchain scalability and privacy challenges by moving compute-intensive and private data processing off-chain. Other similar approaches typically trade resilience and integrity for scalability and privacy. TCF avoids this trade-off by using a TEE to ensure that off-chain computation is done correctly and securely.

Let’s first explore the benefits of off-chain execution:

  • Off-chain smart contract processing is more efficient than traditional blockchain transactions because it does not require replicated execution at each blockchain node
  • High-volume transactions can be throttled off-chain, e.g. a warehouse temperature sensor stream can be pre-processed off-chain and only average, minimum, and maximum temperatures are recorded on-chain once a day instead of the whole raw temperature data stream
  • Complex processing, such as AI for video or genomics, can be processed off-chain (e.g. due to the limitations of EVM) and the results can be recorded on-chain
  • Flexible privacy policies can be implemented off-chain to enforce what and how much information can be shared on-chain and with which participants
  • In many cases data cannot be put on-chain even when encrypted due to privacy regulations, especially if the blockchain network is spread across multiple geographies. Off-chain execution is, in some cases, the only option for processing this data
  • Integration of the existing enterprise legacy application and external data sources is often impractical without some form of off-chain agents

Off-chain execution by itself has limited value for decentralized computation because it doesn’t support computational trust – a key differentiator of any blockchain. Computational trust assumes the use of computer processing to establish validity of transactions rather than the use of an institution or intermediary.

TCF addresses this gap by using a Trusted Execution Environment (TEE), e.g. Intel SGX, for off-chain execution. Town Crier also leverages TEEs, creating several attributes that make them ideal companions to blockchains:

  • Workload isolation. The TEE has special properties that allow it to isolate its workload execution from all untrusted software including the OS kernel. As a result, even the platform owner (e.g. Cloud Server Provider) cannot access the data being processed by the TEE.
  • TEE attestation. The TEE can provide an attestation verification report that delivers a proof that submitted workloads will be executed on the platform with appropriate hardware capabilities, that the platform’s trusted compute base (opcode, firmware) is up to date, and only authorized algorithms will be used to execute workloads.
  • Policy enforcement. TCF utilizes TEE isolation and attestation to implement capabilities that ensure data confidentiality and integrity and provide cryptographic proof of the valid workload execution that can be stored on-chain. The data from multiple sources can be independently encrypted by the corresponding data owners, processed in decrypted form only within the TEE, and discarded after the processing.

By using a TEE, TCF extends the benefits of blockchain computational trust to off-chain assets such as data, sensors, and compute capacity. If the use cases defined in the beginning of this section are executed within TCF environment, they become a natural extension of decentralized compute.

TCF is a framework that delivers baseline off-chain trusted compute capabilities that can be utilized for building various decentralized applications. A combination of TCF and Chainlink using Town Crier’s approach to TEEs, provides a powerful foundation for building solutions that require trusted and verifiable external data sources (aka attested oracles).

A Technical Overview of the Trusted Computation Framework

The diagram below depicts TCF architecture at a high level. Components in blue depict functions that are generic for most applications. Components shown in orange depict application-specific functions. Smart contracts are depicted as a mix of both colors because some dApps may use the baseline implementation as-is while others may replace or extend it.

A high-level overview of the Trusted Computation Framework (TCF) architecture
A high-level overview of the Trusted Computation Framework (TCF) architecture

Trusted Compute Service (TCS) hosts trusted Workers, e.g. Intel SGX enclaves, and makes them available for execution of Work Orders (WO). During the worker initialization, TCS contacts an external attestation service (e.g. Intel Authentication Service – IAS) to produce the worker’s attestation verification report. TCS maintains a Work Order queue and schedules the Work Orders for execution by the appropriate workers.

Additionally, TCS provides a pluggable API for a workload within the worker to securely access external data sources during its execution. Consequently, submitted WO requests may include input data embedded in the request or they may include a reference (e.g. URI) for accessing the data externally. The latter is particularly useful in the case of large-size data sets, dynamic data, or data that must adhere to rigid privacy requirements. The same is applicable to the WO output data.

Accessing TCS via smart contracts is called proxy model because the blockchain is acting as a proxy. Alternatively, the Requesters can interact with TCS directly via the HTTP Listener (aka direct model). This connectivity option is complementary to the proxy model and it provides (almost) the same interfaces, but its intended use is for supporting specific application requirements, e.g. high WO request rate or privacy policy that doesn’t allow sharing the data on the blockchain.

It should be noted that TCF takes a standard based approach. Its APIs and implementation are compatible with and based on Off-chain Trusted Compute Specification defined by Enterprise Ethereum Alliance (EEA).

Work orders are submitted by the Requesters, e.g. end user front-end UI (as shown on the diagram), or (enterprise app specific) smart contracts, legacy applications, or external data source adaptors.

Requesters can access TCS via TCF smart contracts on the blockchain that provide the following capabilities:

  • Registry listing with entry point to Worker registries in the system
  • Worker registry (usually one per TCS) is used by the TCS to list its workers and by the Requesters to find and verify suitable Workers
  • Work Order queue for scheduling WO requests and getting results back
  • Work Order receipt log for maintaining cryptographic proof of the WO execution

TCF design assumes that it is an open system for use as a part of a broader solution along with other frameworks and libraries. It makes it well-suited for integration with Chainlink to deliver usages dependent on attested and decentralized oracles (as shown on the diagram).

An oracle is a digital agent employed by a smart contract to retrieve and/or connect it to data and systems outside its native blockchain (off-chain). Oracles enable this off-chain connectivity for the smart contract by reformatting external connection points (APIs) so that two different software applications are compatible for data exchange. The oracles can then pull data into the smart contract and/or push data out based on predefined instructions and endpoints outlined in the Service Level Agreement (SLA).

An image showing how Chainlink connects to real-world inputs and outputs.

Chainlink is a decentralized oracle network that gives smart contracts secure and reliable access to data providers, web APIs, enterprise systems, cloud providers, IoT devices, payment systems, other blockchains, and much more. It has the following features:

  1. A robust market of independent oracles providing a range of data and connections
  2. Flexibility to customize an oracle connection including the number of oracles, types and number of data sources, aggregation strategies, staking deposits, trusted execution environments, Mixicles, and more
  3. A reputation framework for evaluating oracles based on on-chain metrics

It’s an all-in-one network for users to customize how their contract communicates with anything off-chain using varying levels of decentralization, data aggregation, and oracle selection.

Without good data and reliable connection, the contract logic running on the blockchain or in the TCF will produce faulty outcomes despite them being secure and functioning properly. Chainlink gives the TCF trusted connection to input data for contract execution and to external networks for relaying output data for contract settlement. It can also relay attestations from the TCF to the blockchain to prove that computation was done correctly, prompting the production of timestamped cryptographic receipts for all parties.

Below are two graphs highlighting the basic architecture of how the process works. In the first diagram, the querying on-chain contract creates a request for the TCF to complete a work order. The Chainlink Node is tasked with routing the message between the two environments and retrieving external APIs that may be needed for execution.

How to relay a work order request and API via Chainlink Nodes to the TCF
How to relay a work order request and API via Chainlink Nodes to the TCF

In the second diagram, the TCF returns a result back to the on-chain contract based on completion of the work order. The consuming response can be an attestation of completion or trigger further action from the on-chain contract such as some type of settlement.

How to use Chainlink Nodes to relay an output from the completed TCF work order to the consuming smart contract
How to use Chainlink Nodes to relay an output from the completed TCF work order to the consuming smart contract

Now that the full architecture is understood, let’s examine three major industries where smart contracts via the TCF design can enhance operational efficiency in backend processes and open up completely new business models for additional revenue streams.


Decentralized Finance (DeFi) is one of the fastest-growing use cases for public blockchains. It uses smart contracts to facilitate a robust market where users can lend, borrow, and generate interest on their own money, as well as make bets and gain/reduce exposure to assets and events, all without a central coordinator. While DeFi applications on public smart contracts may be acceptable to the retail market, it’s currently not applicable to the enterprise space. Finance at the enterprise level is highly regulated, subject to data security laws, and requires access to fiat currencies and customization to truly thrive.

The TCF offers a secure environment where parties can enter into a variety of derivatives contracts in which all terms are kept completely confidential. This is especially attractive for OTC derivatives, where position sizes are very large and information slippage can ruin investment advantages. The TCF also provides off-chain computation to enable high throughput and lower cost updating to contracts before final settlement. Chainlink oracles can relay essential market data needed for execution, send metadata to regulators and repositories, and connect the contract to various payment rails for settlement.


Insurance is a multi-trillion dollar global industry driven by the need for businesses and individuals to manage risk. Given the proclivity for disagreements regarding insurance claims, insurers and policyholders generally operate from positions of mistrust, where policyholders overreport positive attributes to receive favorable rates and insurers raise premiums to account for fraud. By moving policies away from manual verification models based on trust and towards shared infrastructure that automates claims processing directly by data, the insurance industry can save money on the back-end, while re-establishing trust with consumers. Though public blockchains offer tamperproof computation, they lack effective mechanisms for hiding sensitive data about the policy details, payouts, and events data.

The TCF conceals confidential execution details needed to process claims and settle the contract, while Chainlink oracles feed in important data that details events and determines outcomes. Chainlink gives the TCF access to embedded IoT sensors (within trade routes, machinery, personal devices, smart grids, etc), Web APIs that track events data (flights, weather, network uptime), and KYC services to accurately tie claims to identities. Compared to expensive on-chain computation, the TCF provides low-cost processing, which enables more frequent data measurements, such as daily reports on driving metrics to determine car insurance discounts. Chainlink can also relay important insurance metadata to researchers, provide attestations to the blockchain, and connect payouts to external payment systems for settlement.

Global Trade

Globalization is increasing at a rapid rate as world economies become more interconnected via international trade. Global trade involves several components — supply chain, trade financing, and regulation — to successfully move a product from one location to another and to result in a settlement payment. Each of these processes depends upon access to data, and in many cases sensitive data. For example, supply chain and trade finance companies need access to IoT sensors, Web data, and payment systems to track goods and make payments, while regulators need transactional and product metadata throughout the trade route to ensure compliance.

TCF offers a computation engine to process global trade contracts that keeps confidential IoT, GPS, and Web data used to track and maintain quality control, as well as the business logic used. It’s important companies keep this data and logic concealed to avoid it becoming vulnerable to corruption, stolen by competitors, or capitalized on by outside entities frontrunning the competition. The TCF can also compartmentalize data involved in the contract by only giving each entity involved access to the information they need to complete their end. Chainlink oracles act as a trusted bridge to get IoT, Web, and ERP data into the smart contract and send data out in the form of external payments, attestations to produce blockchain receipts, and metadata for regulatory agencies.

Connected Consensus Between Public and Private Computing Environments

By leveraging private and scalable off-chain computation through the TCF and enabling off-chain connectivity via Chainlink, blockchains can focus on their core utility of truth arbitration, while still meeting the demands of enterprises. Through the new TCF design, legacy systems can build next-generation smart contract applications on blockchain networks without the need to remake their backend systems. It opens up a whole new frontier that gives developers tools for customized Dapp designs, as opposed to being stuck in a single framework. The next wave of innovation is not about deciding between on-chain vs. off-chain or public vs. private, but rather a collaboration of these systems to give developers options to seamlessly connect across the different environments.