DCA orders — dollar cost average into any token
PassAudited by ClawScan on May 7, 2026.
Overview
This is a transparent instruction-only crypto order helper, but it guides wallet approvals, EIP-712 signatures, and signed order submission, so users should review amounts and recipients carefully.
Install only if you are comfortable using an agent to prepare DeFi order payloads. Review every wallet prompt carefully, especially token addresses, maxAmount, output recipient, slippage, deadline, and spender/verifying contract, and protect any saved signed payloads.
Findings (3)
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.