Automated crypto take-profit orders
ReviewAudited by ClawScan on May 7, 2026.
Overview
This instruction-only crypto order skill is coherent and disclosed, but using it means approving/signing wallet actions and sending signed order data to a relay.
Only use this skill if you understand the crypto order being created. Verify all addresses and amounts, use exact token approvals, review the wallet signing prompt carefully, and do not store or share signed payloads except as needed for the active order.
Findings (4)
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 or maliciously altered order could authorize spending or trading crypto assets within the signed order limits.
The skill guides the agent through wallet approval and EIP-712 signing, which can authorize the protocol to spend tokens up to the order amount.
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, input.maxAmount, output recipient, deadline, slippage, verifying contract, and spender; prefer exact approvals over maxUint256.
The relay receives the signed order and can process it according to the order terms until it is filled, cancelled, rejected, or expires.
The workflow sends a signed wallet order payload to an external relay endpoint, which is expected for the protocol but exposes order details and a usable signature within its signed constraints.
Submit this exact relay payload to `https://agents-sink.orbs.network/orders/new`: ... `"order": "<typedData.message>", "signature": "<full signature or { r, s, v }>`Use only if you trust the relay/protocol, verify the endpoint from an official source, and avoid signing broad or long-lived orders.
If the saved signed payload is exposed in logs, shared chat, or persistent memory, another party may be able to submit the same order within its valid period.
The skill recommends retaining a signed payload for retry; that payload is sensitive because it may remain usable until the order expires or is cancelled.
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 in a secure, task-scoped location, avoid sharing them unnecessarily, and delete them after the order is resolved or expired.
Users may have less assurance that the listed relay and contract addresses match the intended official protocol deployment.
The registry metadata does not establish an official source or homepage, which matters more for a skill that asks users to sign crypto orders against fixed contract addresses.
Source: unknown; Homepage: none
Independently verify the skill publisher, protocol documentation, relay URL, and contract addresses before using it with real funds.