Skip to content

This reference describes the configuration and deployment parameters for the Gas Station Service.

This applies to on-premise deployments only. For SaaS deployments, the Gas Station Service is managed by Ripple.

Prerequisites

Before deploying the Gas Station Service, ensure you have:


Configuration parameters

Configure the Gas Station Service using environment variables or Helm values:

ParameterDescriptionDefaultRequired
GATEWAY_SERVER_URLRipple Custody API gateway URLYes
PRIVATE_KEYBot user private key (PEM format)Yes
POLLING_INTERVAL_MSInterval for checking pending transactions (milliseconds)5000No
MAX_RETRY_ATTEMPTSMaximum immediate retry attempts for failed funding3No
RETRY_INTERVAL_MINUTESInterval between queue-based retries5No
FEE_SAFETY_MARGIN_PERCENTSafety margin added to estimated fees10No
POSTGRES_URLPostgreSQL connection stringYes
LOG_LEVELLogging verbosity (debug, info, warn, error)infoNo
OTEL_EXPORTER_OTLP_ENDPOINTOpenTelemetry collector endpointNo

Helm values

Create a values file for the Gas Station Helm chart:

gasStation:
  enabled: true
  gatewayUrl: "https://your-custody-gateway.example.com"
  pollingIntervalMs: 5000
  maxRetryAttempts: 3
  retryIntervalMinutes: 5
  feeSafetyMarginPercent: 10
  
  database:
    host: "postgres.example.com"
    port: 5432
    name: "gas_station"
    username: "gas_station_user"
    existingSecret: "gas-station-db-credentials"
    
  credentials:
    existingSecret: "gas-station-credentials"
    privateKeyKey: "private-key"
    
  telemetry:
    enabled: true
    otlpEndpoint: "http://otel-collector:4317"

Database setup

The Gas Station Service requires a PostgreSQL database for event deduplication and failed job tracking.

Create the database

CREATE DATABASE gas_station;
CREATE USER gas_station_user WITH ENCRYPTED PASSWORD 'your-secure-password';
GRANT ALL PRIVILEGES ON DATABASE gas_station TO gas_station_user;

Database schema

The service automatically creates the following tables on startup:

TablePurpose
processed_eventEvent deduplication and distributed locking
failed_funding_jobFailed funding attempts for queue-based retry
dead_letter_queuePermanently failed jobs requiring manual intervention
sponsorSponsorship configuration
alertLow-balance alert thresholds
eventAudit trail for configuration changes

ProcessedEvent table

Serves as both event deduplication log and distributed lock mechanism. The UNIQUE constraint on id prevents duplicate event processing across multiple service instances.

ColumnTypeDescription
idUUIDEvent ID from Ripple Custody (primary key, provides distributed lock)
locked_atTIMESTAMPWhen lock was acquired (for stale lock detection)
transaction_order_idUUIDTransaction order ID for idempotency tracking
created_atTIMESTAMPWhen event was first detected
processed_atTIMESTAMPWhen processing completed successfully
statusVARCHAR(20)Processing status: processing or completed

Locks older than 10 minutes are considered stale (crashed worker). The service automatically releases stale locks and retries processing.

FailedFundingJob table

Stores failed funding attempts for background retry processing.

ColumnTypeDescription
idUUIDUnique job identifier
event_idUUIDReference to Ripple Custody event ID
account_idUUIDAccount that needs funding
sponsor_idUUIDSponsor account providing funds
required_amountVARCHAR(100)Amount needed (string to preserve precision)
ticker_idUUIDToken/ticker UUID for the native token
created_atTIMESTAMPWhen job was created
retry_countINTEGERNumber of retry attempts
next_retry_atTIMESTAMPWhen job should be retried next

DeadLetterQueue table

Stores funding jobs that have permanently failed after exhausting all retry attempts.

ColumnTypeDescription
idUUIDUnique identifier
event_idUUIDOriginal Ripple Custody event ID
account_idUUIDAccount that needed funding
sponsor_idUUIDSponsor account that was attempted
required_amountVARCHAR(100)Amount that was needed
ticker_idUUIDToken/ticker UUID
original_error_messageTEXTLast error message before failure
final_retry_countINTEGERNumber of retry attempts before giving up
failed_atTIMESTAMPWhen job was moved to dead letter queue

Jobs in the dead letter queue require manual investigation. Set up alerts to monitor for new entries in this table.


Security considerations

Private key protection

  • Store the bot user's private key in a secrets management solution (Kubernetes Secrets, HashiCorp Vault, AWS Secrets Manager)
  • Never commit private keys to version control
  • Rotate keys periodically according to your security policy

Access control

  • Restrict database access to the Gas Station Service only
  • Use network policies to limit communication between services
  • Enable TLS for all connections (database, API gateway, telemetry)

Audit logging

  • Enable audit logging in Ripple Custody to track all bot user actions
  • Forward Gas Station logs to your SIEM for security monitoring
  • Set up alerts for unusual funding patterns

Monitoring and observability

The Gas Station Service exports metrics and traces via OpenTelemetry.

Gauges (current state)

MetricDescription
failed_jobs_queue_sizeNumber of jobs in FailedFundingJob table
processed_events_countNumber of rows in ProcessedEvent table (for cleanup monitoring)
sponsor_balance_<ticker>Current balance of each sponsor account

Counters (cumulative)

MetricDescription
funding_attempts_total{status, chain}Total funding attempts by status (success/failed) and chain (e.g., eth)
events_processed_total{outcome}Events processed by outcome (funded/skipped/failed)
retry_attempts_total{attempt}Distribution of retry attempts (1, 2, or 3) before success/failure

Histograms (distributions)

MetricDescription
funding_duration_secondsTime from event detection to funding completion
job_age_at_success_hoursHow long jobs were in queue before succeeding
api_latency_seconds{endpoint}Ripple Custody API latencies (dry_run/submit_intent/get_balance)

For telemetry configuration, see Telemetry overview.


Health check endpoints

The Gas Station Service exposes health check endpoints for Kubernetes liveness and readiness probes:

EndpointPurposeDescription
/healthLiveness probeChecks if the service is running and responsive
/readyReadiness probeVerifies database connectivity and Ripple Custody API reachability

Configure Kubernetes probes

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 30

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

These endpoints enable proper orchestration, zero-downtime deployments, and automatic service recovery.


TopicDescription
Gas Station conceptsSponsorship hierarchy and multi-chain support
Configure bot usersSet up bot users for automated operations
Configure gas sponsorshipAPI reference for sponsorship configuration