Rule-driven sweeps from user addresses to treasury
An automation rule watches a vault for deposits of a given asset and forwards them the moment they confirm — above the threshold you set, evaluated per deposit address, with a retry queue behind it. Incoming user deposits become consolidated treasury without an operator.
Share the Trust, Guard the Keys
Platforms that issue deposit addresses end up with balance scattered across thousands of them, and a cron job somewhere sweeping it up. Automations make forwarding a property of the address: funds arriving above a threshold you set move to the destination you chose, as a real transaction under your policy.
Scoped per vault, asset and chain — one address or all of them. The minimum-amount threshold is evaluated per deposit address, so dust stays put and real deposits move. Failed forwards retry automatically.
A forward is a real transaction: with a server co-signer it signs hands-off; with mobile-only signing it waits for your tap. Automations never bypass the signing model — they ride it.
Precisely what fires, and what does not.
Get answers to commonly asked questions.
Deposit arrival — live. Time-based and balance-threshold triggers are on the roadmap; we say what is live, not what is planned.
No cap on forwarded volume by design; the rule count is the plan constraint.
It enters the retry queue and surfaces via webhooks and the dashboard — nothing silently retries outside policy.
