KRNL Node

Introduction

The KRNL Node is the heart of the KRNL Protocol—a decentralized orchestration engine that enables cryptographically verifiable workflows bridging Web2 services, blockchain interactions, and AI agents. Built as a non-invasive extension to go-ethereum (Geth), it allows developers to execute secure off-chain computations without compromising Ethereum’s consensus or relying on trusted third parties.

Whether you're building a DeFi yield optimizer, a compliance tool for real-world assets, or an AI-driven dApp, the KRNL Node handles complex workflows with end-to-end cryptographic proof, ensuring smart contracts can trust off-chain data as if it were on-chain.

New to development? No worries, here are some of the terms to keep in mind while reading this page:

• Workflow/DSL: A plan with tasks, like a recipe.

• Sandbox/gVisor: A safe isolated space where tasks run within a controlled environment.

• Proof: A digital stamp showing the task was done right. This stamp is created using a key only known to the one requesting the execution and one executing it

• Geth: It's a software which let's you run the Ethreum blockchain on your system

• Executor: Open-source, community-audited code that runs a workflow step like calling an API or calling the balanceOf() on a contract.

• Attestor: Developer-controlled component that signs and verifies execution like a check if things are good to go

• Bundler/Relayer: Think of it as parcel delivery system which deliver your parcel (KRNL response) to the recipient (Target Smart Contract) where a may or may not paymaster pays for the cost of the delivery (Gas fees)

How it works

The KRNL-Node works as follow on a high level:

1. Receives a workflow request (via KRNL SDK or Smart Contract Account).

2. Parses the workflow DSL into a Directed Acyclic Graph (DAG).

3. Executes each step in an isolated gVisor sandbox.

4. Signs all network traffic (HTTP/HTTPS, DNS) for full attestation.

5. Generates a cryptographic proof using ephemeral keys.

6. Bundles results into a UserOp for on-chain execution via a relayer.

Architecture Overview

The KRNL Node extends Geth without modifying its core codebase, running workflow orchestration as parallel services. This "additive-only" design preserves 100% Ethereum Foundation compliance.

At its foundation:

• Core Geth Integration: The node leverages Geth's battle-tested Ethereum client for blockchain interactions.

• Workflow Engine: Processes KRNL DSL-defined workflows as DAGs, where each step (or "kernel") is an isolated task like an HTTP request, EVM query, or AI inference.

• Security Layer: Uses gVisor for sandboxing, ephemeral keys for signing, and a novel executor-attestor separation model to ensure trustless execution.

• Network Attestation: Monitors and cryptographically signs all outbound/inbound traffic (HTTP/HTTPS, DNS), providing forensic-level transparency.

Here's a high-level diagram of the architecture:

KRNL Node
├── Workflow Orchestrator
│   ├── DAG Parser (from KRNL DSL)
│   ├── Step Scheduler
│   └── Input/Output Binding
├── gVisor Sandbox Manager
│   ├── Executor Loader (Open-Source, Community-Verified)
│   └── Attestor Loader (Closed-Source, Developer-Controlled)
└── Proof Generator
    ├── Ephemeral Key Derivation
    └── Network Interceptor (HTTP/HTTPS + DNS)

The node receives workflow requests executes them in isolated environments, attests to the results, and bundles outputs for on-chain delivery.

Key Capabilities

The KRNL Node isn't just a runner—it's a verifiable execution platform. Here's what it enables:

1. Workflow Orchestration as DAGs execute multi-step logic defined in KRNL DSL. For example, a workflow might fetch telemetry from a Web2 API, read an EVM balance, encode results into calldata, and bundle it into an ERC-4337 UserOp.

   • When to Use: For complex automation like cross-chain yield farming or pre-transaction compliance checks.

   • Example DSL Snippet

     {
       "name": "fetch-telemetry",
       "type": "HTTP",
       "image": "ghcr.io/krnl-labs/executor-http@sha256:...",
       "attestor": "https://public.mypinata.cloud/ipfs/...",
       "inputs": {
         "url": "https://api.example.com/telemetry",
         "method": "GET"
       },
       "outputs": [{ "name": "data", "value": "response.body" }]
     }

2. gVisor Sandbox Isolation Each workflow step runs in a user-space kernel sandbox with syscall interception. This provides multi-dimensional isolation to prevent escapes or tampering.

3. Executor & Attestor Management

   • Executors: Community-reviewed, open-source containers for task logic. These are the doers which will go the do the task specified in the DSL workflow

   • Attestors: Developer-controlled for signing results and monitoring traffic.

4. Cryptographic Proof Generation Every execution produces composable proofs using ephemeral keys (derived from master secrets + context). This prevents replays and binds proofs to specific workflows.

   • Network Attestation: Signs full HTTP/HTTPS requests/responses and DNS resolutions for transparency.

5. Bundling & Relaying Outputs are ABI-encoded, wrapped in AuthData structs, and bundled into UserOps for relayers (e.g., Pimlico). The node signs and sends these to external bundlers for on-chain execution.

In summary KRNL node is the heart of the KRNL protocol, which orchestrates the end-to-end flow in a decentralized architecture

What's next?

Executors