Assume we get hacked. Then read the rest of this page.
Every automation product asks for access to your money. Most answer the obvious question with a promise about their own conduct. That promise is worth exactly as much as their security, so the useful version of the question is the hostile one: if Qleva were entirely compromised — servers, database, signing key — what could someone do with your wallet?
The answer, in full
Nothing here depends on us behaving well, because none of it is checked by our servers. It is checked by the contract that holds your funds, every time an automation runs.
An attacker could not
Move your funds to another address
The recipient is written into the permission. A different one fails the check, so there is no address for stolen funds to arrive at.
Swap for a token you did not choose
Both sides of the pair are fixed when you sign. Neither can be substituted for something worthless later.
Spend more than you approved
Capped per run, and again by the number of runs. Each approval replaces the last rather than adding to it, so they cannot accumulate.
Keep going indefinitely
Every permission carries an expiry. It stops on its own, with nobody watching and nothing to switch off.
An attacker could
Run your automation at a worse moment
Up to the cap you already approved. Timing is not something the contract can check, so this is the risk that remains.
Run it sooner than you intended
Again bounded by the number of runs you authorised — a month of buys could happen in an hour, but not a month and a day of them.
So the worst case is the money you already agreed to spend, spent badly — not your wallet. Bounding the damage to that is the entire point of the design.
Why that is true
Your funds never leave your own wallet. There is no Qleva account they pass through, no balance we hold on your behalf, and no withdrawal path we could use if we wanted to.
What you sign instead is a permission: a statement that one specific action may be taken from your wallet, within limits you set. The limits travel with it and are re-checked by the contract on every single run.
Your smart wallet
holds the funds, always
The permission
limits, checked on-chain
Qleva's executor
can only act inside them
The order matters. The permission sits between us and your wallet, which is why compromising us does not reach past it.
Four things every permission bounds
A permission that named only the action would not be a limit at all — 'may call approve' still permits approving an attacker for everything you own. So each one fixes four things, and anything left unfixed is something we would be trusting ourselves not to do.
What can be called
One contract, one function. Nothing else is reachable.
With which arguments
The token pair and the destination are pinned byte for byte.
How much
A hard ceiling per run, set by you before you sign.
How long, how often
A run count and an expiry, both enforced by the contract.
You see all four before you sign. The approval card states them in plain language, generated from the same values that go into the permission itself — so the sentence you read cannot drift from the limit that gets enforced.
What we enforce ourselves
These are real, and they are ours — which means a compromise removes them. They exist to catch mistakes and abuse, not to be the last line of defence. Part 1 is the last line.
Emergency pause
One switch stops every automation on your account.
Daily spend and run ceilings
Checked before each run, on top of the on-chain caps.
Fails closed
If those limits cannot be verified, the run is refused rather than allowed.
One run at a time
A lock makes double execution impossible, even across restarts.
Refuses to price blindly
No trustworthy price means no trade — never a fallback number.
What we do not claim yet
A security page containing only good news is marketing. These are the things that are not finished, written here because you would otherwise have to discover them.
Cancelling is enforced by us, not yet by the chain
Cancelling stops our executor immediately, and that is what happens in practice. But it does not yet tear the permission up on-chain, so against the compromised-server case above, the backstop is the expiry and the run count rather than the cancellation. Closing this is on the roadmap; until it is closed, neither of those two limits is ever optional on a permission we create.
One signing key runs every account
What that key may do is bounded per user by everything above. But it is one key rather than one per account, which is a larger blast radius than it needs to be. Splitting it is planned work, not finished work.
We are not audited yet
The permission contracts are MetaMask's and are audited. Our own executor and API are not. We would rather say so than let the word 'audited' do work it has not earned.
Found something wrong with this?
Tell us. A security page is a set of claims, and claims should be checkable — if one of these does not hold, we would rather hear it from you than read about it later.