Smart contracts, particularly with the advent of tokenized real-world assets and institutional adoption, have evolved considerably from simply consisting of onchain logic on a single blockchain to now requiring access to external data, cross-chain interoperability, identity and compliance solutions, and connectivity to existing systems. These new institutional-grade smart contracts are inherently more complex, and thus, require a more efficient and practical way to build and run them end-to-end.

The Chainlink Runtime Environment (CRE) is an orchestration layer that lets you write institutional-grade smart contracts and run your own workflows in TypeScript or Golang, powered by Chainlink decentralized oracle networks (DONs). With CRE, you can compose different capabilities (e.g., HTTP, onchain reads and writes, signing, consensus) into verifiable workflows that connect smart contracts to APIs, cloud services, AI systems, other blockchains, and more. The workflows then execute across DONs with built-in consensus, serving as a secure, tamper-resistant, and highly available runtime.

In this blog, we’ll walk through five CRE applications that you can deploy and run today, including stablecoin workflows, tokenization orchestration, AI-assisted prediction markets, agent-driven triggers, and custom data feeds. These are just examples; we are sure the community will build many more.

CRE’s Capabilities and Built-In Functionality

At the core of CRE are Capabilities—decentralized microservices that perform tasks, such as making HTTP requests, reading from and writing to blockchains, or running consensus on results. Each capability is powered by its own Capability DON, which allows developers to securely run verifiable offchain functions without hosting any infrastructure. Together, these components form the orchestration layer of CRE, connecting blockchains, data providers, and offchain systems into one interoperable environment.

Through the CRE SDK, you can write workflows in TypeScript or Golang that assemble various capabilities, such as HTTPClient for web API calls and EVMClient for onchain reads and writes.

CRE supports multiple Triggers, such as cron jobs, HTTP calls, or onchain events. CRE also uses Callbacks, which contain your custom business logic that runs in response to a trigger. This modular structure makes it easy to compose multiple services into complex workflows. Developers can securely manage Secrets for API keys, handle asynchronous operations with .result() or .Await(), and rely on CRE’s Byzantine Fault Tolerant consensus to ensure every output is trustworthy.

With CRE, you build once and run everywhere. Developers can orchestrate data oracles, cross-chain operations, compliance checks, and system integrations in a single workflow, all verifiably executed across Chainlink’s verifiable execution environment. Together, these building blocks let you connect smart contracts, APIs, and data services with minimal code.

1. Stablecoin Issuance

Financial institutions and stablecoin issuers can utilize CRE to orchestrate an end-to-end cross-chain stablecoin issuance flow, encompassing deposit capture in existing systems, Proof of Reserve, compliance checks via the Chainlink Automated Compliance Engine (ACE), onchain minting, and cross-chain delivery to the destination network.

This example uses a two-phase architecture: (1) verification and minting, then (2) compliance checks for issuance and volume-based CCIP controls.

Workflow Execution Flow:

Bank/Custodian → HTTP TRIGGER 
    ↓
CRE Workflow → Proof of Reserve Check
    ↓
CRE Workflow → Stablecoin Minting
    ↓
CRE Workflow → ACE Compliance Check
    ↓
CRE Workflow → CCIP Transfer to Depositor on Destination Chain

Phase 1: Verification & Minting

The depositor places USD with a custodian. The custodian confirms receipt by updating the reserve balance and notifying the issuer. The bank/issuer then submits a SWIFT-style MT103 message to a CRE HTTP endpoint to initiate issuance.

This message triggers a CRE workflow, which calls Chainlink Proof of Reserve to perform a secure mint check (mint only if sufficient reserves are verified offchain) with validateProofOfReserve() that fetches the Proof of Reserve Feed endpoint using HTTPClient.

// Define validateProofOfReserve
const validateProofOfReserve = (
  runtime: Runtime<Config>,
  config: Config,
  mintAmount: bigint,
): boolean => {
  runtime.log('\n[PoR Validation] Fetching reserve data...')

  let reserveData: { totalReserve: number; lastUpdated: string }

  reserveData = runtime.runInNodeMode(
    (nodeRuntime: NodeRuntime) => {
      const httpClient = new cre.capabilities.HTTPClient()
      const response = httpClient.sendRequest(nodeRuntime, {
        url: config.porApiUrl,
        method: 'GET',
      }).result()
      const data = JSON.parse(new TextDecoder().decode(response.body))
      return {
        totalReserve: data.totalReserve,
        lastUpdated: data.lastUpdated,
      }
    },
    consensusMedianAggregation()
  )().result()
}
// We check if reserves can cover the mint amount
if (reservesWei < mintAmount) {
  throw new Error(
    `[PoR FAILED] Insufficient reserves: have ${reservesWei} wei (${reserveData.totalReserve} USD), need ${mintAmount} wei for this mint`
  )
}
runtime.log(`✓ PoR validation passed - reserves (${reserveData.totalReserve} USD) can cover mint`)
return true
}

Once the reserves are verified, the CRE workflow writes this verification onchain to the stablecoin smart contract, effectively granting permission for minting the stablecoins. The stablecoin smart contract mints the new stablecoins based on this authorization.

// Encode mint report
const reportData = encodeAbiParameters(
    parseAbiParameters('uint8 instructionType, address beneficiary, uint256 amount, bytes32 bankRef'),
    [INSTRUCTION_MINT, checksummedBeneficiary, amount, bankRefHex],
)
// Generate DON-signed report
const reportResponse = runtime
    .report({
        encodedPayload: hexToBase64(reportData),
        encoderName: 'evm',
        signingAlgo: 'ecdsa',
        hashingAlgo: 'keccak256',
    })
    .result()

// Submit to MintingConsumerWithACE
// CRE Forwarder verifies signatures, then calls onReport()
const resp = evmClient
    .writeReport(runtime, {
        receiver: runtime.config.sepolia.mintingConsumerAddress,
        report: reportResponse,
        gasConfig: { gasLimit: '500000' },
    })
    .result()

Phase 2: Compliance Checks and Issuance

Before sending the minted stablecoins to the depositor, the CRE workflow calls Chainlink Automated Compliance Engine (ACE) and its defined policy  AddressBlacklistPolicy.sol to verify that the depositor’s address is not blacklisted.

// --- Policy Contract (AddressBlacklistPolicy.sol) ---
function run(
    address, bytes4, bytes[] calldata parameters, bytes calldata
) public view override returns (IPolicyEngine.PolicyResult) {
    address addressToCheck = abi.decode(parameters[0], (address));
    // Get storage reference to blacklist mapping
    AddressBlacklistPolicyStorage storage $ = _getAddressBlacklistPolicyStorage();
    if ($.blacklist[addressToCheck]) {
        revert IPolicyEngine.PolicyRejected("address is blacklisted");
    }
    return IPolicyEngine.PolicyResult.Continue;
}

// CONSUMER CONTRACT: MintingConsumerWithACE.sol
function onReport(bytes calldata metadata, bytes calldata report) 
    external 
    runPolicy  // Triggers PolicyEngine to run AddressBlacklistPolicy
{
    processMintReport(report);
}
// CRE WORKFLOW: 
// bank-stablecoin-por-ace-ccip-workflow/main.ts
const resp = evmClient.writeReport(runtime, {
    receiver: runtime.config.sepolia.mintingConsumerAddress,
    report: reportResponse,
}).result()

Once approved, the CRE workflow uses the Chainlink Cross-Chain Interoperability Protocol (CCIP) to enable the transfer of funds cross-chain to the depositor’s address on the destination network. Here, ACE’s VolumePolicy.sol is used to enable cross-chain transfers in a set range. 

// VolumePolicy.sol - Enforces min/max transfer amounts
function run(
    address, bytes4, bytes[] calldata parameters, bytes calldata
) public view override returns (IPolicyEngine.PolicyResult) {
    uint256 amount = abi.decode(parameters[0], (uint256));

    if (($.maxAmount != 0 && amount > $.maxAmount) || amount < $.minAmount) {
        revert IPolicyEngine.PolicyRejected("amount outside allowed volume limits");
    }
    return IPolicyEngine.PolicyResult.Continue;
}

// CRE Workflow (main.ts) - Encode CCIP message
const reportData = encodeAbiParameters(
  parseAbiParameters('uint64 destinationChainSelector, address sender, address beneficiary, uint256 amount, bytes32 bankRef'),
  [destChainSelector, checksummedSender, checksummedBeneficiary, amount, bankRefHex],
)
// Write to CCIPTransferConsumerWithACE
const resp = evmClient
    .writeReport(runtime, {
        receiver: runtime.config.sepolia.ccipConsumerAddress,
        report: reportResponse,
        gasConfig: { gasLimit: '1000000' },
    })
    .result()
