On April 24, DeepSeek released a preview of V4, its long-awaited flagship model. Two variants shipped: Pro and Flash. The Pro variant is the one claiming world-class reasoning and the best open-source agentic coding. The Flash variant is the smaller, cheaper one. What makes V4 a policy story rather than a release story is what it runs on. The model was adapted for Huawei’s Ascend AI processors, the Chinese chipmaker’s advanced accelerators, rather than the Nvidia hardware the entire global AI industry defaults to.

That adaptation is not cosmetic. Chinese AI firms have been cut off from the highest-performing Nvidia and AMD chips since the Biden-era export controls, a posture the Trump administration has maintained and expanded. DeepSeek’s choice to build V4 around Huawei silicon is the direct consequence of that policy. It is also the first serious test of whether the policy did what it was designed to do.

The answer is in DeepSeek’s own technical report. V4, by the company’s acknowledgment, “falls marginally short of GPT-5.4 and Gemini 3.1-Pro,” with a developmental trajectory the company says trails leading frontier models by approximately three to six months. That sentence is the US chip export control scorecard in plain language. Three to six months of lag, achieved without access to Nvidia’s top-end hardware. Not a decade. Not a generation. A quarter or two.

For context on what that means: last year’s DeepSeek V3 drop collapsed the assumption that Chinese frontier AI was structurally behind. V4 shows the pattern holding and tightening. The policy has bought time, not built a moat. Our prior coverage on the state-level AI regulation fight and the federal preemption framework the Trump administration released in March treats US AI policy as if the core variable is domestic. V4 is a reminder that the binding constraint on US AI leadership is not going to be set in any state capitol or in Washington. It is going to be set by how fast Huawei can scale Ascend production and how aggressively Beijing will subsidize the chip stack.

Price matters too. DeepSeek undercut on API pricing with V3 and has done it again with V4. Flash is explicitly positioned as a cheap variant. If the V4-Pro-versus-GPT-5.4 gap is three to six months and the V4-Flash-versus-everything-else gap is closer to parity at a fraction of the cost, the commercial layer of the frontier is being redrawn regardless of what Washington does about chips. Developers in emerging markets, research institutions in resource-constrained universities, and governments that cannot justify US hyperscaler pricing now have a credible alternative they did not have eighteen months ago.

The counter-argument worth stating is that three to six months of model lag matters more than the raw benchmark gap suggests. In frontier AI, a two-quarter advantage compounds. The most advanced users deploy the newest models first, they build the infrastructure around those capabilities, and the next generation arrives before the competition closes the previous gap. US policy is not trying to stop China from building frontier AI. It is trying to preserve a rolling lead that only works if it is continuously reinforced. By that narrower standard, the policy may still be working. The question is whether the political will and the downstream supply-chain investment will survive the next four years.

There is also a harder read of V4. If a Chinese lab can release a frontier-adjacent model trained on Huawei silicon at competitive prices, the US advantage is not the chip stack. It is the ability to turn that stack into real-world products that ship. Google, Anthropic, OpenAI, and the hyperscalers serving them are still ahead on deployment, integration, enterprise distribution, and the capital stack required to keep training at ten-figure cluster sizes. Those advantages are real. They are also orthogonal to anything the Commerce Department can control through export licensing.

Here is the short read and the long read, side by side. The short read is that US chip export policy has reached its ceiling. Three to six months of frontier lag, held under the tightest export regime the West has ever imposed on China, is a speed bump. It is not a moat.

The long read matters more. Every Western strategic-advantage play through export controls has historically had a twelve-to-twenty-four-month adaptation cycle before the target catches up. CoCom on the Soviet Union, Wassenaar on dual-use tech, even the post-Huawei 5G campaign. Twelve to twenty-four months, and then the counter-adaptation arrives. V4 is the evidence that we are now well inside that cycle on AI, and that the Chinese counter-adaptation is further along than anyone who drafted the original policy assumed.

What that means for the AI race is that the next US response cannot be about chips. The chip lever is spent. The question Washington has to answer in the next twelve months is whether industrial policy can do what trade restriction no longer can. Packaging capacity. Cluster-scale deployment subsidies. A coherent federal regime that does not trip over itself on preemption. An actual workforce pipeline. The playbook for that kind of response exists. Whether the current political coalition is capable of running it is a separate problem.

DeepSeek has a preview out. The full V4 release is coming. So is V5. The scoreboard updates on its own schedule, not Washington’s.

Here is something that happened this week that you probably did not hear about, because most of it happens in language normal people were never supposed to care about. It matters anyway. A worm is loose in the plumbing that almost every app on your phone runs on, and the way it is designed is going to change how companies defend your data for years.

Start with the plumbing. Nearly every modern app, website, and service is built on top of free, shared code that developers all over the world contribute and reuse. Your banking app does not contain custom code for every tiny function. It borrows chunks from a public library of code, called a package registry. The biggest one is called npm. Think of npm like a giant shared warehouse where developers go to pick up the ingredients they need to build your apps. The apps on your phone each contain hundreds, sometimes thousands, of these shared ingredients.

On April 22, a security company called Socket.dev flagged a new kind of attack in that warehouse. They gave it a name, CanisterSprawl. Here is what it does, in plain terms. A developer somewhere downloads one poisoned ingredient from the npm warehouse to use in their app. As soon as it installs, the poison quietly steals that developer’s warehouse key. With that key, the poison automatically goes and contaminates every other ingredient the same developer owns, bumps the version number, and republishes them back to the warehouse so the next developer who downloads any of them gets contaminated too. Then that next developer’s key gets stolen, and the cycle repeats. This is what “self-propagating” means. The malware makes more of itself without anyone driving it.

The second thing that makes CanisterSprawl different is where its command center lives. Old-fashioned malware reports back to a computer somewhere in the world that the attacker controls, and defenders respond by finding that computer, calling its internet provider, and getting it shut down. CanisterSprawl does not have a computer to shut down. Its command center runs on a blockchain called the Internet Computer Protocol, which is distributed across thousands of machines that no single person or company owns. You cannot raid a blockchain. You cannot subpoena one. The attackers have moved their hideout to a place the conventional response playbook does not reach.

Why does this matter for you, personally, when you do not write code and have never heard of npm? Because every app your life depends on is built out of these shared ingredients. Your banking app. Your ride-share app. Your doctor’s patient portal. Your kid’s school’s grading system. Your employer’s payroll platform. Each of them is layered on top of hundreds of packages that came from npm. When a poisoned ingredient makes it into the stack of one of those apps, and a developer’s key gets stolen, every app that developer is responsible for becomes a way into your personal data, your accounts, your money.

So who is actually helping. Socket.dev found this and named it. A company called StepSecurity is independently tracking how it spreads. A researcher named Paul McCarty, who Laterstack interviewed a couple of weeks ago about this exact class of attack, runs a community of researchers who were ahead of the major security vendors on it. Companies like Chainguard, Snyk, and Aqua Security are the ones building the tools to catch this kind of thing in enterprise environments. When you see headlines about “supply chain security,” these are the people doing the work.

Who is making it worse, or at least not helping fast enough. The registry itself (npm is owned by GitHub, which is owned by Microsoft) still operates on a publish-first, ask-questions-later model that was fine in 2015 and is not fine in 2026. Attackers are migrating to blockchain infrastructure for command and control specifically because the regulatory environment has not caught up. There is no federal rule that says a package registry must verify publishers or sandbox the code they accept. There is no enforcement body whose job is to police this warehouse. Right now, the defenders are volunteers and small companies. The attackers are organized and funded.

For the everyday reader, the practical takeaway is less about what you should do and more about what you should expect. Expect more data breaches at companies that seemed secure, because their apps inherited a poisoned ingredient from four layers down the stack. Expect the price of digital security to get built into every product you buy, because companies will have to pay people to monitor this warehouse on their behalf. Expect the regulatory argument about who is responsible for package registries to get loud in the next year, because CanisterSprawl is the kind of event that forces that conversation. The security of the apps your life runs on is no longer just up to the company on the app icon. It is up to the whole chain behind it, and the chain is under attack.

Socket and StepSecurity are tracking new affected packages daily. The worm is still spreading. The first broad-scale enterprise breach traced back to this specific worm is probably already happening. We just do not know about it yet.

