Solard Documentation

SOLARD is a local-first execution stack for Pump and PumpSwap. Its SOLARD trade app, solard CLI, and typed SDK share one SQLite database, one venue resolver, and one transaction pipeline.

#Quickstart

The actual trade app is two long-running processes. The indexer collects and writes market state; the TradJS server reads that state and serves the browser interface. Run both from the repository root in separate shells.

1 · Clone and install

$ git clone https://github.com/7flash/solard
$ cd solard
$ bun install
$ cp .env.example .env

2 · Configure the minimum

# required for wallet import/decryption
SOLARD_MASTER_KEY=replace-with-a-long-secret

# required for chain operations and indexing
HELIUS_RPC_URL=https://mainnet.helius-rpc.com/?api-key=...

# keep live execution disabled while testing
SOLARD_ENABLE_LIVE_TRADES=0

3 · Start the indexer

Leave this process running. Without it, the trade app can render but its indexed market state will not advance.

$ bun run indexer/main.ts

4 · Start the TradJS trade app

Open a second shell in the same repository. Export the port before starting TradJS.

$ export BUN_PORT=3000
$ bunx tradjs server
# open http://localhost:3000

5 · Use the CLI separately

The CLI is an operator interface, not the trade-app launcher. Inspect its commands independently:

$ solard help

6 · Make the first simulation

$ solard wallet import <base58_private_key> --name main
$ solard token add <token_ca>
$ solard quote <token_ca> --sol 0.1
$ solard buy <token_ca> --wallet main --sol 0.1 --simulate-only

#Configuration

Runtime configuration uses the SOLARD_ prefix alongside provider-specific variables. Use the names exactly as shown.

#Architecture

Core boundaries

• Venue registry: resolves one executable market plugin for a token and user.
• Pump plugin: includes bonding-curve and PumpSwap venue implementations, instruction builders, routing, launch sources, and creator-fee claims.
• Senders: CLI trade flags expose rpc, helius, and jito.
• Persistence: the CLI and web console share a local database.
• Observability: worker supervision uses bgrun and operations are instrumented with measure-fn.

Repository modules

#Workers

A standard start brings up server-worker and helius-logs-v1. Telegram signals joins when SOLARD_TELEGRAM_SIGNALS=1. Additional workers can be enabled for LaserStream, PumpPortal, curve snapshots, holder snapshots, metadata repair, and reconciliation.

#Web console

The browser trade app is served by TradJS. Start the indexer first with bun run indexer/main.ts, then run export BUN_PORT=3000 and bunx tradjs server in a second shell.

The public /trade route streams token discovery through polling and adds Dexscreener pair metrics as they become available. Wallet and execution routes remain inside the SOLARD console.

#HTTP API

The repository's app/api tree exposes route families for health, status, processes, workers, trade app data, prices, tokens, portfolio, trade, wallet import, groups, watch groups, signals, jobs, launching, and SMA data.

#New-token stream & DEX enrichment

The server starts token discovery when the Bun process starts. An inline bootstrap polls /api/tokens while the page HTML is loading, before the TradJS page client mounts. The page client then replays buffered events and continues scheduled polling.

Source selection

Pipeline

1. Discovery begins with the server process, so arrivals can be buffered before a browser opens.
2. The root-layout bootstrap opens polling automatically; no button, scroll, or other interaction starts the stream.
3. Each unique mint is returned on the next poll with its creation signature when available.
4. An enrichment queue batches up to 30 addresses into DEX Screener token requests.
5. Missing pairs are retried with bounded backoff at 5, 15, 30, 60, and 120 seconds.
6. When a pair appears, an polling update replaces “pair pending” with price, liquidity, market cap, volume, and transaction counts.
7. ETags, bounded backoff, and visibility-aware intervals keep polling predictable and easy to debug.

Stream configuration

Pair enrichment

New mints appear before a DEX pair exists. Until Dexscreener indexes a usable pair, the interface shows pair pending instead of inventing a price or liquidity value.

See the Solana logsSubscribe reference, getTransaction reference, PumpPortal real-time API docs, and DEX Screener API reference.

#CLI reference

