It is not what the tool does with yours. The product is non-custodial: it reads your positions and prepares a transaction that you approve in your own wallet. We never hold your keys and never move your funds. This is published because a tool you can check is worth more than a promise, not because any of it happens on your behalf.
Where the money sits
The capital sits in a Safe smart account controlled by a hardware wallet — one owner, and every owner action signed on the device. Not a hot wallet with a key in a file on a server.
No key our automation holds can move that capital. The keeper — the machine that runs on a schedule — holds a key that can do exactly one thing: trigger a sweep that was already bounded when the module was deployed. It cannot change a destination, a cap, or a fee limit, and it cannot withdraw principal. If the keeper key leaked tomorrow, the worst an attacker could do is cause a sweep that was already due, within the same fee limit — they would be choosing its timing and, up to the cap set by the owner, what it pays to bridge. They could not choose where it goes.
What our automation is not allowed to do
The routine work runs as Safe modules — contracts the owner has explicitly enabled, which can do only what their code does. Ours are written so that:
- destinations are fixed at deploy time. A module cannot send funds to an address chosen at runtime, because the addresses it can send to are compiled into it. Whoever calls it, the money goes where it was always going to go.
- each module does one job. The one that sweeps fees cannot touch a range; the one that handles ranges cannot sweep. Neither can withdraw principal to an outside address.
- timing is enforced on-chain, not by the scheduler. The fee sweep refuses to run again until an interval has passed, measured by the chain's own clock. A machine that reboots, double-fires, or is asked to run twice cannot produce two sweeps. The chain is the authority, not our server.
- the code is immutable. No upgrade path, no proxy, no admin key over behaviour. A few operational settings — the per-sweep cap, the maximum fee, the keeper address — can be changed, and only by the Safe owner: called by anyone else, including the keeper, they revert.
- the owner can switch a module off in one transaction, without needing us, our servers, or our cooperation. Those disabling transactions are prepared in advance, and rebuilt whenever the Safe's state changes.
Both modules were tested against real chain state on a fork before going near live funds — the fee sweeper and the range module each passing their full suite — and the deployed runtime was checked against the reviewed build by hash, not by eye.
How a range is handled
A concentrated liquidity position earns while the price sits inside its range and earns nothing while it sits outside. The obvious response is to move the range back quickly. It is not what these positions do, and that is the one thing our own measurements changed our mind about.
Re-centring is not a free repositioning. It withdraws at the current price, swaps to the ratio the new range needs, and re-deposits — turning a difference that was sitting on paper into a settled one, and paying a swap to do it. A position that drifts just past its edge and comes back has cost nothing if it was left alone.
So the rule is to hold through small excursions rather than chase them. When we priced impermanent loss exactly against these positions, the result pushed us the opposite way from where we expected: re-centring too often did not pay for itself. We publish that because it contradicts what is usually said, not because it flatters us.
Today a re-centre is prepared automatically and approved by the owner. The scheduler works out whether a move is due and assembles the transaction; nothing moves until it is signed. Waiting is not free either: in a steady one-way move a position that waits earns nothing while it sits outside its range and gives up more than one that follows the price. It is a trade-off chosen for choppy markets, and which kind of week it turns out to be is not knowable in advance.
What happens to the fees
Fees and rewards accumulate in the position until they are worth collecting. Collecting costs a transaction and sometimes a swap, so a sweep that fires on every small accrual loses money to gas and slippage. Ours run on an interval, above a floor, and skip silently when there is nothing worth moving.
Where they go is fixed in the module at deploy time, which is what makes the arrangement checkable: the destination cannot be changed by whoever happens to be running the scheduler.
What this does not give anyone
No arrangement here removes market risk. If both assets in a pair fall, the position falls with them, and no amount of architecture changes that. Bounded modules limit what the automation can do wrong; they do nothing about what the market does. A sustained trend in one direction costs money however the range is handled.
And to say it once more plainly: these are the founder's own positions, run with the company's tools. Your positions stay in your wallet, under your keys, and every action the tool prepares is one you approve yourself.