On April 21, a startup called Blue Energy raised $380 million. The round was led by VXI Capital with participation from Engine Ventures and Tamarack Global. The business plan is narrower and stranger than most climate-tech rounds. Blue Energy wants to assemble small modular nuclear reactors inside shipyards, float them on barges to deployment sites, and plug them directly into the power demand of AI data centers and advanced manufacturing. The first Texas plant is targeted at 1.5 gigawatts. Construction is supposed to start in the third quarter of this year. Deployment, per Blue Energy’s own claims, will take 48 months. Industry norm for new nuclear is measured in decades.

If the pitch sounds like it was written specifically for the fight playing out in Tucson, Marana, and Chandler right now, that is because it was. Last week Laterstack reported on the cross-partisan revolt against grid-scale data center expansion across Arizona. The substantive concerns were water, electricity rates that shift onto existing ratepayers, and noise. The structural concern was that the public cost of powering AI at hyperscale was landing on towns that had no meaningful say in whether the next hyperscaler got sited in their zip code.

Blue Energy’s product is the industry’s answer to that political reality. If the public grid fights are getting lost, build your own onsite reactor. Ship it in on a barge. Skip the fight. That is the thesis. Whether the thesis survives contact with the Nuclear Regulatory Commission, the skilled-labor supply chain, and the physics of actually standing up a light-water reactor outside a traditional construction site is a separate question.

The technical gamble is the shipyard manufacturing claim. Shipbuilders have moved large pressure-vessel and reactor components before. Naval propulsion reactors have been built to tight schedules inside shipyards for decades. Commercial SMR deployment at shipyard scale is a different problem, involving commercial NRC licensing, civilian-grade worker certification, and interconnection processes the US Navy does not have to touch. The industry norm is decades long not because the physics are impossible but because every interface between the reactor and the rest of the world takes years to negotiate.

Blue Energy is not the only player betting on onsite nuclear for AI data centers. Our prior reporting on the political pressure building against hyperscaler electricity pricing flagged this wave was coming. Oklo, NuScale, and several stealth-stage SMR startups are running parallel plays. What makes Blue Energy distinct is the barge logistics and the shipyard production model. That model, if it works, could compress the build cycle enough to matter. If it does not work, it joins a decade of SMR promises that have not yet shipped their first operational commercial unit.

The counter-argument is that onsite reactors do not actually solve the political problem. The Tucson revolt was not only about grid-scale power demand. It was about water, property values, land use, and the opacity of the deal terms under which these facilities arrive. An SMR barged into a data center site is still a nuclear facility requiring cooling water, security infrastructure, emergency planning zones, and a level of community consent that varies sharply by geography. Texas will accept one. Arizona’s referendums may not. The industry is sending its money toward Texas first for a reason.

The finance angle is worth saying plainly. $380 million for a pre-revenue nuclear startup is not normal climate-tech behavior. That capital is a bet that the AI infrastructure market will pay a premium for faster, closer, cleaner power, and that the premium will be big enough to cover cost overruns, licensing delays, and first-of-a-kind engineering risk. The venture math requires at least one of the first three Blue Energy plants to land on time and on budget. If the first plant slips the 48-month deployment claim, the funding environment for everyone else chasing this model changes overnight.

Step back from the finance and the engineering for a moment and the shape of what is happening comes into focus. Towns in Arizona spent the last year organizing, collecting signatures, filing lawsuits, and, in at least three jurisdictions, winning the grid-expansion fight. The industry response is not to take those votes as feedback and renegotiate the terms of how AI infrastructure gets sited. The industry response is to invest in a deployment model that skips the grid entirely so the fights do not matter. Call that innovation if you are a VC. Call it a retreat from democratic input if you are one of the residents who just voted. Both readings are true at the same time.

For the common American, the pros are easier to name than to count on, and the cons are worse than they look on first read. On the positive side, if Blue Energy’s shipyard SMR actually works, your electricity bill stops absorbing the rolling cost of AI data center expansion. Your local water utility does not compete with a hyperscaler’s cooling demand. Your state grid gets less stress. Clean baseload power lands faster than waiting for the utility to site a conventional plant. Those are real benefits if the technology delivers. On the negative side, a nuclear reactor barged into your county is a different kind of neighbor than a grid substation. Emergency planning zones, security footprint, skilled-labor pressure on local markets, the property-tax treatment of industrial facilities, and the quiet transfer of deal negotiations from your city council to your state’s regulatory commission all change at once. Most Americans have never had a conversation about onsite nuclear with their zoning board. In states that take this wave seriously, they are about to.

And there is the policy layer underneath all of it. Whether the shipyard SMR model lands depends on three things that no VC controls. Nuclear Regulatory Commission licensing timelines, which have been slow for forty years and which the current administration has promised to accelerate, with mixed early evidence. State-level siting law, which varies enormously and which most states have not updated for onsite industrial nuclear. And local permitting, which is where every federal and state policy runs into the same residents who just beat grid-scale data center expansion in Tucson, Marana, and Chandler. The policy picture three years from now is either that Washington forces a federal override of local authority on nuclear siting, or the shipyard SMR wave stalls in every jurisdiction that has a functioning civic culture. Neither version of that future is comfortable.

Construction on Blue Energy’s Texas plant is supposed to begin in three months. The scoreboard starts then.

Rial (Lamar) Whitmer took over as Chief of Staff to Scottsdale Mayor Lisa Borowsky on October 6, 2025. By January 14, 2026, the city had placed him on paid leave. On March 20, City Manager Greg Caton fired him. Two weeks later, Whitmer’s attorney filed a $1.5 million notice of claim against the city. That is the public shape of the episode.

The substance is different. Laterstack has obtained the city’s Confidential Executive Summary of the 65-day internal investigation, produced March 20 by investigators Jason Stokes and Fred Verdugo and released as part of the City of Scottsdale’s partial response to public records request 26-006729. Additional records in the same response are still under review, and the city has indicated that the response is partial. Seven of nine allegations in the Executive Summary were substantiated. Two were not. The two that were not are also worth naming, because they include the one the public has heard the loudest about: the allegation that Whitmer solicited a campaign donation from Axon in exchange for Mayor Borowsky’s November 2025 vote on the company’s headquarters expansion. That allegation was not substantiated. The investigators wrote that Axon declined interviews and that no corroborating evidence was obtained. The other unsubstantiated count involved whether Whitmer attended a personal HOA hearing from his city office. Also ruled out.

What remains is a list of seven substantiated findings that, read together, describe a pattern the city’s own investigators concluded was incompatible with the duties of the Chief of Staff office. On one track, involvement with an outside nonprofit that paid for ads criticizing the same city councilmembers the Mayor needed working relationships with. On another, activity inside the mayor’s office that the investigators concluded was aimed at heading off a potential recall petition against the Mayor herself. Both tracks operating in the same three months. The contradiction is the story.

The Alliance ads

Finding three in the Executive Summary is the one the public record has described most. The investigators concluded that Whitmer’s involvement with an organization called The Alliance for Scottsdale’s Future constituted a conflict of interest and violated the city’s outside-employment rules under Administrative Regulation 350. They wrote that his activities were “inconsistent or incompatible with his duties and responsibilities as the Mayor’s Chief of Staff” and that the Alliance “placed several ads targeting City Councilmembers for criticism and implying criticism of City government as a whole.” Per reporting in the East Valley Tribune and scottsdale.org, the ads named three sitting councilmembers as targets: Barry Graham, Adam Kwasman, and Jan Dubauskas.

That is the investigators’ summary language. What the ads themselves said is more specific. One Alliance ad, included as Exhibit 7 in the city’s records release, warns of Scottsdale being “hijacked by fake conservatives” and invokes both “George Soros” and “Chinese communist bots hired to create chaos and division on our city council in Scottsdale, Arizona.” A separate January 4, 2026 full-page ad in the Scottsdale Progress announced a “special City Council meeting” and directed readers to contact Mayor Borowsky at her city email address. That ad stated that it was paid for by the Alliance.

The investigators also found that Whitmer refused to answer questions about his employment with the Alliance. That refusal is its own substantiated finding: number four, failure to cooperate with a city investigation.

The recall, the NAACP, and a Juneteenth event the city had already canceled

Finding six, presented in the Executive Summary as “Interference in Recall Petition Process / Appearance of Impropriety / Use of Position to Influence a City Process or Decision,” is where the story shifts from a conflict-of-interest case into a state election-law case.

