SPECTRE
Research
Methodology2026-05-16

SPECTRE × Hexagate Gatelang — Monitor Rule Exporter Design

Author: spectre-solana-max engineering Status: Design doc. PoC implementation deferred to a follow-up. Companion: spectre-vs-competitors-gap-analysis-2026-05-16.md (tier-3 item 9).

Premise

Hexagate (Chainalysis) ships real-time on-chain monitoring for 75+ chains including Solana. Its custom DSL, Gatelang, lets protocol teams write per-transaction detection rules that fire when on-chain behavior matches a defined shape. Hexagate then simulates and blocks pre-signing where the transaction risk is unambiguous.

SPECTRE catches the architectural pattern at build time. Hexagate catches the behavioral signature at run time. Today these are two separate workflows with two separate authorship surfaces. The integration: export SPECTRE findings as Gatelang monitor rule skeletons, so the static finding automatically produces the run-time monitor that would catch live exploitation of the same architectural class.

Why this composes well

SPECTRE finding shape (per finding):

  • Rule ID (e.g. CROSS-007)
  • Source program ID
  • Target program ID (for cross-program rules)
  • Handler / instruction name
  • Architectural pattern (e.g. "delegation to weakly-gated venue")

Gatelang monitor needs (per rule):

  • Trigger condition (typically: program_id == X AND instruction == Y AND <constraint>)
  • Severity / action (warn / block / alert)
  • Description shown in the dashboard

The shape map is direct. SPECTRE finding → Gatelang rule is mostly a template fill, not a logical translation.

Integration shape

Component 1: pinpoint spectre gatelang-export (3-5 days)

A new CLI subcommand that takes a SPECTRE scan output JSON and emits a Gatelang .gate file with one monitor per finding (deduped by (program_id, rule_id)). Pre-fills:

  • program_id = "<source program declare_id from scan>"
  • instruction_name = "<handler name>"
  • Trigger conditions derived from the rule's semantics (per-rule template)
  • Description copied from the SPECTRE finding's title + suggested_action

Per-rule templates (the hand-written part):

SPECTRE rule Gatelang trigger shape
CROSS-007 (delegation to Mango v3 etc.) "any tx where program_id == AND target_program == "
AUTH-100 (single-step admin transfer) "any tx calling instruction 'set_authority' OR 'transfer_ownership' OR matching pattern"
ITER-001 (sentinel iteration) n/a — pure off-chain detector, no run-time signature. Skip.
RACE-001 (stale account after CPI) "any tx with N+ token::transfer/burn/mint CPIs followed by no Account.reload" (hard to express in Gatelang directly; emit as "monitor for high-frequency reload-less CPI handlers")
ORC-002 (oracle composition) "any tx where price oracle changes by > X% in the same slot as a borrow on the same collateral"
TOK-022 / TOK-023 (Token-2022 latent surface) "any tx where vault accepts a mint with TransferHook / PermanentDelegate extension"

Some rules export cleanly; others don't have a run-time signature. The exporter skips the latter and notes why.

Component 2: Severity → action mapping (~1 day)

SPECTRE severity Gatelang action
Critical block (with operator confirmation)
High alert + simulate
Medium alert only
Low log only

The dev tunes per-rule in the generated file; the default is conservative.

Component 3: Round-trip auditing (~1 week)

pinpoint spectre gatelang-audit <gate-file> <repo> — given an existing Gatelang .gate file and a repo, report:

  • Which SPECTRE rules have corresponding Gatelang monitors (covered).
  • Which findings have no Gatelang monitor (gap).
  • Which Gatelang monitors reference handlers that don't exist in the repo (stale).

Composes the static + run-time security postures into one auditable view.

Why this is high-leverage

  • Hexagate adoption is growing on Solana (cited in their Drift Protocol response post-incident). Protocol teams already pay for it.
  • Static-only or run-time-only leaves a gap. SPECTRE catches the pattern before it ships; Hexagate catches the exploit during execution. The pairing is defense-in-depth — but only if the two surfaces are kept in sync, which is exactly the friction this exporter removes.
  • Zero per-protocol overhead. The exporter is repo-driven; no Hexagate-side API integration needed for Phase 1 (just dump a .gate file the dev imports).

Concrete next steps

  1. Phase 1 (1 day): pinpoint spectre gatelang-export CLI stub + JSON-to-template fill.
  2. Phase 2 (3 days): Per-rule trigger templates for the 10 highest-frequency exportable rules.
  3. Phase 3 (1 day): Severity-to-action mapping with overrides.
  4. Phase 4 (1 week): gatelang-audit round-trip mode.

Scope boundary

Phase 1-3 ships a usable artifact: protocol team runs SPECTRE, runs the exporter, imports the .gate file into Hexagate. No Hexagate-side cooperation needed for that minimum-viable path.

Direct Hexagate API integration (auto-push rules to a team's monitor set on every CI run) is a separate sales conversation. The exporter itself is independent of that.

References