Automation
Rules that act on your positions while you are not watching, without Hoodium ever holding a key, taking custody, or being able to do anything you did not sign for.
The model in one paragraph
You grant the automation contract operator rights over your position NFT (setApprovalForAll), then sign an EIP-712 order naming one position, one trigger and hard limits. An allowlisted relayer watches for the condition and, when it is met, submits your order to the contract. The contract verifies the signature against the position's current owner before it acts, enforces the limits from the signature rather than from anything the relayer says, and pays every proceed to the owner. Governance can pause relaying entirely; governance cannot touch a position.
What a rule can do
| Kind | What fires | Typical trigger |
|---|---|---|
| Compound | Claims the fees and adds them back to the same range. Liquidity grows, range unchanged. | Fees above an amount, or a fixed interval |
| Harvest | Claims the fees and, when the order names a token, consolidates them into it. The liquidity never moves. | Fees above an amount, or a fixed interval |
| Rebalance | Closes the position, moves the range around the current price, reopens it. | Price leaves a band, held for a buffer |
| Exit | Closes the position and stops. | Price leaves a band, or one token's share of the position's value crosses a threshold |
Triggers
- Price bands are set as a percentage below, above, or both. One-sided is valid.
- A time buffer requires the price to hold past the trigger before it counts, so a wick does not rebalance you. It is capped at 12 hours: past a few hours a buffer stops filtering and starts being a delay that outlasts the move.
- An exposure trigger fires on how much of the position's value has become one token. It is the same question as "am I fully converted into the side that fell", asked directly.
- Fee-amount and interval triggers drive compound and harvest. An interval is a minimum of one hour.
Nothing fires for seven days
A new rule enters shadow mode. It evaluates its trigger and records what it would have done, and executes nothing. After seven days it becomes pending review: you are shown that record, and only your explicit confirmation moves it to armed. The relayer reads armed and nothing else.
This is a lifecycle rather than an on/off flag on purpose. A boolean makes the waiting period a policy somebody has to remember to apply; a state machine makes it the only path, and the transition into armed is the one place in the codebase that can write it.
A rule can be moved to disabled at any time, and revoking the contract's approval in your wallet stops every rule on that venue immediately, with no cooperation from Hoodium needed.
Limits the contract enforces
These are not promises in copy. Each is a revert:
- The performance fee is capped at 5% in the contract's own code. The live rate is 1.5% of the fees a rule claims for you, charged only when a rule fires.
- Exit and rebalance rates are pure functions of the pool's fee tier: 0.01%, 0.03% or 0.05% of the amount withdrawn. Governance cannot widen them at all.
- Gas is recovered at cost and bounded by a ceiling you signed into the order; your own gas ceiling defers any execution that would cost more than you allowed.
- Proceeds go to the owner. There is no recipient parameter for the relayer to fill in.
- Ownership is re-checked at execution. An order signed by a previous owner does not execute for a new one.
Every charge emits a PlatformFeeCharged event beside the action it was taken from, so any question about a specific execution is answerable from its transaction hash.
Which keys exist
Governance
Can set the executor, set the allowlisted swap router, set the fee within the coded cap, pause relaying, and hand governance on. Cannot move, close or touch a position. Its key never sits in a server environment.
Executor (the relayer)
A separate wallet whose key lives in the worker's environment and pays the gas to relay. It can only submit orders that owners actually signed, within the limits in those signatures. A stolen executor key cannot invent an order or redirect a proceed.
The split is the point: the key that has to live on a server is the one that can do the least.
When the contract is redeployed
Orders are bound to the deployment's EIP-712 domain, so an order signed against a previous instance is refused by the contract and, before that, by the relayer's own address check. This is a safety property, not a bug: it means an old signature cannot be replayed against new code. It does mean that when Hoodium ships a new automation contract, owners re-sign their rules in the app. The app tells you when a rule is stranded.
What automation cannot protect you from
- A rebalance is a real trade at a real price. Rebalancing into a falling market realises the loss the range was already carrying. Automation changes when that happens, not whether.
- A trigger evaluated on chain state can be met and then unmet before the relay lands. The time buffer narrows this; it cannot close it.
- If the relayer is down or the chain is congested, a rule fires late or not at all. Nothing accrues in the meantime and nothing is owed, because a rule that never fires costs nothing. A rule is still not a guarantee of execution.