Nexus launch agent

nexus-launch-agent is a conversational, non-custodial agent and machine-readable CLI for planning token launches through:

• Pools Instant on Robinhood Chain (eip155:4663), with an optional bounded atomic creator buy
• pons v2 on Robinhood Chain (eip155:4663)
• Flap on BNB Chain (eip155:56)
• Pump.fun on Solana mainnet (solana:mainnet-beta)

It builds and simulates an exact launch, hashes the complete plan and transaction, stops for approval of that exact plan ID, then re-simulates before returning a wallet signing request. Nexus MCP and CLI tools reject private-key and seed-phrase inputs; chat context reaches the Nexus-hosted service and its model provider, so never paste secrets into the conversation. Nexus does not sign for the funding wallet, hold funds, or broadcast. The handoff page lets EVM wallets submit directly. For Pump.fun, Phantom signs a fully unsigned transaction first; Nexus validates the signed public bytes, adds only a short-lived memory-only mint signature, re-simulates, and returns the completed transaction for direct browser-to-Solana-RPC submission. Nexus and its launch adapters are not independently audited.

Pools support uses the current public Uniswap Liquidity Launcher v3.2.0 deployment and SDK-compatible 1.10.0 calldata. It binds the fixed one-billion supply, creator-fee beneficiary, native-ETH Uniswap v4 pool, permanent fee-splitter custody, predicted token, runtime identities, and exact transaction. An optional atomic creator buy targets exactly 0.5%, 1%, 2%, or 5% of supply; Nexus pins the Universal Router strategy and router and binds the exact ETH input, minimum output, recipient, and deadline. Crowd/CCA remain unsupported. Nexus also supports the reviewed Flap Portal v5.18.0 implementation. Conversational Flap launches complete a read-only protocol-identity and transaction-simulation preflight before asking to publish artwork, so deterministic protocol drift cannot make metadata public first.

Install

npm install -g nexus-launch-agent
nexus chat

If npm returns EACCES on macOS or Linux, do not retry with sudo. Use a folder owned by your account:

npm config set prefix "$HOME/.local"
npm install -g nexus-launch-agent@latest

If nexus is then not found, add $HOME/.local/bin to your shell's PATH.

The nexus name on npm belongs to an unrelated project. Install nexus-launch-agent; it supplies the nexus and nexus-launch-agent-mcp executables.

Holder-only intelligence uses the NEXUS ERC-20 on Robinhood Chain, contract 0x9fe4d977d595c0c347711d5d6150f4ebfa5cdc6c. Run nexus login, choose an EVM wallet, and sign one login message. This uses no gas, approval, or transaction. nexus account shows the wallet and live balance; nexus logout revokes the scoped session. The session can call only launcher activity, narrative, X, exact-post, and CA-first research. It cannot approve or execute launches, trade, sign, broadcast, or move funds. Launch planning and verification stay available without login.

nexus login
nexus account
nexus chat

Starting with 0.2.5, an interactive Nexus startup checks the public npm latest tag with an 800 ms timeout. If a newer release exists, Nexus writes the exact installed and latest versions plus npm install -g nexus-launch-agent@latest to the terminal before continuing. Starting with 0.2.27, a non-writable macOS or Linux install also prints the user-owned-prefix fix above. Registry failures are silent, machine-readable --json output never receives the notice, and NEXUS_DISABLE_UPDATE_CHECK=1 disables the request. Releases installed before 0.2.5 cannot gain this behavior retroactively and require one manual update.

Conversational mode

Pasting a bare EVM contract or Solana mint triggers CA-first research. Nexus resolves a supported launcher from an exact verified launch, finalized launcher-index identity, or exact Pump.fun public token record, then combines the bounded exact-address X sample with exact-address DEX Screener evidence and one cited web search available only for the immediate result turn. It never resolves by ticker or token name and does not ask the user to guess the launcher.

