Security audit
Security checks for vulnerabilities and agentic risk
The skill is instruction-only, but its DCA-only description under-discloses broader crypto trading authority involving real approvals, signatures, and order submission.
Review this as an advanced crypto trading skill, not just DCA buys. Before installing or using it, verify the supported chain, token addresses, recipient, amounts, slippage, deadlines, and order type before any approval or EIP-712 signature. Prefer exact approvals over standing max approvals unless you intentionally want repeat-use authority, and treat typedData and signatures as sensitive.
The skill metadata says it is only for DCA crypto buys, but the README describes a much broader protocol that supports limit, TWAP, stop-loss, take-profit, delayed-start, and sell/exit behaviors. This mismatch can mislead agents or users into invoking capabilities with materially different financial risk than expected, causing unsafe automation or policy bypass in an agent context.
The provided skill manifest says this skill is for DCA orders that split buys over time, but the package description claims support for market, limit, TWAP, stop-loss, take-profit, and delayed-start swaps. That indicates the skill package represents substantially broader trading behavior than the manifested DCA-only scope.
The instructions tell users to copy a signed relay payload shape and replace fields, while also allowing alternate signature formats, without warning that signatures are bound to exact payload contents and can be invalid, replay-sensitive, or misused if handled incorrectly. In a crypto order workflow, this can lead users or integrators to mutate transaction-like data unsafely, misunderstand signature validity, or submit malformed or unintended orders involving real funds.
The examples file materially expands the apparent capability of the skill from DCA-only into limit and stop-loss order construction. In a financial signing context, this is dangerous because users or downstream agents may generate and sign unintended order types that carry different execution semantics and risk profiles than the manifest suggests.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
'{order: $typed[0].message, signature: $sig, status: "pending"}' \
./relay-payload.json
curl -fsS -X POST 'https://agents-sink.orbs.network/orders/new'
-H 'content-type: application/json'
--data @./relay-payload.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
status: "pending",
};
const response = await fetch("https://agents-sink.orbs.network/orders/new", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify(relayPayload),
The manifest claims support for 8 EVM chains, while the README only provides generic multi-chain language and points to an external config as the canonical source. This can cause incorrect assumptions by integrators or agents about where the skill is safe or available, potentially leading to failed transactions or interaction with unintended deployments.