runtime.log(`⚠️  CCIP report delivered: ${bytesToHex(resp.txHash)}`)

This example demonstrates how CRE serves as an orchestration layer for the issuance of stablecoins to any supported blockchain, combining onchain and offchain integration, compliance, policy management, and cross-chain interoperability into one process.

The complete source code and instructions for this example can be found in the CRE demo-dapps GitHub repository.

2. Tokenization Platform Orchestration

Tokenization turns real-world assets, such as treasuries, private credit, investment funds, invoices, and carbon credits, into onchain tokens, enabling benefits like real-time settlement, enhanced liquidity, and fractionalization. The complexity lies in keeping issuers, custodians, transfer agents, and other offchain systems of record in sync with smart contracts so lifecycle events remain consistent, compliant, and auditable.

CRE connects these offchain systems to onchain contracts and keeps them synchronized in real time. It can listen for events on both sides, validate schemas and policies, write updates onchain when required, and mirror onchain events back to the offchain system of record so dashboards, ledgers, and compliance tools stay up to date.

This example demonstrates a design pattern using CRE as the orchestration layer between offchain systems of record (e.g., AWS database) and onchain blockchains for the tokenization lifecycle, routing messages in both directions as the asset moves through various stages, such as registration, verification, issuance, transfer, and redemption.

In this use case, the CRE workflow is designed to continuously monitor asset states within a tokenization platform (e.g., a custom ERC-1155–based marketplace). It listens to onchain events, applies schema validation and transformation, and persists the normalized output to an AWS-hosted database via RESTful API calls.

Capturing Onchain State Changes

Using the CRE LogTrigger and HTTP capability, the workflow listens for ERC-1155 contract events, decodes them, and pushes normalized data to an AWS Lambda endpoint that represents an offchain system of record, where it is stored for analysis and compliance. This event-driven approach removes the need for manual polling and allows immediate propagation of onchain changes to offchain systems.

/**
 * Validate Required fields on incoming params.
 */
