Skip to content

CLI release notes: formats

Every Candle CLI release note carries a Formats line. It says whether the release changes anything the CLI keeps on disk (vault.enc, tee-wallets.enc, the files beside the vault, config.json, and the names it stores secrets under) and whether an older CLI still reads what this one writes. Check it before you run two CLI versions against one vault, restore a backup on an older machine, or pin a bot to an older release.

The full notes for each release are on its GitHub release. This page keeps the Formats lines together, newest first.

  • candle launch --wallet <tee> --buy <amount> makes the first buy at launch, from the same TEE wallet. The amount is in whole units of the quote asset, converted as candle swap --amount is (SOL, USDC or CNDL on Solana; ETH on Hood). On Solana the buy rides in the launch transaction; on Hood it is Candle’s own curve buy, signed as the last leg after the curve and the fee, and the CLI signs it only when it pays this launch’s curve exactly that amount. The preview names the buy before you confirm. Without --buy the launch is unchanged. It needs a server with TEE_LAUNCH_BUYS_ENABLED on, which is off by default: until then Candle refuses the buy, and the CLI says so (VALIDATION_FAILED, naming the flag, with nothing built or signed) and suggests launching without --buy and buying with candle swap.
  • candle wallets allow-launch <wallet>... lets TEE wallets pay for a launch, which candle launch needs, and candle wallets disallow-launch <wallet>... stops them. They take the selectors wallets trust takes (a label, address, id, or prefix*) and the device token, never an API key. The screen shows each wallet’s label, address and bound key before you type confirm; disallow-launch --yes skips the confirm. A wallet that is not a TEE wallet is named and left alone. They need an API with the allow-launch preview; an older one answers ALLOW_LAUNCH_UNSUPPORTED and nothing changes. candle launch’s LAUNCH_NOT_ALLOWED message now names the command instead of the raw endpoint.
  • candle plans and candle launch --help say which launch paths need a plan. The two launch rows read “Launch from a linked or TEE wallet (self-signed)” and “Atomic launch: launch + 1–4 first buys in one bundle”, and the note under the table says every plan, Free included, can launch from its embedded wallet with an optional dev buy (same transaction on Solana; best-effort follow-up on Hood) (the headless launch: MCP candle_launch_and_seed, SDK launch()). candle launch itself is unchanged: it is the TEE-wallet path and needs Pro or Max.
  • candle swap from the embedded wallet now swaps between base assets on one chain (SOL, USDC and CNDL on Solana; ETH and USDG on Hood). It shows the quote and asks before anything is sent, as a token trade does: Candle builds the swap and holds it, and the CLI submits that stored plan once you confirm. It used to refuse a base pair from the embedded wallet with PAIR_UNSUPPORTED. A server that cannot hold an embedded swap for confirmation answers EMBEDDED_PAYER_UNSUPPORTED and nothing is built. When the outcome is uncertain, the CLI prints the known hashes and says not to retry under a new id.

Formats: none. No change to vault.enc, tee-wallets.enc, config.json or the secret store.

  • A project .env no longer configures the CLI. The compiled binary ignores .env and bunfig.toml; export CANDLE_* variables or store settings in a profile.
  • candle doctor tells an owner profile from a bot profile. API key valid (launch:write) is renamed API key valid, and in the bot role Launch wallet delegated is renamed Embedded wallet. --json rows have stable ids, and the role and provenance fields are additive. A paused profile fails the Trade path check.
  • candle portfolio <filter> shows only the wallets whose label or address contains the filter, in every group: vault, external, TEE and embedded, on both chains. The rule is vault list’s: a case-insensitive substring, no glob. Vault and external keys the filter leaves out are never sent to your RPC, so a few wallets out of a large vault read in a few requests where the whole vault can be rate-limited on the public endpoint. Subtotals and the total are for the matched wallets, the first line says how many matched, and --json gains filter, matched and wallets. No match prints one line and exits 0 when the list and the reads were whole.
  • candle portfolio keeps a cut-off wallet list partial on its own. Filtering out a wallet Candle could not read, or an LP position it could not read, no longer makes the result look complete, and no match says when the list was only part of the account. Against an older API that does not say whether the list was cut off, that partial answer stays partial instead of being reported complete.

