Real-time onchain threat detection and pre-transaction enforcement across 75+ chains. Detects 300+ threat types via ML, graph analysis, mempool monitoring, and simulation; integrates via API, webhook, or push for protocols, wallets, and chains.
- 01protocol threat monitoring
- 02pre-transaction enforcement (Guardian)
- 03wallet-level scam + phishing protection
- 04governance + treasury alerts
- 05automated incident response
| Variable | Scope | Description |
|---|---|---|
| HYPERNATIVE_CLIENT_ID | Server | Hypernative API client ID, sent in the `x-client-id` header. |
| HYPERNATIVE_CLIENT_SECRET | Server | Hypernative API client secret, sent in the `x-client-secret` header. |
| HYPERNATIVE_WEBHOOK_SECRET | Server | Shared secret for verifying inbound alert webhooks (HMAC-SHA256 over raw body). |
Use Hypernative for real-time onchain threat detection. Authenticate every request with `x-client-id` + `x-client-secret` headers against `https://api.hypernative.xyz`. Address screening (Screener): `POST /assets/reputation/addresses` with `{ addresses: [{ chain, address }] }` returns `recommendation` (`Allow|Deny|Review`), `flags[]` (sanctions, phishing, exploit, mixer), and a numeric `risk_score`. Create monitored watchlists with `POST /watchlists` and add assets via `POST /watchlists/{id}/assets`. Configure custom agents (detection rules) and route their alerts to your webhook channel — handler verifies `x-hypernative-signature` (HMAC-SHA256 of raw body) using `HYPERNATIVE_WEBHOOK_SECRET`, then dispatches by `riskTypeId` and `severity` (`Info|Low|Medium|High|Critical`). For pre-transaction enforcement (Guardian), call the verdict API before broadcast and gate the transaction on `Allow`.
- ⚑Hypernative auth uses paired client-id + client-secret headers (not Bearer) — both must be sent on every request; missing either returns a generic 401 with no hint.
- ⚑Webhook signature is HMAC-SHA256 of the exact raw body — Next.js App Router needs `runtime = 'nodejs'` and `req.text()` before parsing, or HMAC will not match.
- ⚑Severity bands are not symmetric — `Critical` is reserved for active exploits in progress; daily ops should treat `High` as the primary actionable threshold to avoid alert fatigue.
- ⚑Guardian pre-transaction verdicts add round-trip latency (typically 100–400ms but can exceed 1s under load) — define a fail-open vs fail-closed policy explicitly per flow (e.g. fail-closed for treasury, fail-open for retail UX).
- ⚑Chain coverage for the 75+ list is uneven across products — Screener supports more chains than Guardian; verify your specific (chain, product) pair in the dashboard before shipping.
- ⚑Custom detection agents can produce noisy alerts on edge cases (e.g. legitimate flash-loan rebalances flagged as exploits) — tune `minImpact` and counterparty allowlists during a 1–2 week shadow-mode rollout before enforcing.