Run solard help for the current command list. From a source checkout, the equivalent entrypoint is bun src/cli.ts ….

Wallets and tokens

solard import <private_key> [name]
cat key.json | solard import --stdin [name]
solard wallets [--token <token>] [--addresses-only]
solard token <token_ca> [name] [--metadata-json <json>]
solard token set <token|ca> [--pool <address>] [--quote-mint <mint>] [--quote-program <program>]
solard token refresh <token|ca>
solard tokens

Prices and trading

solard quote buy <token|ca> --sol 0.5
solard price <token|ca>
solard price average <token|ca> --period 15m
solard price watch <token|ca...> [--interval 1s] [--period 1m]

solard buy <token|ca> (--wallet <wallet> | --wallets w1,w2 | --group <name>) --sol 0.5 [--sender rpc|helius|jito] [--simulate-only]
solard sell <token|ca> (--wallet <wallet> | --wallets w1,w2 | --group <name>) [--bps 10000] [--sender rpc|helius|jito] [--simulate-only]
solard unwrap-wsol (--wallet <wallet> | --wallets w1,w2 | --group <name>) [--simulate-only]
solard claim <token|ca> --wallet <wallet> [--sender rpc|helius|jito]

Groups, agents, watches, and ALTs

solard group create <name> [description]
solard group add <group> <wallet> [weight_bps]
solard group add-many <group> w1,w2,w3
solard group show <group>
solard group list
solard agent create <name> --wallet <wallet> [--config-json <json>]
solard agent list
solard watch token <token|ca> [label]
solard watch wallet <wallet> [label]
solard watch program <address> [label]
solard watch list
solard history
solard jito tip-accounts [--endpoint <url>]
solard alt add <address> [label]
solard alt list
solard alt create --wallet <wallet>
solard alt extend <address> --wallet <wallet> <account...>

#Venues & senders

The Pump plugin directory contains separate pump-curve-venue.ts and pumpswap-venue.ts implementations plus routing and instruction builders.

Senders

#Launching

The CLI supports metadata upload, direct Pump deployment, coordinated buyer groups, and script-driven launch workflows. Use solard deploy pump for direct deployment or a registered script for multi-step workflows.

solard metadata upload --image ./logo.png --name "TOKEN" --symbol TKN --description "..." [--provider pump-frontend|pinata]

solard deploy pump --wallet dev --name "TOKEN" --symbol TKN --image ./logo.png --description "..." [--live]

solard run launch-pump-token --creator dev --metadata token.json [--creator-buy-sol 0.1] [--buyer-group snipers] [--live]
solard run prepare-pump-launch-alt --creator dev --metadata token.json --creator-buy-sol 0.1 [--create --live]

Submit modes

• after-deploy-processed
• spam-after-market-ready
• fast-spam

#SDK, scripts & agents

The package exports the SDK root plus venue, claims, Pump venue, trader preset, launches, launchpads, and runner modules.

import { defineSolardConfig } from "solard/runner";

export default defineSolardConfig({
  scripts: {
    snipe: "./scripts/snipe.ts",
    "claim-trade-send": "./scripts/claim-trade-send.ts",
  },
});

solard scripts
solard run <name-or-path> [script flags...]
solard run snipe --name "EXACT NAME" --group snipers --sol 0.05 --sender jito
solard run claim-trade-send --claim <token> --buy <token> --wallet main --recipient <address>

Agent posture

• Use dedicated low-balance wallets.
• Allow read-only quotes and simulations freely.
• Keep SOLARD_ENABLE_LIVE_TRADES=0 while developing tool calls.
• Use group weights and agent config as blast-radius controls.
• Inspect history and activity after every automated run.

#Safety & operations

• Live gate: shipped as SOLARD_ENABLE_LIVE_TRADES=0.
• Wallet encryption: CLI help requires SOLARD_MASTER_KEY to import/decrypt stored wallets.
• Simulation: buy, sell, and unwrap support --simulate-only.
• Local auth: use SOLARD_WEB_TOKEN when serving beyond localhost.
• Supervision: bgrun process state, staleness deadlines, optional auto-recovery.
• Tracing: measure-fn instrumentation is present across the codebase.

#Source reference