The finding is grounded in an Arizona statute, A.R.S. 9-500.14, which prohibits the use of city resources to influence a recall election, including “supporting or opposing the circulation of a petition for the recall of a public officer.” The investigators wrote that after being specifically advised by the Scottsdale City Clerk that employees are prohibited from engaging in election matters, Whitmer “sought recall petition information” and then “arranged and participated in a meeting with the petition requester during work hours using city resources.”

According to the Executive Summary, the potential recall was directed at Mayor Borowsky. The investigators wrote that the petition requester “was contemplating filing a recall petition and the possibility of filing of a recall petition was what prompted the meeting.” Another witness, per the Executive Summary, “stated that he believed the request was used as a ‘threat’ to encourage the Mayor to begin a dialogue with the NAACP.” Laterstack notes for clarity: the NAACP is referenced in the Executive Summary only as the organization with which a dialogue was sought. Nothing in the findings alleges or implies any improper conduct by the NAACP.

Here is where the contradiction at the center of the piece sharpens. In response to the recall threat, the investigators found, Whitmer “made efforts to create a Juneteenth event, including attempting to enlist the assistance of another employee, for the purpose of heading off the filing of a recall petition.” He pursued that effort, the report notes, “even though the City’s Juneteenth event had been discontinued after the Council voted to eliminate the City’s DEI programs.”

Read together, those findings describe a single sequence. The outside organization Whitmer was involved with was paying for ads that invoked George Soros and “Chinese communist bots” to criticize Scottsdale’s city council. Inside the mayor’s office, according to the city’s investigators, Whitmer was working to stand up a Juneteenth event “for the purpose of heading off the filing of a recall petition” directed at the Mayor, after “the City’s Juneteenth event had been discontinued after the Council voted to eliminate the City’s DEI programs.” Both activities occurred in the same three-month period covered by the investigation. Both were substantiated.

Findings four (failure to cooperate) and six (recall interference) both include specific refusals on Whitmer’s part to answer questions or disclose information about the groups whose activities underpinned the investigation. The city’s state-law citation on finding six is not a technical one. It is the legal claim that Scottsdale used to convert a workplace conduct case into an election-integrity case.

What Whitmer says

Whitmer’s attorney, Dennis Wilenchik of Wilenchik & Bartness P.C., filed the $1.5 million notice of claim against the city and Caton personally on April 10, 2026. Under Arizona law, a notice of claim is a mandatory pre-lawsuit step. Whitmer has 60 days after the claim is rejected or ignored to convert it into a filed case. The notice alleges wrongful termination, breach of contract, defamation, and due process violations. It seeks money and reinstatement.

The legal argument is narrower than the underlying conduct. Per the notice, the official Scottsdale Chief of Staff job description states that the position reports directly to the mayor. Wilenchik’s position is that because the role reports to the mayor and not to the city manager, Caton lacked the authority to fire Whitmer in the first place. “Mr. Caton has no business interfering in the Mayor’s directions to her staff,” the notice reads, per KJZZ’s reporting. Wilenchik has further characterized the HR investigation itself as “a sham” that was “predetermined to defame Mr. Whitmer and result in the city manager assuming complete control of the mayor’s staff,” per the same KJZZ reporting. Those are serious allegations and they are Whitmer’s position on the record through counsel.

The city’s response to the notice of claim, delivered through Scottsdale spokesperson Holly Peralta and quoted across multiple outlets, was: “The city has received the notice of claim and, consistent with our practice, does not comment on pending or potential litigation. No further comment will be provided.” That is the city’s position on the record.

The Dismissal Letter the city issued on March 20, which Laterstack has obtained, points to a different section of the Scottsdale Revised Code. It cites Section 14-71(c), which classifies the Chief of Staff as an “unclassified, at-will employee” with no right to appeal to the Scottsdale Personnel Board. The letter’s formal substantive justification, stated in one sentence on the face of the letter, is that “we have lost trust and confidence in your ability to fulfill the duties and expectations of this position.” The seven substantiated findings sit in a separate report.

Whether the reporting-structure argument survives collision with a named at-will statute is something a court will answer. The institutional question underneath it, the one worth watching past this episode, is which office actually runs the mayor’s staff in a city-manager form of government when the two are in direct conflict. Scottsdale is a council-manager city. The mayor is a political executive with her own agenda. The city manager runs personnel. When they disagree on whether a senior political appointee should keep his job, one of them has to win. The notice of claim is one read of the answer. The at-will statute the city quoted is the other.

Why this matters outside Scottsdale

Most local-government firings do not travel past the local paper. This one travels because it sits where three stories that matter well beyond a single city overlap.

The first is the question of how partisan political operations interact with ostensibly nonpartisan municipal government. The Alliance for Scottsdale’s Future is a domestic nonprofit registered with the Arizona Corporation Commission. The investigators substantiated Whitmer’s involvement with it as a conflict of interest. Finding three of the Executive Summary also documents, in its own language, that Whitmer sent “email invitations to AZ Republican Roundtable breakfast events … using the Fulcrum Group email domain, logo and signature line” on specific dates during his city employment, including twice while on paid non-disciplinary leave. Laterstack will publish a dedicated piece on the Fulcrum and AZ Republican Roundtable component of the findings separately.

The second is what happens when a local government with no DEI program is still named, in a substantiated investigative finding, as the setting for a senior appointee’s effort to stand up a DEI-coded event for a political purpose. The Juneteenth finding is not a side detail. It is the specific fact the investigators concluded under Finding Six: that Whitmer worked to create a Juneteenth event “for the purpose of heading off the filing of a recall petition” even after “the City’s Juneteenth event had been discontinued after the Council voted to eliminate the City’s DEI programs.” That tension between a city’s stated policy and a senior appointee’s documented conduct is going to recur in other cities, and the record here is now a reference case.

The third is the simpler one: whether a city can fire a senior appointee for substantiated political-activity violations without triggering a successful wrongful-termination claim, when the appointee’s boss publicly disagrees with the firing. Borowsky’s on-record statement after the dismissal, reported by KJZZ and others, said she hoped Whitmer’s successor would be “allowed to fulfill the responsibilities of a chief of staff, including speaking with city staff.” A reasonable reading of that sentence is that the Mayor considers the city manager’s authority over her staff an open question. If the notice of claim becomes a lawsuit, the court will hear that argument directly.

Seven substantiated findings. Two unsubstantiated. One notice of claim pending. One 60-day statutory clock running. And at the center of it, the pattern the city’s investigators documented: involvement with an outside nonprofit whose ads targeted the same councilmembers the Mayor needed to work with, and activity inside the mayor’s office aimed at heading off a recall petition against the Mayor herself, both occurring in the same three-month period.

The firing is what already happened. The fight over whether it was lawful is what comes next. Laterstack will follow it.

Methodology

The reporting in this piece relies primarily on records obtained from the City of Scottsdale under Arizona public records law through Laterstack’s public records request 26-006729. The partial response, received April 21, 2026, includes the city’s Confidential Executive Summary dated March 20, 2026, a Supplemental Addendum to the Investigatory Report dated March 24, 2026, the Letter of Dismissal dated March 20, 2026, and twenty-five related exhibits. Additional context draws from public reporting by KJZZ, 12News, the Scottsdale Progress, scottsdale.org, East Valley Tribune, Axios Phoenix, Newsweek, and other outlets listed in the Sources section. Every direct quotation from the city’s records is verbatim from the public document as released. Characterizations of the findings are attributed to the city’s investigators by name (Jason Stokes and Fred Verdugo). Analytical passages are presented as Laterstack’s good-faith reading of the public record.

Requests for comment

Laterstack sent written requests for comment to the City of Scottsdale (through spokesperson Holly Peralta), to Mayor Lisa Borowsky’s office, to City Manager Greg Caton’s office, to Axon, and to Dennis Wilenchik on April 18, 2026, with a response deadline of April 20 end of business. None of those parties responded to the specific questions asked by that deadline. The city’s public posture on the pending notice of claim, delivered through spokesperson Holly Peralta and quoted across multiple outlets, is reproduced in the body of this piece.

A second round of written requests targeting the specific substantiated findings was sent on April 22, 2026 at 10:20 AM MST to Dennis Wilenchik (updated with the findings in hand), to The Alliance for Scottsdale’s Future, and to The Fulcrum Group, with a response deadline of April 23 end of business MST. Responses received after that deadline will be added to this piece as post-publication updates.