const REQUIRED_FIELDS = {
  read: ["assetId"],
  AssetRegistered: ["assetId", "issuer", "initialSupply", "assetName"],
  AssetVerified: ["assetId", "isValid"],
  TokensMinted: ["assetId", "amount"],
  TokensRedeemed: ["assetId", "amount"],
  sendNotification: ["assetId", "apiUrl"],
};
...
// within lambda handler
  try {
    // Validate action exists and is supported.
    if (!action || !handlers[action]) {
      return buildResponse(STATUS_BAD_REQUEST, { error: "Invalid action" });
    }
    validateParams(action, params);
    // Execute the specific action handler.
    const result = await handlers[action](client, params);
    return buildResponse(STATUS_OK, result);
  } catch (error) {
    console.error("Error:", error);

Once the event is captured and decoded, the normalized payload is sent to an AWS Lambda endpoint, where it is ingested and written to a DynamoDB table.

On the AWS side, a deployed Lambda function acts as the ingestion layer, processing incoming POST requests. The function parses the payload based on the event type and applies corresponding business rules. Here’s a simplified TypeScript implementation for the AssetRegistered event:

/**
 * Handlers for each supported action.Returns promise.  */
const handlers = {
...
  /**
   * Registers a new asset in DynamoDB.
   */
  AssetRegistered: async (client, { assetId, issuer, initialSupply, assetName }) => {
    const item = {
      AssetId: assetId,
      AssetName: assetName,
      Issuer: issuer,
      Supply: initialSupply,
      Uid: crypto.randomUUID(),
    };
    await putItem(client, item);
    return { message: "Asset registered successfully" };
  },
};

Capturing Offchain State Changes

During stages of the tokenization lifecycle (e.g., registration), there may be a need to send a message from an offchain system of record back to the tokenization platform’s smart contracts. In this case, a Lambda function in AWS represents the offchain system of record and initiates an HTTP POST to trigger a CRE workflow, which then updates the tokenization smart contracts to reflect the registration of new assets, all without the offchain system of record needing to manage RPCs, private keys, gas tokens, or any other blockchain infrastructure.

const handlers = {
  sendNotification: async (client, { assetId, apiUrl }) => {
    const item = await getItem(client, assetId);
    if (!item?.Uid) {
      throw new Error("Asset UID not found");
    }

    const postData = JSON.stringify({
      assetId: Number(assetId),
      uid: item.Uid,
    });

    const parsedUrl = new URL(apiUrl);
    const options = {
     // ...post options
    };

    const response = await new Promise((resolve, reject) => {
      const req = https.request(options, (res) => {
        let data = "";
        res.on("data", (chunk) => (data += chunk));
        res.on("end", () => resolve({ statusCode:        res.statusCode, body: data }));
      });

      req.on("error", reject);
      req.write(postData);
      req.end();
    });

    if (response.statusCode >= 200 && response.statusCode < 300) {
      return {
        message: "POST request sent successfully",
        assetId: Number(assetId),
        uid: item.Uid,
        apiResponse: response.body,
      };
    } else {
      throw new Error(`POST request failed: ${response.body}`);
    }
  },
};

The CRE workflow then takes the relevant data from the HTTP trigger and calls a function in the tokenization platform’s onchain contracts, synchronizing state from the offchain system to the onchain smart contracts for the newly registered asset:

const evmClient = new cre.capabilities.EVMClient(network?.chainSelector.selector)

// generate signed report
const reportResponse = runtime.report({
      encodedPayload: hexToBase64(reportData),
            encoderName: 'evm',
      signingAlgo: 'ecdsa',
      hashingAlgo: 'keccak256',
    })
    .result()

// submit report to the tokenized asset platform contract 
const writeReportResult = evmClient
        .writeReport(runtime, {
            receiver: evmConfig.assetAddress,
            report: reportResponse,
            gasConfig: {
                gasLimit: evmConfig.gasLimit,
            },
        })
        .result()

const txHash = bytesToHex(writeReportResult.txHash)    runtime.log(`write report transaction succeeded: ${txHash}`)

By bridging onchain smart contracts with offchain infrastructure and systems, CRE eliminates operational bottlenecks and delivers a standardized, event-driven, end-to-end solution for tokenization platforms. This paves the way for scalable, institutional-grade tokenization where automation, transparency, and trust work together at scale.

The complete source code and instructions for this example can be found in this GitHub repository.

3. AI-Powered Prediction Market Settlement

Prediction markets are one of the hottest narratives at the moment in the Web3 industry, with applications like Polymarket surging in user acquisition and institutional investment. However, most systems still resolve outcomes either via manual proposer/challenge flows or operator checks against a hard-coded source, which don’t generalize well to nuanced, real-world questions.

With CRE and LLMs, such as Google Vertex AI, settlement becomes event driven and auditable. A market contract requests resolution, CRE invokes Vertex AI against a predefined rubric, and the model returns a structured verdict with confidence and citations. CRE then produces a signed report and the contract finalizes onchain, with any low-confidence or disputed cases escalating to human review. 

This use case shows how CRE combines the probabilistic nature of AI with the deterministic guarantees of blockchains and oracle networks to improve existing Web3 applications. The result in this case is less manual work, faster settlement, and support for markets that rely on subjective or multi-source evidence, all while keeping funds and final settlement onchain with a clear audit trail.

Setting the Stage

The SimpleMarket smart contract allows users to create and participate in prediction markets. When a market closes, it emits a SettlementRequested event, signaling that it’s ready for resolution. In this workflow, CRE acts as the orchestration layer between AI inference, offchain APIs, and onchain settlement, ensuring every step of the process is verifiable and compliant.

event SettlementRequested(
        uint256 indexed marketId,
        string question
    );

Triggering the Workflow

CRE’s LogTrigger continuously monitors onchain events. When it detects a SettlementRequested event, it automatically invokes a CRE workflow. The workflow extracts the event metadata, including the question being resolved, and prepares a structured request for the Gemini API.

Using Gemini with Grounded Search

The Gemini API processes the market question using its multimodal reasoning capabilities, with grounding enabled via Google Search. Grounding ensures that Gemini’s response is anchored to verifiable, real-world information, reducing hallucinations and providing evidence links.

For example, if the market question is “Did SmartCon take place on Nov 4, 2025?”, Gemini searches verified web results, confirms the outcome, and returns a structured JSON response like:

{ "outcome": "Yes", "confidence": 0.97, "sources": [ ... ] }

Writing the Result Onchain

Once the Gemini response is received, CRE generates a signed report that includes the outcome and confidence score. It then calls the market contract’s onReport() function:

function onReport(bytes calldata, bytes calldata report) external override {
  _processReport(report);
}

The smart contract validates and records the settlement onchain, updating its status to Settled or NeedsManual depending on the AI’s confidence.

Persisting Offchain Data

Finally, the workflow logs the AI output, confidence score, and transaction hash to Google Firestore. This provides an audit trail and allows frontends or dashboards to visualize market settlements in real time.

By pairing Google Gemini’s grounded reasoning with CRE, prediction market settlement becomes a trust-minimized, verifiable workflow. This system removes manual intervention, reduces settlement time, and guarantees that every outcome is derived from transparent, consensus-secured computation, bridging onchain smart contracts with offchain intelligence.

The complete source code and instructions for this example can be found in the Google Vertex AI Powered Prediction Market Settlement repository.

4. AI Agents Consuming CRE Workflows With x402 Payments

AI and blockchain are two opposing but complementary paradigms: AI is probabilistic and blockchain is deterministic. According to the International Data Corporation, “AI solutions & services will generate a global economic impact of $22.3 trillion by 2030”. This signals a generational technological shift, one where AI and Web3 converge to reshape how intelligence influences the movement of value through digital systems. But there’s a problem: most AI agents operate as opaque black boxes. They can think, decide, and even transact onchain, but you can’t validate that what they did was correct or safe. If you’re giving economic value to an AI agent, you need constraints and verifiability—proof that the computation, logic, and result are all valid. That’s where Web3 and specifically, CRE, comes in.

CRE introduces verifiable execution, allowing AI agents to trigger deterministic, consensus-verified workflows that add trust to autonomous actions. An agent can decide what to do, but the verification and enforcement happen in a cryptographically verifiable system that checks bounds, limits, and rules, so you don’t have to trust the agent to validate its own reasoning or actions.

x402 As Payment For Consuming CRE Workflows

Coinbase’s x402 is an emerging micropayment pattern that lets clients (including AI agents) pay and call a service in a single request by attaching a proof-of-payment “receipt” to the API call. The service verifies the receipt and then executes, enabling pay-per-use access without long-lived keys or custom billing plumbing. This fits CRE well: An agent can fund a call with x402 and immediately trigger a verifiable CRE workflow.

In this use case, we will demonstrate how an AI agent triggers a reward workflow using x402 for payment. It reads a list of entries from a Google Sheet, selects three winners based on a rubric, and submits the proposed results to CRE. The CRE workflow validates the payload and criteria, enforces any policy checks, and then writes the winners onchain, producing a clear, verifiable audit trail.

Sending The Request

The AI Agent makes a request, including the x402 payment for the CRE workflow to validate selections that it has made from a list of potential winners. In this case, we are using a deployed MCP Server to accept the payment and then call the HTTP trigger to execute the CRE workflow:

The workflow then validates the input data and executes an onchain transaction if all checks pass:

// Validate inputs - workflow will revert if any validation fails
    if vaultRequest.Recipient == "" {
        logger.Error("Validation failed: recipient is required")
        return nil, fmt.Errorf("recipient address is required")
    }
    if !common.IsHexAddress(vaultRequest.Recipient) {
        logger.Error("Validation failed: invalid address format", "recipient", vaultRequest.Recipient)
        return nil, fmt.Errorf("recipient must be a valid Ethereum address")
    }
    if len(vaultRequest.Messages) == 0 {
        logger.Error("Validation failed: at least one message is required")
        return nil, fmt.Errorf("at least one message is required")
    }
    
    logger.Info("Parsed request", "recipient", vaultRequest.Recipient, "message_count", len(vaultRequest.Messages))
    logger.Info("Validation passed, proceeding to store messages")

    txHash, messageCount, err := storeMessages(config, runtime, vaultRequest.Recipient, vaultRequest.Messages)

CRE gives AI agents a verifiable way to act onchain, combining probabilistic reasoning with deterministic execution. By integrating with x402, agents can autonomously pay for and consume decentralized services, enabling a new era of agent-powered economies built on crypto rails that carry real financial actions and value across blockchains.

5. Custom Proof Of Reserve Data Feed

Bringing custom offchain data into smart contracts is a common design pattern for Web3 developers. This example shows how to use CRE to build a Proof of Reserve feed that connects external API data to verifiable onchain state. It highlights the core pattern CRE enables: bridging offchain data sources with onchain actions.

The Proof of Reserve workflow in this demo showcases two distinct execution paths that represent common data movement patterns in decentralized applications. 

Path A: Proactive (CRON or HTTP Trigger)

In the proactive path, the workflow is triggered either on a CRON schedule or through an HTTP request. It performs an end-to-end offchain-to-onchain Proof of Reserve check:

1. Fetch offchain data: The workflow calls an external API that provides the current reserve balance for a token.
   
2. Read onchain state: It queries the ERC-20 contract to obtain the total token supply.
   
3. Compute the report: The workflow scales and formats the data into a consistent structure.
   
4. Write the verified result onchain: It uses the CRE runtime’s evm.writeReport() method to submit a signed report through a Forwarder contract, which performs verification before updating the target contract.
   

Here is an example of the workflow getting triggered via a CRON trigger:

const onCronTrigger = (runtime: Runtime<Config>, payload: CronPayload): string => {
    if (!payload.scheduledExecutionTime) {
        throw new Error('Scheduled execution time is required')
    }
    runtime.log('Running CronTrigger')
    return doPOR(runtime)
}

Once the workflow is triggered, it can do the HTTP request and then perform the Proof of Reserve check:

const httpCapability = new cre.capabilities.HTTPClient()
    const reserveInfo = httpCapability
        .sendRequest(
            runtime,
            fetchReserveInfo,
            ConsensusAggregationByFields<ReserveInfo>({
                lastUpdated: median,
                totalReserve: median,
            }),
        )(runtime.config)
        .result()

    runtime.log(`ReserveInfo ${safeJsonStringify(reserveInfo)}`)

    const totalSupply = getTotalSupply(runtime)
    runtime.log(`TotalSupply ${totalSupply.toString()}`)

    const totalReserveScaled = BigInt(reserveInfo.totalReserve * 1e18)
    runtime.log(`TotalReserveScaled ${totalReserveScaled.toString()}`)

    const nativeTokenBalance = fetchNativeTokenBalance(
        runtime,
        runtime.config.evms[0],
        runtime.config.evms[0].tokenAddress,
    )
    runtime.log(`NativeTokenBalance ${nativeTokenBalance.toString()}`)

This pattern demonstrates how developers can use CRE to implement data feeds similar to Chainlink Proof of Reserve, where offchain data is fetched, validated, and then committed to the blockchain in a single automated loop.

Path B: Reactive (Log Trigger)

In the reactive path, the workflow responds to a specific contract event. When the event is detected, the workflow performs the following sequence:

1. Receives the event payload: The trigger provides the transaction hash and event index, which CRE uses to locate the log onchain.
   
2. Extracts event data: The workflow parses the event topics to identify key parameters, such as the emitter’s address.
   
3. Performs a follow-up query: Using that address, the workflow calls another contract function (e.g., getLastMessage) to fetch related information.
4. Logs the result: The retrieved message or data is displayed in the simulator output, completing the event-driven response loop.

const onLogTrigger = (runtime: Runtime<Config>, payload: EVMLog): string => {
    runtime.log('Running LogTrigger')
    const topics = payload.topics
    if (topics.length < 3) {
        runtime.log('Log payload does not contain enough topics')
        throw new Error(`log payload does not contain enough topics ${topics.length}`)
    }
    // topics[1] is a 32-byte topic, but the address is the last 20 bytes
    const emitter = bytesToHex(topics[1].slice(12))
    runtime.log(`Emitter ${emitter}`)
    const message = getLastMessage(runtime, runtime.config.evms[0], emitter)
    runtime.log(`Message retrieved from the contract ${message}`)
    return message
}

The proactive path executes this logic in response to a CRON or HTTP trigger, while the reactive path uses similar runtime capabilities, but is initiated by a LogTrigger event rather than a timed or external request.

Custom data feeds built with CRE allow developers to securely and verifiably publish offchain data to onchain smart contracts without managing separate infrastructure or middleware. Developers can:

• Run complete end-to-end simulations locally using the cre workflow simulate command.
• Test both scheduled and event-driven behaviors against real testnet environments.
• Validate API integration, contract logic, and report generation before deployment.
  

By providing reusable capabilities, such as HTTPClient, EVMClient, and runtime.report(), CRE streamlines the process of building decentralized data pipelines.

The complete source code and instructions for this example can be found in the CRE Proof of Reserve Feed folder in the CRE SDK Examples repository.

Conclusion

CRE is the all-in-one orchestration layer unlocking institutional-grade smart contracts for onchain finance, as well as native web3 use cases such as connecting smart contracts to AI, any data feed, and much more.

Start building today with the CRE docs, or contact us to learn how CRE can orchestrate your onchain finance use cases.