Kido

Demo

About

Kido is a cross-chain Web3 agent platform designed to make advanced blockchain protocols usable by everyday users, not just developers. Instead of forcing users to understand different wallets, gas tokens, bridges, transaction formats, or protocol-specific interfaces, Kido lets them express what they want to achieve in simple language. Kido converts that intent into a structured agent plan that can interact with protocols across multiple chains, such as Uniswap and Morpho on Ethereum and Cetus on Sui. For example, a user could ask Kido to swap assets, move liquidity across chains, repay a risky lending position, or rebalance funds without manually navigating every protocol. Kido is paired with Amane, a universal financial authority layer that gives agents bounded permissions rather than unrestricted access to user funds. Amane creates chain-native accounts on Ethereum and Sui that share the same root controller and policy model. On Sui, an Ethereum wallet can authorize an action using a secp256k1 signature, while an untrusted relayer submits the actual Sui transaction and pays gas. The Amane Move package independently verifies the signature, account, amount, destination, adapter, nonce, expiry, policy, and budget before allowing the action to execute. This means Kido can automate sophisticated cross-chain workflows while keeping financial authority constrained and verifiable on-chain. The goal is to bring normal users closer to powerful Web3 protocols by hiding unnecessary technical complexity without hiding the security rules underneath.

How it's made

Kido is built as a cross-chain agent foundry with a separate financial authority layer called Amane. The core idea is that Kido can understand a user’s intent, turn it into a structured execution plan, and interact with protocols across different chains, while Amane independently limits what the agent is financially allowed to do. On the Ethereum side, we built Amane as a smart-account-style Solidity system on Sepolia. It supports bounded actions such as SWAP, REPAY, and PAY, with Root Policies, short-lived Leases, nonces, expiries, budgets, approved adapters, and exact action parameters. We integrated Uniswap v3 for swaps and Aave v3 for lending repayment, and designed the same adapter model to extend to protocols such as Morpho. On Sui, Amane is implemented natively in Move rather than trying to copy Ethereum account abstraction. Each user has a shared Amane account/vault object governed by a deployed Move package. We use Sui’s object model, typed assets, Programmable Transaction Blocks, and a hot-potato ActionTicket pattern. After an action is verified, the Move core creates a typed ActionTicket and releases only the exact controlled balance required for that operation. The approved adapter must consume the ticket within the same transaction, which prevents an untrusted executor from simply taking an unrestricted Coin object and redirecting it elsewhere. One of the more unusual parts of the project is cross-VM authorization. The user can keep an Ethereum secp256k1 controller, such as MetaMask, while still authorizing actions on their Sui Amane account. The Ethereum wallet does not sign a native Sui transaction. Instead, it signs a canonical Amane authorization containing the exact account, chain, asset, amount, destination, adapter, nonce, and deadline. An untrusted relayer then builds and submits the Sui PTB and can pay the SUI gas. The Amane Move package reconstructs the authorization digest on-chain, verifies the secp256k1 signature against the controller stored in the Sui account object, checks the policy and budget, and only then allows the action to proceed. This lets a user interact with Sui without needing a separate Sui wallet or holding SUI for gas, while the relayer remains outside the financial trust boundary. For Sui DeFi, we integrated Cetus CLMM for swaps. On Ethereum, Uniswap provides swap execution and Aave provides repay functionality. Our cross-chain architecture is designed so these can be composed into workflows such as using liquidity on Sui to protect or repay an Ethereum lending position. We are also building the transport layer around cross-chain messaging/bridging so a Kido plan can move value between chain-native Amane endpoints instead of treating each chain as an isolated wallet. Kido itself acts as the planning and orchestration layer. User requirements are converted into a canonical Agent Blueprint describing identity, protocols, assets, actions, permissions, privacy requirements, data sources, recovery behavior, and financial constraints. From that blueprint, Kido can generate protocol-specific execution plans, adapters, runtime configuration, tests, and monitoring logic. The runtime never receives unrestricted authority simply because the AI requested it; every financial action must still fit inside Amane’s on-chain policy envelope. We also built protocol and provider knowledge into the runtime so agents understand the exact protocols, chains, adapters, permissions, and limits they are operating with. For privacy-sensitive workflows, the architecture supports chain-native privacy providers, including Seal on Sui, with additional support being explored for confidential-compute systems such as Nautilus and CRE depending on the chain and trust model. A major engineering focus was making the system adversarial by default. Relayers and executors are treated as untrusted. They can construct malformed transactions, delay execution, or refuse to submit, but they should not be able to change the authorized amount, destination, adapter, account, or policy. We wrote negative tests for replay attacks, unauthorized adapters, wrong recipients, excessive amounts, expired permissions, and signature manipulation. We also added canonical signing tests so the TypeScript, Solidity, and Move implementations agree on exactly the same authorization bytes and hashes. The most “hacky” part is probably making an Ethereum wallet act as the root controller for a Sui-native programmable account without pretending that Ethereum and Sui are the same execution environment. We keep execution fully Sui-native—Move objects, PTBs, typed balances, Move adapters, and Sui gas—while making the owner’s financial authorization portable across VMs through secp256k1 verification. That gives us a universal account experience without relying on a trusted backend to custody funds or define authority.