Formats: none. No change to vault.enc, tee-wallets.enc, config.json or the secret store.

  • candle plans prints the plans the API serves (GET /api/v1/agent/plans): each plan’s monthly price, agent trade fee and Hyperliquid perps builder fee, the limits a new key gets, and one row per capability, such as buying or selling tokens not launched on Candle, self-launch, linked wallets and limit orders. Every number is the server’s. It needs no key and sends none; --json is the server’s body. Against a server without the table it says so and exits 1.
  • candle swap, candle launch and candle perps help say what each plan can do: any plan can sell a token it holds, buying a token not launched on Candle and launching from a TEE wallet need Pro or Max, and every plan except Max pays the perps builder fee. They point at candle plans for the rates in force rather than naming them.
  • candle mcp gains candle_get_plans, and --read-only pins six keyless tools.
  • candle pnl reads the one P&L (see the 2026-10-02 entries in the partner API changelog): Total is the console’s figure, to the cent.
  • candle pnl --profile prints a Hyperliquid block: realized gross, funding, fees and net for the key’s bound EVM TEE wallets since their current binding, kept apart from the spot total.
  • candle perps deposit <amount> <SOL|USDC|ETH|USDG> moves USDC onto the key’s Hyperliquid account through Relay, paid from the key’s Solana TEE wallet (SOL or USDC) or Hood TEE wallet (ETH or USDG); --to <evm tee> picks the account when the key has more than one. candle perps deposit status <id> follows one. It needs swap:write and a raw cap on the asset, takes no Candle fee and is mainnet only. There is no withdrawal yet. candle mcp gains candle_perps_deposit.

Formats: no change to vault.enc, tee-wallets.enc, config.json or the secret store.

  • Hyperliquid perpetuals: candle perps setup|open|close|cancel|orders|positions|leverage, from the EVM TEE wallet bound to the key. The key needs the perps:write scope, which is opt-in. setup approves Candle’s builder fee once (0.1% on Free, Believer and Pro; none on Max). open <coin> <long|short> <size> trades at market, or as a limit with --price, with optional --tp and --sl; close <coin> closes reduce-only. Candle builds each action within the key’s limits; the CLI recomputes its hash and checks the action type and Candle’s builder before anything is signed, then submits the signed action to Hyperliquid itself. CANDLE_HYPERLIQUID_BUILDER pins the builder and CANDLE_HYPERLIQUID_NETWORK=testnet trades testnet. Depositing to Hyperliquid from the CLI is not in this release. candle mcp gains the matching candle_perps_* tools.
  • candle portfolio shows Hood: the account’s Hood TEE and embedded wallets (ETH, USDG and tokens, from Candle) and EVM vault keys (ETH and USDG, over your own Hood RPC: --evm-rpc-url, else CANDLE_EVM_RPC_URL, else the built-in Hood RPC). A CHAIN column, chain on every wallet and holding in --json, subtotals per group and per chain, and --chain solana|hood to show one. An unpriced Hood token shows why. An EVM RPC that is not Hood is refused with EVM_CHAIN_MISMATCH. Against a server that does not send Hood wallets yet, the output is Solana only.
  • candle pnl shows a Solana block, a Hood block and the combined figure, and a CHAIN column on positions. candle pnl --profile does the same from pnl.byChain and lists each paying wallet with its chain.
  • Solana tee sweep and vault demote read, simulate and confirm against one finalized RPC context, so a load-balanced RPC can no longer size a transfer from a newer state and simulate it against an older one. A transaction the RPC rejects before broadcast is reported as rejected and not broadcast (broadcast: false in --json) instead of “may still land”, and the sweep carries on with the other accounts; it stops after a third rejection and lists what it did not attempt. --json gains contextFloorSlot and an optional slot on each receipt.

