Your keys, our schedule

For a long time, “automated” in crypto meant one of two things. Either you handed your funds to a platform and trusted it, or you signed every transaction yourself. The first is custody with extra steps. The second isn’t automation.

Smart accounts are a third option, and I don’t think most people have noticed how big that is.

What a smart account changes

A normal wallet is one key that can do anything. A smart account, like ZeroDev’s Kernel, is a contract that decides who is allowed to do what. Your key stays the owner. But you can install extra validators on the account, like a second key that may only call certain contracts, with certain functions, up to certain amounts.

That second key is a session key, and the rules around it are policies. The account checks every transaction against them. If the session key tries anything outside the rules, the transaction simply fails.

How Elitra uses it

Elitra’s recurring buys, which we call AutoBuy, are built on this:

1. You get a Kernel smart account. Its owner is your own embedded wallet, which signs in your browser.
2. When you set up a plan, our server creates a fresh session key for it. In your browser, you sign a permission that lets only that key act, and only inside the plan’s policy.
3. On schedule, our worker uses the session key to send the buy as a user operation. Your account checks it against the policy, runs the swap, and the tokens land back in your account.
4. When you stop the plan, you sign one more transaction that uninstalls the permission. From that moment the session key can’t do anything.

The policy is where it gets concrete. For a buy, the session key may:

• approve USDC to one spender, up to a cap
• send a fee only to our treasury, up to the fee amount
• call the router’s swap only for tokens on an allowlist, only with your account as the recipient, and only up to the amount you set

That last rule is the one I like most. Even if someone stole the session key, the most it could do is buy an allowed token with a capped amount of your money and send it to you.

Some routes go through LI.FI, and those didn’t fit neatly into a call policy. For them the limits live in an on-chain hook instead: a maximum spend per trade, a cooldown, a budget per time window and an expiry date. The comment at the top of that contract sums up its job: it “can only ever cause a userOp to revert.”

What we do hold

I want to be precise here, because “non-custodial” gets thrown around a lot. We do hold something: the session key, encrypted, on our servers. We have to, or nothing could run at 3am on a Tuesday. What we never hold is your owner key or your funds. Your money sits in your account the whole time, and our key can only follow the rules you signed.

That’s the distinction I care about. Custody is about who can move your money anywhere. A permission is about who can do one specific thing. Smart accounts let you give the second without giving the first, and that’s the unlock. Once it clicks, a lot of products that used to need “trust us” don’t anymore.

Where this goes

Recurring buys are the obvious first use. The same pattern works for rebalancing, stop losses, subscriptions, or an AI agent that can trade for you but only inside limits you can read. The hard part isn’t the cryptography anymore. It’s writing policies that are strict enough to be safe and loose enough to be useful, and showing them to people in a way they understand before they sign.

That’s the part I find most interesting right now.