As blockchain applications expand across multiple chains and execution environments, deployment and operational complexity increases quickly. Multi-chain systems require teams to manage smart contracts, off-chain services, and external dependencies in parallel, introducing a growing maintenance burden over time.
Practical execution constraints often force teams to move non-trivial computation off-chain, which in turn adds new services, data flows, and coordination logic that must remain tightly synchronized with on-chain state. As these boundaries multiply, failures tend to emerge not from core protocol logic, but from the effort required to keep distributed components aligned. User experience degrades when systems depend on users to manually bridge gaps that the infrastructure itself could automate.
Enter the Chainlink Runtime Environment (CRE). Moonsong Labs was given the opportunity to test the capabilities of Chainlink’s all-in-one orchestration layer. To better understand where the CRE fits into this problem space, Moonsong Labs built a set of four working examples. However, before going deeper into these examples, a brief primer on the CRE is helpful.
The CRE is an orchestration layer that lets developers compose Chainlink capabilities including triggers, data fetching, consensus, and chain writes into unified workflows executed by decentralized oracle networks. The product has been purpose-built for on-chain finance and enables institutional-grade functionality without needing to manage significant infrastructure or complex on-chain logic.
Each example explores a different coordination challenge: event-driven automation, external state synchronization, off-chain computation, and large-scale distribution. Rather than treating them as independent demos, we approached them as a single investigation into CRE’s execution model and its practical limits.
What follows is not a feature tour, but a description of how these systems were designed, what constraints mattered, and what architectural patterns emerged.
CRE as a Constrained Execution Environment
Before looking at the examples themselves, it is worth being explicit about CRE’s operating model, because it strongly shapes system design.
CRE workflows execute inside a decentralized oracle network. They are synchronous, short-lived, and deterministic. They are not designed to wait on external services or behave like general-purpose servers. These constraints are intentional. They force workflows to be explicit about inputs, execution, and outputs.
Early on, it became clear that CRE works best when treated as a precision execution layer. Workflows excel at reacting to events, transforming data, and submitting transactions. Anything involving time, polling, or indefinite waiting are areas to leverage with CRE in future development versions.
This principle guided all four examples.
Example 1: Automating Cross-Chain Relaying
The first example addresses a common point of friction in cross-chain transfers. Many bridge designs separate the deposit or burn transaction on the source chain from the mint or release transaction on the destination chain. The separation is structurally sound but operationally brittle. Users must monitor progress, return at the right time, and hold gas on a chain they may not otherwise use.
The relayer example removes that second user action.
The system is split into two CRE workflows and a lightweight backend. The first workflow listens for deposit events on supported source chains. When a deposit occurs, it extracts the relevant metadata and emits a structured message. This workflow does exactly one thing and exits immediately.
At this point, the system must wait for an off-chain attestation to become available. Because CRE workflows do not block or poll, that responsibility moves to the backend. The backend receives the message, polls the attestation service, and triggers the second workflow once the attestation is ready.
The second workflow constructs and submits the destination-chain transaction. Gas is sponsored, which removes the requirement for the user to fund the destination chain.
The important design decision here is not the relaying itself, but the separation of concerns. Event detection, asynchronous waiting, and transaction execution are each handled by a component that is well-suited to the task. CRE workflows remain deterministic, and easy to reason about.
This example establishes a pattern that recurs throughout the rest of the work: CRE workflows as composable execution steps, coordinated externally rather than overloaded internally.
Example 2: Synchronizing External State with an Onchain Allowlist
The second example shifts focus from event reaction to state synchronization.
In regulated environments, token transfers are often gated by allowlists. These lists are typically managed by compliance teams using internal tools such as spreadsheets, databases, or CRMs. Asking those teams to interact directly with smart contracts introduces both operational friction and risk.
In this design, the authoritative state lives off-chain. A CRE workflow reads an external data source, compares it against on-chain state, and applies only the necessary changes. Additions and removals are explicit, idempotent operations.
The smart contract remains simple. It enforces the allowlist but does not attempt to manage it. CRE acts as the bridge between two worlds that already exist.
One subtle challenge here is avoiding drift. External systems change independently, and workflows must be resilient to partial updates or repeated execution. Designing the synchronization logic around diffs rather than full replacements proved important. It ensures that rerunning the workflow produces the same result without unintended side effects. This was a surprising additional benefit to the CRE workflow process.
This example demonstrates that CRE can safely connect non-crypto systems to on-chain enforcement without requiring those systems to understand blockchain mechanics. It also reinforces the idea that workflows should be designed around reconciliation rather than imperative control.
Example 3: Using CRE as a Co-Processor for Off-Chain Computation
The third example pushes on computational boundaries rather than coordination alone.
Certain classes of logic, such as risk modeling or portfolio analysis, are impractical to perform inside the EVM. They require access to external data, complex calculations, or both. At the same time, their outputs often need to be consumed on-chain in a verifiable way.
In this design, CRE workflows run complex off-chain calculations on a schedule and write the resulting metrics back to the blockchain. The chain consumes results, not the computation itself.
This model treats CRE as a co-processor. The blockchain remains the source of truth for enforcement and settlement, while CRE supplies derived data that would otherwise be too expensive or cumbersome to compute on chain.
An important consideration here is trust minimization. The workflow’s role is limited to producing data and submitting it on-chain. Verification and use of that data remain on-chain concerns. CRE does not replace on-chain guarantees; it complements them.
This example highlights a broader design principle: decentralization does not require that all computation happen on-chain. It requires that the boundaries between on-chain and off-chain logic be explicit and well-defined.
Example 4: Large-Scale Distribution with Gas-Sponsored Claims
The final example combines several of the patterns explored earlier.
Token distributions often rely on large off-chain datasets and Merkle proofs. Users are typically responsible for submitting their own claim transactions, which introduces cost, coordination overhead, and a non-trivial failure surface.
In this system, one CRE workflow constructs Merkle proofs from an off-chain dataset. A second workflow submits gas-sponsored claim transactions on behalf of users. The backend coordinates data availability and workflow triggering, while the smart contract verifies proofs and enforces correctness.
What matters here is not the specific distribution mechanism, but the way responsibilities are divided. Proof construction, transaction submission, and verification are cleanly separated. Each component operates within its natural constraints.
This example reinforces the composability of the earlier patterns. Event detection, external data ingestion, and gas abstraction all coexist without any single component becoming overly complex.
Implementation Realities
Across all four examples, workflows were written in TypeScript and compiled to WebAssembly using Javy. Because Javy targets QuickJS, not all Node.js primitives are available. This constraint influenced implementation choices, particularly around cryptographic utilities and standard library usage.
Rather than working around these limitations with ad hoc solutions, we leaned into them. Keeping workflows narrow reduced the need for unsupported primitives and made the execution model clearer.
Another practical decision was to reuse the same backend and frontend across examples. This allowed engineering effort to focus on workflow design rather than boilerplate, and made it easier to compare patterns across use cases.
What Emerged
Taken together, these examples suggest that CRE is most effective when used as a coordination and execution layer, which encourages explicit architectural thinking. State boundaries become clearer. Failure modes are easier to reason about.
Perhaps most importantly, iteration cycles are fast. Once a pattern is understood, workflows can be modified and redeployed quickly, making CRE well-suited for early system design and experimentation.
Closing
This exploration was less about producing polished applications and more about developing intuition. Each example pushed on a different edge of CRE’s execution model and revealed trade-offs that are not immediately obvious from documentation alone.
CRE simplifies architectural complexity, by allowing teams to automate coordination that would otherwise fall on users, without expanding the trusted surface area of their systems.
That, ultimately, is the value these examples are intended to demonstrate.