Formats: a sweep receipt in tee-wallets.enc can carry an optional slot; older CLIs ignore it. No change to vault.enc, config.json or the secret store.

  • candle mcp (the MCP server this CLI bundles) gains candle_get_portfolio: balances and prices for the account’s embedded and TEE wallets on Solana and on Hood. Vault and external wallets stay on candle portfolio, which reads them over your own RPC. The same server’s candle_get_profile_pnl now describes per-chain P&L: chain on each open position and wallet row, and pnl.byChain with each chain’s own figures. This is the portfolio command surface from #1538. A server that predates it omits hood, chain and byChain.
  • Two other bundled-server text changes landed after 0.11.12 and ship in this binary. They are already on the standalone @candledottv/mcp npm package: candle_get_profile_pnl describes pnl.byWallet (#1501, MCP 0.10.3), and candle_token_forensics says a Hood token Candle did not launch names its launch account for pons.family and pools.trade, with no record of earlier coins (#1537, included in MCP 0.10.4).

Formats: none. No change to vault.enc, tee-wallets.enc, config.json or the secret store.

  • Bridging between Solana and Hood in candle swap: a TEE wallet swaps a base asset on one chain for a base asset on the other (SOL or USDC on Solana, ETH or USDG on Hood), through Relay, into the same key’s TEE wallet on the other chain. No Candle fee. --to <tee> picks the destination when the key has more than one on that chain, candle swap status <id> --wait follows a bridge until it fills, refunds or fails, and tee sweep refuses a wallet while a bridge from or to it is still open. Vault to vault is vault fund, then candle swap across, then tee sweep.
  • vault promote --to-key and tee rebind report trade readiness by the rule the server uses: only a cap of zero stops an asset, and a missing cap or transaction limit is unlimited, so a key with no caps no longer warns that it cannot trade. A Hood wallet is checked against its ETH and USDG caps.
  • candle mcp (the MCP server the CLI runs) now describes clientSwapId on the swap tool as a durable idempotency key. A retry of the same request with the same id, amount and slippage replays the stored result instead of swapping again, so after a timeout an agent retries with the same id rather than stopping. A confirmed first leg of a bridge is replayed with its hash and is not run a second time.

Formats: a swap’s local operation record (the file candle swap status reads) can carry an optional bridge field for a bridge; older CLIs ignore it. No change to vault.enc, tee-wallets.enc, config.json or the secret store.

  • Only the limits a key’s owner set apply. A TEE trade or swap needs neither a per-asset cap nor a USD transaction limit; a missing one is unlimited, and a limit that is set still binds. candle doctor and the swap readiness checks follow the same rule.
  • The automatic stop after five consecutive buys of the same token is removed. Trade-rate, failed-sell and owner-set loss limits stay.

Formats: none. No change to vault.enc, tee-wallets.enc, config.json or the secret store.

  • Key signers: candle tee signer new, keys signer approve, keys signer move, and vault promote --to-key and tee rebind onto a key that has a signer. See Key signers.
  • Hood TEE wallets in the CLI: EVM promote, fund, sweep, demote and swap on Hood. See Hood TEE wallets.
  • candle keys access changes a key’s access level in place.
  • A default Solana RPC, a per-profile RPC setting, and a prompt when the public RPC rate-limits you.
  • A key can hold up to 1,000 wallets (the Max plan’s linked-wallet cap), read from the server, and a rebind that adds no wallet is never refused for size.
  • candle wallet close-empty closes the embedded wallet’s empty token accounts and reclaims their rent.

Formats:

  • vault.enc version 4, one way. A vault moves to version 4 on the write that creates its first Hood TEE wallet (an EVM promote, or vault restore --phrase --evm-tee-count of 1 or more), and never moves back. 0.11.9 and every older CLI refuse a version 4 vault with VAULT_VERSION_UNSUPPORTED. A vault with no Hood TEE wallet keeps its version 2 or 3 header byte for byte and still opens in older CLIs. Before creating a Hood TEE wallet, update every machine that opens that vault or its backups.
  • New file vault.evm-record.sealed beside the vault, and <copy>.evm-record.sealed beside a backup. Older CLIs do not read it or copy it.
  • config.json gains keySigners (the key-signer index and pins) and publicRpcNotice. Older CLIs ignore both and keep them when they write the file.
  • Secret store: new refs key_signer_<prefix>_<spkiSha256>. Older CLIs ignore them. A wallet owned by a key signer trades only from a CLI that has this release: an older CLI looks only for the wallet’s own wallet_signer_<id>, and a tee rebind or keys signer move onto a key signer deletes that slot once the move is read back.
  • tee-wallets.enc is unchanged.

EVM vault keys (vault new-key --chain evm, vault transfer on Hood or any EVM chain), and tee rebind pointers.

Formats: no version change. EVM keys are new entries in the existing version 2 and 3 index, which already allowed them, so older CLIs open the vault. Older CLIs predate the check that stops Solana-only commands from being pointed at an EVM key, so run commands that name an EVM key only from 0.11.9 or later. tee-wallets.enc, config.json and the secret store are unchanged.

candle transfer, keys create --access, wallets trust, and a security key can authorize adding another factor.

Formats: none. No change to vault.enc, tee-wallets.enc, config.json or the secret store.

candle lp, portfolio and pnl with LP valuation, vault promote --to-key, and vault transfer from a promoted wallet.

Formats: tee-wallets.enc sweep records can now have kind lp-close, an addition. Older CLIs open the file and carry the record through unchanged; how they display an lp-close record has not been checked. vault.enc, config.json and the secret store are unchanged.

The unlock menu, tee rebind, the promote confirmation, and security keys in sealed backups.

Formats:

  • The vault’s state file (vault.state.json) gains four optional backup fields that tie a backup to the factors it was made with. An older CLI keeps them, but its own vault backup does not update them, so after an older CLI’s backup vault status stops naming which keys the last backup carries. Nothing is lost.
  • A sealed backup copy now keeps security-key envelopes as well as the passphrase. The copy’s version is unchanged, and older CLIs already open a vault with security-key envelopes.
  • vault.enc itself, tee-wallets.enc, config.json and the secret store are unchanged.

vault list, vault promote-batch, and a working install for GitHub CLI users.

Formats: none. promote-batch writes the same index fields a single promote does.

vault rename, the label uniqueness guard, and the backup transcript.

Formats: none. A rename rewrites an existing label field; the version is unchanged.

vault.enc version 3 (the external branch, for candle external and candle sign) predates 0.11.4. A CLI from before it refuses a version 3 vault with VAULT_VERSION_UNSUPPORTED; a vault that never used the external branch stays version 2.