How Non-Custodial LP Automation Actually Works (Contracts, Keepers, Guards)

The reasonable question about any automation tool is: if a bot is managing my liquidity, what stops it from running off with it? For Super9MM the answer is architectural. Your funds sit in a smart contract that only you can withdraw from, a keeper is whitelisted to call a fixed set of automation functions and nothing else, and on-chain guards constrain every action it can take. Custody never leaves you.

The building block: a per-user Automator contract

When you use Super9MM, your liquidity position lives inside your own Automator contract — one contract per user, holding your position and nobody else’s. This is the single most important design decision, so it is worth being precise about what it means. There is no shared pool. Your capital is not commingled with other users’ funds. The contract has an owner — you — and the non-custodial guarantee is enforced in code: only the owner can withdraw. The keeper cannot pull your funds out. The Super9MM team cannot pull your funds out. Withdrawal is an owner-only function, full stop.

If you want the low-level details of how the contract is structured and what each function does, the Automator contract walkthrough goes deeper than we do here.

The keeper: an off-chain bot on a short leash

Automation needs something watching the market and firing transactions at the right moments. A keeper is that off-chain bot. It monitors positions and, when conditions call for it, calls your Automator to rebalance, compound, or take profit.

The critical constraint is what the keeper is allowed to call. It is whitelisted to invoke only the hard-coded automation functions on your contract — rebalance, compound, accumulate, take-profit or stop-loss, DCA — and it has no access to anything outside that set. It cannot withdraw. It cannot change the owner. It cannot redirect funds to another address. If the keeper were compromised tomorrow, the worst it could do is trigger the automation functions it is already permitted to call, and even those are fenced in by the guards below. The keeper is a scheduler with a very short leash, not a custodian.

The guards: on-chain limits the keeper cannot cross

Whitelisting the keeper to a fixed function set is the first layer. The second layer is on-chain guards that constrain how those functions may execute — checks written into the contract itself, so they hold no matter who calls or what the off-chain bot intends.

TWAP price-manipulation check

The most dangerous moment for any automated LP action is a rebalance during a manipulated price. If an attacker could yank the pool price, trigger a rebalance at that fake price, and restore it, they could drain value. The TWAP guard defends against this. Time-weighted average price is derived from price over a window, which is expensive and impractical to fake for a meaningful duration. Before acting, the contract compares the current spot price against the TWAP; if they diverge too far — the signature of manipulation or a flash-crash — the action is blocked. The keeper cannot force a rebalance into a manipulated price because the contract itself refuses.

Rate limit

The second guard is a rate limit. Automation functions cannot be called arbitrarily often; the contract enforces spacing between actions. This caps the blast radius of a malfunctioning or hostile keeper — it cannot churn your position with a flood of transactions to bleed it through fees or repeated re-centering. Actions happen at a sane cadence or not at all.

You keep the override

On top of ownership and the guards, you retain direct control. You can pause automation at any time, and you can withdraw at any time. If you ever dislike what the automation is doing, you are not waiting on anyone’s permission or a support ticket — you act on your own contract directly. The automation runs on your behalf, at your pleasure, and stops the moment you say so.

Contrast: pooled vaults where a manager controls the funds

It helps to see what this is not. In a common alternative design — a pooled vault — many users’ deposits are commingled into one contract, and a manager (a strategist, a multisig, sometimes an admin key) has authority to move that combined pool according to a strategy. That can be convenient, but it concentrates trust: you are relying on the manager not to misbehave, not to get compromised, and not to have a bug that touches everyone’s capital at once. Your funds mingle with strangers’, and the entity with control is not you.

The per-user, owner-only-withdraw model inverts that. There is no pool to drain, no manager holding the keys to everyone’s money, no commingling. The keeper’s authority is narrow and enumerated; the guards are enforced by the chain; and withdrawal is yours alone. Trust is minimized by structure rather than by promises.

What automation does and does not protect against

Being honest about the boundaries matters. This architecture is designed to keep custody with you and to constrain the keeper — it addresses the “who can touch my funds” question. It does not make you immune to market risk. Concentrated liquidity still carries impermanent loss when the two tokens diverge in price; automation manages your range and re-centers efficiently, but it cannot repeal price movement. And Super9MM is an independent, non-custodial automation layer built on top of Uniswap V3 on Robinhood Chain — it is not affiliated with Uniswap Labs or Robinhood. Safety here means non-custodial by design and keeper actions fenced by on-chain guards; it does not mean risk-free yield.

How the fee model fits the trust story

The economics reinforce the design. Super9MM charges a performance fee of 9% of earned yield only — there is no deposit, entry, or exit fee, and the fee never touches your principal or your impermanent loss. You keep 91% of what your position earns. The fee is hard-capped at 20% on-chain, so it cannot be quietly raised beyond that ceiling. The platform only earns when your position earns, which aligns its incentives with keeping you profitably in range rather than churning your capital.

Put the pieces together — a per-user contract with owner-only withdraw, a keeper whitelisted to hard-coded functions, a TWAP guard and a rate limit enforced on-chain, an owner override, and a yield-only capped fee — and you have automation you do not have to hand custody to obtain. If you want to go deeper, read the contract walkthrough, weigh it against managing a position manually, or start configuring at super9mm.com.