Module 13: Trading Systems and Automation
On-Chain Automation
Chapter 8 of 12 · about 4 minutes
8.1 Automation without an exchange
Node preferred self-custody (Module 2) and didn't want to leave funds on an exchange for a bot. "Can I automate trades while keeping my assets in my own wallet?"
"In several ways," said Hash. "On-chain automation lets smart contracts or approved services act for you, within limits you set. It removes exchange custody risk, but adds smart contract risk and makes your permissions the most important part of the setup."
8.2 Ways to automate on-chain
| Method | How it works | Example use |
|---|---|---|
| On-chain limit orders | You sign an order; it executes when the price is reached | Buy ETH if it falls to a set price |
| Intent-based orders | You sign a desired outcome; solvers compete to fill it (Module 9, Chapter 2) | Swap at the best available price within a time window |
| Recurring orders | A protocol executes swaps on a schedule | Weekly DCA from stablecoins into ETH |
| Automation networks (keepers) | Third-party networks trigger contract actions when conditions are met | Repay a loan if the health factor drops |
| Vaults | Deposit into a smart contract that runs a strategy (Module 9) | Automated liquidity management or options vaults |
| Smart account permissions | Grant limited, time-bound permissions to an app or agent (Module 2, Chapter 13) | Allow a bot to swap up to $500 a day, nothing else |
8.3 How on-chain orders differ
On a centralised exchange, the exchange holds your funds and matches orders internally. On-chain, your order is usually a signed message or a pre-approved permission that someone else executes later.
That means the security lessons of Module 2 apply directly:
| On-chain automation step | Security consideration |
|---|---|
| Approving tokens for the order contract | Approvals can be exploited if the contract is malicious or hacked (Module 2, Chapter 8) |
| Signing the order | Read exactly what you're signing (Module 2, Chapter 7) |
| Waiting for execution | Your order may be visible, and exposed to MEV (Module 3, Chapter 11) |
| Cancelling | Some cancellations require an on-chain transaction and gas |
8.4 Protective automation in DeFi
One of the most valuable uses of on-chain automation is protection, not profit.
Example: automated loan protection. Node has a DeFi loan with a health factor of 1.65 (Module 9, Chapter 6). Node sets up an automation that:
| Trigger | Action |
|---|---|
| Health factor falls below 1.4 | Repay 20% of the loan from a reserve of stablecoins |
| Health factor falls below 1.25 | Repay another 30% |
This works while Node sleeps. But it depends on the automation service working correctly, having enough gas, and executing in time during congestion. It reduces risk without eliminating it, so Node keeps the alert as well (Module 9, Chapter 6).
8.5 Session keys and limited permissions
Smart accounts (Module 2, Chapter 13) allow session keys: temporary keys with narrowly limited permissions, such as:
| Limit | Example |
|---|---|
| Specific contracts only | Only a particular DEX |
| Specific actions only | Swaps only, no transfers |
| Spending caps | Up to $500 per day |
| Time limits | Valid for 7 days |
| Token limits | Only USDC and ETH |
Session keys let automation act without holding your main keys. If a session key is compromised, the damage is limited to what it was allowed to do.
"So instead of giving the bot my whole wallet, I give it a small, fenced-off allowance," said Node.
"That's the right mental model," said Hash. "It's the on-chain version of an API key without withdrawal permission (Chapter 6)."
8.6 Risks of on-chain automation
| Risk | Explanation |
|---|---|
| Smart contract bugs | The automation or vault contract can be exploited (Module 9, Chapter 13) |
| Excessive approvals | Unlimited approvals for automation contracts expose all of a token (Module 2, Chapter 8) |
| Execution failure | Congestion, gas spikes, or keeper failures prevent timely execution |
| MEV | Pending orders and predictable automation can be front-run or sandwiched (Module 3, Chapter 11) |
| Oracle issues | Automation triggered by wrong prices (Module 3, Chapter 12) |
| Phishing | Fake automation tools request dangerous signatures (Module 2, Chapter 10) |
8.7 Try it yourself
On a testnet, place an on-chain limit order or recurring swap using a DEX or protocol that supports it. Note exactly what you approved and signed. Then check your token approvals (Module 2, Chapter 8) and revoke any you no longer need. If your wallet supports smart account permissions or session keys, explore what limits you could set.
Key takeaways from this chapter
- On-chain automation lets smart contracts or approved services act for you while assets stay in self-custody.
- Methods include limit orders, intents, recurring orders, automation networks, vaults, and smart account permissions.
- On-chain automation relies on signatures and approvals, so Module 2's security lessons apply directly.
- Protective automation, like automated loan repayment, can reduce risk but isn't guaranteed to execute in time.
- Session keys grant narrow, time-limited permissions, limiting damage if compromised.
- Risks include contract bugs, excessive approvals, execution failure, MEV, oracle issues, and phishing.