DCA orders — dollar cost average into any token
PassAudited by VirusTotal on May 7, 2026.
Overview
Type: OpenClaw Skill Name: dca-order Version: 1.0.0 The skill bundle provides a comprehensive framework for an AI agent to facilitate decentralized, gasless DCA and limit orders via the Orbs Network 'Spot' protocol. It uses EIP-712 typed data (RePermit) to ensure non-custodial execution, binding allowances to specific order hashes. The instructions in SKILL.md and the reference files are well-structured, focusing on parameter normalization, signing, and submission to the official Orbs relay (agents-sink.orbs.network). No evidence of malicious intent, data exfiltration, or prompt injection was found; the bundle aligns perfectly with its stated purpose of crypto order management.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A mistaken approval or signature could allow the protocol order to spend the specified token amount according to the signed parameters.
The skill asks the user to authorize token spending and sign wallet data for a DeFi order. This is expected for the stated crypto order purpose and is scoped to input.maxAmount by default.
If allowance for `input.token` to `typedData.domain.verifyingContract` is lower than `input.maxAmount`, the default suggestion is a standard ERC-20 `approve(..., input.maxAmount)` transaction first. ... Sign `typedData` ... The signer must equal `swapper`.
Before approving or signing, verify the chain, token addresses, max amount, deadline, spender/verifying contract, and recipient. Prefer the exact approval over maxUint256 unless you intentionally want a standing allowance.
If the wrong payload is submitted, a live order may be created with unintended parameters.
The skill includes network submission and transaction-tool workflows. These are disclosed and central to the order-submission purpose, but they create live financial orders once signed.
Submit signed orders with `POST https://agents-sink.orbs.network/orders/new`. ... Handle approval, signing, and submission exactly as described in [references/sign.md].
Require user review before submitting any signed payload, and compare the relay payload to the wallet-signed typed data.
Anyone who obtains the signed payload may be able to submit the exact same order, although the signature is bound to that order's parameters.
The populated typed data and signature are reusable authorization material for the exact order. Persisting them is purposeful for retry safety, but they should be treated as sensitive.
After an ambiguous relay failure such as a timeout or `5xx`, persist and reuse the exact populated `typedData` and signature for any retry.
Store signed payloads only as long as needed, avoid placing them in shared logs or long-term memory, and delete them after order status is resolved.