QELT DEX
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This skill is coherent for QELT/Uniswap v4 use, but users should carefully verify any signed blockchain transaction, token approval, and contract address before broadcasting.
This appears safe to install as an instruction-only DEX helper, but treat it like any blockchain tool: never provide private keys, independently verify the QELT contract addresses, use limited token approvals when possible, and approve broadcasting only after checking the exact signed transaction details.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
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.
If the wrong signed transaction is submitted, funds or token positions could be changed or lost on-chain.
The skill documents a Bash/curl path for broadcasting raw signed transactions to the QELT Mainnet RPC. This is purpose-aligned for a DEX skill, but it is a high-impact operation because broadcasts are irreversible.
curl -fsSL -X POST https://mainnet.qelt.ai ... "method":"eth_sendRawTransaction","params":["0xSIGNED_TX_HEX"]
Only broadcast a transaction after the user explicitly approves the chain ID, recipient contract, value, token amounts, slippage, deadline, and raw transaction origin.
A broad token approval can leave funds exposed if the approved contract path is misused or if the user intended only a one-time limited transaction.
The SDK example uses an unlimited ERC-20 approval to Permit2. This is a common DeFi pattern and fits the liquidity workflow, but it grants broad token-spending authority unless the user later revokes or limits the allowance.
await token0.approve(CONTRACTS.permit2, ethers.MaxUint256);
Prefer exact-amount approvals where possible, explain allowance scope to the user, and suggest revoking unused approvals after the operation.
Users have less assurance that the packaged metadata accurately identifies the publisher and version they are installing.
The packaged metadata contains a placeholder owner ID and a version that differs from the registry metadata shown for the skill. This does not show malicious behavior, but it is a provenance and packaging-quality issue for a financial integration.
"ownerId": "YOUR_CLAWHUB_OWNER_ID", "slug": "qelt-dex", "version": "1.0.0"
Verify the publisher, version, homepage, and contract addresses independently before using the skill for any transaction.