Withdrawal, deposit & trading protection

We integrate at three main surfaces so you can apply risk intelligence exactly where losses and compliance matter. Withdrawal protection is the primary enforcement layer for loss prevention. You can hook us when the user pastes or edits an address (UI advisory), before creating the withdrawal request (pre-withdrawal, server-side—recommended so clients cannot bypass), or immediately before transaction signing (signing gate, strongest). On each call we apply address similarity scoring, dust transfer analysis, scam-cluster detection, and exposure checks to risky entities, and return a recommended action and evidence. Deposit monitoring is risk-aware crediting: we hook on deposit detection or before crediting funds to the user balance, and we run AML typology detection (layering, peel chains, consolidation), mixer and risky-exchange exposure scoring, and risk flags so you can block or route to manual review. Trading and token safety protects investment flows: we hook when a token is selected in the UI (warn before commit), before trade confirmation (final gate), or optionally after trade for monitoring. Here we run honeypot detection via simulation and contract analysis, owner-privilege detection (minting, blacklist, upgradeability), liquidity risk (LP locks, concentration), and pump-and-dump anomaly detection. Across all three surfaces, you choose the hook depth and how to map our recommended_action to your UX—allow, warn, step up, manual review, or block.

How we do it

• Withdrawal: you call our API with source address (user), destination address, chain, asset, amount, and optional user_risk_tier. We run address poisoning, scam-cluster, and exposure checks and return recommended_action and evidence. Integration options: (1) UI advisory—call when user pastes or edits destination (client or backend proxy); (2) pre-withdrawal—call from your backend before creating the withdrawal request (recommended; client cannot bypass); (3) signing gate—call immediately before the signing service signs the tx (strongest; catches internal misuse). All use the same request/response schema; only the call site and who enforces the action differ.
• Deposit: you send depositing address, chain, asset, amount, and optional user id or risk tier. We run AML typology, mixer/sanctions exposure, and risky-cluster checks. Hook points: on deposit detection (when you see the inbound tx) or before crediting (when you are about to update balance). Response tells you whether to allow, flag for review, or block crediting. We do not need your internal user id; you can pass an opaque id or risk tier for logging.
• Trading: you send user address, token or pair, direction, and amount. We run token-risk checks (honeypot, owner privilege, liquidity) and optional pump-and-dump signals. Hook points: when token is selected in UI (warn before commit), before trade confirmation (final gate), or after trade (monitoring/alerting). Same API contract; you decide whether to block, warn, or log.
• All three surfaces use the same core API: POST with a JSON body describing the context, response with risk_score, recommended_action, reason_codes, evidence, decision_id, model_version. You implement idempotency and retries on your side; we are stateless and idempotent per request.

Outcomes

• •Withdrawal: UI advisory, pre-withdrawal, or signing-gate hooks with address and scam detections
• •Deposit: on detection or before crediting; AML typologies, mixer and exchange exposure
• •Trading: token selection, pre-trade, or post-trade hooks with honeypot and rug-pull signals
• •Same API contract everywhere: risk_score, recommended_action, reason_codes, evidence