Scope notes

• The allegation that Whitmer solicited a campaign donation from Axon was found not substantiated by the city’s investigation. The Executive Summary specifically states that “AXON representatives declined interviews and no corroborating evidence was obtained.” Axon is named in this piece only to reflect the scope of what was investigated and ruled out. Laterstack is not alleging any improper conduct by Axon or any of its officers or employees.
• Scottsdale councilmembers Barry Graham, Adam Kwasman, and Jan Dubauskas are named in this piece only as the publicly reported targets of the Alliance for Scottsdale’s Future advertising. Their names have been publicly reported in that capacity by the East Valley Tribune and scottsdale.org. They were not the subject of this piece and were not contacted for comment because the piece makes no allegation against any of them. Nothing in the city’s investigative findings or in this piece alleges any improper conduct by any councilmember.
• The NAACP is referenced in this piece only as the organization with which a dialogue was sought, per one witness account in the Executive Summary. Nothing in the city’s findings or in this piece alleges or implies any improper conduct by the NAACP or its representatives.
• Jeff Walters, Ben Lane, Colleen London, Monica Boyd, Jason Stokes, and Fred Verdugo appear in this piece only in their professional capacities as referenced in the official public records. No allegation of wrongdoing is made against any of them.
• Characterizations of Mr. Whitmer’s activities in this piece are drawn from the substantiated findings in the Executive Summary and from the text of the advertisements and email invitations included in the records release. Where the piece offers analysis of those findings, it is presented as Laterstack’s good-faith reading of the public record and is clearly marked as such.
• Quotations from advertisements published by The Alliance for Scottsdale’s Future, including the specific phrases “hijacked by fake conservatives,” “George Soros,” and “Chinese communist bots hired to create chaos and division on our city council in Scottsdale, Arizona,” are taken directly from Exhibit 7 of the city’s records release. These quotations are reproduced for the purposes of news reporting, comment, and criticism, uses expressly protected as fair use under 17 U.S.C. § 107.
• A Supplemental Addendum to the investigative report, dated March 24, 2026 and prepared by the City of Scottsdale Human Resources Department, was also included in the records response. That document addresses an additional finding specific to the parking-citation matter, including a Scottsdale Revised Code 14-72(8) citation relating to the standard for “knowingly made a false statement.” The supplemental will be covered in detail in Piece 2 of this series.

Legal posture

This piece reports on matters of public concern involving public officials and public proceedings in Arizona. It relies on records lawfully obtained through a state public records request and on public statements by the parties involved. Reporting on the content of an official municipal investigation and the text of a filed notice of claim is entitled to fair report privilege under Arizona law. Analytical passages reflect Laterstack’s good-faith commentary on matters of public concern and are protected opinion under applicable First Amendment and state law, including the protections of Arizona Revised Statutes 12-751 (Arizona’s anti-SLAPP statute as expanded effective September 24, 2022, which explicitly protects the lawful exercise of freedom of the press).

Corrections and updates

Laterstack is committed to accurate reporting. Any party that believes a factual statement in this piece is inaccurate is invited to contact the editor at lamar@laterstack.com. Substantiated corrections will be published inline with timestamps. New information received after publication will be added as dated updates rather than silent edits.

Image credit

Featured image: West elevation of Scottsdale City Hall, designed by Bennie Gonzales (dedicated 1968). Photograph from the Historic American Buildings Survey (HABS ARIZ,7-SCOT,1-3), Library of Congress Prints and Photographs Division. Public domain. Brand-treated by Laterstack for this piece.

On April 13, a Pima County Superior Court judge dismissed a lawsuit from opponents of Project Blue, the $3.6 billion, 290-acre data center the Tucson City Council rejected in August 2025 and the Pima County Board of Supervisors approved anyway. The ruling clears the last formal legal obstacle to the project. The fight is not over. Residents of neighboring Marana have already submitted referendum petition signatures to put hyperscale data centers on the ballot, the first public referendum on data centers in Arizona. A state that was supposed to be the next obvious destination for the AI buildout after Texas and Virginia saturated is now the front line of its political resistance.

The national context makes the stakes clear. Fortune reported on April 20 that data centers accounted for roughly half of U.S. electricity demand growth last year, a share the International Energy Agency projects will hold through 2030. Globally, data centers drove 17 percent of electricity demand growth. In the U.S., that number was 50 percent. Pew polling cited by Fortune shows Americans are more likely to be concerned than excited about AI, with more than half saying they expect the technology to do more harm than good over the long run.

Arizona was supposed to be easy. Cheap land. A regulatory posture historically welcoming to large industrial customers. A state corporation commission that has not typically blocked hyperscaler interconnection requests. Frontier AI labs and the hyperscalers building inference capacity for them need power and cooling in bulk, and the deserts of the Southwest are where the available land is. Our prior coverage of the political pressure building on data center electricity prices took the national shape of this story. Arizona is where the shape became specific.

The specificity matters because of who is resisting. The Tucson City Council rejecting Project Blue in a blue-leaning city was the kind of vote a reader might expect. Chandler, a Republican suburb, rejected a data center proposal last year. Marana, a conservative-leaning district, is the one now putting the issue to a direct public vote. The No Desert Data Center Coalition, the Tucson Democratic Socialists of America, and the Party of Socialism and Liberation are part of the organized opposition in Tucson. In Marana and Chandler the organized opposition looks different. The policy concerns are identical. Water scarcity. Rising power costs. Noise. Secrecy in the deal terms. NPR reported on April 20 that data center disputes are shaping up as a tipping point in the 2026 midterms, and the cross-partisan Arizona map is why.

Even the projects with the most political wind behind them are hitting the same resistance. Fermi America, the Trump-branded AI data center megaproject in Texas co-founded by former Energy Secretary Rick Perry, is stalling. Axios reported on April 19 that the CEO departed and the project has become a high-profile test of whether the biggest AI infrastructure promises can actually deliver. Nationally, local opposition blocked or delayed at least 16 data centers last year worth a combined $64 billion, per Fortune. Maine approved a statewide moratorium on new data centers.

The industry counter-argument is that data centers bring investment, grid upgrades that can benefit ratepayers over time, and efficiency gains relative to the older on-prem server rooms they replace. Some individual facility water-use numbers in opposition literature have been overstated. Those defenses are real. They are not winning the argument at the county planning commissions and local ballots where the decisions are actually being made.

What this means for everyday people

If you live in Arizona, your electricity bill, your water bill, and your local property-tax base are being shaped right now by whether the next hyperscaler gets its rezoning. The energy gap behind the AI buildout is not abstract. It is already arriving on your utility statement. The AI revolution people read about in the tech press is being decided at county planning commissions most residents have never attended. The Pima County judge dismissed one lawsuit. The Marana referendum is coming next. Vote in local elections.

Closing

The demand numbers are not slowing. The political friction is accelerating. Which one gives way first is the story of the next 18 months.

When the Trivy compromise hit in March, a cross-company group of supply chain researchers had it flagged, triaged, and documented before any of the major vendors published anything. Paul McCarty was one of them. He got the word out publicly on OpenSourceMalware while CrowdStrike, Wiz, and Socket were still catching up. The credit for catching Trivy belongs to the whole group. Paul was kind enough to sit down with me and walk through how this kind of work actually gets done.

I wrote about the Trivy attack a few weeks ago and kept circling back to one question. How does an informal network of researchers keep beating a billion dollar vendor stack to the punch? Paul’s answer is worth sitting with, because it isn’t about genius or luck. It’s about a threat model the vendor industry was never built for, and a people shortage nobody wants to fund.

I sent him six questions. He came back with something closer to a masterclass on why EDR platforms keep missing software supply chain attacks, why git was never built for security, and where the post-SolarWinds billions actually went.

—

1. You caught the Trivy compromise before CrowdStrike, Wiz, and Socket. Walk us through what that actually looked like. What were you doing when you noticed it, and what was the first thing that looked wrong?

Paul: I didn’t discover the trivy compromise. I’m part of an intel sharing group and I found out about it from that group. I jumped on it immediately and added a threat report and advisory on OpenSourceMalware. It’s super important that once you know that something is malicious you get the word out as quickly as possible so you can try and limit the blast radius that happens when a popular tool like Trivy is compromised. The reality is that Trivy is a great tool, and lots of orgs use it in production, which is why it was such a perfect target. I had Trivy installed across all my environments

