TL;DR: Vaultody Automations let a treasury team define threshold-based sweep rules that move balances from deposit addresses to designated destinations without maintaining a hot wallet holding a private key. Every sweep is still signed by a 3-of-3 MPC (multi-party computation) threshold signature scheme (TSS) quorum where Vaultody holds two shares and the client holds one, so the trigger is automated but the signature is not delegated to an always-online key. The operational difference from a hot-wallet sweeper is the custody perimeter: no single machine ever holds a complete key, and every rule evaluation, policy check and signature produces a timestamped record an auditor can reconstruct.
The question, stated plainly
A treasury operations lead running manual sweeps is deciding one thing: how to stop doing this by hand without putting a signing key on an internet-facing server.
The manual process is familiar. Someone checks deposit addresses at 08:00 and 16:00. Balances above a threshold get consolidated to a cold vault or an exchange settlement address. Two people approve. Someone screenshots the result for the file. Across 17 blockchains and 34 networks, that is not a job, it is a rota.
The conventional fix is a hot wallet. Fund an operational address, run a sweeper script against it, keep the private key in an HSM (hardware security module) or a cloud key management service, and accept that a compromised orchestration layer can drain whatever sits in that wallet. The size of the loss is bounded only by how much you left in the wallet and how fast you notice.
The decision is whether automation and a standing hot key are actually the same purchase. They are not.
How each approach works
Take Fireblocks as the honest comparison, because it is the platform most treasury teams evaluate alongside Vaultody and because its automation tooling is mature. Fireblocks runs an MPC-CMP implementation with key shares distributed across its cloud and customer-controlled co-signers. Automated transfers run through the Transaction Authorization Policy engine, which evaluates source, destination, asset and amount before routing to signers. A designated API co-signer can sign programmatically without a human present. That is genuinely well-built, and the policy language is more granular than most competitors offer.
The architectural consequence is that an API co-signer is, functionally, a key share that signs on demand. It is not a hot wallet in the 2017 sense, but it is an automated signing participant whose availability is the point. Compromise the co-signer environment and its policy constraints, and you have signing capacity.
Vaultody separates the two functions more strictly. Automations is a rule layer, not a signing layer. A rule has three parts:
- Trigger. Balance crosses a threshold on a watched address, or a scheduled interval elapses, or an inbound deposit confirms to a set depth.
- Condition. Asset, network, minimum and maximum amount, destination allowlist, time window.
- Destination. A pre-registered address, whitelisted under policy, with a change-control delay before it becomes usable.
When a rule fires, it constructs and submits a transaction proposal. It does not produce a signature. The 3-of-3 quorum still has to complete: Vaultody's two shares and the client's one. Below a configured value ceiling, the client share can be satisfied by a pre-authorised policy grant scoped to that exact rule, that destination and that amount band. Above it, a named human approves in the console or via the approval API. The key is never reconstructed at any point on either path.
The practical rule: automation decides when and where. Policy decides whether. They are different systems with different change-control.
Where the difference shows up in operations
Custody perimeter. With a hot-wallet sweeper, the balance sitting in the operational address is the exposure. With Vaultody, there is no operational address to fund. Deposit addresses are themselves MPC-derived and sweep directly to the destination. Nothing is pre-positioned.
Key material. No full private key exists in Vaultody's model at rest or in memory. Shares sign independently and the signature is assembled. For a team that has already read our note on MPC custody versus multisig for institutions, the relevant point here is that threshold signing and automated triggering are decoupled — which is not true of every MPC platform.
Approvals. What still needs a signature: any destination not on the allowlist, any amount above the rule's ceiling, any change to the rule itself, any new destination added. What does not: a sweep inside an existing rule's parameters. That boundary is configurable per rule, per asset, per network.
Recovery. If the client share is lost, the 3-of-3 construction means recovery runs through a documented share-reconstitution procedure, not through Vaultody unilaterally moving funds. Vaultody cannot sign with two shares. This is the difference that makes the non-custodial claim structural rather than contractual.
Chains. 17 blockchains across 34 networks, including Bitcoin, Ethereum, Solana, Tron, Polygon, Arbitrum and BNB Chain. Fireblocks supports a materially larger asset universe. If your mandate requires long-tail tokens or exotic L2s, that is a real gap and you should weigh it.
Audit trail. This is the part operations leads underweight until an auditor asks. Each sweep produces: the rule ID and version hash at time of firing, the trigger evaluation with the observed balance, the policy decision with the approving identity or the pre-authorisation grant reference, the signing quorum participants, the raw transaction, the broadcast timestamp, and the confirmation. Exportable. No screenshots.
Which one fits which mandate
Fireblocks is the better answer if you need breadth of asset coverage above all, if your desk depends on its DeFi connectivity and network of counterparties, or if you want a single vendor that is already SOC 2 Type II certified today. Vaultody's SOC 2 Type II and ISO 27001 programmes are in progress, not complete, and any compliance lead should treat that as a live item rather than a footnote.
Vaultody fits where the custody perimeter is the controlling constraint. EU entities operating under MiCA benefit from the non-custodial architecture: because Vaultody never holds sufficient shares to move client assets, the arrangement sits outside the CASP (crypto-asset service provider) safeguarding definition. For a broker consolidating client deposits or a treasury team sweeping across Bitcoin, Ethereum and Tron on a daily cycle, removing the funded hot wallet removes the single largest quantifiable loss scenario in the operating model.
If your current sweep runbook has a line that reads "check hot wallet balance," that line is the exposure.
Frequently asked questions
Can an automated sweep run without any human approval at all?
Yes, within limits you define. A rule scoped to a whitelisted destination, a specific asset and an amount band below your configured ceiling can execute end to end using a pre-authorised policy grant for the client key share. Anything outside those parameters halts and waits for a named approver.
What happens if the automation service goes down mid-sweep?
Transaction proposals are idempotent and keyed to the triggering event, so a restart does not double-broadcast. Unsigned proposals expire after their configured window. Funds remain in the source address under the same 3-of-3 MPC quorum they were in before the rule fired.
How does this satisfy an auditor asking about segregation of duties?
Rule authorship, policy approval and destination whitelisting are separate permissions and can be assigned to different people. The export shows who created a rule, who approved the policy grant that let it run unattended, and the version hash of the rule at the moment of each execution.
Does Vaultody support sweeping on Tron and Solana with the same rule logic?
Yes. Trigger, condition and destination logic is network-agnostic across all 17 supported blockchains and 34 networks. Fee handling and confirmation-depth defaults differ per chain and are configurable per rule.
Is Vaultody SOC 2 Type II certified?
No. SOC 2 Type II and ISO 27001 are in progress and have not been awarded. Treat that as a dated open item in vendor diligence rather than a completed control.
Book a technical walkthrough of Automations with our solutions engineers and bring your current sweep runbook — we will map each manual step to a rule, a policy grant or an approval gate, and show you the audit export before you sign anything. Request a demo.
Copy link