Home › Features › Automations
Features · deposits that forward themselves

Deposits that forward themselves

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

Create accountLive on testnet in an afternoon
Compare PlansIncluded in a plan, not an add-on
The problem

Deposits that sit where they land are working capital you cannot use

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.

  • Threshold in, transfer outA rule fires on the amount that arrives, so dust does not trigger a transfer that costs more than it moves.
  • A real transaction, not a shortcutThe forward is signed by the committee and carries the same audit trail as a manual transfer.
  • Fees handled underneathForwarding draws on the vault's funding address, and stacks with gas sponsorship and TRON energy optimization where they apply.

How it works

Rule anatomy

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.

  • Deposit-arrival trigger, live today; time and balance triggers are roadmap
  • Up to 10 combined rules by default; no volume caps by design
  • Works across all major chains including Solana
rule — sweep USDT to treasury
vault: operations asset: USDT · chain: tron scope: all deposit addresses threshold: ≥ 100 USDT per address action: forward → treasury vault on fail: retry queue

Signed under your signing scheme

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.

  • Every forward carries the full audit trail
  • Gas sponsorship stacks: sweeps without native-coin top-ups
  • 3 rules on Standard, 5 on Business, custom on Enterprise
last 24h — automation
1
14 deposits
≥100 USDT each
forwarded
2
2 deposits
below threshold
held
1
1 forward
gas spike — retried
succeeded
Specification

Automation specification

Precisely what fires, and what does not.

TriggerAmount threshold on incoming funds — the one control that is actually enforced today.
UniquenessAt most one active forwarding rule per asset in a vault, so two rules cannot fight over the same balance.
DestinationAny address you nominate, including another vault you own.
Fee sourceA per-vault funding address covers activation and network costs for the forward.
GovernanceCreating or changing a rule is an approval-gated action.
CapacityNo automation rules on Entry, three on Standard, five on Business; unset means unlimited on negotiated plans.
Not yetTime-based and balance-threshold triggers are roadmap, not shipped. We will not describe them as live.
CoverageWorks across the supported chain set, including Solana.

Frequently asked questions

Get answers to commonly asked questions.

What triggers exist today?

Deposit arrival — live. Time-based and balance-threshold triggers are on the roadmap; we say what is live, not what is planned.

Is there a volume limit?

No cap on forwarded volume by design; the rule count is the plan constraint.

What happens when a forward fails?

It enters the retry queue and surfaces via webhooks and the dashboard — nothing silently retries outside policy.

Share the Trust Guard the Keys

Set the rule once; the sweep runs forever.