Most of these big attacks are actually worked in parallel by researchers at multiple companies, which is funny at the end because everyone claims “discovering” it.

2. You’ve said EDR vendors flat out can’t detect malicious interpreted malware like Python or JavaScript. For people who haven’t thought about this, why? What makes a malicious pip install invisible to something like Falcon?

Paul: EDR platforms like CrowdStrike, SentinelOne and Windows Defender are all built to detect classic binary based malware or ransomware. So, in practice this means they over index on two things: first, they detect file hashes of known bad files. If they’ve seen a binary or dll before, they’ll have the hash and if that hash shows up anywhere else, they already know its bad and they block it. Okay, then the second thing that EDR does: they identify malicious behaviour related to things like ransomware. So for example, EDR will detect if a number of files is encrypted in a short period of time. If one or two files are encrypted, the EDR doesn’t do anything because that’s normal behaviour: people compress files, etc. But if you see 50 files get compressed then the EDR can step in and say “this is anomalous, lemme block that”.

Open-source malware, which is 99% interpreted JavaScript or Python, doesn’t do any of those things. First, there’s no point in using filehashes for interpreted files like .py or .js. If you block a filehash, the bad guy will just add a single zero to the file, and publish a new version, and your security control has been bypassed.

You can see this on VirusTotal, and the sandboxes like Joe’s and Any.run: they don’t detect interpreted payloads. I have dropped thousands of JavaScript and Python payloads into VT, and the EDR vendors never detect them. The only company that actively detects JavaScript malware in that space is Kaspersky and their detection is very rudimentary.

Similarly, the behaviour of infostealers and cryptostealers is harder for EDR to detect. They do things once, and then move on. So for example, infostealers will look for files to exfil in browser directories, or they’ll look for certain browser extensions. Then they POST that data in a JSON blob to a webservice. This all happens via HTTP and blends into all the other web traffic. These are all actions that your browser, and other associated apps and processes do all day long. The behaviour just looks normal. And even if an EDR vendor finds some way to detect malicious Javascript for example, the threat actor will just push a new version of it because its just code after all. It’s not like a binary that needs to be compiled and distributed, which means that pushing a new version of a malicious binary payload takes time. That time works against the bad guy. With the case of highly iterative javascript payloads, the bad guy can produce 20 different versions in a day, which I have seen happen.

3. Git tags are mutable. Almost nobody pins GitHub Actions by commit SHA. Why hasn’t the industry fixed this after repeated tag based attacks?

Paul: Omg, you could ask the same type of question about why the industry doesn’t sign their commits, or use pre-commit git hooks to run security scans. The reality is that the engineering industry lags behind security best practices because the engineering leaders are really only incentivizing how fast the engineering teams (and individuals) can push new features and code.

About GitHub actions specifically: these actions aren’t widely understood, and so a lot of the behaviours we see is simply because the users of GitHub actions don’t really understand how it works.

4. You’ve been doing supply chain red teaming training at BSides for a couple years. When you’re teaching people to think like an attacker in this space, what’s the first thing you have to get them to unlearn?

Paul: Haha! great question! The first thing I start on is git. I show them very deliberately how git wasn’t built with security in mind. It accepts the user identity implicitly, which is why in 2026 I can still push a commit to GitHub as Linus Torvalds. It’s crazy.

Then I dive into how git commit history can be faked. GitHub and other SCM providers have spent a lot of time making us think that git commit history is an important function and validation. I mean, it’s attached to every single github user’s profile, right?

Well that thing is, that git commits and the git index itself all lives on your local machine, and you can make it say or do anything you want. You can then push it to GitHub and it trusts it all implicitly. So, yeah, that’s where I start. 🙂

5. If you had to bet, five years from now, are we better or worse at catching these?

Paul: Oh man. That’s tough. We are definitely gonna be better at catching certain attacks or malicious behaviours. Ai will definitely help us there.

But, circling back to your question about immutable tags in GitHub Actions, the reality is that we are moving really fast and using new tools all the time and that just means there’s a lot of room for a gap in security understanding. That gap is between us using a thing (like Claude) and us understanding the security implications of that thing.

Ai skills is a great example. My skills in Claude are awesome and automate a bunch of the hard parts of my job. But, by using Skills I open myself up to a new attack. Just this week I noticed that one of my sandboxes had a malicious AI skill in the .claude/skills directory. And skills, unlike python or javascript, don’t have well understood functions, classes and operating principles. You can basically put anything you want in an AI skill and then run it five times, and you will get five different bad outcomes.

6. After SolarWinds, enterprises poured billions into supply chain security. Automated scanning, dependency tracking, vendor risk platforms. And when Trivy got compromised, a cross-company research group caught it first. Where is that money actually going?

Paul: Oh the money spent on tools was appropriate. Before Solarwinds most orgs had zero fucking dollars for AppSec budgets. If Solarwinds did anything it unlocked budgets in this space. However, to your point, tools ain’t the only thing we need. We also need people with the right skill set and subject expertise guiding those tools and the industry has failed to build or encourage those subject matter experts. I guess they thought, if I buy the tools, they’ll magically fix all the things and we’ll all live happily ever after.

There aren’t many AppSec teams in Australia, but most of them that do exist are a team of one person. That one person ends up doing vuln management and triage for the tools that were bought after Solarwinds. They sit in between engineering teams and the AppSec tools and basically just help the former navigate the latter. It’s a shit show.

Organizations have systematically underfunded AppSec teams and it shows.

—

Laterstack take

Two things in Paul’s answers keep circling back for me, and I think they’re actually the same thing.

The obvious one is the people gap. After SolarWinds, every enterprise finally got an AppSec budget. All of it went to tools built for binary malware, which is the wrong threat model for 99% of what’s actually shipping. The people who understand the real threat, the ones who catch these things first, are sitting in one-person teams without the budget to breathe. Paul said it plain, and it should be printed on the wall of every CISO’s office.

The less obvious one is buried in his answer about AI. He mentioned finding a malicious AI skill in one of his sandboxes last week. Read that sentence again. The supply chain attack surface is already moving from npm and PyPI into .claude/skills directories, and there is zero mature tooling for it. No hash detection, no behavior signatures, no sandbox model anyone trusts. The same gap Paul is describing at the previous layer, moved one floor up, and nobody is ready for it.

What this means

For everyday users. You don’t run Trivy and you don’t install AI skills. But every app you trust with your data is built by developers who do. When a compromised dev tool siphons credentials or injects bad code into a build pipeline, the blast radius doesn’t stay inside engineering. It hits your bank, your health portal, your employer’s HR system, the app you use to talk to your kids’ teachers. Almost every “we’re writing to inform you of a data breach” email you’ve received in the last five years traces back to something that started on a developer’s machine and rolled downhill.

For technical people. If you’re a developer or running AppSec, Paul basically handed you a working checklist. Pin your GitHub Actions by commit SHA, not tag. Sign your commits. Run pre-commit hooks that actually scan. Don’t assume your EDR caught anything malicious in your last pip install or npm install, because Paul just told you it didn’t. And that AI skill you dropped into .claude/skills last week, treat it like a random package from an account you’ve never heard of, because that’s what it is until proven otherwise. The detection layer you’re counting on was built for a previous decade of threat, which means the burden is back on engineering judgment. The teams that survive this era will be the ones where developers and AppSec treat each other as peers, not as a tax on each other’s velocity.

For enterprises. If your AppSec team is one person and you’ve already bought the post-SolarWinds tool stack, Paul is telling you plainly that you don’t have a security program. You have a risk transfer document with scanners bolted to it. The companies that actually get this right over the next five years will have fewer tools and more subject matter experts, and they’ll be the ones not showing up in headlines.

For legislators and policymakers. The current regulatory frameworks on software supply chain (SBOM mandates in the US, the Cyber Resilience Act in the EU) assume the problem is transparency. Know what’s in your software. That’s useful, but it’s already one regulation behind the actual threat. The scanners you’re mandating visibility into were built for a threat model that isn’t the threat model anymore. You can mandate inventory all day on a detection layer that cannot see interpreted malware and has no framework at all for malicious AI skills, and you still end up with the same gap Paul is describing. Policy is already playing catchup, and AI skills means it’s about to be playing catch up on two fronts.

Paul McCarty runs OpenSourceMalware and teaches supply chain red teaming at BSides. The research on the Trivy compromise was a collaborative effort across a cross-company intelligence sharing group.

Median rent in Phoenix is $1,650. If you rent an apartment in a large multifamily building in Arizona, that number was probably set by a piece of software you’ve never heard of.

The software is called YieldStar, and its successor product AIRM (AI Revenue Management). It is made by RealPage, a company headquartered in Richardson, Texas. According to ProPublica’s 2022 investigation, YieldStar at that time covered around 16 million large multifamily units in the United States, a sizable majority of the large-building rental market. RealPage’s own marketing today claims the company serves over 24 million units worldwide. Property managers feed it data on their own units, market demand, and vacancy rates. It spits back a daily rent recommendation for every unit they manage. ProPublica reported acceptance rates from landlords running around 80 to 90 percent.

Arizona Attorney General Kris Mayes filed a state-level suit against RealPage and eleven apartment companies operating in Arizona on February 28, 2024. The federal Department of Justice filed its own case in August 2024 in the Middle District of North Carolina, joined as co-plaintiffs by ten states (California, Colorado, Connecticut, Illinois, Massachusetts, Minnesota, North Carolina, Oregon, Tennessee, and Washington). Arizona was not one of them. RealPage and the DOJ reached a proposed consent decree settlement on November 24, 2025, pending final approval from the federal judge in North Carolina. The ten plaintiff states were not part of that settlement. Class-action suits are also still working through the courts. The fight is still live.

How it actually works

The pitch RealPage makes to landlords is straightforward. Instead of setting rent based on instinct and a spreadsheet, subscribe to a platform that models optimal pricing at the unit level, every day, using data from across the market. The company claims up to seven percent revenue outperformance.

The mechanic that makes this legally contested is the input data. YieldStar didn’t just use a landlord’s own pricing history. It ingested nonpublic, competitively sensitive data from other landlords on the platform. A former RealPage executive told ProPublica that staff pushback on the recommendations was typically ten to twenty percent, meaning roughly 80 to 90 percent of recommendations got accepted. The model was also configured to recommend holding units vacant longer rather than discounting rent. In a conventional market, a landlord sitting on empty units loses money fast. In a market where most of the competing landlords are running the same algorithm, nobody breaks first.

Why this is a policy fight, not a court case

The DOJ case got a settlement, not a conviction. The Duane Morris analysis of the settlement made the point plainly. DOJ is not treating algorithmic pricing as inherently illegal. The settlement forces RealPage to stop ingesting competitors’ nonpublic data and to retrain its models on compliant datasets within 180 days. It does not say shared third-party pricing algorithms are against the law.

That is because antitrust law, specifically the Sherman Act, requires an agreement between competitors. Two landlords who happen to reach the same price by subscribing to the same software have not agreed to anything. They have independently chosen to follow recommendations from a shared vendor. That is parallel conduct, which is generally legal. The law was written when price collusion required a phone call.

This is the loophole. The reason the DOJ went after RealPage at all is that the specific data flows inside the platform (using nonpublic competitor data to train the model, running back-channel consulting calls where executives discussed market positioning) started to look more like coordination than like parallel conduct. The settlement forces that specific behavior to stop. The broader practice of building rent pricing on a shared algorithm is still on the table.

What states are doing while Congress watches

California was first. Assembly Bill 325 was signed by Governor Newsom on October 6, 2025, amending the Cartwright Act to restrict algorithmic rental pricing. New York followed ten days later. Governor Hochul signed Senate Bill 7882, which took effect December 15, 2025. Colorado passed HB25-1004 through both chambers along party lines. Governor Jared Polis vetoed it on May 29, 2025, writing that he had “grave concerns about prohibiting companies using algorithmic pricing software derived from multiple data sources from doing business in Colorado.”

City ordinances have moved faster than state legislatures. San Francisco, Berkeley, Philadelphia, Minneapolis, San Diego, Jersey City, and Seattle have all passed local bans. Bellingham, Washington is putting one on the November ballot.

Arizona has not passed a state ban. The attorney general has sued. The legislature has not moved. The Commerce Committee and the House Science and Technology Committee both have jurisdiction that touches this. Housing affordability is regularly named as a top-three issue by legislators from both parties in Phoenix metro and rural districts. The bill has not been written.

What this means

For everyday renters. If you rent in a large apartment building anywhere in Phoenix, Tucson, Flagstaff, or the Valley suburbs, there is a real chance a daily algorithmic price recommendation is shaping your rent. Your landlord is not sitting in a smoky room colluding with the competition. They are running software that produces a similar coordination effect without the phone call. The DOJ settlement reins in the most legally exposed version of that software. It does not reshape the practice.

For policy people. The antitrust framework inherited from the twentieth century does not catch algorithmic signaling. Two landlords using the same pricing platform produce a market outcome that looks identical to price-fixing without satisfying the Sherman Act’s agreement requirement. Closing that gap requires statutory fixes at the state or federal level, not more litigation. California and New York have done it. Twenty-three other states could move next session if advocates knew which committee chairs to call.

For Arizona legislators. You have the attorney general’s suit, two years of federal discovery, a settlement on the table, a market where 73 percent of units run on this software, and housing affordability ranked as a top issue by nearly every member. The bill is already written in California and New York. Copying it is the easiest policy work your committee will do this session. The question is who picks up the pen.

For enterprises and landlords. If you run a multifamily portfolio using RealPage, you have 180 days from the North Carolina judge’s approval to adapt. Your revenue management software will be running on different inputs by next summer. Expect rent growth recommendations to normalize toward fundamentals. This is not the end of revenue management as a category. It is the end of the phase where the algorithm was doing antitrust work the law was not equipped to name.

Laterstack has reached out to RealPage for comment and will update this story if the company responds.

The quantum computing industry has spent years arguing about which qubit technology is going to win. Superconducting qubits, like the ones Google and IBM build, are fast but fragile. Trapped ions, like IonQ uses, are slower but hold coherence longer. Neutral atoms have other tradeoffs. Photonic qubits are different still. Everyone has been betting on their horse.

DARPA just said maybe the bet itself is wrong.

On April 14, the agency announced the performer teams for its Heterogeneous Architectures for Quantum program, known as HARQ. The idea is to stop trying to pick a winner and build systems that use different qubit types together, each doing the job it’s actually good at. Nineteen performer teams from 15 organizations will spend the next 24 months building the foundations for that kind of architecture.

Program Manager Justin Cohen, who works in DARPA’s Microsystems Technology Office, put it bluntly: “HARQ is asking the community to shift away from a ‘one-qubit-to-rule-them-all’ mindset.”

That’s a direct shot at roughly a decade of industry positioning.

Two tracks, very different problems

HARQ runs on two parallel workstreams. The first is MOSAIC, which stands for Multi-qubit Optimized Software Architecture through Interconnected Compilation. The goal there is to build compilers that can intelligently route parts of a quantum algorithm to whichever qubit type handles it best. DARPA says this approach could cut resource demands by a factor of 1,000 compared to single-platform systems. That number sounds aggressive, but the logic is straightforward: if your algorithm has a step that needs long coherence times, send it to the trapped ions. If it needs speed, use superconductors. A smart compiler could handle that routing automatically.

The MOSAIC performers are Infleqtion, memQ, Q-CTRL, the University of Michigan, and the University of Pennsylvania. memQ’s role is worth watching specifically. They’ve been selected to build a hardware- and network-aware compiler that can handle partitioning across heterogeneous processors connected over quantum networking links. Their team pulls in researchers from MIT, Yale, and the University of Chicago, along with quantum platform provider qBraid. They also built a distributed quantum compiler on Nvidia’s CUDA-Q platform, so they’re not starting from scratch.

The second workstream is QSB, Quantum Shared Backbone. This is the hardware problem: how do you actually get different qubit systems to talk to each other without destroying the quantum state in the process? QSB performers include IonQ, Harvard, Stanford, Carnegie Mellon, UC Berkeley, University of Illinois Urbana-Champaign, University of Maryland, University of Texas Austin, Australian National University, and EPFL in Switzerland.

