Automated Yield Strategy Bots: Pendle + Kamino + Lido Cross-Chain Optimization
Building a DeFi yield optimization bot means wiring together Pendle for fixed-rate yield, Kamino for Solana liquidity, and Lido for liquid staking — and doing that across both EVM and Solana chains in a single coherent strategy. Most developers end up with a graveyard of half-finished protocol SDKs, inconsistent error handling, and fragile RPC logic before they even write the first line of strategy code. WAIaaS gives you one unified API across 15 DeFi protocols and 18 networks so you can focus on the strategy, not the plumbing.
The Real Problem: Protocol Fragmentation
Cross-chain yield optimization isn't conceptually hard. The idea is simple: find the best risk-adjusted yield available, rotate capital toward it, and hedge where needed. Pendle lets you strip fixed yield from yield-bearing tokens. Kamino concentrates liquidity on Solana for boosted LP returns. Lido gives you stETH so your staked ETH keeps earning while you deploy it elsewhere.
The implementation is hard because each of those protocols has its own SDK, its own transaction format, its own RPC requirements, and its own quirks. Add in cross-chain bridging via LI.FI or Across, and you're now managing async state across multiple chains simultaneously. A bot that sounds like a weekend project turns into a months-long integration effort — before you've written a single line of strategy logic.
The stakes are real. Yield optimization bots that can't react quickly to rate changes leave basis points on the table. Bots that have brittle multi-SDK setups go down at the worst moments. And bots that don't have proper policy guardrails can drain a wallet on a bad parameter.
One API Across 15 Protocols
WAIaaS integrates 15 DeFi protocol providers: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap. That's the full stack for a cross-chain yield strategy — Lido and Aave on EVM, Kamino and Jito on Solana, Pendle for fixed yield, LI.FI or Across for bridging — all behind a single REST API running locally at 127.0.0.1:3100.
The architecture is straightforward. You spin up the WAIaaS daemon (one Docker container), create wallets for each chain, create session tokens for your bot, set spending policies, and then call the action API. Every DeFi operation goes through the same endpoint pattern:
POST /v1/actions/<provider>/<action>
Authorization: Bearer wai_sess_<token>
Your bot doesn't need to know about Kamino's SDK, Pendle's contract ABI, or Lido's submit method. It just speaks REST.
Structuring a Cross-Chain Yield Bot
Here's how you'd architect a Pendle + Kamino + Lido optimization bot using WAIaaS.
Step 1: Separate wallets per chain. You want an EVM wallet for Lido/Pendle/Aave and a Solana wallet for Kamino/Jito/Jupiter. Each wallet gets its own session token. Your strategy engine holds both tokens and routes actions to the right one.
Step 2: Policy first, strategy second. Before your bot executes anything, define the guardrails. A spending limit policy with a daily cap, an allowed tokens whitelist, and a contract whitelist prevents a strategy bug from becoming a catastrophic loss.
# Create spending limit on the EVM wallet
curl -X POST http://127.0.0.1:3100/v1/policies \
-H "Content-Type: application/json" \
-H "X-Master-Password: my-secret-password" \
-d '{
"walletId": "<evm-wallet-uuid>",
"type": "SPENDING_LIMIT",
"rules": {
"instant_max_usd": 100,
"notify_max_usd": 1000,
"delay_max_usd": 10000,
"delay_seconds": 900,
"daily_limit_usd": 50000
}
}'
Transactions above $10,000 will queue for 15 minutes before executing. Transactions above the daily limit get blocked entirely. This isn't optional safety theater — it's the difference between a recoverable bug and a drained wallet.
The policy engine supports 21 policy types. For a yield bot specifically, LENDING_LTV_LIMIT is critical: it caps the loan-to-value ratio your bot can reach on Aave or Kamino lending. LENDING_ASSET_WHITELIST ensures the bot can only supply or borrow approved assets. CONTRACT_WHITELIST enforces that only known protocol contracts can be called.
Step 3: Check positions before acting. Your strategy loop should start by reading the current state. WAIaaS exposes DeFi positions across protocols through a single call that returns lending positions, staking balances, and LP positions.
curl http://127.0.0.1:3100/v1/wallet/balance \
-H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."
Step 4: Execute the strategy actions. Here's where the unified API pays off. Lido staking, a Jupiter swap on Solana, and a Kamino deposit all follow the same pattern — you just change the provider name.
# Stake ETH via Lido
curl -X POST http://127.0.0.1:3100/v1/actions/lido-staking/stake \
-H "Content-Type: application/json" \
-H "Authorization: Bearer wai_sess_<evm-token>" \
-d '{
"amount": "1.0",
"network": "ethereum-mainnet"
}'
# Swap SOL → USDC via Jupiter before depositing to Kamino
curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
-H "Content-Type: application/json" \
-H "Authorization: Bearer wai_sess_<solana-token>" \
-d '{
"inputMint": "So11111111111111111111111111111111111111112",
"outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
"amount": "1000000000"
}'
For Pendle, you're interacting with yield token markets — buying PT (principal tokens) to lock in a fixed rate, or LP'ing to earn trading fees. For cross-chain rebalancing, you'd route through LI.FI or Across depending on which bridge offers better rates for that specific route.
Dry-Run Before Every Rebalance
Any strategy that moves meaningful capital should simulate before executing. WAIaaS has a dry-run flag on every transaction:
curl -X POST http://127.0.0.1:3100/v1/transactions/send \
-H "Content-Type: application/json" \
-H "Authorization: Bearer wai_sess_<token>" \
-d '{
"type": "TRANSFER",
"to": "recipient-address",
"amount": "0.1",
"dryRun": true
}'
Pass "dryRun": true and the request runs through the full 7-stage transaction pipeline — validation, auth check, policy evaluation, gas estimation — but stops before broadcasting. You get back exactly what would happen, including any policy denial, without committing to the chain. For a yield bot that's rebalancing every few hours, this is how you validate the move before making it.
The TypeScript SDK for Strategy Code
If you're writing your strategy engine in TypeScript rather than shelling out to curl, the @waiaas/sdk package wraps the REST API cleanly:
import { WAIaaSClient, WAIaaSError } from '@waiaas/sdk';
const evmClient = new WAIaaSClient({
baseUrl: 'http://127.0.0.1:3100',
sessionToken: process.env.EVM_SESSION_TOKEN,
});
const solanaClient = new WAIaaSClient({
baseUrl: 'http://127.0.0.1:3100',
sessionToken: process.env.SOLANA_SESSION_TOKEN,
});
// Check balances on both chains before deciding where to rotate yield
const [evmBalance, solanaBalance] = await Promise.all([
evmClient.getBalance(),
solanaClient.getBalance(),
]);
console.log(`EVM: ${evmBalance.balance} ${evmBalance.symbol}`);
console.log(`Solana: ${solanaBalance.balance} ${solanaBalance.symbol}`);
Error handling is typed and consistent across every protocol:
try {
const tx = await evmClient.sendToken({ to: '...', amount: '1.0' });
} catch (error) {
if (error instanceof WAIaaSError) {
// error.code: INSUFFICIENT_BALANCE, POLICY_DENIED, TOKEN_EXPIRED
console.error(`[${error.code}] ${error.message}`);
if (error.code === 'POLICY_DENIED') {
// Strategy tried to exceed spending limit — log and skip this cycle
}
}
}
The SDK covers getBalance(), getAddress(), getAssets(), sendToken(), getTransaction(), listTransactions(), signTransaction(), and x402Fetch() — enough to build a complete strategy loop without touching the raw REST API at all. A Python SDK (pip install waiaas) is also available with async/await support for teams that prefer Python for quant work.
Gas-Conditional Execution
Yield optimization on EVM is heavily gas-sensitive. Rebalancing a Pendle position during a gas spike can wipe out days of yield. WAIaaS has a gas conditional execution feature that holds a transaction until the gas price meets a threshold — the transaction queues and executes automatically when conditions are met, without your bot needing to poll.
This is particularly useful for Lido staking operations and Aave supply/withdraw calls that don't need to happen in the same block they're triggered — you set the gas threshold and let the daemon handle the timing.
Human-in-the-Loop for Large Moves
For rebalancing moves above a certain size — say, bridging $50k from EVM to Solana via Across — you probably want a human to approve before execution. The policy engine's APPROVAL tier combined with WalletConnect integration handles this:
# Approve a pending transaction (ownerAuth via WalletConnect or Telegram)
curl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id>/approve \
-H "X-Owner-Signature: <ed25519-or-secp256k1-signature>" \
-H "X-Owner-Message: <signed-message>"
When a transaction hits the APPROVAL tier, the daemon sends a push notification through the configured signing channel (push relay, Telegram, or WalletConnect). The fund owner reviews and signs on their phone. The bot waits. Once approved, execution continues automatically.
This is how you build a yield bot that scales to serious capital: the bot handles the analysis and routine operations autonomously, but large moves require a human signature.
Quick Start: From Zero to Running Strategy
1. Start the daemon
git clone https://github.com/waiaas/WAIaaS.git
cd WAIaaS
docker compose up -d
2. Create wallets and sessions via CLI
npm install -g @waiaas/cli
waiaas quickset --mode mainnet
This creates wallets across chains and outputs MCP session config in one step. For programmatic setup, use the REST API directly:
# Create EVM wallet
curl -X POST http://127.0.0.1:3100/v1/wallets \
-H "Content-Type: application/json" \
-H "X-Master-Password: my-secret-password" \
-d '{"name": "evm-yield", "chain": "evm", "environment": "mainnet"}'
# Create session for your bot
curl -X POST http://127.0.0.1:3100/v1/sessions \
-H "Content-Type: application/json" \
-H "X-Master-Password: my-secret-password" \
-d '{"walletId": "<wallet-uuid>"}'
3. Set policies before funding
Configure SPENDING_LIMIT, ALLOWED_TOKENS, CONTRACT_WHITELIST, and LENDING_LTV_LIMIT before sending any capital to the wallet. The policy engine is default-deny: transactions to contracts not on the whitelist are blocked automatically.
4. Install the SDK and write your strategy
npm install @waiaas/sdk
Your strategy loop calls getBalance() → evaluate yield opportunities → dry-run the rebalance → execute if simulation passes.
5. Explore the interactive API docs
open http://127.0.0.1:3100/reference
The interactive Scalar API reference at /reference documents all 39 REST API route modules with live request/response examples. It's the fastest way to explore what's available for a specific protocol before writing code.
What's Next
The 15 DeFi protocol integrations in WAIaaS cover the most common yield strategies, but the architecture is built for composition — Pendle PT positions hedged with Hyperliquid perps, Kamino LP positions funded via Jupiter swaps, Lido stETH bridged to Solana via Across. The policy engine with 21 policy types gives you the guardrails to run those strategies with real capital.
Explore the full codebase and open issues on GitHub at https://github.com/waiaas/WAIaaS, and see the complete documentation and protocol coverage at https://waiaas.ai.
Top comments (0)