nexus chat is a native Nexus runtime. It does not execute Claude Code, Codex, another agent CLI, or the bundled MCP server. It requires no user-supplied model API key. The CLI sends bounded typed conversation context to https://cli.nexus/v1/chat; that service calls Anthropic's Messages API directly with its own credential and pins the model, Nexus instructions, and a fixed allowlist containing only launcher discovery, finalized launcher activity and narrative evidence, exact-token and exact-post X intelligence, provider-specific planning, local exact approval/handoff, and read-only verification. Parallel function calls are disabled. Conversational volume questions are launchpad-specific: unqualified requests compare Pump.fun, pons, and Flap, while named chains map to their supported launchpad. Chain-wide DEX volume is not exposed as a chat tool or fallback. Launcher comparisons come from Nexus's finalized onchain event index, support 5m, 1h, 6h, 24h, and 7d windows, default to 1h when no duration is stated, and preserve partial or unavailable source coverage instead of substituting chain totals. Narrative questions reuse the same aligned index and rank public token themes using volume, traders, trade count, active-token breadth, launches, and previous-window momentum. Before ranking, the hosted API resolves a bounded, volume-prioritized set of Pump.fun tokens through its public server-side coin endpoint and pons/Flap tokens through read-only contract calls. Results expose concentration, token-count and volume-weighted metadata classification coverage, and source status; low-coverage results are inconclusive rather than forecasts. When the launcher is already explicit, exact-token X questions work identically in native and web chat: Nexus uses the launcher and exact contract or mint and calls the server-side bounded recent-search endpoint with its own credential, and returns aggregate activity plus direct post links without post text. Exact aggregate requests are cached and coalesced, paid misses are rate- and budget-limited across replicas, and a bounded stale aggregate may be returned instead of spending more credits. For one exact public X status URL, Nexus may separately return the requested post text and a bounded aggregate of up to 25 recent direct replies and quotes. It never returns or retains sampled response text. The exact-post route has its own 15-minute cache, six-hour stale fallback, per-client limits, and durable cross-replica allowance. This is contextual research, not independent fact-checking, and X samples are not sentiment, safety, authenticity, organic-demand, endorsement, or performance signals. There is no shell, browser, general filesystem, code-execution, signer, or broadcast function. The one narrow local-file operation is inside conversational planning: after the user names token artwork and separately types PUBLISH, the local CLI may read only that selected image, validate it, and send it to the selected platform's public upload route. The hosted model receives the path and resulting public URI/CID, never the image bytes.

Launcher venue coverage is explicit: Pump.fun includes its bonding curve and PumpSwap; pons currently includes native-ETH v2 bonding curves but excludes non-native quote pairs and post-graduation Uniswap v4 trades; Flap currently includes the bonding curve but excludes post-migration PancakeSwap trades. USD values use current native-asset prices and are estimates. Counts can include bots, arbitrage, and wash trading and are not evidence of safety or organic demand.

The client cannot choose the model or inject instructions or tool schemas. The endpoint enforces a matching client version, strict message shapes, bounded context, timeouts, and rate limits. Public hosted chat currently allows 40 requests per source IP per hour under a 500-request global hourly ceiling. Running bare nexus starts the same mode. While a hosted turn is pending, Nexus animates one small star indicator and clears it before any response, tool status, prompt, or error. Model Markdown and tables are rendered as compact terminal-native text and raw HTML elements are removed. NO_COLOR=1 nexus chat retains the star without ANSI color; NEXUS_REDUCE_MOTION=1 nexus chat makes the pending indicator static.

Start the chat and describe the token you want to launch. Nexus will:

1. Ask only for the missing public wallet, token details, and artwork supported by the selected launcher. In native chat, drag the image into the terminal or type or paste its location on the computer; in browser chat, attach it with FILE. A path such as ~/Desktop/sadasd is accepted by the native client; Nexus normalizes terminal quotes and escaped spaces and resolves a unique common image extension locally.
2. Accept only a real PNG, JPEG, WebP, or GIF up to 5 MB, reject symlinks, and display the exact selected file. For Flap, first complete the full read-only compatibility and transaction-simulation preflight. Then require the explicit local word PUBLISH (uppercase or lowercase) before making the image and public token details available through the provider's uploader. Invalid input is corrected within the local prompt; CANCEL stops.
3. Insert the resulting Pools/Pons image URI, Flap metadata CID, or Pump.fun metadata URI automatically. Users never have to build or host metadata JSON in conversational mode.
4. Prepare and simulate one exact transaction without broadcasting.
5. Immediately display one concise local review containing the material launch amounts, risk line, simulation status, expiry, and full plan ID. Serialized transactions, lookup tables, and protocol diagnostics are not dumped into the normal conversation.
6. Ask once for APPROVE, DETAILS, or CANCEL. APPROVE is bound internally to the exact cached plan. DETAILS displays the complete machine envelope and returns to the same prompt; invalid or blank input also remains local. None of these responses become model-visible user messages, and the model cannot fill or bypass the prompt.
7. Revalidate protocol identity without another model-chat round trip.
8. Open the unsigned, unbroadcast request on the fragment-only cli.nexus/handoff page locally; Nexus does not print that private fragment or send it through model-visible chat.
9. Connect the exact wallet named in the plan and review the immutable chain, target, value, and calldata or serialized transaction. For EVM, Nexus discovers EIP-6963 and legacy injected providers, finds the provider exposing the approved address even when that address is not its first account, and uses that same provider for network switching and submission. The raw transaction is collapsed unless you choose to inspect it. For Pump.fun, wallet setup does not consume the blockhash lifetime: Nexus requests and simulates a transaction differing only by a fresh recent blockhash when you click review, then starts a conservative 60-second countdown and checks the blockhash live. If it ends while the plan remains active, click review again for another blockhash-only refresh. Solana mobile users can open the exact page in Phantom's dapp browser.
10. Approve the external wallet's own confirmation to sign. EVM wallets submit directly; for Pump.fun the wallet signs first, Nexus adds the one-time mint signature and re-simulates, and the browser submits the completed bytes directly to Solana RPC.
11. For EVM launches, the page checks the successful receipt against the exact approved transaction, immediately displays the CA, and opens the canonical Pools, pons, or Flap page while safe-finality verification continues in the handoff tab. Pump.fun opens after its fast finalized check. Only finalized receipts enter the Nexus launch feed and trigger verified native-chat completion. If EVM finality remains pending, the handoff preserves the CA, provider link, transaction ID, and an in-page retry; nexus verify remains the recovery path.

In conversational pons launches, slippage and creator tax are entered and reviewed as percentages. Nexus uses 5% opening-buy slippage, 0% creator tax, and disabled buyback when you do not request different settings. The lower-level JSON CLI keeps explicit basis-point arguments for deterministic machine integrations.

Do not add hooks or automation that prefill, accept, or auto-respond to Nexus approval. Native conversational approval requires a human-entered APPROVE; machine-readable CLI and MCP approval still require the complete exact plan ID. A model statement, chat message, plan, simulation, form response, approval artifact, or wallet request is not a transaction receipt.

Never paste a private key, seed phrase, mnemonic, recovery phrase, keypair, wallet secret, signer credential, API key, or credential-bearing RPC URL into the conversation. Conversation text, assistant messages, local image paths, and local tool results—including resulting public metadata, plans, and simulations—are processed by the Nexus-hosted service and Anthropic; selected image bytes are not. Nexus rejects secret-named fields, private-key-shaped hexadecimal/base58 planning values, canonical base64 32/64-byte key material, keypair arrays, checksum-valid BIP-39 phrases, mnemonic/recovery indicators, credential-bearing metadata/social URI components, and provider-incompatible wallet values before provider execution or plan caching. This is a conservative heuristic, not a secret detector: a public hash/signature and a secret can have the same encoding, so never paste secrets into plan-ID or verification fields either. Funding and signing stay in your external wallet. The PUBLISH and native APPROVE, DETAILS, or CANCEL responses entered in local control prompts are never appended to model-visible input.

Public MCP server

The native chat runtime calls the launch adapters directly. A separate MCP client may run the bundled stdio server:

nexus-launch-agent-mcp

The client must support direct MCP form elicitation. Clients without it fail closed at handoff. The server exposes only:

• nexus_multichain_launchers: supported chains and current integration availability;
• nexus_multichain_plan: strict public-field planning and non-broadcast simulation;
• nexus_multichain_handoff: direct exact-ID form approval, revalidation, re-simulation, and unsigned handoff;
• nexus_multichain_verify: read-only verification against the session's exact plan.

It also provides static guide and launcher resources plus a launch prompt. It has no general shell, filesystem, private-key, signer, or broadcast tool. The MCP plan cache is bounded, process-local session state. Approval and handoff eligibility expire within the original validity window, while the exact plan remains cached until process exit so a later receipt can still be verified; closing or restarting requires a fresh active plan. Hosted model processing remains subject to the Nexus service and model provider data policies.

Machine-readable exact plan flow

The JSON CLI does not use hosted chat. It preserves the file-based flow for humans and other agents. Confirm the installed release and launcher status first:

nexus --version
nexus --json launchers

Create a plan. Amounts passed to --initial-buy use the chain's native display unit (ETH, BNB, or SOL). Onchain amounts, slots, timestamps, and counters in saved JSON are base-10 strings; fixed schema discriminants such as EVM chainId and the bounded slippage setting remain JSON numbers.

nexus --json plan \
  --launcher pons \
  --wallet 0xYOUR_PUBLIC_WALLET \
  --name Signal \
  --symbol SIGNAL \
  --metadata-uri ipfs://IMAGE_CID \
  --description "Signal on Robinhood Chain" \
  --initial-buy 0.01 \
  --slippage-bps 500 > launch-plan.json

Review the complete data.plan, exact data.transaction, and data.simulation. Approval must repeat the exact 32-byte plan ID:

nexus --json approve \
  --plan-file launch-plan.json \
  --plan-id 0xEXACT_PLAN_ID > launch-approval.json

nexus --json handoff \
  --plan-file launch-plan.json \
  --approval-file launch-approval.json > wallet-request.json

handoff checks expiry and protocol identity and simulates the unchanged transaction again. The CLI still does not send anything. In an interactive terminal, press Enter to open the exact browser handoff; JSON mode returns the same URL without opening it. The URL keeps its request in the fragment, so it is not sent to or stored by the Nexus web server. The page requires the wallet and chain from the plan before requesting the external wallet's final review. EVM wallets submit directly. For Pump.fun, the page follows Phantom's multi-signer guidance: it gives signTransaction an exact transaction with both signature slots empty, validates the returned funding signature and permits only bounded Compute Budget or Phantom Lighthouse augmentation, then asks the same-origin Nexus endpoint to add the one-time memory-only mint signature and perform final signature-verifying simulation. The endpoint destroys that mint key and returns the completed public transaction; the browser sends it to the release-pinned Solana Tracker public RPC. Neither Nexus nor the endpoint receives the funding-wallet secret or broadcasts. After EVM submission, the page validates the successful receipt and exact transaction, displays the CA, and opens the canonical provider page immediately; safe-finality verification and receipt publication continue in the handoff tab. Use the retained public transaction ID with verify if automatic verification cannot finish:

nexus --json verify \
  --plan-file launch-plan.json \
  --transaction-id 0xEVM_HASH_OR_SOLANA_SIGNATURE

A final successful verification includes the token's external platform page (ponsfamily.com, flap.sh, or pump.fun). An exact successful EVM receipt may expose its CA and provider link before safe finality, but that state remains clearly labeled confirmed and must not be published as a verified launch. Reverted or mismatched receipts receive neither.

The approval digest proves only that this local artifact repeats the exact plan ID; it is not a wallet signature, authenticated consent record, or authorization for Nexus to broadcast. The funding wallet must independently review and sign the exact handoff request.

Provider rules

• pons v2: native ETH launch config 0, with economics pinned in calldata. A positive initial buy uses the official atomic launch-and-buy router and a nonzero output floor.
• Flap: standard zero-tax Token V3 launch through the reviewed Portal v5.18.0 implementation and newTokenV7 / TOKEN_V3_PERMIT, migrating through PancakeSwap Infinity CL. Bundled initial buys are rejected because the entry point has no caller-controlled minimum output. The reviewed configuration assigns 100% of configured distributable fees to eligible holders in native BNB with a 10,000-token minimum share balance. Nexus binds and revalidates all V7 runtime dependencies, native-BNB quote configuration, salt lock, and exact transaction. Conversational planning runs the complete read-only compatibility and simulation preflight before public metadata upload, then repeats it with the exact published CID.
• Pump.fun: uses the pinned @pump-fun/[email protected] instruction schema in the Nexus prepare endpoint. Nexus accepts only the exact sequence ComputeBudget limit + price, Pump create_v2, idempotent Token-2022 ATA creation, and Pump buy; any extra instruction is rejected. It Borsh-decodes the token fields and buy, requires maxSolCost = requestedLamports + floor(requestedLamports / 100) (an exact 1% cap), caps the priority price, and requires both funding-wallet and mint signatures to be absent during planning. The plan binds the one-time mint authorization, mainnet genesis hash, release-approved upgradeable Pump program and ProgramData hashes, full builder-response hash, active and warmed-up lookup-table contents/indexes, resolved accounts, compute settings, and blockhash. An upstream Pump upgrade fails before planning until a new runtime is separately reviewed and released.

Pump handoff refetches the program, ProgramData, and lookup tables and resolves and validates the five instructions again. At the wallet-review click, the same-origin refresh endpoint accepts only the current authorized unsigned bytes, replaces only the recent blockhash, proves every signer/instruction/account/lookup is unchanged, and simulates before opening Phantom. The browser uses signTransaction, not signAndSendTransaction, and Phantom receives both signature slots empty. After wallet approval, Nexus cryptographically validates the funding signature and any bounded Compute Budget or Lighthouse augmentation, adds the single-use mint signature held in process memory, performs a final signature-verifying simulation, destroys the mint key, and returns the completed bytes for browser submission. Verification requires Solana finalized status, exact signed bytes, the execution-time loaded addresses, a valid Token-2022 mint, and the expected Pump bonding curve. Pump's program and lookup table remain third-party mutable state: they can theoretically change between the final pre-signing read and transaction inclusion. Every spend and fixed account role is independently constrained, and verification fails if the execution-time loaded addresses differ, but a standard RPC cannot prove historical program bytes at the execution slot. Rebuild and reapprove after identity drift or plan expiry; a blockhash timeout alone can be refreshed from wallet review while the plan remains active.

Pump.fun currently requires a positive initial buy. Solana base fees and account-creation rent are additional to the plan's Pump buy and priority-fee caps. Conversational mode publishes the confirmed local artwork and provider-specific metadata before planning. The deterministic JSON CLI and MCP interfaces intentionally remain lower-level: their metadataUri input must already contain the exact public Pons image URI, canonical bare Flap CID, or Pump.fun metadata URI that will be bound into the machine-readable plan.

RPC configuration

Public defaults are built in. Operators may set these environment variables for their own read/simulation endpoints:

NEXUS_PONS_RPC_URL=https://...
NEXUS_FLAP_RPC_URL=https://...
NEXUS_SOLANA_RPC_URL=https://...

Credential-bearing RPC URLs belong only in the environment or a local secret store. They are never included in a plan or error. There is intentionally no PRIVATE_KEY, seed, signer-RPC, send, or broadcast setting.

Risk

Token launches are irreversible and can lose all value. Provider contracts and configuration can change. A successful simulation is not authorization, inclusion, finality, an audit, or a guarantee of execution price. pons, Flap, Pump.fun, Robinhood Chain, BNB Chain, and Solana are third-party names used to identify integrations; their inclusion is not an endorsement or partnership.