IonQ’s angle is interesting. The company announced alongside the DARPA selection that it had already demonstrated a photonic interconnect between two independent trapped-ion quantum systems, done in collaboration with the Air Force Research Laboratory. That’s the first time two commercial quantum computers have been networked via quantum entanglement at a distance, according to the company. Whether or not you take that “first” claim at full face value, the timing is telling. IonQ didn’t just get selected for HARQ, they showed up with proof of concept on the same day.

Why DARPA is doing this now

HARQ doesn’t exist in a vacuum. DARPA has been running the Quantum Benchmarking Initiative for a while, which includes the US2QC program, tasked with evaluating whether any single approach to quantum computing can actually reach utility scale. Microsoft and PsiQuantum are currently in negotiations for the next stage of US2QC. That program is about validating what individual platforms can do. HARQ is asking what happens after that, when no single platform does everything well enough.

The defense applications here are not subtle. Breaking Defense noted that a capable enough quantum computer could crack the encryption underpinning most modern communications infrastructure, solve optimization problems that are currently intractable for military planning, and model molecules for applications in materials science and medicine. DARPA’s language is careful, but “decisive advantage for national security” is how the agency describes HARQ’s long-term purpose.

The military isn’t just a funding source here. It’s the motivation for moving faster than the market would otherwise.

What the 1,000x claim actually means

The factor-of-1,000 resource reduction target deserves some scrutiny. That’s the number DARPA puts on what a heterogeneous compiler could achieve over a homogeneous single-platform system. It’s a theoretical upper bound under ideal conditions, not a promise for current hardware. The logic is that error correction overhead in quantum systems scales poorly, and different qubit types have very different error profiles. A compiler that routes operations to the right substrate could avoid burning extra qubits on error correction that the platform handles naturally. Over a long circuit, those savings compound.

Whether 1,000x is achievable in 24 months is a different question. HARQ is explicitly a foundational research program, not a deployment program. The point is to prove the concept works and build the architectural toolkit, not to ship a product. DARPA wants to know if heterogeneous systems are worth the much harder engineering problems they create.

Getting different qubit types to talk to each other without decoherence is genuinely hard. That’s why the QSB track has so many universities on it. This is not a solved problem. IonQ’s photonic interconnect demonstration is a meaningful step, but it’s one step in a very long chain.

The actual bet DARPA is making

The industry has been betting that one approach gets good enough fast enough. DARPA is hedging against that bet failing. If no single qubit technology reaches fault-tolerant scale on a reasonable timeline, a heterogeneous architecture gives you a fallback that doesn’t require starting over. You just plug the best pieces together with the right software and interconnects.

That’s not a pessimistic view. It’s a practical one. The Quantum Insider called this one of the more ambitious structural shifts DARPA has proposed for the field. The combination of compiler work and physical interconnect work happening simultaneously, with 15 organizations coordinating across 24 months, means HARQ is trying to solve the software and hardware problems in parallel rather than sequentially.

If it works, the industry stops arguing about which qubit wins and starts arguing about how to connect them. That’s a very different conversation, and probably a more productive one.

Why This Matters Outside the Lab

HARQ is a federal program spending federal money to build quantum infrastructure that the Department of Defense considers a national security priority. That makes it a policy story, not just a physics story.

Arizona already has skin in this game. Infleqtion, one of the MOSAIC performers, is headquartered in Boulder but operates quantum hardware on the International Space Station and maintains a presence in the broader Southwest quantum corridor. IonQ, a QSB performer, just received $500,000 from Washington state to expand its manufacturing facility. These are not abstract research labs. They are companies receiving direct government investment to build hardware with military applications, and they are choosing where to put their facilities based on which states offer the best regulatory and infrastructure deals.

Arizona’s state legislators are currently debating AI and technology policy without a clear picture of how federal quantum spending intersects with state economic development. The AI data center power and water conversation that is already hitting the Arizona Corporation Commission is the near-term version of a longer pattern: federal technology programs choose locations, those locations absorb infrastructure costs, and state legislators find out about the tradeoffs after the commitments are made.

HARQ’s 24-month timeline means the performer teams will be selecting lab space, hiring engineers, and signing facility agreements over the next two years. States that understand the game early will shape the terms. States that don’t will get the terms shaped for them.

That’s not a quantum computing question. That’s a governance question. And right now, very few state legislators are equipped to ask it.

Anthropic launched the Model Context Protocol in November 2024 with a straightforward pitch: give AI models a standard way to connect to external tools and data sources. No bespoke integrations for every new app. One open protocol, universal connectors.

Sixteen months later, MCP is sitting at 97 million monthly SDK downloads across Python and TypeScript. It is running inside ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. OpenAI, Google, Microsoft, AWS, and Cloudflare are all shipping MCP-compatible tooling. The Linux Foundation is now governing it through something called the Agentic AI Foundation, co-founded by Anthropic, OpenAI, and Block.

One company proposed a standard. The whole industry fell in line. That doesn’t happen often, and when it does, it’s worth paying attention to why.

What MCP Actually Does

The protocol itself is not glamorous. MCP defines a client/server architecture where AI applications (clients) connect to tool providers (servers) through a standardized interface. The server exposes tools, data, and prompts in a structured format. The client, which is the AI model, reads those definitions and uses them to take action.

Before MCP, every AI application that wanted to connect to, say, a GitHub repo or a database needed its own custom integration layer. Multiply that by every tool a developer wants to use, and you end up with an explosion of one-off glue code that nobody wants to maintain. Google Cloud’s own documentation compares MCP to USB-C: one port, everything plugs in.

That framing is a little too clean, but it captures the core value. Standardization reduces friction. Friction reduction accelerates adoption.

How Fast This Moved

The growth curve here is genuinely unusual. SDK downloads were roughly 100,000 in November 2024. By April 2025, that number had crossed 8 million. By March 2026, it hit 97 million. That’s not organic curiosity driving numbers. That’s a sequence of deliberate decisions by the people who control AI infrastructure.

OpenAI adopted MCP in March 2025, integrating it across the Agents SDK, Responses API, and ChatGPT desktop. Google DeepMind confirmed Gemini support in April 2025. Microsoft followed in July 2025. AWS in November 2025. And then in December 2025, Anthropic handed governance to the Linux Foundation through the newly formed Agentic AI Foundation.

When you look at that sequence, it reads less like organic adoption and more like a coordinated recognition that the protocol wars were settled. Everyone picked a side and it was Anthropic’s side.

Today the ecosystem has more than 10,000 public MCP servers, over 300 MCP clients, and 72% of developers who have adopted it say they plan to expand usage. Claude alone offers 75+ connectors powered by MCP.

The Lock-in Question Nobody Wants to Answer Directly

Here’s the tension that everyone in this space is careful to talk around. Anthropic invented MCP. Anthropic’s products run on MCP. When the entire industry builds on a standard one company created, that company carries structural advantages even after handing the project to a foundation.

To be fair to Anthropic, donating to the Linux Foundation was a real move. Linux Foundation governance is not theater. MCP joins a credible track record of neutral open-source stewardship. The AAIF’s co-founders include OpenAI and Block, with Google, Microsoft, AWS, Cloudflare, and Bloomberg all supporting. That’s a genuine multi-stakeholder structure.

But StackOne’s production analysis raises a more practical concern: MCP still has real gaps. Multi-tenancy, admin controls, context-aware discovery, real-time notifications. These are not edge cases. They’re enterprise blockers. The argument from practitioners is that foundation governance could slow down exactly the kind of iterative work needed to close those gaps.

The companies building on MCP are betting that a Anthropic-adjacent standard, now held by a neutral body, will evolve faster and more safely than any alternative they could build internally. That’s probably the right bet. But it’s still a bet.

The Security Problem Nobody Solved Before Shipping

Ninety-seven million installs spread fast enough that the attack surface expanded before anyone could properly think through what they were exposing. The security research tells a messy story.

Simon Willison documented prompt injection vulnerabilities in MCP as early as April 2025, noting that the protocol’s core architecture creates a category of attack where malicious instructions embedded in tool metadata can be read by the AI model but not visible to the user.

The incidents that followed were not theoretical. Invariant Labs demonstrated that a malicious MCP server could silently pull a user’s entire WhatsApp message history by poisoning tool definitions. JFrog disclosed CVE-2025-6514, a critical command injection vulnerability in mcp-remote, a widely used OAuth proxy with over 437,000 downloads. The official GitHub MCP server was shown to be vulnerable to attacks where a malicious public GitHub issue could hijack an agent and exfiltrate data from private repositories.

