The bank's Kinexys unit is launching a new tokenized money-market vehicle on Ethereum, expanding institutional on-chain settlement from pilot to portfolio strategy.
JPMorgan filed to launch a second tokenized money-market fund[1] on Ethereum, investing in U.S. Treasuries and repurchase agreements. The move follows the bank's Kinexys (formerly Onyx) platform demonstrating cross-border tokenized Treasury redemptions[2] with Ripple and Mastercard earlier this month, and marks the clearest signal yet that Wall Street's blockchain infrastructure is moving from proof-of-concept to product shelf. The new vehicle will sit alongside the bank's existing JPM Coin deposit token, which already settles over $2 billion in daily institutional payment volume. The market priced the news at +1.63% on the day—muted relative to the structural significance. What changed: institutional tokenization is no longer a settlement experiment confined to interbank rails. The cross-border redemption demo on May 7 proved the plumbing works across chains, counterparties, and jurisdictions. Now JPMorgan is productizing that capability into a fund structure clients can allocate to. This is the inflection point where blockchain moves from back-office efficiency play to front-office distribution channel. The timing matters: Stripe's $1.1B Bridge acquisition and Visa's Tokenized Asset Platform rollout both happened in the past six months. The race is no longer whether to tokenize—it's who controls the issuance rails and captures the settlement spread as assets migrate on-chain. We're watching three signals. First, whether JPMorgan can pull institutional AUM into the tokenized fund at scale—proof that allocators see on-chain settlement as differentiated enough to justify migration cost. Second, how regulators treat these vehicles: are they funds that happen to use blockchain plumbing, or does tokenization trigger new custody, transfer-agent, or cross-border reporting requirements? Third, competitive response from the asset-management complex. If BlackRock, Fidelity, or State Street launch competing tokenized vehicles in the next 90 days, it confirms the distribution thesis. If they don't, it suggests the use case is still confined to JPM's captive institutional client base—a smaller wedge than the market is pricing.
Including Our Take, the Tailwinds & headwinds framing, Connections across the FOBI roster, and What should you do.
Already subscribed? Sign in →
A wrongful-death suit alleges OpenAI's chatbot gave dangerous drug-combination guidance that led to a teenager's fatal overdose. The case arrives as regulators worldwide are finalizing AI liability frameworks—and OpenAI scales voice APIs into customer-service layers where guardrails matter most.
A family alleges in court that ChatGPT provided fatal drug-combination advice to their teenager[1], a claim that transforms the AI-liability landscape from theoretical to concrete. The chatbot reportedly assured the user that a specific mixture of substances was safe; toxicology later confirmed it was lethal. OpenAI did not prompt the user toward medical professionals, did not flag substance-abuse hotlines, and did not surface obvious warning signals. The case hinges on duty of care: did OpenAI's design, instruction-tuning, and deployment safeguards fall below a reasonable standard for a system it knew would be asked to answer health and safety questions? This lawsuit lands at a pivot point in OpenAI's product architecture. Two weeks ago, OpenAI launched GPT-Realtime-2 voice APIs[2] optimized for customer-service integration—bank chat, insurance claims, school counseling systems. Voice creates immediacy and intimacy; users treat voice outputs differently than text, trusting them more readily and acting on them faster. When ChatGPT moves from chat.openai.com (where users expect entertainment and rough-draft thinking) into a school nurse's intake system or a financial-distress hotline (where users expect medical or expert judgment), the liability posture shifts. A jury may argue OpenAI had duty to implement guardrails proportional to the decision's stakes. Today, OpenAI does not mandate different safety profiles for different deployment contexts; a single model drives all uses. That architecture—one capability, many risk contexts—is now under scrutiny. The second signal to track is regulatory response. The EU's AI Act, now in enforcement phase, imposes strict liability on "high-risk" systems including health and substance-abuse advisory. The US FDA is moving toward pre-market review of clinical-decision-support AI. This lawsuit, if it survives summary judgment, will shape how courts interpret "foreseeability" of harm and "design defect" in AI products. OpenAI's legal team will argue the user made an autonomous choice; the plaintiff's team will argue the chatbot's training deliberately optimized persuasiveness and did not anticipate or prevent misuse in high-stakes health contexts. The precedent that emerges—whether liability attaches to the designer, the deployer, or the end-user system integrator—will reset insurance, indemnification, and product-development roadmaps across the sector.
Including Our Take, the Tailwinds & headwinds framing, Connections across the FOBI roster, and What should you do.
Already subscribed? Sign in →
The move from fixed-seat subscriptions to flex allotments and a new Max plan reveals GitHub's confidence in Copilot's stickiness—and previews how the entire developer-tools industry will price AI agent capacity as adoption scales.
GitHub unveiled flex allotments and a new Max plan for Copilot individual subscriptions[1], replacing simple per-seat pricing with a usage-based model. Pro users get a monthly token or request budget; Pro+ users get more generous allotments; Max is a new tier targeting power users who exhaust higher budgets. The move surfaces a critical inflection point: Copilot is no longer a "nice-to-have" productivity marginal at the editor toolbar. It's a core dependency in the development workflow, and GitHub is confident enough in that stickiness to bet on extracting margin from consumption rather than fighting for marginal seat growth. This matters because it exposes the real competitive battleground in AI coding tools. Incumbent incumbents like JetBrains and Amazon Q Developer now have a pricing road map to follow—and a set of conversion targets to hit. Meanwhile, open-weight models from Meta and Mistral AI present an asymmetric pressure: enterprises can self-host and avoid usage metering altogether. GitHub's shift assumes most developers will tolerate or even prefer the pricing friction of flex budgets (it creates natural rate-limiting) in exchange for seamless integration and Copilot's superior model performance. That assumption holds as long as OpenAI's models stay ahead of open-weight alternatives. If Claude Code or Codestral narrow that gap further, usage-based pricing becomes a liability—a switching cost that favors open-source or on-premise deployments. Watch the next signal: which customer cohorts upgrade to Max, and at what monthly bill. GitHub's own usage metrics (tokens per request, agents-per-month) will reveal whether power users are already hitting pro-rata limits or if Max is pure margin expansion in a largely fixed-user pool. The real pressure test comes in Q3 when enterprises integrate agents into CI/CD pipelines, where token burn is predictable and measurable. If those buyers start building token budgets into their CapEx and negotiate annual contracts, pricing moves from individual angling into enterprise deal structures—and that's when the real competitive separation happens.
Including Our Take, the Tailwinds & headwinds framing, Connections across the FOBI roster, and What should you do.
Already subscribed? Sign in →
The asymmetric bet here is on guardrails and compliance becoming a competitive moat. Anthropic, which has invested heavily in Constitutional AI and has explicit safety frameworks[2], is now differentiated on liability. For capital allocating into the AI-applications layer, the positioning question is: will you back integrators who use OpenAI's raw models with loose wrapper guardrails, or builders who layer domain-specific safety (medical boards, toxicology databases, expert routing)? The former scales faster; the latter survives litigation. If courts rule OpenAI liable, the cost of retrofit—adding safety to deployed systems—becomes catastrophic. Better to price that into architecture today.
Strategic-positioning commentary · not investment advice
Strip away the AI framing. A company built a product it knew would be asked to answer health and safety questions. The product's design does not treat health and safety differently from entertainment or creative work. When used as designed, the product gave advice that killed someone. A reasonable jury might ask: did the designer foresee that risk? Did it take steps proportional to that risk? The answers are probably yes and no. That's negligence. Whether it's a design defect under product-liability law depends on whether a jury believes OpenAI should have built guardrails into the base model (rather than offloading that burden to deployers). If yes, OpenAI's liability exposure multiplies: every deployment of ChatGPT in a health, financial, or safety-critical context becomes grounds for damages claims.
The EU AI Act already classifies health advisory and substance-abuse screening as high-risk, requiring pre-market conformity assessment and supplier documentation of risk mitigation. The FDA's Center for Devices and Radiological Health has signaled that clinical-decision-support systems will require pre-market review. This lawsuit lands as those frameworks enter enforcement. US courts may not explicitly adopt the EU's liability regime, but the regulatory trend toward strict liability for high-risk AI is clear. If this case survives summary judgment and a jury finds OpenAI breached a duty of care, expect state attorneys general and international regulators to cite it when prosecuting guardrail gaps in other models. The precedent propagates fast in regulatory space.
The asymmetric bet is clear: GitHub's willingness to meter Copilot suggests it believes the LLM cost curve has stabilized enough that seat-to-usage conversion is profitable. This challenges the open-source narrative that dominates venture positioning around Meta and Mistral AI. It also signals that OpenAI's model moat in coding remains defensible, at least for the next refresh cycle. For allocators: track whether the Max tier cannibalizes Pro+ or genuinely attracts net-new power users. If the former, GitHub is optimizing a shrinking pie. If the latter, it validates the thesis that code generation is moving from "writing snippets" into "agentic infrastructure"—which means the play is not in the models or the IDE integrations, but in the orchestration and qualit…
Strategic-positioning commentary · not investment advice
Strip the pricing narrative: what's really happening is that GitHub is moving from a hit-driven acquisition model (sell a seat, keep it) to a throughput-driven monetization model (sell tokens, let usage vary). This only works if token supply is abundant and token demand is sticky. OpenAI's API infrastructure ensures supply; developer lock-in to VS Code + GitHub integration ensures demand. But this equation breaks if (a) another LLM provider underbids on model quality or (b) developers prove willing to accept slower, cheaper open-weight models in exchange for metering-free infrastructure. GitHub is implicitly betting that (a) won't happen for at least the next refresh cycle and (b) will be too slow to matter. That's a high-confidence bet, which suggests the market is moving faster toward agentic infrastructure than most investors realize.
GitHub's old model extracted value per developer per month—simple seat accounting. The new model extracts value per token per request, with tiers based on monthly budget caps. This is profitable only if three conditions hold: (1) model inference costs stay flat or decline, (2) token burn per request is predictable enough to forecast margin, and (3) developers prefer paying for usage over switching to on-premise or open-source alternatives. The Max tier is the margin play: it targets developers and teams already hitting Pro+ limits, charging a premium for a higher budget. The real revenue lever is agentic workflows in enterprise CI/CD. When GitHub Actions runs an agent that auto-generates pull requests or refactors code across a monorepo, token burn becomes a line item in infrastructure budgets—and at that scale, GitHub can justify prices that would feel absurd for individual developers.
