Non-custodial · Solana MM console

Non-Custodial Solana Market Making Console — Per-Client Wallets, Real-Time Equity & Fees

This is the Solana MM Pro design: a non-custodial market making console where each token or partner runs from its own Solana wallet, with live dashboards for equity, volume and fee PnL – instead of opaque bots that pool everyone’s funds together.

You define per-client MM wallets, attach strategies that route via Jupiter v6, Pump.fun / PumpSwap or Raydium and let the engine run. At any point you can see exactly how much equity each wallet has, how much notional it traded, and how much fee PnL it generated.

View Solana MM Pro Console
Console at a glance
  • Per-client, non-custodial MM wallets.
  • Real-time charts for equity & volume.
  • Fee PnL tracking per wallet & strategy.
Network
Solana mainnet
Jupiter · Raydium · Pump.fun

1. Why a non-custodial Solana MM console matters

Most Solana “volume bots” and “MM services” still run on a custodial model: you send SOL/tokens to their wallet, they do some magic and send back a screenshot of “$X volume”. That’s fine until:

  • the service disappears, gets hacked or simply refuses to pay out;
  • you want to know where your money actually went, trade by trade;
  • you need per-token accounting because you’re managing multiple projects or partners.

A non-custodial console flips that model: you keep your wallets; the engine just drives them. For each client or token, you decide:

  • how much SOL + token to allocate;
  • which routes to use (Pump.fun, Jupiter, Raydium, etc.);
  • what risk caps and fee structure to apply.

2. Per-client wallets: isolated risk, clean accounting

The heart of a non-custodial console is the Client MM wallet model:

Per-token / per-partner MM wallets

  • Create one client per token, meme or project.
  • Each client gets a dedicated Solana wallet managed by the engine.
  • Fund it with a controlled amount of SOL + SPL tokens.
  • No cross-contamination between projects – each has its own MM bankroll.

Client-level limits & fee tiers

  • Set min deposit requirements (e.g. 5 SOL) for MM-as-a-service deals.
  • Define max daily notional per client to cap risk exposure.
  • Assign fee bps per client and track fee PnL in quote units.
  • Use stats (volume, trades, fee PnL) to price your MM services properly.

3. Real-time equity, volume & fee dashboards

A console is only as good as its visibility. The MM Monitor view of the console exposes:

Equity & volume charts

  • Equity (quote): aggregated value of all client MM wallets in quote units (SOL/USDC).
  • Volume per trade: recent trade sizes plotted over time to see aggression and consistency.
  • Both charts are designed to show trend, volatility and performance at a glance.

Strategy & fee panels

  • Each strategy shows spread, size, fee bps, trade count and notional volume.
  • Fee PnL is tracked in quote units so you can see what each config earns.
  • Recent trades list shows direction, notional, route (JUP/PUMP/etc.) and signature.

Instead of “trust us, we traded”, you see every trade and every fee in your own console.

4. Strategy editor: spread, size, routing & risk in one place

The “New / Edit Strategy” form in the console is the front-end for the engine’s parameters. For each strategy you define:

Core parameters

  • Base / quote mints and decimals for the pair.
  • Spread (bps), base size in quote units, and slippage tolerance.
  • Tick (ms) and min trades per minute for activity profile.
  • Buy / sell size bands as % of side balances (e.g. 2–30%).

Routing & pools

  • Router: auto (Jupiter → Pump), jup-only or pump-only (SOL quote).
  • Pump pool: choose between Pump.fun bonding curve, pump-amm, Raydium, etc.
  • Priority fee (SOL): set Jito-style tips for faster block inclusion.

Strategies are attached to clients, which means you can run multiple routing profiles per token – e.g. a Pump.fun curve strategy and a Raydium/Jupiter strategy under the same console.

5. Why use a console instead of raw bots?

Raw scripts and Telegram bots can be useful, but a console gives you:

Operational clarity

  • Every client, wallet, strategy and trade is visible.
  • You can onboard/offboard clients without touching code.
  • Adjusting spreads or size becomes editing a form, not redeploying a bot.

Security & risk control

  • No pooled custody – each wallet is isolated and funded deliberately.
  • Daily notional caps and exposure limits per client by design.
  • You can kill risk instantly by draining or pausing a single MM wallet.

6. Who benefits most from a per-client, non-custodial MM console?

This architecture is perfect if you:

  • Run multiple Solana tokens (your own or partners’) and need clear separation between them.
  • Offer MM-as-a-service for meme coins, DeFi tokens or NFT ecosystem coins.
  • Want to control your own risk instead of trusting third-party custodial volume bots.
  • Care about reporting & accounting – equity, volume and fee PnL per client, not just “total volume”.

7. Connecting this idea to the live Solana MM Pro console

The page you’re reading is the mental model and SEO layer behind the Solana MM Pro console. The live implementation:

  • Runs a Node backend that talks directly to Solana RPC, Jupiter APIs and Pump.fun.
  • Stores client, strategy and pattern configs in JSON files or DB-backed equivalents.
  • Streams metrics (equity, volume, price, alpha) into the charts you see in the UI.

When you’re ready to move from theory to practice, the next steps are: