Skip to content

Changelog

Bullpen CLI is still in Alpha. For current install and account setup, use the Quickstart and Authentication guides.

The latest published release is v0.1.118.

This page covers changes that affect how you use the CLI. Internal service, deployment, and test details are intentionally omitted.

v0.1.119 - Unreleased

v0.1.119 is not yet published. This release moves Polymarket data reads to the current Data API ahead of the old version's retirement on October 24, 2026, and tightens several money-moving safety checks.

What changed

  • Polymarket data reads (positions, redeem, closeout, consolidate, wallet-audit, portfolio, trades, activity, holders, tracker, the data analytics, and leaderboards) now use Polymarket's v2 Data API. Command names, flags, and JSON field names are unchanged. Visible differences: leaderboard, builder, and live-volume figures are now share counts (tables label them as shares), activity --sort accepts only TIMESTAMP, very large listings stop with an explicit page-cap error instead of returning a truncated list, and a malformed Data API response now fails instead of being read as an empty or zero holding.
  • Money-moving writes on legacy Proxy (POLY_PROXY) wallets now refuse before signing, with a pointer to bullpen polymarket wallet-audit --refresh --output json. Read-only commands are unchanged.
  • Ambiguous Solana sponsored-transfer and swap submissions are now reported as outcome unknown (safe_to_retry: false) instead of "try again shortly"; reconcile with bullpen solana history --output json before retrying.
  • Safe-wallet relayer submissions now reconcile a stale nonce against the chain before signing, which fixes migrations that reverted on-chain.
  • The TLS dependency stack is updated to address a published advisory.

Not in this release

  • Polymarket Protocol V2 was announced on October 5, 2026, and new markets are expected to move to it around early November. This release does not support trading, approving, or redeeming on Protocol V2 markets.
  • The deposit-wallet relay-service route remains off by default.

v0.1.118 - September 10, 2026

This release adds a cash transfer between your Bullpen-managed Solana wallet and Hyperliquid perps buying power, pending EVM transfer approvals, transfer history lookup, and a rebuilt Solana limit-order engine on Jupiter Trigger v2.

What changed

  • bullpen funds cash-transfer previews and submits USDC moves between your Solana wallet and Hyperliquid perps buying power. After a submit whose outcome cannot be confirmed, the CLI blocks a silent resubmit of the same route and amount for 15 minutes; reconcile with bullpen funds balances before overriding with --acknowledge-unknown-outcome.
  • bullpen wallet approvals list and approve show and approve pending EVM transfer approvals. Listing can fail while any one approval is still generating server-side; approve itself is tested only in mock and source-level scenarios this release, not yet against a live generated approval.
  • bullpen funds transfers lists recent cash transfers, including a --tx <SIGNATURE> lookup by on-chain signature when a transfer id was lost.
  • Solana limit orders (limit-buy, limit-sell, orders, cancel-order, cancel-all-orders) now run on Jupiter Trigger v2. Orders execute as a swap once the trigger price is crossed, so the received amount is an estimate; the minimum order size rises from $5 to $10, and --expiry now defaults to 30 days (an order can no longer be created with no expiry).
  • bullpen wallet select now returns an error, instead of only a warning, when the server does not confirm that a wallet switch actually took effect.
  • Copy-trading execution status shows a delayed state accurately and labels statuses this CLI build does not recognize as unknown rather than guessing pending.

Known limitations in this release

  • Cash-transfer status output can now show TransferStatusRefunded (input returned to the source) and TransferStatusNeedsReview (outcome still being confirmed) in trace_status. This release treats both as an unknown outcome (safe_to_retry: false); reconcile with bullpen funds balances --output json before retrying.
  • A cash transfer's status can stay "in progress" after the funds have already been delivered; check your balance if a transfer looks stuck.
  • Balance reads can lag on-chain settlement by a few minutes after a transfer completes.
  • Copy-trading execution status, email verification (bullpen verify-email), and cash-transfer quote binding still depend on backend capabilities that did not change this release: execution stage and staleness remain CLI-side heuristics, email verification behaves as before, and duplicate-submit protection for cash transfers is local to the CLI rather than a server-enforced guarantee.

v0.1.117 - August 31, 2026

This release focuses on safer recovery output, clearer account status, and Polymarket order checks that use current market rules before preparing orders.

What changed

  • Recovery dry-runs show each planned source wallet, destination wallet, asset, action, evidence, and submit capability. Live recovery rechecks those facts before moving funds.
  • JSON recovery output uses safe_to_retry=false for conflicting wallet evidence, missing or uncertain recovery evidence, order credit the CLI cannot move, and unknown submit outcomes.
  • bullpen status separates valid local auth, expired auth with refresh credentials, login-required state, and unchecked auth state. Unrelated service failures should not force a new login.
  • bullpen identity show <USERNAME_OR_USER_ID> provides a public Bullpen identity lookup without requiring login. Wallet addresses are rejected with guidance to use bullpen polymarket data trader-profile instead.
  • Collateral migration guidance is narrower: use bullpen polymarket migrate for normal moves to the current Polymarket wallet. Move assets back to an older wallet only when Bullpen Support or a reviewed recovery workflow identifies that older wallet as the destination.
  • Polymarket buy, sell, limit-buy, and limit-sell preparation refresh market, outcome token, price increment, minimum order size, related-outcome market type, and fee data before building the order. Markets with smaller price increments such as 0.0025 remain supported.
  • sell --min-price rechecks the orderbook late in order preparation.
  • Copy-trading reads use bounded retries for short-lived unreadable responses. Mutating copy-trading updates are not replayed when the CLI cannot confirm the outcome.
  • Rewards output attributes balances to their source chain and avoids comparing unrelated reward programs.
  • Polymarket order output keeps returned trade IDs when transaction hashes are not available yet and treats missing hashes as pending instead of failed.

Still limited

  • Missing rewards, missing deposits, wallet deployment or registration, and order credit the CLI cannot move can still require Bullpen Support.
  • Copy-trading still cannot always name a stable market identity for older or incomplete copy events. The CLI shows the available event fields instead.
  • This release does not claim to repair older copy-event data, affected copy subscriptions, missing rewards, or deposits that have not appeared in your account.

Support notes

  • If JSON shows safe_to_retry=false, do not retry the signed command. Create a redacted support bundle with bullpen support bundle --output json. It writes a local diagnostic bundle only; it does not refresh auth, sign, or verify wallet/order-credit state.
  • For refreshed wallet and order credit evidence, use bullpen polymarket wallet-audit with --refresh, --include-order-credit, and --output json when the CLI or Bullpen Support asks for it.
  • For account state and authentication diagnostics, see Authentication.

v0.1.116 - July 23, 2026

This release focuses on Polymarket accounts that were difficult to diagnose or recover, and prepares order output for Polymarket's newer response format.

What changed

  • Current and legacy Deposit Wallet support. The CLI now recognizes both current Deposit Wallets and older, pre-migration Deposit Wallets across status, fix, wallet diagnostics, trading checks, and recovery. When the account-selected wallet is a deployed, approved legacy Deposit Wallet and no current Deposit Wallet has replaced it, trading stays pinned to that wallet. An older address that still needs external deployment or registration is identified as a support-owned recovery case, and money-moving repair commands are blocked.
  • New Polymarket order responses no longer look like failed trades. Polymarket may confirm a match with one or more trade IDs before a settlement transaction hash is available. When the service returns that successful response, Bullpen keeps the order ID and trade IDs and marks the transaction hash as pending instead of turning the fill into an error. JSON output adds trade_ids and transaction_hash_resolution.
  • Recovery can use another owned Polymarket wallet. bullpen recover funds can plan recovery from the selected wallet, another Bullpen-managed wallet, or a CLI-verified locally signable owned EOA without silently changing the account's selected trading wallet.
  • Recovery plans are rechecked before submission. Dry-run output shows the source, destination, and action. Live recovery verifies the same facts again before moving funds and reports any unfinished step.
  • Redeem attempts are easier to track safely. Live redeem output includes a durable operation ID. Use bullpen polymarket redeem-status to check that operation without submitting the redeem again.
  • Authentication failures give a specific next step. The CLI distinguishes an expired access token, a browser-login problem, unreadable local credentials, and an expired signing session. It asks for a new login only when a new login is actually required.
  • Balance and portfolio warnings are more honest. A failed data source no longer becomes a synthetic zero. The CLI shows which source was used and warns when wallet, position, and service totals disagree.

Important limits

  • Bullpen can recognize an undeployed or externally unregistered legacy Deposit Wallet, but the CLI cannot complete an external deployment or registration. Follow the support handoff printed by bullpen fix --refresh; do not keep switching wallets or repeating money-moving commands.
  • A pending settlement transaction hash does not mean the order failed. Keep the order ID and trade IDs, then inspect order or activity status.
  • Compatibility with trade-ID order responses is included in this release. Live post-change confirmation still depends on Polymarket returning that response in production.
  • If a redeem result is uncertain, do not submit it again. Check redeem-status or create a redacted bundle with bullpen support bundle --output json.

v0.1.115 - July 17, 2026

This release made trade output more predictable and reduced background analytics traffic.

  • Polymarket market buys handle fine tick sizes without increasing the requested spend.
  • Successful money-moving JSON no longer invents order IDs, fills, or transaction hashes that the venue did not return.
  • Hyperliquid spot and transfer previews show more of the evidence used by the live command.
  • Invalid wallet endpoints, leverage, order size, and liquidity failures give a concrete field to change.
  • Successful reads and repeated failures are combined into hourly analytics totals. Trades, funding actions, auth changes, recovery actions, and the first failure remain individual events.

v0.1.114 - July 14, 2026

This release simplified account recovery. Current first-run and login guidance lives in Quickstart and Authentication.

  • bullpen fix became the first repair command for common account problems.
  • Polymarket trading follows the wallet selected for the account. Older owned wallets are handled through explicit recovery flows.
  • bullpen support bundle --output json creates one redacted local diagnostic bundle when the CLI cannot repair the account.
  • Money-path errors share a consistent recovery shape in JSON.
  • bullpen status stays passive; it does not refresh credentials or change wallet state.
  • Device login gained bounded progress and stall reporting instead of waiting forever.
  • Polymarket preview and submit use the same tick-size rules.

v0.1.112 - July 6, 2026

This release corrected auth and balance diagnostics after v0.1.111.

  • bullpen status --output json plus the refreshed auth diagnostic (bullpen doctor auth --refresh --output json) checks local state and attempts a refresh when refresh credentials are available before reporting that login is required.
  • Wallet and wrap checks can fall back to exact on-chain pUSD, USDC.e, and native USDC balances when the portfolio service is unavailable.
  • Deposit Wallet checks understand both the current wallet derivation and the older derivation used by existing accounts.
  • Repeated temporary service failures stop with evidence for Bullpen Support instead of encouraging an endless retry loop.

v0.1.111 - July 4, 2026

This was a focused stability follow-up to v0.1.110.

  • Polymarket wallet audits and balance summaries gained exact on-chain fallback reads.
  • status distinguishes a valid local access token, an expired access token with refresh credentials available, a login-required state, and token state not checked.
  • Wallet warnings identify whether the selected trading wallet or only an inactive wallet is affected.
  • Solana balance refresh and Hyperliquid service failures use bounded, typed retry behavior.

v0.1.110 - July 3, 2026

This release concentrated on Polymarket submission failures and support diagnostics.

  • Market buys retry one unusable tick-size response using recently verified market metadata.
  • Deposit Wallet CLOB-binding failures have their own error class and recovery guidance.
  • Wallet diagnostics separate self-service actions from account states that need support.
  • Device login reports a stalled completion instead of a generic auth error.
  • Redeem diagnostics record scan progress and rate-limit context.
  • Managed same-chain wallet transfers became available.
  • Hyperliquid spot IOC orders that find no liquidity return a specific no-match result.

v0.1.109 - July 1, 2026

This release tightened validation and made automation output more consistent.

  • Solana swap, limit-order, and DCA commands fail earlier on invalid routes, sizes, schedules, or token input.
  • Hyperliquid errors identify leverage caps, HIP-3 minimum sizes, and spot minimum notional.
  • Hyperliquid order reads accept the same market naming used by cleanup commands, including HIP-3 DEX prefixes.
  • Polymarket wrap, unwrap, and cancel output includes clearer identifiers and rejects placeholder order IDs before making a request.

v0.1.108 - June 29, 2026

This release expanded the first CLI versions of Bullpen's three trading products.

  • Memes (Solana): improved token discovery, hidden-token management, history filters, DCA scheduling, and post-swap balance reporting.
  • Perps (Hyperliquid): broader HIP-3 market support, safer spot cleanup, and clearer DEX-specific account and margin errors.
  • Pear: documented and tested setup, status, positions, orders, open, close, cancel, risk, and leverage workflows.
  • Hyperliquid copy trading: added leader lookup and subscription lifecycle management.
  • Login, redeem, and rate-limit failures gained clearer next steps.

Solana, Pear, and Hyperliquid copy trading remained experimental in this release.

v0.1.107 - June 24, 2026

This release introduced broad Hyperliquid automation support.

  • Added Pear pair setup, reads, open, close, cancel, risk, and leverage commands.
  • Added Hyperliquid copy-subscription create, update, pause, resume, stop, risk, and pending-execution commands.
  • Added HIP-3 trading for a selected DEX.
  • Made auth refresh and credential-save failures stop safely.
  • Added Solana withdrawal previews.

v0.1.106 - June 18, 2026

This release focused on difficult Polymarket recovery cases.

  • Redeem can discover more positions when public market indexing is incomplete or a market uses a more complex payout structure.
  • Portfolio output separates recoverable value from stuck or resolved value.
  • Wallet refresh and selection became more reliable after an auth refresh.
  • The first Pear pair-trading commands were introduced.
  • Public docs were reorganized around installation, auth, recovery, and product workflows.

v0.1.105 - June 17, 2026

  • Homebrew and npm installs receive package-manager-specific upgrade guidance.
  • The terminal UI points managed installs to the correct upgrade path.
  • Unsupported Polymarket withdrawal routes fail before submission and direct users to the web app.
  • Homebrew trust and relink recovery steps were added to installation docs.

v0.1.104 - June 16, 2026

  • Hyperliquid perp entry, close, take-profit, stop-loss, and modify commands gained explicit size units.
  • Hyperliquid deposit dry-run clearly shows that no transfer was submitted.
  • DEX-scoped Hyperliquid market, order book, price, funding, and candle reads were added.
  • Early Pear pair-trading commands became available.
  • Polymarket resolved-position cleanup became easier to inspect.

v0.1.103

  • Improved Polymarket redeem discovery across owned wallets.
  • Added clearer approval and receipt handling for redeem.
  • Resolved losing positions can be reconciled without submitting an order to a closed order book.

v0.1.102

  • Improved refresh-token handling for longer-running agents.
  • Added clearer Polymarket position source and reconciliation output.
  • Reduced repeated login prompts when a session could be refreshed.

v0.1.101

  • Improved JSON consistency and full identifier output for automation.
  • Added stricter wallet-route checks before Polymarket money movement.
  • Expanded command and documentation validation in the release process.

v0.1.100

  • Consolidated the main Polymarket trade, wallet, and recovery workflows.
  • Added stronger release-build, credential, and command-coverage checks.
  • Improved support diagnostics for wallet routing, redeem, and auth failures.