Release 010 · August 26, 2026 · Current
VEX 0.2.7
The agent learns to show its work - eighteen market tools that read what the DexScreener site reads, a Board that puts the analysis on screen, and a first look at Vex Studio.
Since 0.2.6, 164 commits landed across three arcs and a full redesign of the desktop shell. The DexScreener surface was rebuilt from twelve public-API tools into 18 tools that read the same channels the DexScreener website itself uses - buyers and sellers per pair, candles down to one second, the trade tape, trader leaderboards, safety reports, narratives and paid promotion - and every one of them was probed live before a line of adapter code was written. The agent can now present its findings as a visual Board with a live candlestick Spotlight instead of describing them. Behind the scenes, the groundwork for Vex Studio ships in this build - a first look at where Vex is heading, with the reveal to follow. Around those arcs sit two themes for the app, Solana balances read straight from the chain with one honest pricing rule, a validation fix that makes every refusal say why, a 25 bps fee on the generic EVM signing lane, the VEX badge on pools.fun launches, and fixes for the three defects reported against 0.2.6. Eleven database migrations (084-094) apply automatically on first start.
01 · DexScreener tool surface
The agent no longer talks to the public DexScreener API. Its 18 read-only tools read the screener, pair, search, spotlight, narrative, bars and trade channels the website itself renders, so the agent sees what a person on the site sees, including fields the public API never carried: buyers, sellers and makers per window, the buy and sell volume split, holder and audit blocks, and the tape. The twelve old tools are gone without aliases. Every answer carries its provenance - which transport served it, when it was fetched, whether it came from a cache - and treats issuer-written names, symbols and profile text as untrusted data, stripping invisible and bidirectional characters with the affected fields named and never shortening anything readable without saying so.
01 · Seven screening boards share one filter family. The boards run server-side over the whole indexed population, 100 rows per page with offset paging, and every one accepts the same filters - chain, DEX, pool label (v2, v3, v4, CLMM, DLMM, CPMM), narrative, launchpad, liquidity, volume, market cap, FDV, transactions, buys, sells, price change, pair age, boost count, launchpad progress - and echoes every filter that actually went on the wire, because the provider silently drops the ones it does not know.
02 · dexscreener__pairs_trending_list answers "what is moving right now". Pairs ranked by the site's trending score for the 5-minute, 1-hour, 6-hour or 24-hour window, with price, volume, liquidity, market cap, buys and sells, buyers, sellers and makers, derived flow ratios and each pair's share of its chain's volume. Trending order mixes organic activity with paid boosts, so boost counts are shown per row and no quality floor is applied.
03 · dexscreener__pairs_top_list answers "where is the volume, the depth, or the paid attention". Metric leaders by volume, transactions, buys, sells, liquidity or active paid boosts, with turnover, net flow and transactions-per-maker ratios and the filtered set's aggregate stats. Ranking by market cap or FDV is deliberately not offered because the provider returns a wrong ordering for it; filter on those bounds and rank by liquidity or volume instead.
04 · dexscreener__gainers_list ranks price change with the site's own quality floor. The 24-hour floor (300 transactions, 30 sells, 100,000 USD of volume, 250,000 USD of liquidity and a token profile) is applied and echoed; loosen or drop it explicitly and the answer reports whether the floor held, tightened, weakened or was removed. One flag returns all four windows' price changes on every row.
05 · dexscreener__losers_list separates a real exodus from a thin-book wick. The same board ascending, plus sell-side flow - sellers, sell volume share and net outflow in USD - which is what tells the two apart.
06 · dexscreener__pairs_new_list hunts fresh listings. Pairs newest first, under a maximum age (default 24 hours) and above a minimum liquidity (default 1,000 USD, removable), with exact pair age, early volume, a five-minute-versus-trailing-hour volume acceleration ratio, and the launchpad a pair graduated from. New pairs were measured appearing 17 to 39 seconds after creation.
07 · dexscreener__tokens_screen answers about a token rather than one of its pools. Token-level rows rather than pool rows, with volume, liquidity and transactions summed across a token's pools next to the provider's representative pool, and an honesty block stating that the universe is profile-carrying tokens only, the ranking is the provider's opaque score and there is no server-side total.
08 · dexscreener__pairs_search is the first tool for a named ticker. Name, symbol or address across up to five chains in one call, at most 30 rows per chain with no continuation, with a warning that copycat names are common and a pointer to compare liquidity, pair age and the address.
09 · dexscreener__narratives_list reads themes before any single pair. The 18 DexScreener narratives with per-chain market cap, change, volume, liquidity and token count, and each narrative's id, which is the exact value the screening boards take to list that theme's pairs (the human slug matches nothing; the id matched 243 pairs in the live probe).
10 · dexscreener__pair_get is the tool for polling a position. One pair's complete live state in about a kilobyte: every windowed metric including buyers, sellers, makers and the buy/sell volume split, derived flow ratios, reserves, profile links and launchpad origin, with reactions and the provider's insight blurb as optional side reads.
11 · dexscreener__token_pairs_list shows every pool a token trades in. Every indexed pool for a token, deepest first, at most 30, with each pool's share of liquidity and volume, the venue count and the deepest pair over the returned window - never over the real pool set, and the answer says so, because routing a swap on a sample that reads as a survey is how it ends up in the wrong pool.
12 · dexscreener__pairs_batch_get refreshes a watchlist in one frame. Rows for an explicit list of pairs or tokens with no artificial input ceiling (a 300-input probe completed), where the per-input accounting - resolved, invalid, duplicate, omitted by the provider - always sums to the number of identities passed. Nothing vanishes from a list that still looks complete.
13 · dexscreener__chains_list is the vocabulary. 74 chains with their DEXes, explorer link templates, native chain ids and which audit integrations exist per chain, cached daily. An unknown chain is refused by name with the nearest matches.
14 · dexscreener__pair_details_get is the safety report. Audit blocks from two third-party providers are kept separate with their disagreements listed; buy and sell taxes come as the raw value and a normalized decimal; top holders carry the number of holder rows every concentration percentage was computed over; LP locks, supply, mint and authority flags follow. A block the provider did not return reads unavailable with its reason, an answer with every block empty reads not indexed yet, and no composite score is invented. No audit data and no problems found are different answers, and this tool never confuses them. The project's socials in the profile hand off to the Twitter/X and web research tools.
15 · dexscreener__candles_list reads price history at 18 resolutions. OHLCV history from one second to one month, up to 999 bars per call, over any historical window resolved through a block anchor rather than a page walk, as a price or market-cap series in USD or the native quote, with a summary of period change, high and low with timestamps, total volume, the largest single-candle move, gap count and whether the newest bar is still forming. Every price is a decimal string, and an empty first page names both readings - wrong identifier or no bars.
16 · dexscreener__trades_list walks the tape to any depth. A pair's trades newest first, 100 per page, with an exact cursor (block, transaction index and event index, because a block-only cursor was measured omitting a real buy), second-precise time windows, side and size filters, and a single wallet's history on the pair; each row carries the counterparty's retained share of what it bought and whether it is new on the pair, and an aggregate mode returns net flow, unique buyers and sellers, new-wallet share, a size histogram and the largest trades with the covered range stated.
17 · dexscreener__top_traders_list ranks the wallets on one pool. Up to 100 wallets by bought, sold, net cash flow or current holding value over the provider's 30-day window, which cannot be widened. Every answer names what the venue cannot see - other venues, transfers, cost basis, supply share - and net cash flow is labeled as exactly that, never profit. Holding values are computed as the exact decimal product of balance and price with the basis reported, and a per-page coverage figure says how many rows carried a balance at all.
18 · dexscreener__launchpad_pairs_list reads bonding curves the normal screens hide. Bonding-curve pairs and graduated ones, with progress percent, creator address, migration DEX, market cap and flow; it states that a creator address is the deploying wallet only on bonding rows, that a graduated token can appear twice (dead curve plus migrated pool), and that bonding rows carry no liquidity field, so a liquidity threshold would exclude all of them.
19 · dexscreener__spotlight_get reads paid attention. The top boosts, the boosts just purchased and the newest token profiles from the same document the website renders, with a statement on every answer that a boost is bought visibility - not demand, quality or safety - and that two calls should never be diffed and reported as news, because tied rows reorder between cached copies.
20 · How the app reaches the site. The desktop app carries a dedicated site transport: a hidden, sandboxed window in its own session that loads a single in-memory page and reads the site's data channels over Chromium's own network stack, the way a browser tab does. The transport is allowlisted by host and path, admits the image CDN only for token icons, single-flights identical requests, caps concurrent exchanges at four, materializes nothing until the first DexScreener question is asked, and is torn down with the agent runtime. Wire formats are decoded through checked-in schema descriptors, so every enum and field name the code emits comes from a machine artifact rather than convention, and money fields are preserved as decimal strings end to end.
21 · Found by intent, verified live. Carrying all 18 schemas in every request measured about 66,000 tokens, so the agent finds these tools through ToolSearch instead. The system prompt carries a compact DexScreener capability card naming nine areas - market screening and leaderboards, search and token pools, pair snapshot and batch refresh, narratives and market context, paid attention and promotion feeds, chain and DEX catalog, token safety and holders, price history and charts, trades and trader leaderboard - and the research source order: DexScreener, web research and the Twitter/X reader first, other market namespaces as fallback, and an executable price only ever from a fresh venue quote. Three rounds of independent verification - two with one endpoint per verifier, then a third with every tool in play under ten trading personas - re-probed every parameter against live bytes and closed a 61-item ledger: a batch row-and-identity invariant, holder concentration that excludes the pool's own account, a market cap that can never exceed FDV, narrative ids validated against the catalog, and a deepest-pool choice that is withheld with a named reason when a token's pools disagree on price.
02 · What the agent analyzes now
VEX can show its market analysis instead of describing it. Whenever a reply presents tokens, pools, a comparison or a watchlist, the agent composes a Board and attaches it to that reply. The agent supplies only its analysis: a title in its own words, up to eight pools, a one-line takeaway per pool, a full written assessment per token, up to twelve notes of risks and caveats, and optionally one chart with up to twelve marks it drew itself. Every price, liquidity figure, volume, trade count, token name, photo and candle on the board is read by the runtime at the moment of composition and stamped with that time.
01 · Board. In the chat a board arrives as a compact card - the agent's title, a UTC subtitle, three token photos, a Snapshot or LIVE state, a tally of clean, high-risk and unchecked pools, and a View board button that is never pressed for you. View board opens a grid of equal token cards: photo or monogram, chain mark, hero price, 24-hour change, an inline sparkline, Liquidity, 24h Volume, Trades and Pair age, a status chip such as New pair, Clean checks or High risk, a Spotlight button, Ask VEX, and a DexScreener link. A Show filter narrows the grid by safety state, the board can be pinned to the sidebar, and the BOOK panel gains a Portfolio | Board tab with the active board and an unseen dot that lights only when a live board arrives. The tab is never switched for you.
02 · Spotlight. Spotlight is the deep view of one token: the provider's description rendered whole with an honest freshness line, five stat rows including Holders, Buy/Sell and Liquidity lock bars, factual safety rows, the agent's whole assessment as the primary section, and five further sections - Smart money, Tape, Momentum, Promotion and Other pools. Four quick questions hand off to Ask VEX.
03 · Candles. The Spotlight chart offers 1H, 24H, 7D and 30D views (one-minute, quarter-hour, two-hour and eight-hour candles) with a volume histogram, a UTC axis, a crosshair tooltip with open, high, low, close and volume, a keyboard bar cursor with a spoken readout, a tint on the bar still forming, and a caption that discloses when the provider had fewer buckets than the range asks for. A failed refresh keeps the last good bars on screen. Axis decimals follow the series' own precision, a negative-zero tick prints as 0, and an annotation whose time falls outside the loaded bars is reported rather than silently moved. The agent's own chart, when it draws one, uses any of the 18 provider resolutions and up to 200 candles.
04 · Safety checks. Safety on a board is a table of facts, not an opinion. Each row names the check, its source and a pass, fail or unverified verdict: honeypot, sellability, mint, blacklist and pause powers, hidden or reclaimable ownership, proxy and open-source status, buy and sell tax at exact thresholds, owner and creator concentration, LP burn and lock share, read from two audit sources by the runtime itself. No pool is marked clean on partial evidence, unknown pools stay counted rather than disappearing, and the chip distinguishes Unverified, Partial checks, Sources disagree and Checks out of date from High risk. The agent's prose can never color the chip.
05 · Smart money, tape, momentum. Smart money is the 30-day cash-flow leaderboard for this one pool - every wallet the provider returns, with bought, sold and net in dollars, and a plain statement that net cash flow on one venue is not profit and not a position. The Tape streams the latest trades every five seconds with side, size, price and wallet, and never hides a hole: if a poll cannot reach the block it already published, the oldest row carries an explicit gap marker. Momentum places the provider's 5-minute, 1-hour, 6-hour and 24-hour windows on one axis by normalizing each to volume per hour, trades per hour and buy share, so acceleration can be read off the row.
06 · Other pools and promotion. Other pools lists where else the same token trades, with an honest count of what the provider's window contained and a note when that window was full and more pools exist. Promotion shows active boosts when the pair reports them (and says "not reported" rather than zero when it does not), states that bought visibility is not demand, and names the narratives the token sits in.
07 · Live data. A LIVE switch streams the cards' figures. It is off on every open and never remembered. When on, the app re-reads the same pools every five seconds and publishes a tick only when every pool resolves exactly; a partial answer keeps the last good figures and shows the board as degraded, never as a mixed snapshot presented as connected. After six consecutive failures the stream is dropped. Board traffic across cards, chart, tape, smart money, momentum and other pools is capped at two concurrent exchanges so the agent always keeps a channel for its own tools, and every feed is cut the moment its surface closes.
08 · Assessment, notes, description, and Ask VEX. The assessment is written in a fixed reading order - the safety sentence first, then the thesis, what is moving the price, the levels with their numbers, the risk and what would invalidate it, and what to watch next - and rendered whole in its own section. Boards carry observations, never advice: the agent never tells you to buy, sell, hold or size a position. A board too large to store is refused whole with its measured size and the heaviest pool named, so the agent knows which assessment to shorten; nothing is ever trimmed. The Composed analysis / Data notes disclosure keeps every authored string reachable on every board, with provenance stating which transport the figures came through and when they were read. Ask VEX hands a question about one token to the main chat with the board context attached - board, token, pair, price, and whether the figures were live or a snapshot and when they were read; four quick questions pre-fill the box and nothing is sent until you submit.
03 · Workflows the agent can run
Research now runs in three layers - identity and discovery, then depth and price sanity, then narrative and safety - and reports which layer was unavailable when one could not be reached. Two companions carry the second opinion. WebResearch returns six hits and reads the top three, offers a dated-news shape, and reads one whole page from a URL. TwitterAccount is read-only Twitter/X research through a configured secondary account with thirteen actions - tweet_search, user_timeline, user_details, tweet_details, tweet_replies, tweet_likers, tweet_retweeters, user_search, user_replies, user_followers, user_following, space_details and account_status - and it never posts, likes, follows, reads DMs or changes any account state; those operations are not in its schema. The agent has learned that an unfiltered cashtag sweep is mostly spam (15 of 19 rows on a live sweep had zero likes, reposts and replies), so it searches with a likes floor and a recent window, then asks user_details whether the account behind a signal has the audience to matter. Post text, names and bios are treated as untrusted, and no address found in a post is acted on without independent verification. The DexScreener tools below are the ones introduced in section 01; their dexscreener__ prefix is dropped for readability.
01 · Is this ticker the real token? pairs_search scoped to the chain, comparing liquidity, pair age and addresses across the copycats; token_pairs_list on the chosen contract to see every pool and the deepest one; pair_get with the profile group to read the issuer's X link; then TwitterAccount user_details on that handle (followers, verification, bio) and tweet_search on the cashtag with a minimum of ten likes inside 24 hours. The user gets the exact chain and contract address, the pool to quote on, and whether the account behind the profile is credible and currently discussed. The price to execute still comes from a fresh venue quote, never from these reads.
02 · Find and verify a mover. pairs_trending_list or gainers_list with the quality floor on; pair_details_get for the audit blocks, taxes, holder concentration and LP locks; WebResearch with the contract address and the news shape for why it is moving; TwitterAccount tweet_search with an engagement floor and user_details on the loudest authors; then a Board with the safety read first. The result is a token with a verified identity, a safety report that says what was unavailable rather than calling it clean, and a view of who is talking about it.
03 · Is the spike real? gainers_list for the hour with all four windows; candles_list at five minutes with volume, in the native quote for sub-percent questions; trades_list filtered to buys above a size, with trader profiles; losers_list sell-side flow for comparison. The answer separates a sustained move with broad buyers from a thin-book wick driven by a few wallets new on the pair.
04 · Pre-buy safety check. pair_details_get with security, holders, liquidity locks and supply; top_traders_list by current holding value; trades_list in aggregate mode over the last hours. The user sees taxes, honeypot and mint flags per provider, holder concentration with the rows it covers, LP lock state, the wallets holding the most, and whether recent net flow is in or out, and decides to proceed, size down or skip.
05 · Paid attention versus organic movement. spotlight_get on the boosts just purchased; pairs_batch_get on those tokens with a liquidity floor; pairs_trending_list on the same chain to see which of them trend on activity; TwitterAccount tweet_search on the cashtags with an engagement floor. The result names which promoted tokens have volume, liquidity and engagement behind the boost and which are bought visibility only.
06 · Theme rotation to a shortlist. narratives_list for the six-hour window sorted by market-cap change; the leading narrative's id passed as metaIds to pairs_top_list or tokens_screen with a liquidity floor; pair_details_get on the survivors; a Board. A sector view first, individual pairs second, with the note that narrative membership is the provider's own classification.
07 · Launchpad graduation watch. launchpad_pairs_list on bonding curves sorted by progress; pair_get on near-graduation rows for live flow; after graduation, the same tool on the graduated stage with launchpad ids to collapse the dead curve and the migrated pool; pair_details_get on the migrated pool. pairs_new_list adds the newest pairs with their volume acceleration ratio. The agent knows a creator address means something only on a bonding row.
08 · Watchlists, charts, and wallet forensics. pairs_batch_get refreshes every followed pair in one frame with per-input accounting, and trades_list continued from the last block follows a pair incrementally. token_pairs_list picks the deepest venue and candles_list reads its history for a Board chart carrying the agent's own levels, zones and event markers. top_traders_list sorted by net cash flow ascending finds the largest net sellers, trades_list filtered to one maker gives that wallet's full history on the pair, and candles_list around those trades gives the price context - stated as venue-local cash flow, never profit. And before a price feed knows a token exists, TwitterAccount tweet_search on cashtags with spam words excluded, user_details, then pairs_search scoped by chain and pair_get tell whether a token being talked about has an indexed market yet and which contract is the real one.
04 · Balances and valuation
01 · Solana balances come from the chain. Vex reads native SOL and every token account under both the classic SPL Token program and Token-2022 directly over RPC. A wallet holding real positions no longer shows $0 because a provider scan reported the chain as empty; the provider is now a fallback that runs only when the RPC read is skipped. Every token account passes a schema, amounts stay exact integer strings end to end, decimals come from the account itself, two accounts claiming different decimals for one mint fail the read, and a single account that cannot be parsed marks the whole read incomplete rather than quietly disappearing as a zero balance. A bad read never overwrites a good one: on failure, timeout or an incomplete answer nothing is written, the previous rows stay, and the fallback's empty-chain cleanup can no longer wipe fresh Solana rows. Each RPC call has a ten-second deadline that cancels the request rather than abandoning it.
02 · One pricing rule everywhere. Only a pool quoted in a recognized USD stablecoin or in the chain's wrapped native, with at least $1,000 of liquidity, may price a token. Among those the deepest pool wins; a stablecoin pool converts through the provider price and a native pool converts through Vex's own native price. Depth in a token nobody can value is not evidence: in a live measurement a JUP/MET pool reported $176M of depth denominated in a mispriced token and implied $1,136 per JUP, while JUP/USDC and JUP/SOL agreed on $0.217; the rule takes the latter. Thin books do not set prices either - a $43 pool quoting jlUSDC at $1.058 is exactly what the liquidity floor refuses. (Prices quoted here are frozen measurements from August 26, 2026.)
03 · A second look when the representative pool is untrusted. The provider's token lookup answers roughly one representative pool per address, and for JUP and $VEX that pool is exactly the kind the rule refuses. One bounded pass re-reads the full pool list for up to twelve still-unpriced tokens per valuation, which is how both recover their real price; anything past the cap is reported as skipped, not silently dropped.
04 · EVM price fallback. When the balance provider stops populating prices - as it did for Base and Arbitrum on August 26, when ETH and USDC rows went unpriced while the balances themselves were intact - those rows now fall through to the same tiered rule on 16 EVM chains, each confirmed live: Ethereum, Optimism, BNB Chain, Unichain, Polygon, Monad, zkSync, Abstract, Robinhood Chain, Mantle, Base, Arbitrum, Avalanche, Linea, Berachain and Katana. A price the provider does supply is never overwritten, the fallback never touches a balance, and every stablecoin address was read out of a live pair row and shown to trade at a dollar before it was trusted; a test re-derives every address from committed live captures, so a hand-edited one fails the suite. Symbols were not taken on faith: zkSync's USDC.e showed a $1.14 quote in one thin pool but implies a dollar across a $4.38M pool, Berachain's dollar asset is echoed under the symbol BUSD at an address that is not Binance USD, and Robinhood Chain's only trusted dollar is USDG.
05 · Unpriced is a state, not a deletion. A holding without a trusted price keeps its row with a null USD value, is counted as unpriced, and stays visible in the portfolio, because no price is not the same claim as zero value. Every price decision is traceable: the sync logs which pool, which quote class and how much liquidity produced each fallback price, and a per-chain census of how many rows the provider priced, how many Vex priced, and how many stayed unpriced.
06 · One price seam. Price watches, the own-token banner, Uniswap quote safety and EVM balance valuation now read through one price seam with a shared request cache, and a live comparison measured no change in what any of them returns. Price watches keep choosing the deepest pool from the full pool list, because the batched lookup was measured handing back pools that are not the deepest. The $VEX market widget reads its price and its 24-hour sparkline from the same surface, a retired second price provider is gone, and against the old path all eight price fields were byte-identical and 24 of 24 hourly candles lined up.
05 · Vex Studio preview
Vex Studio is coming. It will let the coding agent you already use work with Vex's wallet and protocol tools from inside your own projects, while Vex stays the one place where the keys live and every approval happens. The groundwork ships inside 0.2.7 so the Studio screen can land on tested ground in a coming release.
01 · What it will be. Your coding agent, Vex's tools, your rules - nothing moves without your approval in Vex.
02 · What ships now. The foundation only. There is no Studio screen and nothing in this build connects an external agent to your wallet; the details arrive with the screen.
06 · Interface
01 · Two themes. Vex ships chronos, the dark ink shell, and celeris, a light day shell. A fresh install follows your operating system's scheme and switches live when it changes; pick either explicitly under Settings > Preferences > Appearance, or type /theme in the composer. The theme is applied before the first paint, so opening the app on a light desktop never flashes dark and then flips. The whole color system was rebuilt on one token set rooted at the brand blue of the vx mark, with a measured contrast pair for the primary keys (6.5:1 in chronos, 14.7:1 in celeris); the setup and unlock screens follow the theme too. Boot opens with the Chronos Gate, a short four-act sequence bound to the real startup stages that becomes a static frame under reduced motion; the orb cinematic and the particle sigil of 0.2.6 are gone, and with them the raster monogram, so one inline vx mark now serves both themes.
02 · Board cards, Spotlight, and photos. The Board surfaces described above are built on the same tokens: equal token cards with a 64px photo or a designed single-letter monogram, a flat chain mark with no disc or ring, an inline sparkline and four figures; Spotlight with its candlestick chart, factual rows and channel sections. Token photos are served through the app's own image path with a size bound and image validation; a token with no published artwork gets a monogram, and a transport failure says the image could not be loaded rather than claiming nothing was published.
03 · Icons, marks, and chips. The icon vocabulary is now Vex's own typed glyph set of 86 inline SVG components; the last icon-library dependency is gone and a build gate keeps it out. Chain marks (Ethereum, Solana, Polygon, Base, Arbitrum) render as flat brand marks in the portfolio and on the Board, resolved through one renderer whether the source is a numeric chain id or a market provider's chain slug. Wherever the vx mark stands alone on a theme surface it follows one ink rule - white in chronos, brand blue in celeris - the sidebar and BOOK rail toggles share one glyph geometry, mirrored, and the model chip in the header shows the bare model name with the full routed id kept as its accessible name and tooltip.
04 · Tool ledger and transcript. Tool rows are strictly one line with a duration chip shown only when a duration was actually measured, and expand to input and output under labeled, capped scroll sections; JSON opens as a collapsible tree; explorer links sit on their own line, capped at three with a +N more toggle. Assistant turns are signed by the inline vx mark. Streaming Markdown is lexed incrementally so long replies render as they arrive, code is highlighted by an owned highlighter for JavaScript, JSON, Python, shell and SQL, and while a turn streams each reasoning block shows its latest line as a live one-line summary. Hover any message to copy it, see its timestamp or report it; day separators and a turn stats line show where you are. Every in-flow disclosure opens through one smooth 220ms expand primitive that is instant under reduced motion.
05 · Composer and conversation. The composer is a capsule. Each session keeps its own draft across switches, slash commands (/plan, /export, /clear-draft, /theme, /help) open a menu without stealing focus, and Enter behavior is a preference (Enter sends, or Ctrl/Cmd+Enter sends). Sending while the agent is busy either steers the running turn - delivered at the agent's next step boundary, never inside a tool call, and marked as steered - or lands in a visible queue you can edit, reorder or send now. Branch a session from any message into a new session that never rewrites the original, or load an earlier message back into the composer to edit and resend. Composer state is scoped to its session, so Stop can only cancel the conversation it was pressed in, and the text field and its caret survive the move from the welcome hero into an active session.
06 · Context ring, scroll, and shell. The RUNTIME & COST card is gone; context-window occupancy now sits in the composer as a small ring tinted by the engine's own pressure bands, opening a panel with the occupancy sentence and the compaction control, while turn cost stays on the transcript's stats line and now totals the whole turn across every model round. The transcript follows a streaming reply only while you are within 24px of the bottom, and a scroll-to-bottom pill appears whenever you have left the tail. The sidebar and BOOK have drag handles with remembered widths; the BOOK folds to a spine when the window gets tight without rewriting your saved preference; session rows are single-line with a hover card and rename on double-click. Error surfaces state the sanitized cause and a remedy hint, and an optional native notification tells you when a session finished a turn while the app was in the background.
07 · Links and copy. Every board card carries a DexScreener link built from its chain and pair address, tool rows carry explorer links, and every overlay screen and dialog sits on the same v2 base. 183 user-visible strings dropped the em dash for a plain hyphen, typography settles on Inter Tight for the shell with JetBrains Mono for code and Instrument Serif reserved for the boot screen, and the welcome headline rotates through a small pool of time-of-day greetings that use your display name when you have set one.
07 · Honesty and validation
01 · Every refusal says why. A packaging quirk had been dropping the validation library's English messages from every process, so any rejected input - a tool argument, a settings field - read only "Invalid input". In production, 32 stored tool outputs carried that blank message and not one carried a specific one; the case that exposed it was the agent handing a Board more notes than it allows and being told "notes: Invalid input (received a list)". The locale is now registered explicitly at the main, preload and renderer entry points, each process runs a real failing parse at boot and reports if messages have gone generic again, the build fails if any of the three bundles ships without the registration, and the agent is now told the exact bound it has to fix.
02 · Tool arguments are whole or absent. The transcript used to cut a tool call's arguments at 2,000 characters and append a "(truncated)" marker, so a large call was never fully readable after the fact. Every structural cut in that path is gone - per-string, per-array, per-object, depth and whole-serialization limits alike. The only bound left is a corruption guard set far above the largest legitimate call, and a row that somehow exceeds it shows no arguments instead of misleading partial ones. Secret redaction is unchanged: key-shaped values, JWTs, mnemonics and long encoded blobs are still replaced with a marker, and transaction hashes stay readable.
03 · Engine failures name the cause and the fix. Each error event carries the sanitized real cause, up to 280 characters, and a remedy drawn from the real failure code: top up provider credits, fix the API key or permissions, wait out a rate limit, wait for the provider to recover, compact the session, or remove the attached image. Failures with no user-side fix say so rather than inventing one, and even an unexplained failure now says the provider call failed and the cause was not reported. The cause is scrubbed of URLs, bearer tokens, provider keys and long hex at the moment it is emitted and again at the process boundary, so no banner, subscriber or report can carry a secret. A mid-stream failure shows its cause in place of the blanket "Stream error".
04 · Budgets refuse, they never trim. A Board over its storage budget is refused whole with its measured size and the heaviest pool named. A tool whose provider key is missing answers with the variable and the remedy. Output envelopes report what they leave out: a tool that drops rows says so with the way to recover them, a paged tool says whether more exists and how to continue, and WalletBalances says when a trimmed snapshot is smaller than the full scan. A retired parameter spelling is rewritten in place, and a call carrying both spellings is refused by name rather than guessed at.
05 · Ceilings are measured. The static prompt prefix fell from roughly 102 to 110 KB to roughly 57 to 63 KB depending on mode, and byte-exact snapshots of every prompt mode pin the size so no change to the prompt goes unmeasured. The mission contract, written by the agent, now passes through the same untrusted-block sanitizer as every other model-authored text before it reaches the prompt.
08 · Everything else
01 · The VEX badge on pools.fun. Tokens you launch through Vex on pools.fun now carry the VEX badge on the partner's site, as Trench Express launches already do. Right after a launch confirms, the wallet that launched the token signs a short attestation naming that exact token, versioned and bound to pools.fun so it can never be replayed against Trench Express on the same chain, and Vex delivers it. A badge can never fail a launch: the identity record, the signature, the confirmation and the Vex fee settle first and the badge request goes last. If the partner is down or rate-limited, a background sweep retries in batches of 25 every two minutes, waiting ten minutes between attempts on the same token, and never signs anything on its own. Every answer is classified by a closed code, never its wording; redirects are refused and the request travels only over HTTPS. The lane is on by default with a single kill switch, and the first badged launch was measured: attested within seconds of confirmation on the first request. Only launches performed by Vex are attested.
02 · A 25 bps fee on the generic EVM signing lane. Vex charges 0.25% of the native value a transaction sends through the new generic EVM transaction tools - WalletEvmTransactionPrepare and WalletEvmTransactionConfirm, which let the agent propose an arbitrary transaction for your approval - collected as a separate transfer to the Vex treasury only after your transaction has confirmed. Zero-value transactions - every ERC-20 transfer and approve - pay nothing, Solana carries no fee on this lane (the database enforces it), and the fee is skipped when it would not exceed what its own collection transfer could cost at the gas caps you approved. Every fee decision is printed on the approval card before you sign - rate, base, amount, receiver, the ceiling on its own network cost, or the reason nothing applies - and those lines are part of the proposal digest. The fee is not a parameter: no tool can set, redirect or waive it. A fee that is refused, reverts or stays unconfirmed is missed Vex revenue and nothing more; your transaction is already confirmed.
03 · Wallet-grade signing. Intent, activity and execution records for a signed transaction are settled together in one locked database transaction. Wallet authority is re-checked when the intent is claimed, immediately before the key is loaded, and again after staging immediately before broadcast; locking Vex, switching the wallet or flipping a session's permission mid-flight refuses with nothing signed or nothing broadcast, and signing itself happens fully offline. Each wallet owns its nonce per chain, reserved durably before signing, so two transactions cannot sign the same number and a restart cannot forget one; a second transaction that waits more than 60 seconds refuses with nothing signed. Addresses are shown whole in every approval-card headline, so a lookalike address cannot hide in an ellipsis. When the chain proves another transaction has consumed a pending nonce, the pending row closes as superseded without claiming a revert or that nothing was spent.
04 · Transfers in your activity history. Agent wallet transfers now land in the unified activity history: a send opens its durable record before anything is signed, stages its hash and nonce (or signature and blockhash) before the bytes are submitted, and submits exactly once. A transfer whose broadcast could not be confirmed is recorded as broadcast-unconfirmed, never as failed, and historical transfers were re-classified conservatively with anything inconclusive parked in a named review queue. An ERC-20 transfer records its executed amount only when the receipt's own Transfer log proves it. In Agent Scan, fee legs fold under their parent as FEE, transfers appear as TRANSFER, and generic signed transactions appear as TX with their decoded effect beside them.
05 · Tools that speak one grammar. Every protocol tool has a public name of the form namespace__resource_action, and every core tool a plain PascalCase name - SwapQuote, BridgeExecute, WalletBalances, MemorySearch, WebResearch, TwitterAccount. The catalog counts 177 tools: 37 core and 140 protocol across eleven namespaces. Old names resolve through typed aliases at every boundary, including an approval queued before the rename. One ToolSearch tool replaces the old discover-and-describe pair with three modes - intent search, select by name, and a namespace listing - and Uniswap and Relay are now discoverable like any other venue, with route preference written as guidance and every execution still gated by approval. 127 of 166 model-facing descriptions were rewritten to say what a tool does, when to reach for it and what it returns. The prompt's protocol layer is eleven typed declarations, one per protocol, stating what each can read, quote and act on and the chains it covers, projected from the runtime itself, plus six task shapes: research, swap, bridge, yield, positions and risk, launches. Retrieval is measured against per-namespace datasets, 505 queries across thirteen sets, with dense gates that fail closed against the live catalog.
06 · Memory and missions. Memory tools carry the same naming and honesty: MemorySearch, MemoryGet, MemoryHistory and MemorySuggest for durable cross-session lessons, SessionMemorySearch and SessionMemoryResolve for this session's own compaction record, each stating what its concise and detailed shapes contain and when a result was cut to the inline cap. A mission session no longer dead-ends behind a notice: the contract fields still missing are listed by name in both the standing notice and the contract modal, the notice says who fills them (only Vex) and what to do (tell Vex what is missing), one readiness rule drives the badge, the controls and the modal so they cannot contradict each other, and MISSION PREPARING has liveness - a setup turn that writes nothing is reported, and if no real update follows within 45 seconds the header names the stall. Accept is still withheld on an incomplete draft because starting would be refused anyway; acceptance still binds to the exact contract hash.
07 · Docker on Windows, and a model that answers with nothing. Docker Desktop installed after Vex was already running is now detected on Windows without a restart: Vex looks for Docker in its known install directories on disk first and falls back to PATH, checks engine liveness on the engine's own named pipe or socket, and tells apart not installed, engine stopped, engine starting, ready, permission denied and a probe that could not complete, each with its own screen. Windows on arm64 gets the Docker Desktop installer link instead of an unsupported wall. A model that returns neither text nor a tool call now stops the turn after three consecutive empty rounds instead of re-sending the identical prompt fifty times and billing every round; the reply says so, points to the transcript for what did run, and offers one-click Retry only when no tool call ran. The cost line under a turn now aggregates every model round and shows the round count.
08 · Engineering. Eleven migrations (084-094) ship in this release. Continuous integration gained a required live-PostgreSQL job for the Studio schema, Linux and Windows jobs that format, vet, race-test and cross-compile the Studio bridge for all six release targets, and a pull-request-scoped test-deletion gate where every deleted test file must be named with the change that removed its subject and the suite that still covers the behavior. The em-dash gate keeps a closed exemption list that can only shrink. The slippage-ceiling suite is deterministic offline, the end-to-end boot smoke selects the app shell by URL rather than window order, and the motion library moved to 13.1 with no change to the React surface.
09 · Known limitations
01 · The DexScreener tools read; they never execute. They quote, sign and execute nothing, and an executable price always comes from a fresh venue quote. Indexing lags by minutes to hours for brand-new tokens, and a missing row does not prove no market exists.
02 · Safety data is evidence, not a verdict. dexscreener__pair_details_get relays third-party audit data and emits no verdict; a missing block reads unavailable, never clean. Trader and trade figures are venue-local cash flow over a 30-day window, never profit.
03 · Some reads are bounded by the provider. Search and token-pool reads cap at 30 rows with no continuation, the trader leaderboard is one bounded set, spotlight feeds cannot be enlarged, and dexscreener__tokens_screen is neither exhaustive nor metric-exact. Trending order, narrative membership and boosts are provider labels shaped by engagement and payment.
04 · A Board is a snapshot unless LIVE is on. LIVE is never remembered, boards cannot be edited after the fact, cannot be composed during mission setup, and are not exported to external agents. On some first opens the Spotlight chart stays empty until you switch the timeframe once; the cause is being traced and the fix is queued for the next release.
05 · Balance and pricing coverage has edges. The agent's WalletBalances tool still reads Solana through the balance provider; the direct RPC reader serves the background portfolio sync. The EVM price fallback trusts one stablecoin per chain and does no per-token second pass, so a token whose only pools are quoted in something else stays unpriced. Solana valuation does not classify NFTs, compressed NFTs, stake accounts, or Token-2022 transfer-fee and interest-bearing adjustments.
06 · Vex Studio is not usable in 0.2.7. The Agent | Studio toggle on the welcome screen is a placeholder, and nothing in this build connects an external agent to your wallet.
07 · Research companions need their keys. TwitterAccount and WebResearch require their provider keys and are hidden without them; Twitter/X access runs through the configured secondary account, is rate-limited per session, and can stop working when the provider changes its interface.
08 · The fee lane is narrow. The 25 bps fee applies only to native value on the generic EVM signing lane, is a separate transfer that pays its own network fee, and is not shown in USD. The generic transaction tools decode only what they can verify and refuse router, aggregator and Token-2022 transactions by name.
09 · The badge lives on the partner's site. The VEX badge on pools.fun is visible there; the badge field is not yet projected into Vex's own pools.fun listings, and tokens launched elsewhere cannot be badged after the fact.
10 · Shell edges. Docker installed to a custom directory is found only if it is on PATH. The transcript code highlighter covers five grammars; other code fences render unhighlighted. There is no per-session model picker and no file attachments in the composer.
Community
Every line in this release was written in-house, and two groups outside the repository shaped it. Thanks to the users who reported the three defects against 0.2.6 - Docker Desktop going undetected on Windows, the mission setup that dead-ended behind a notice, and the turn that spun through fifty empty model rounds - each reproduced, fixed and covered by a regression test here. And thanks to pools.fun for agreeing to show the VEX badge and standing up the endpoint that receives Vex's signed attestations; the first badged launch went through on the first request.
10 · Before you update
Eleven new migrations (084-094) run automatically on first start; the first launch after updating may take a moment longer. Three changes you will feel: the app follows your operating system's light or dark scheme by default (set a theme explicitly under Settings > Preferences if you prefer one), agent replies that present tokens now arrive with a Board card, and the generic EVM transaction tools charge a 25 bps fee on native value that is printed on every approval card. Tokens you launch on pools.fun through Vex are attested to the partner by default; a single setting turns that off. No manual action is required.