# How Does the KRNL Protocol Work?

#### This page is dedicated to illustrating how the KRNL Protocol works when a dApp submits a transaction to a smart contract, and how smart contracts receive responses from kernels. This is the high level architecture:

#### Step 1 — User interacts with dApp

The user initiates an action (e.g., rebalance, verify, fetch data) through the dApp frontend, which is integrated with KRNL SDK.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FXobbjjUIeaeZkcKrOn1v%2Fstep%201.png?alt=media&#x26;token=fe82c3df-a8e6-4f02-b844-59185383edf6" alt=""><figcaption></figcaption></figure>

#### Step 2 — User Account (EOA) Authorizes a smart contract account

The user’s Externally Owned Account (EOA) delegates execution rights to their SCA via EIP-7702, enabling account abstraction flows.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FGHEMdI58ozbyxZaM0Ltf%2Fstep%202.png?alt=media&#x26;token=960b128a-bfa1-4501-b2b0-f1faf3fecd29" alt=""><figcaption></figcaption></figure>

#### Step 3 — dApp uses KRNL SDK (fetch metadata)

The dApp backend uses the KRNL SDK to retrieve workflow definitions and registry metadata, ensuring the correct kernel set and logic are loaded.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FHGvTeZkpxcdBGwhYc044%2Fstep%203.png?alt=media&#x26;token=927688eb-148b-40cb-9f5f-97fa1931b62f" alt=""><figcaption></figcaption></figure>

#### Step 4 — SDK sends JSON-RPC request to KRNL Node

The execution request (workflow DSL + parameters) is transmitted to the KRNL-Node over JSON-RPC for orchestration.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2Ff68yMZeCJfwczlu9UXbU%2Fstep%204.png?alt=media&#x26;token=069351c9-814a-4e7d-aae4-1f0cdcb222be" alt=""><figcaption></figcaption></figure>

#### Step 5 — Workflow Engine loads the workflow

KRNL-Node parses the workflow DAG, allocates resources, and prepares execution in isolated gVisor sandboxes.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FNMhOuSQHfRcIdiNuFbh2%2Fstep%205.png?alt=media&#x26;token=2d80dce9-a2bb-411f-a5de-d692b803d805" alt=""><figcaption></figcaption></figure>

#### Step 6 — Executor runs steps (sandboxed) and calls externals

Each kernel (API call, blockchain op, data transform) is executed by an Executor

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FltL6Y0E90uZq9nVGvzOq%2Fstep%206.1.png?alt=media&#x26;token=1ce1e016-c2ec-472d-b219-3d38c4bc8b38" alt=""><figcaption></figcaption></figure>

#### Step 7 — Attestor signs the final result

The Attestor monitors network traffic, derives ephemeral keys, and cryptographically signs the final result.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2F7evxnKOh507ysPdqI3AS%2Fstep%206.2.png?alt=media&#x26;token=c8d295e4-f3b7-4640-bc4d-2ebd488e8a7e" alt=""><figcaption></figcaption></figure>

#### Step 8 — KRNL Node sends the UserOps to the Relayer/Bundler&#x20;

The signed execution proof is wrapped into a user operation (userOp) and handed off to the external bundler for blockchain submission.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FNHMre5BvqeEX9YvMtui2%2Fstep%207.png?alt=media&#x26;token=89a88ab6-0e4d-4df1-ae5a-6ccf41b0e166" alt=""><figcaption></figcaption></figure>

#### Step 9 — Bundler forwards the UserOps after validation to designated SCA

The bundler checks proof validity, batches ops if needed, optimizes gas usage, and submits the userOp to the EntryPoint/SCA for on-chain processing.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FZKAsm9Wbu5ZsJMx1jML0%2Fstep%208.png?alt=media&#x26;token=cb0f7aca-b55c-4942-bdb7-73573bcb1113" alt=""><figcaption></figcaption></figure>

#### Step 10 — SCA sends the fees to KRNL Vault & Execute the target smart contract

On-chain, the SCA verifies the attestor’s signature, atomically transfers execution fees to KRNL-Vault, and calls the target smart contract with the verified result.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2FXGnWwtnE5fO3sLuxqwEV%2Fstep%209.png?alt=media&#x26;token=f30b1e60-1fb0-4ab4-ad6e-909c7ce4cf01" alt=""><figcaption></figcaption></figure>

#### Step 11 — Target Contract updates state / business logic

The target contract executes its logic (e.g., swap, asset update) only after validating the KRNL proof, ensuring trustless correctness.

<figure><img src="https://4254516379-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9YZopA2A53QCZtcc7WU0%2Fuploads%2Fs2YYUoMmPkLa7oDFNrRx%2Fstep%2010.png?alt=media&#x26;token=7e8ed211-5ae7-4c96-83a7-a3e2c0944b4e" alt=""><figcaption></figcaption></figure>

<br>