# Automation Workflows

Deposits that forward themselves — rule-driven sweeps from user addresses into treasury.

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.

## Rule anatomy

- **Scoped per vault, asset and chain** — one address or all of them.
- **Threshold in, transfer out** — the minimum amount is evaluated per deposit address, so dust
  stays put and does not trigger a transfer that costs more than it moves. Failed forwards retry
  automatically.
- **Deposit-arrival trigger today** — time-based and balance-threshold triggers are roadmap, and
  we say what is live rather than what is planned.
- **Up to 10 combined rules by default**, with no volume caps by design: 3 rules on Standard, 5 on
  Business, custom on Enterprise.

## Signed under your signing scheme

A forward is a real transaction, not a shortcut. 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 — every forward carries the full audit trail, and gas sponsorship and TRON fee optimization
stack underneath so sweeps do not need native-coin top-ups.

## FAQ

**Which triggers exist today?**
Deposit arrival. Time-based and balance-threshold triggers are on the roadmap.

**Is there a cap on forwarded volume?**
No cap on volume by design; the rule count is the plan constraint.

## Related

- [Webhook Notifications](/features/webhooks)
- [Gas Sponsorship](/features/gas-sponsorship)
- [Policy Engine](/features/policy-engine)
- [Organization Wallets](/solutions/organization-wallets)
