You can lose money using this product. This page is a plain-language account of how, written to be understood rather than to satisfy a lawyer. It is not a substitute for the terms.
Providing concentrated liquidity means holding two assets in a ratio that changes as the price moves. When one asset rises against the other, you automatically end up holding more of the one that fell and less of the one that rose. Compared to simply holding both tokens, that difference is a loss. It is called impermanent loss, which is a misleading name: once you close the position, it is entirely permanent.
Fees are what compensates for this. Sometimes they do not. A pool can generate less in fees than the position lost to price movement, and the tighter the range, the sharper this trade-off becomes. An agent that manages the range well changes the size of this effect. Nothing removes it.
Impermanent loss is measured against holding the tokens. If both tokens fall, you lose money regardless, and a delta hedge only offsets directional exposure at a cost, imperfectly, and is not enabled by default. A liquidity position is not a savings account and there is no fixed yield anywhere in this product.
Your funds interact with contracts we did not write: the DEX where liquidity sits, the position manager that holds it, the Safe that owns it, and the permission module that constrains the agent. A flaw in any of them can cause loss, and that possibility exists no matter how careful we are.
We have not been through an external audit and we do not claim otherwise. What exists instead is an on-chain permission model you can inspect, and a test suite that attacks our own setup on every change, including tests that try to move funds out and expect to be blocked. That is meaningful, and it is not the same thing as an audit.
The agent runs on a schedule, reads chain data through third-party providers, and signs transactions. Any of these can fail: a node can serve stale data, a transaction can revert, a scheduled run can be delayed. The system is built to detect and stop rather than guess, which protects funds but means a position can sit unmanaged while something is wrong.
This is not hypothetical. In July 2026 our live agent froze for 22 hours because a transient infrastructure hiccup was converted into a permanent standstill by two of our own safeguards. No funds were at risk at any point, and the position remained in the Safe throughout. We published the full account because the failure is visible on-chain either way, and because a product that hides this kind of thing is worse than one that does not.
The agent signs with a key that lives in operational infrastructure. If that key were stolen, the on-chain permissions mean an attacker could not withdraw your funds, but they could still cause disruption within what the role allows. We treat this as a real risk rather than a solved one, which is why the permission scope is deliberately narrow and why an emergency stop exists.
Validating a strategy out of sample reduces the chance that it only worked by accident. It does not make it correct. Market conditions can arrive that nothing in the historical record resembles, and a strategy that held up across eight years of data can still lose money in the next quarter. Our methodology page describes both the process and what it fails to prove.
This product is early. It manages a small amount of real capital in a deliberately narrow pilot, and the surface it has been exercised against is correspondingly small. Bugs that have not shown up yet are more likely here than in mature software. Do not commit capital you cannot afford to lose, and nothing here is financial advice.