← ClaudeAtlas

write-ekubo-automationlisted

Write, test, and propose an Ekubo Wallet automation — EVM runtime bytecode the wallet polls on a cron schedule and whose returned calls it queues through the ordinary policy path. Trigger when asked to automate a recurring onchain action, run something every block or on a schedule, react to a chain condition without a live agent, or debug an installed automation.
EkuboProtocol/wallet · ★ 4 · AI & Automation · score 58
Install: claude install-skill EkuboProtocol/wallet
# Write an Ekubo Automation An automation is EVM runtime bytecode installed against one wallet and one network, plus a cron schedule. On each tick the wallet runs your bytecode through `eth_simulateV1` — as the code at the wallet's own address — and reads back a list of calls. Those calls are queued through the same simulation and policy path as anything else the wallet sends. An automation cannot do anything the installed policy does not already allow. You write the contract. You compile it. The wallet takes hex. ## The contract ```solidity interface IEkuboAutomation { struct Call { address to; uint256 value; bytes data; } /// Runs as the wallet, at the wallet's address, inside a simulation whose /// writes are discarded. Deliberately not `view`: probe freely. function automate(bytes calldata config) external returns (Call[] memory); } ``` Return an empty array to mean "nothing to do this tick". Return a non-empty array and every entry executes as one atomic batch. ## Compilation is your responsibility The wallet does not compile anything and has no opinion about your source language. Solidity, Vyper, Huff, or hand-written opcodes are all fine. The contract is that you hand over **deployed runtime bytecode** as hex — solc's `deployedBytecode`, not `bytecode` — that runs correctly on the target network. Getting the artifact field wrong is the most common first mistake: `bytecode` is creation code, and the wallet never runs