GoRoverGoRover Docs
Rover

Seeker & Keeper

The dual-agent architecture of the GoRover engine.

Seeker & Keeper

GoRover uses a two-stage autonomous loop to discover, enter, and manage liquidity positions.

The Dual-Agent Loop

Rover operates by orchestrating two distinct modules in parallel cycles.

Discovery

The Seeker

The screening module. It runs every 30 minutes to find new LP candidates based on your preset.

  • • Scans Meteora DLMM API
  • • Evaluates TVL/Volume ratios
  • • Verifies Smart Wallet signals
  • • Executes Enter transaction
Management

The Keeper

The management module. It runs every 10 minutes to monitor open Stakes and PnL.

  • • Monitors active bin ranges
  • • Detects Drift (out-of-range)
  • • Claims accrued trading fees
  • • Executes Exit transaction

Cycle Workflow

  1. 01.
    Briefing

    Rover pulls global Radar intelligence from Swarm to tune local thresholds.

  2. 02.
    ReAct Loop

    The LLM cortex processes market data and tool outputs to decide on actions.

  3. 03.
    Beacon

    After every action (or skip), a Beacon is sent to update your dashboard status.

Operational Guardrails

Intervals can be customized in rover.config.ts via seekerIntervalMs and keeperIntervalMs.

Safety Gates

  • Balance Check: Seeker will skip Enter if your balance is below minBalanceSol.
  • Position Cap: Rover will never exceed maxPositions (default 3).
  • Drift Wait: Keeper waits outOfRangeWaitMinutes before exiting a drifting position to allow for price reversion.

Deterministic Candidate Scoring

Before deployment, Seeker applies a numeric score model to keep entry decisions explainable:

FINAL_SCORE = QUALITY_SCORE + TIMING_SCORE - RISK_PENALTY

Score ranges:

  • QUALITY_SCORE: 0..50
  • TIMING_SCORE: 0..30
  • RISK_PENALTY: 0..40
  • FINAL_SCORE: 0..100 (clamped)

Interpretation:

  • 85..100: Strong Deploy
  • 70..84: Deploy
  • 60..69: Small Size / Watchlist
  • 50..59: Watchlist
  • <50: No Deploy

Hard gates (default public-safe mode):

  • reject if risk penalty is too high
  • reject if timing score is too low
  • reject if final score is below minimum threshold

This makes candidate selection auditable before any on-chain action.

How Swarm Memory Influences Rover

Swarm acts as a bounded feedback layer, not a blind command source.

  1. Rover makes local decisions (Seeker/Keeper) with local guardrails.
  2. Rover sends Beacons to Swarm.
  3. Swarm verifies and aggregates collective outcomes.
  4. Rover pulls threshold feedback and Radar intelligence for later cycles.
  5. Next cycle uses both local memory and swarm-derived context.

Practical impact

  • Primary influence: local memory/state and deterministic runtime safety checks.
  • Secondary influence: Swarm collective intelligence (Radar + threshold feedback).

This split keeps execution safety local while still benefiting from network effects.

Public docs intentionally omit secrets: private keys, API tokens, and internal privileged endpoints are never exposed.

Next Steps

Beacon Payload

Data structure of Swarm sync.

API Auth

How Scouts authenticate.

Configuration Reference

Technical specification for all `rover.config.ts` parameters.

Swarm Beacon

Technical specification of the Rover data synchronization protocol.

On this page

The Dual-Agent LoopCycle WorkflowOperational GuardrailsSafety GatesDeterministic Candidate ScoringHow Swarm Memory Influences RoverPractical impactNext Steps