kennedy

Posted on Jun 24

We Built an Open-Source SDK for Cross-Chain AI Agents, Here's What Broke

#ai #blockchain #opensource #discuss

It's 3 AM and your AI agent just bridged $500 to a chain you've never heard of.

The logs say "optimal route found." The balance says $0. The agent can't explain why.

This is the problem we spent 6 months solving.

We built Kuberna Labs, an MIT-licensed SDK that gives AI agents secure execution rails across any blockchain. The whole thing is open-source: github.com/kawacukennedy/kuberna-labs

Here's what we actually had to build.

kawacukennedy / kuberna-labs

Agent Orchestration Platform — Deploy, run, and certify autonomous AI agents that execute cross-chain Web3 tasks. Smart contracts, SDK, backend, and dashboard for AI-powered DeFi automation.

Kuberna Labs

Agent Orchestration Platform — Deploy, run, and certify autonomous AI agents that execute cross-chain Web3 tasks.

⭐️ If you find this project useful, please star it on GitHub! ⭐️

It helps others discover the project and motivates contributors.

📋 Table of Contents

Overview

Kuberna Labs gives AI agents secure execution rails across any blockchain: agents parse natural language intents, make autonomous trading decisions, settle via on-chain escrow, and get post-quantum certified for verifiable reputation.

Target users: Web3 developers and teams who want to deploy autonomous AI agents that can trade, monitor, and execute on any chain without managing LLM infrastructure, blockchain RPCs, or certification pipelines.

✨ What Makes Kuberna Different?

Feature	Kuberna	Others
Natural Language → On-Chain Action	Parse "swap 1 ETH for USDC on Solana" → escrow → execution → certificate	Require manual

…

View on GitHub

What "agent execution" actually means

Most people think "AI agent" means a chatbot with tool access. That's not what we're building.

An agent that calls an API and an agent that settles a financial transaction are fundamentally different problems. The first is about formatting HTTP requests. The second is about moving value across chains, proving what happened, and resolving disputes when something goes wrong.

Agent execution, in our definition, means:

An agent forms an intent ("swap 1 ETH for USDC on Solana")
That intent is parsed into a structured, verifiable format
Executors compete to fulfill the intent at the best price
An escrow contract holds funds until conditions are met
A TEE attestation proves the agent's decision was made correctly

Every layer above had to be built from scratch. No off-the-shelf solutions existed for open-source agent settlement.

Why intent-based execution is safer than direct wallets

Giving an agent a private key is the obvious approach. And it's terrifying.

If an agent holds a key, that key is accessible wherever the agent runs. A compromised agent means a drained wallet. There's no intermediary, no dispute window, no recourse.

Our architecture inverts this: the agent never holds keys. It posts intents. Executors compete to fulfill those intents. An on-chain escrow contract settles the transaction only when conditions are met.

const sdk = new KubernaSDK({ apiKey: process.env.KUBERNA_API_KEY })

const intent = await sdk.intents.create({
  sourceChain: "ethereum",
  destChain: "solana",
  sourceToken: "ETH",
  destToken: "USDC",
  sourceAmount: "1.0",
})

The agent posts an intent. The SDK handles the rest. No keys, no custody, no single point of failure.

How we stop the intent parser from hallucinating chains

This was the hardest technical problem we solved.

We started with GPT-4 to parse natural language intents. The results were terrifying:

// Input: "bridge my ETH to Arbitrum"
// GPT-4 output:
{ sourceChain: "Ethereum", destChain: "Arbitrum", token: "ARB" }

It confused the destination chain with the ARB token. If an agent executed this parse, it would swap ETH for ARB instead of bridging. That's a $10,000 hallucination.

We built a 4-layer fallback system:

compromise.js — zero-dependency NLP that works fully offline. Handles 80% of intents.
12 regex patterns — matching "X for Y on Z" and variations. Deterministic, no failure mode.
GPT-4 fallback — only when confidence < 0.6 from layers 1 and 2. Activated in ~15% of cases.
RAG memory — learns from past parses. Common patterns are promoted to layer 2 over time.

Each layer assigns a confidence score. We stop at the first layer with score > 0.6.

The result: zero hallucinated chains in production. 175 tests covering every edge case.

What on-chain escrow looks like for AI agents

Trustless settlement requires an escrow contract that handles the agent-specific edge cases:

function assignExecutor(
  bytes32 intentId,
  address executor,
  bytes calldata params
) external nonReentrant onlyAgent(intentId) {
  Escrow storage e = escrows[intentId];
  require(e.status == EscrowStatus.PENDING, 'not pending');
  e.executor = executor;
  e.executorParams = params;
  e.status = EscrowStatus.ASSIGNED;
  emit ExecutorAssigned(intentId, executor, params);
}

The nonReentrant modifier on assignExecutor and raiseDispute prevents reentrancy attacks. Every intent has a dispute window. If the agent disagrees with execution, funds are held pending resolution.

Why TEE attestation matters for provable decisions

An agent's decision trace must be provable. Without attestation, the agent can claim "I don't know what happened" and you have no way to verify.

We run decision-making inside an SGX enclave. Every inference produces a cryptographic receipt:

{
  "intentId": "0xabc...",
  "decision": "executor_selected",
  "executorAddress": "0xdef...",
  "confidence": 0.87,
  "attestation": "sgx://enclave-123/receipt/0x789..."
}

This receipt is stored on-chain. Anyone can verify that the agent made the decision it claims to have made, inside a trusted execution environment, at a specific point in time.

The circuit breaker problem

An agent that can't stop calling a dead API is an agent that burns money.

We implemented a sliding-window circuit breaker around all OpenAI calls:

CLOSED — normal operation
3 failures in 5 minutes → OPEN
30 second probe interval → HALF_OPEN
Probe succeeds → CLOSED
Probe fails → back to OPEN

const circuit = new CircuitBreaker(intentParser, {
  threshold: 3,
  windowMs: 300_000,
  probeIntervalMs: 30_000,
});

const result = await circuit.call('swap 1 ETH for USDC on Solana');

When the circuit is open, the agent falls back to the local compromise.js parser. No API call needed. The agent still works — it just makes simpler decisions.

Graceful degradation > perfect uptime.

What broke (the honest part)

Not everything went smoothly. Here's what we got wrong:

Math.sin() as a price oracle. Our first "market data provider" used Math.sin() to generate fake price data. It was a placeholder that somehow made it to staging. A real API integration would have caught this earlier.

Direct wallet integration. Our first design gave agents access to a wallet. We reversed this after a close call in testing. The intent-based architecture is harder to build but fundamentally safer.

No circuit breaker. We deployed the first version without rate limiting on API calls. The agent called a dead OpenAI endpoint 47 times before we noticed. Each call cost money. Each call returned nothing.

Intent parser hallucinating chains. The GPT-4 hallucination problem above cost us a week of refactoring. The 4-layer system was born from failure.

Where we're going next

zkTLS integration — proving agent decisions without revealing sensitive data
Solana support — the first non-EVM chain in the execution layer
NEAR Intents — cross-chain settlement using NEAR's intent infrastructure

The whole thing is MIT. 175 tests, all green. If you've fought with cross-chain settlement and won (or lost), I'd love to hear about it in the comments. PRs very welcome.

Next in this series: Why We Don't Let GPT-4 Parse Financial Intents (And What We Use Instead)

DEV Community