The underlying structural problem, as Red Hat’s security team describes it, is that MCP servers hold authentication tokens for multiple services. Compromise one, and you potentially have access to everything it connects to. And because MCP tooling can be built by anyone without security review, the community-built ecosystem expands the attack surface faster than security teams can track it.

This is not a reason to avoid MCP. It’s a reason to watch it closely and not treat 97 million installs as validation that the hard problems are solved.

Why It Won

The honest answer is that MCP won because the problem it solved was real and the timing was right. Every company shipping AI agents in 2025 needed a way to connect those agents to tools and data. Building custom integrations for every connection is expensive. Using a standard that the whole ecosystem supports is cheap.

Anthropic released MCP open-source with SDKs for Python and TypeScript, which meant developers could start building immediately without waiting for anyone’s permission. By the time OpenAI and Google adopted it, there was already enough ecosystem momentum that rejecting MCP would have cost more than joining it.

The New Stack’s analysis frames it this way: MCP succeeded because it solved a coordination problem at exactly the moment when coordination was more valuable than differentiation.

That’s a structural explanation, not a technical one. MCP won the protocol war not because it’s the theoretically optimal solution but because it got to critical mass before any alternative did.

Whether the gaps get closed, whether the security posture matures, whether foundation governance accelerates or stalls development, those are the actual questions for 2026. The protocol question is settled.

Who’s Building on This and Whether They Should Be Worried

The 10,000+ MCP servers and 300+ clients that now exist are not abstractions. They are companies. Startups. Developer tools. People building their businesses on top of a protocol that is 16 months old and just got its first real governance structure.

Some of them are doing genuinely interesting work. qBraid built a distributed quantum compiler on MCP. StackOne is running MCP in production for enterprise integrations and publishing the most honest criticism of what’s missing. Invariant Labs is stress-testing the security model by demonstrating what happens when you don’t.

These are the people who will determine whether MCP becomes a reliable standard or a liability at scale. They are also the people whose work is not getting covered. The press cycle around MCP has been dominated by Anthropic, OpenAI, and Google adoption announcements. The builders in the middle, the ones actually pushing the protocol’s limits and finding the breaks, are the story that matters now. The protocol war is over. The infrastructure war just started.

Europe’s largest budget gym chain just handed hackers a very useful dataset.

Basic-Fit, which operates more than 2,150 clubs across 12 European countries and counts roughly 5.8 million registered members, confirmed on April 13 that attackers broke into one of its internal systems and walked off with personal data belonging to approximately one million people. The affected members are spread across the Netherlands, Belgium, Luxembourg, France, Spain, and Germany.

What got taken: full names, home addresses, email addresses, phone numbers, dates of birth, and bank account numbers, specifically IBANs. Passwords and government ID documents were not in the compromised system, Basic-Fit says.

The IBAN detail matters. A lot.

What They Actually Got

Most breach disclosures focus on the email and password combo, which is familiar enough that people have learned to change passwords and move on. This one is different. With a name, an IBAN, a home address, and a date of birth, an attacker has everything needed to submit a fraudulent SEPA direct debit mandate against someone’s bank account. SEPA’s chargeback window is 13 months for unauthorized transactions, which sounds reassuring until you consider that small, recurring debits often go unnoticed for months. The administrative burden of clawing that money back falls entirely on the victim.

This is not theoretical. SEPA mandate fraud is already a documented attack pattern across Europe, and gym membership payments are specifically structured as recurring low-value direct debits. The dataset Basic-Fit just lost is, functionally, a pre-filled fraud template.

The System That Got Hit

Basic-Fit says the breach came from its club visit-registration system, the platform that logs when members swipe through turnstiles at each location. This system operates across all the affected countries from a centralized database. That architectural choice, one shared platform handling member access data across six countries, is what turned a single intrusion into a seven-figure breach.

The company says its monitoring tools detected anomalous activity and severed the unauthorized access within minutes. Within minutes is the kind of claim that sounds like a win until you realize that bulk data exfiltration at scale can happen in seconds. The breach confirms the access was terminated, not that the download was stopped before it completed.

Franchise locations used separate systems and were not affected, Basic-Fit noted. That distinction provides cover for about 430 franchise clubs, but does nothing for the estimated one million members whose data came from company-owned locations.

The Disclosure Math Doesn’t Add Up

Basic-Fit’s initial public statement emphasized 200,000 members in the Netherlands. The company fulfilled its legal obligation by notifying the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) within GDPR’s 72-hour window. Dutch media quickly reported the full scope: closer to one million across six countries.

That gap, 200,000 in the press release versus one million in the actual data, is worth noting. Basic-Fit is headquartered in Hoofddorp, Netherlands, which makes the Dutch regulator its lead supervisory authority under GDPR. Notifying that authority with partial figures while the broader disclosure trickled out through media reporting is not illegal, but it is a pattern regulators have noticed before.

Basic-Fit reported revenues of approximately €1.1 billion in 2025. Under GDPR Article 83, a fine can reach 4% of annual global turnover, which puts the theoretical ceiling around €44 million. Whether the Autoriteit Persoonsgegevens concludes that Basic-Fit’s security measures were inadequate will depend on the forensic investigation currently underway with external specialists.

Netherlands Is Having a Rough Year

Basic-Fit’s breach landed on the same day that Booking.com disclosed its own incident, affecting reservation data including names, contact details, and booking information. Both companies are Dutch. Neither connection has been publicly established by investigators, and it could be coincidence. But it fits a pattern that has been building for months.

In February 2026, Dutch telecom firm Odido had 6.2 million customer records exposed. Three major incidents across two months at Dutch companies, each involving centralized databases of consumer identity and financial data, suggests that European consumer data is being systematically targeted, and that the companies holding it have not been keeping pace with the threat.

Basic-Fit advised affected members to watch for phishing attempts and monitor their bank accounts. That advice is correct and also insufficient. Phishing emails built on this dataset will use real names, real addresses, real membership details, and potentially real IBAN numbers to appear credible. Standard phishing warnings were designed for spray-and-pray attacks. This is a precision dataset.

What This Means If You Live in the Netherlands

If you are a Basic-Fit member in the Netherlands, here is what just happened to your daily life. Someone you have never met now has your full name, your home address, your date of birth, your phone number, your email, and your bank account number. They can submit charges against your bank account. They can build phishing emails that reference your real gym, your real address, your real membership. They can sell that package to someone else who does the same thing.

The practical steps: check your bank statements for any SEPA direct debit entries you did not authorize, going back 90 days. Call your bank and ask them to flag new SEPA mandates for manual approval before processing. Treat any email that mentions Basic-Fit, your membership, a billing issue, or a password reset as suspicious until further notice. The phishing that follows breaches like this is not the clumsy “Dear Customer” spam most people know how to spot. It will use your real name, your real address, and your real bank details. It will look right.

This is what your €20 a month gym membership just cost you.

What This Means If You Live in America

Basic-Fit does not operate in the United States. But every American who pays for a gym membership, a streaming subscription, a meal kit, or any recurring monthly charge should look at this and ask one question: does the company holding my payment details treat security like a cost center or a priority?

The answer, almost universally, is cost center. American gym chains like Planet Fitness, LA Fitness, and Equinox run the same centralized membership platforms that Basic-Fit runs. Subscription services from meal kits to streaming apps store the same combinations of name, address, date of birth, and payment information. The ACH system in the United States is functionally similar to SEPA in Europe: once someone has your bank routing and account number, initiating a debit is not difficult.

The difference is regulatory. Europe has GDPR, which at least gives regulators the power to fine companies up to 4% of annual revenue for inadequate security. The United States has no federal equivalent. State-level breach notification laws exist, but they mandate disclosure, not prevention. If an American gym chain lost a million members’ bank details tomorrow, the regulatory consequence would be a press release and maybe a class action lawsuit that settles for $2.50 per affected person three years later.

Basic-Fit’s breach is a European story. The vulnerability it exposes is universal.

Basic-Fit has not disclosed how the attacker gained access in the first place. That question matters more than the company’s response time. An intrusion stopped within minutes that still exfiltrated a million records suggests the attacker knew exactly what they were looking for and where to find it. Whether that came from a credential compromise, an API vulnerability, or something else entirely will shape what every subscription business holding consumer payment data needs to do next.

That answer has not been provided yet.