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.
0.11.17 (2026-10-05)
Section titled “0.11.17 (2026-10-05)”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 ascandle swap --amountis (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--buythe launch is unchanged. It needs a server withTEE_LAUNCH_BUYS_ENABLEDon, 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--buyand buying withcandle swap.candle wallets allow-launch <wallet>...lets TEE wallets pay for a launch, whichcandle launchneeds, andcandle wallets disallow-launch <wallet>...stops them. They take the selectorswallets trusttakes (a label, address, id, orprefix*) and the device token, never an API key. The screen shows each wallet’s label, address and bound key before you typeconfirm;disallow-launch --yesskips 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 answersALLOW_LAUNCH_UNSUPPORTEDand nothing changes.candle launch’sLAUNCH_NOT_ALLOWEDmessage now names the command instead of the raw endpoint.candle plansandcandle launch --helpsay 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: MCPcandle_launch_and_seed, SDKlaunch()).candle launchitself is unchanged: it is the TEE-wallet path and needs Pro or Max.candle swapfrom 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 withPAIR_UNSUPPORTED. A server that cannot hold an embedded swap for confirmation answersEMBEDDED_PAYER_UNSUPPORTEDand 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.
0.11.16 (2026-10-03)
Section titled “0.11.16 (2026-10-03)”- A project
.envno longer configures the CLI. The compiled binary ignores.envandbunfig.toml; exportCANDLE_*variables or store settings in a profile. candle doctortells an owner profile from a bot profile.API key valid (launch:write)is renamedAPI key valid, and in the bot roleLaunch wallet delegatedis renamedEmbedded wallet.--jsonrows 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 isvault 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--jsongainsfilter,matchedandwallets. No match prints one line and exits 0 when the list and the reads were whole.candle portfoliokeeps 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.
0.11.15 (2026-10-03)
Section titled “0.11.15 (2026-10-03)”candle plansprints 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;--jsonis the server’s body. Against a server without the table it says so and exits 1.candle swap,candle launchandcandle perpshelp 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 atcandle plansfor the rates in force rather than naming them.candle mcpgainscandle_get_plans, and--read-onlypins six keyless tools.candle pnlreads the one P&L (see the 2026-10-02 entries in the partner API changelog):Totalis the console’s figure, to the cent.candle pnl --profileprints 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 needsswap:writeand a raw cap on the asset, takes no Candle fee and is mainnet only. There is no withdrawal yet.candle mcpgainscandle_perps_deposit.
Formats: no change to vault.enc, tee-wallets.enc, config.json or the secret store.
0.11.14 (2026-10-02)
Section titled “0.11.14 (2026-10-02)”- Hyperliquid perpetuals:
candle perps setup|open|close|cancel|orders|positions|leverage, from the EVM TEE wallet bound to the key. The key needs theperps:writescope, which is opt-in.setupapproves 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--tpand--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_BUILDERpins the builder andCANDLE_HYPERLIQUID_NETWORK=testnettrades testnet. Depositing to Hyperliquid from the CLI is not in this release.candle mcpgains the matchingcandle_perps_*tools. candle portfolioshows 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, elseCANDLE_EVM_RPC_URL, else the built-in Hood RPC). ACHAINcolumn,chainon every wallet and holding in--json, subtotals per group and per chain, and--chain solana|hoodto show one. An unpriced Hood token shows why. An EVM RPC that is not Hood is refused withEVM_CHAIN_MISMATCH. Against a server that does not send Hood wallets yet, the output is Solana only.candle pnlshows a Solana block, a Hood block and the combined figure, and aCHAINcolumn on positions.candle pnl --profiledoes the same frompnl.byChainand lists each paying wallet with its chain.- Solana
tee sweepandvault demoteread, 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: falsein--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.--jsongainscontextFloorSlotand an optionalsloton 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.
0.11.13 (2026-10-02)
Section titled “0.11.13 (2026-10-02)”candle mcp(the MCP server this CLI bundles) gainscandle_get_portfolio: balances and prices for the account’s embedded and TEE wallets on Solana and on Hood. Vault and external wallets stay oncandle portfolio, which reads them over your own RPC. The same server’scandle_get_profile_pnlnow describes per-chain P&L:chainon each open position and wallet row, andpnl.byChainwith each chain’s own figures. This is the portfolio command surface from #1538. A server that predates it omitshood,chainandbyChain.- Two other bundled-server text changes landed after 0.11.12 and ship in this binary. They are already on the standalone
@candledottv/mcpnpm package:candle_get_profile_pnldescribespnl.byWallet(#1501, MCP 0.10.3), andcandle_token_forensicssays 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.
0.11.12 (2026-09-30)
Section titled “0.11.12 (2026-09-30)”- 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> --waitfollows a bridge until it fills, refunds or fails, andtee sweeprefuses a wallet while a bridge from or to it is still open. Vault to vault isvault fund, thencandle swapacross, thentee sweep. vault promote --to-keyandtee rebindreport 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 describesclientSwapIdon 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.
0.11.11 (2026-09-28)
Section titled “0.11.11 (2026-09-28)”- 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 doctorand 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.
0.11.10 (2026-09-26)
Section titled “0.11.10 (2026-09-26)”- Key signers:
candle tee signer new,keys signer approve,keys signer move, andvault promote --to-keyandtee rebindonto a key that has a signer. See Key signers. - Hood TEE wallets in the CLI: EVM promote, fund, sweep, demote and
swapon Hood. See Hood TEE wallets. candle keys accesschanges 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-emptycloses the embedded wallet’s empty token accounts and reclaims their rent.
Formats:
vault.encversion 4, one way. A vault moves to version 4 on the write that creates its first Hood TEE wallet (an EVM promote, orvault restore --phrase --evm-tee-countof 1 or more), and never moves back. 0.11.9 and every older CLI refuse a version 4 vault withVAULT_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.sealedbeside the vault, and<copy>.evm-record.sealedbeside a backup. Older CLIs do not read it or copy it. config.jsongainskeySigners(the key-signer index and pins) andpublicRpcNotice. 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 ownwallet_signer_<id>, and atee rebindorkeys signer moveonto a key signer deletes that slot once the move is read back. tee-wallets.encis unchanged.
0.11.9 (2026-09-24)
Section titled “0.11.9 (2026-09-24)”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.
0.11.8 (2026-09-24)
Section titled “0.11.8 (2026-09-24)”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.
0.11.7 (2026-09-24)
Section titled “0.11.7 (2026-09-24)”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.
0.11.6 (2026-09-23)
Section titled “0.11.6 (2026-09-23)”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 ownvault backupdoes not update them, so after an older CLI’s backupvault statusstops 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.encitself,tee-wallets.enc,config.jsonand the secret store are unchanged.
0.11.5 (2026-09-22)
Section titled “0.11.5 (2026-09-22)”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.
0.11.4 (2026-09-21)
Section titled “0.11.4 (2026-09-21)”vault rename, the label uniqueness guard, and the backup transcript.
Formats: none. A rename rewrites an existing label field; the version is unchanged.
Before 0.11.4
Section titled “Before 0.11.4”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.