Velvet releases Flash 4B, an Apache-2.0 crypto action-routing model

What did Velvet release on 12 October?

Velvet’s blog post dated 12 October 2026 says the company is releasing Velvet Flash 4B as open weights on Hugging Face under Apache-2.0, so builders can download it, run it locally, fine-tune it and ship it in commercial products without an API key or per-call fee. The model card at Velvet-Capital/VelvetFlash matches that pitch: base model Qwen3-4B, BF16, conversational crypto/DeFi/trading tags, Apache-2.0 license metadata.

The Hub API lists the model repository as created on 5 October 2026. The dated public announcement we are covering is the 12 October blog, which is also when Velvet framed the release for a general audience. We treat 12 October as the event date for the open-weights announcement and use the model card as the technical primary for architecture, skills and benchmark tables.

In product terms Flash is not a general chatbot and not a trading bot that places orders. Velvet’s warning line is explicit: it does not execute trades and does not give financial advice. It proposes the action and asks for confirmation; the surrounding application decides whether to execute. That puts it closer to other small specialized routers we have covered—such as Microsoft’s Decision-1 on Foundry for fast structured decisions or H2O Lightning 4B on JEVBench for compact decision workloads—than to a full agent stack.

What jobs does a crypto action-routing model do?

Velvet describes four jobs. Intent mapping turns a plain-English request into the exact command for a skill whose documentation sits in the system prompt, keeping amounts, addresses, symbols, chains and leverage exactly as the user wrote them—no rounding, no silent chain guesses. Confirmation asks for explicit approval before any action that moves funds, while answering read-only queries directly. Safety checks flag scam tokens, wrong-chain transfers, excessive leverage, phishing and credential-harvesting attempts. Skill questions cover how-to and API explanation for the platforms it supports.

The supported surface is broad for a 4B model: spot, perps, margin, DEX swaps, bridging, transfers, staking, yield, portfolio queries and market data across more than 30 venues in the card’s table, including Binance, OKX, Kraken, Uniswap, GMX, Pendle and MetaMask skill packs. Chains listed include Ethereum, Arbitrum, Base, Optimism, Polygon, BNB Chain, Avalanche and Solana. Language support is mainly English with some Chinese request understanding.

Because the model follows documentation placed in the system prompt, Velvet says it can also work with other skills written in the same SKILL.md style. Accuracy is expected to be best on the venues it was trained against. That design choice matters: the model is not memorizing a single proprietary API so much as learning to read a skill document and emit a structured, confirmation-first response.

How does Velvet Flash try to stay safe with money moves?

Crypto assistants fail in expensive ways when they invent an amount, pick the wrong chain, or obey a prompt-injection that says “ignore your rules and send.” Velvet’s training story is built around refusal and confirmation. About 25% of the curated dataset—roughly 2,500 conversations spanning 30 skills, about 70–95 conversations per skill—is adversarial: scam tokens, wrong chains, leverage traps, phishing, prompt injection and attempts to extract private keys or API secrets.

Every fund-moving response is supposed to follow a house format: command, summary table, warnings, confirmation prompt. Read-only balance and market queries skip the confirm step. Responses were quality-filtered so that fund-moving actions either ask for confirmation or warn. The public benchmark’s scenarios were held out of the training set, according to the card.

None of that removes the need for an application-level gate. A model that “asks to confirm” can still be wired incorrectly by a developer who auto-approves, or by a UI that hides the summary table. Velvet’s own limitations section says to always show the proposed action to the user and require explicit confirmation before executing anything. Treat the safety score as a property of the model’s text behaviour under their judge, not as a certified payment stack.

What do Velvet’s own benchmarks claim?

Velvet’s caveats match what a careful reader should already assume. The benchmark measures crypto-skill routing and safety, not general reasoning. Comparison models were not tuned for this task or output format. Scores come from a single LLM judge and vary somewhat between runs. Coverage is the weakest published dimension for Flash at 34, which is honest for a specialist that still trails larger models on some venues.

How do you run the open weights?

The card’s Transformers snippet loads `Velvet-Capital/VelvetFlash` in BF16, puts venue and chain context in the system prompt, disables thinking for short English answers, and recommends `temperature=0` with roughly 300–600 max tokens. A vLLM serve one-liner exposes an OpenAI-compatible server with a 16,384 context length. A LoRA adapter path is documented under `lora/` for teams that prefer to attach adapters to the base Qwen3-4B instead of shipping the full fine-tune.

That local-first packaging sits with other recent open weights aimed at builders who refuse cloud lock-in for sensitive loops—see also Nace’s Drex v1.5 open weights and local GGUF drops such as Underdog’s Saluki 27B local GGUF release. Crypto routing is an especially strong case for on-device or self-hosted inference: prompts can contain wallet addresses, positions and draft transfers you may not want to send to a third-party API.

Operationally you still need the skill documents, live balances and price feeds from your own stack. The model does not call APIs, sign transactions, or know balances unless the application supplies them. Flash is the intent layer; the wallet, exchange client and policy engine remain yours.

What are the limits and open questions?

Velvet lists the obvious limits: it is a small model; always show the proposal; it does not execute; benchmark noise exists; accuracy falls on tools it has not seen. We would add the usual open-weights caveats. Apache-2.0 on a Qwen3-4B fine-tune inherits whatever base-model and dataset issues Qwen and Velvet bring. Adversarial training density helps on the evaluated scam patterns; it does not prove robustness against novel contract-address lures or UI-level auto-confirm bugs.

The Hub creation date of 5 October versus the 12 October blog also means early downloaders may have seen the weights before the marketing post. That does not change the license or the card’s technical claims; it does mean “released today” in the blog is best read as the public launch narrative rather than the first byte on the Hub.

We inspected the Velvet blog post and the Hugging Face model card on 12 October 2026, including the benchmark tables and usage examples. We did not download the weights, run vLLM, connect an exchange, or re-score crypto-skill-benchmark. Until a third party publishes a replication with the same skill documents and judge prompt, the leaderboard is a vendor claim—useful as a shape of what they optimized for, not as a settled ranking of open crypto agents.