It matters because shielded adoption is no longer theoretical. As of activation roughly 4.35 million ZEC sat inside shielded pools, or about 25 percent of all coins in circulation. Orchard alone held 3.6 million ZEC. Shielded transaction adoption hit an all time high of 59.3 percent in February 2026, meaning a majority of network activity was already using privacy features. Quarterly shielded transactions jumped 224 percent in the same period while public transaction counts stayed flat at around 8,500 per day. The shielded pool is not an experiment anymore. It is where most of the action is.

You can watch the migration in real time. The Zodl team is running a live broadcast tracking the whole process, and the Ironwood Migration Dashboard at ironwood.zodl.com shows every ZEC accounted for, pool by pool, updated every minute. As of this writing the dashboard reports 69,129 ZEC already in Ironwood with 3.6 million ZEC still waiting to cross from Orchard.

Why the network had to move

Earlier this year a Zcash security researcher found a soundness flaw in Orchard. In theory the bug could have let someone create counterfeit ZEC inside the shielded pool without detection. It was responsibly disclosed and patched through a coordinated emergency upgrade, and there is no evidence anyone ever exploited it. No user funds were affected, and the total ZEC supply did not change.

The problem is that shielded pools hide transaction amounts by design. Nobody can look inside Orchard and prove nothing counterfeit sits there. That question can only be answered at the edge of the pool, where funds leave it.

Ironwood answers it. When the upgrade activated, the old Orchard pool was restricted. It can no longer receive payments, and the only path out is forward, into Ironwood. Everything leaving Orchard passes through what Zcash calls a turnstile, a network rule that a pool can never release more ZEC than legitimately entered it. Genuine funds cross into Ironwood. Anything counterfeit that might hypothetically exist is stranded, permanently unspendable. Anyone running a Zcash node can verify that from the network’s own rules, with no trust required and without waiting for anyone to migrate.

The new pool itself is built on the same Orchard protocol but strengthened with formal verification and independent security audits. Formal verification expresses the design mathematically and proves its properties the way a theorem is proved, rather than tested. It rules out design level errors capable of allowing undetectable counterfeiting under the protocol’s stated cryptographic assumptions. Audits cover the parts a proof cannot reach, like the code that implements the design.

Together they deliver substantially stronger assurance against the class of bug found in Orchard.

What stays the same

Your addresses have not changed. Ironwood uses the same receiver structure as Orchard, so any address you have already shared keeps working. New shielded payments arrive in Ironwood automatically. Your funds are safe, they remain yours, and there is no deadline to move them.

One thing worth knowing before you migrate anything: the amount that crosses between pools is recorded publicly on the blockchain. This is true of every wallet, not a quirk of one app. Who sent it and who received it stay private, but the figure does not.

How to move your funds

Cake Wallet

Cake Wallet handles the migration for you. There is no setting to turn on, no button to press, and nothing to sign up for. You need three things.

First, make sure you are on Cake Wallet 6.4.0 or later. Second, open your Zcash wallet and let it finish syncing. Third, leave the app open until migration finishes.

You will see transactions labelled “Migration” in your history. Your Orchard balance gets split into standard round number amounts (10 ZEC, 1 ZEC, 0.1 ZEC, and so on) and each one moves in its own transaction. The pacing is roughly one transaction per Zcash block, about 75 seconds apart, so the whole thing takes a while. While it runs, part of your balance shows as confirming rather than available. That is normal. It means those funds are still in Orchard, which the network no longer lets anyone spend from, and they become available again as each chunk lands in Ironwood.

This approach is privacy preserving by design. Standard denominations help your transfers blend in with everyone else’s, and the spacing keeps them from clustering together on chain. Closing the app just pauses the process. Nothing is lost and nothing needs to be restarted. Open it again, let it sync, and migration continues where it left off.

Your total balance dips slightly from network fees, on the order of 0.0002 ZEC per migrated amount. Your address and QR code do not change. You do not need to give anyone a new address.

Zodl

Zodl users need to update to version 3.8.0, available now in the App Store and Google Play. Without it your wallet will not sync and you cannot send funds.

Zodl gives you three paths. You can move everything in one transfer, which is the quickest way but publishes your full Orchard balance as a single public figure. You can move it in stages, sending progressively larger amounts to yourself over days, which keeps your total balance private but takes more attention. Or you can wait for Zodl’s upcoming automated migration feature, which will split your balance into standardized amounts and space the transfers out for you.

If you do it yourself, turn on Tor protection in Zodl’s settings and leave it on. Without Tor your wallet reveals your IP address to the server it connects to, and that server sees every transfer you make. Spread the transfers across days rather than minutes, vary the time of day, and pick round amounts that do not describe you. Plenty of people will send 10 ZEC. Very few will send exactly 10.3467 ZEC.

The step by step is straightforward: copy your own shielded address from the Receive screen, add it to your address book under a name you will recognize, and send yourself a small test amount first. Once that confirms, you can send larger amounts following the guidelines above.

To check whether your funds are in Orchard or Ironwood, tap your balance at the top of the main screen. Zodl shows the breakdown by pool. When Orchard reads zero, you are through.

The bottom line

Your funds are safe regardless of when you update or whether you migrate right away. The turnstile guarantee took effect the moment Ironwood activated. Migration is about making your funds spendable again and settling the supply question for good, not about rescuing anything at risk.

What is a Relay?

A relay is a server that does exactly three things: it receives your posts, it stores them, and it sends them to anyone who asks. It doesn’t decide what you can say. It doesn’t have a CEO or a profit motive. It is just a pipe for information.

The Power of Independence

The most important thing to understand about Nostr is that relays do not talk to each other.

On a traditional social network, one central server holds everything. If you post something, it goes to one place. If that server is taken down or decides to ban you, your content vanishes.

On Nostr, you choose which relays you connect to. If you and I are on different relays, we won’t see each other’s posts until we find a relay we both share. This might sound like a hassle, but it is a powerful feature. It means you can have a private relay for your own personal backups, or a relay dedicated entirely to a specific topic like football or local news.

The Outbox Model

To make sure people can find your content across the network, Nostr uses a simple system called the outbox model. You can publish a small event that tells the world “these are the relays I write to, and these are the ones I read from.” Modern Nostr apps like Damus, Amethyst, and Primal use this list to find your content automatically. If someone can’t see your posts, it is almost always because you don’t share a relay. Adding a popular one to your list solves it instantly.

Fighting Censorship

Because relays are so simple, they are incredibly resilient. Anyone can run one on a tiny VPS or even a low-end phone. Since they don’t talk to each other, shutting down one relay doesn’t affect the others. If a relay is taken offline, a new one can pop up somewhere else in minutes. With hundreds of relays spread across the globe, the network only grows stronger as it becomes more distributed.

How to Get Started

The best way to understand relays is to use them. Download a Nostr client, connect to a few different relays, and start exploring. You are in control of where your data lives, and that is the whole point.

A few clients to start with: Damus for iOS and macOS, Amethyst for Android, and Primal which works on web, iOS, and Android. All three let you pick your relays and manage them directly.

For relays, you can connect to any of these to get going: nos.lol, relay.damus.io, relay.primal.net, or nostr.wine. Connect to two or three of them in your client, publish something, and watch it show up across the network.

The Securities and Exchange Commission has spent more than a decade building a system that records every order, cancellation, and trade across every U.S. stock and options market, and links it all back to the individual investor who made it. It is called the Consolidated Audit Trail, or CAT, and by the SEC's own numbers it can hold information on tens of billions of market events a day, going back years.

Here is the part the agency would rather you not dwell on. When the SEC laid out the legal authority for the whole thing in its founding 2012 rule, it offered a single sentence pointing to a few sections of a 1975 statute. And in a later order, it conceded the obvious: there is no express authorization for CAT from Congress.

That admission is now the center of a fight in the Eleventh Circuit. The American Securities Association and Citadel Securities are challenging the order that funds CAT, and a stack of amicus briefs, including one from the Cato Institute filed at the end of May, is arguing that the entire system was built on authority the SEC never actually had.

This is not a niche securities-law spat. It is a clean example of how surveillance infrastructure gets built in this country: quietly, justified as plumbing, and only fought over once it is already load-bearing.

What CAT actually is

CAT started in 2012 as Rule 613, an SEC directive telling the self-regulatory organizations, FINRA and the exchanges, to jointly build one central repository that stitched together a dozen older, fragmented audit trails. The stated reason was market oversight. After events like the 2010 Flash Crash, regulators wanted to reconstruct what happened across markets quickly instead of subpoenaing data from a hundred different brokers and waiting weeks.

The result is a system that, in the SEC's own description, collects and identifies every order, cancellation, modification, and execution for all exchange-listed equities and options across all U.S. markets. One broker-dealer was penalized over late reporting tied to roughly 26 billion events in a two-year stretch, and that was about 8 percent of just that one firm's reporting obligation. A Reason analysis cited in the Cato brief estimates the full system may take in tens of billions of trades daily, possibly making it the largest database in the world. Treat that last figure as an estimate rather than an SEC count, but the order of magnitude is not in dispute.

The cost matches the scale. SEC orders put implementation at roughly $2.2 billion, ongoing reporting at about $1.5 billion, and the 2025 operating tab at over $156 million. None of it runs through congressional appropriations. It is funded by a fee on securities transactions, which is exactly the funding mechanism now being challenged in court.

The wrinkle nobody in the press release mentions

If you only read the advocacy framing, you would think CAT is a database with your name in it. As of early 2026, that is no longer quite true, and the honest version of this story has to start there.

Under pressure that built for years, the SEC has steadily pulled the most sensitive personal information out of the repository. Social security numbers went in 2020. Names, addresses, and birth years came out in February 2025. And in January 2026, the Commission approved an amendment so the central repository no longer collects customer and account information at all. The old customer database was renamed and rebuilt to store transformed identifiers instead of raw personal data.

So is the privacy problem solved? The challengers say no, and this is where the argument gets interesting.

The architecture still assigns every investor a unique CAT-Customer-ID that links their entire trading history across every market, broker, and account. Regulators can query at least six years of that activity, tied to the identifier, without showing reasonable suspicion. The personal details that connect an ID to a human, the name and address, now sit one step away, held by the broker, to be handed over to regulators on request. CAT did not stop tracking you. It changed the procedure for unmasking you, from a name sitting in a federal database to a name a broker produces when asked.

Whether that one-step-removed design is a meaningful privacy protection or a procedural fig leaf is, in a sense, the whole case.

The real argument is not the Fourth Amendment

Most coverage will lead with privacy and the Constitution. The briefs do not. The strongest argument, and the one Cato spends the most time on, is structural: the major questions doctrine.

The idea is straightforward. When an agency claims a power of vast economic and political significance, courts expect Congress to have said so clearly. Congress, as the Supreme Court likes to put it, does not hide elephants in mouseholes. The challengers argue CAT is an elephant: a national financial surveillance system touching tens of millions of Americans, costing billions, funded outside the appropriations process. And the mousehole is two general provisions of the 1975 Securities Exchange Act, one letting the SEC facilitate a "national market system," the other requiring brokers to make and keep records for examination.

Read the way a reader in 1975 would have, the brief argues, "national market system" meant a plan for organizing securities trading, not a machine for cross-market, cross-broker, cross-account surveillance of a single customer. And "make, keep, and furnish records" meant maintain the records you already keep, not generate entirely new categories of data, timestamped to the millisecond, that no broker tracked by custom.

This is the argument that should interest anyone who cares about where power actually sits. It is not really about whether financial surveillance is good or bad. It is about who gets to decide. The challengers' position is that a decision this big belongs to Congress, on the record, not to an agency interpreting decades-old text expansively and then conceding it has no express authorization.

Where the Constitution comes in, and where it gets contested

The constitutional claims reinforce the structural one, and they are worth understanding precisely because they are contestable.

On the Fifth Amendment, the argument is that forcing brokers to create and hand over new categories of records can amount to compelled testimony against the people in them. The SEC's likely shield is the "required records" exception, which lets the government compel records that regulated parties customarily keep. The counter is that CAT demands records brokers did not customarily keep, which arguably puts it outside the exception.

The Fourth Amendment fight is the cleaner one to follow, because both sides have real precedent. The challengers lean on Carpenter v. United States, the 2018 case where the government pulled 12,898 cell-site location points over 127 days and the Supreme Court called it a search requiring a warrant. CAT, they argue, is Carpenter at enormous scale: tens of billions of datapoints over years, queried without a warrant or any individualized suspicion.

The government's best answer is the third-party doctrine, anchored in United States v. Miller (1976), which held you have no reasonable expectation of privacy in financial records you voluntarily hand to a bank. One published analysis argues the doctrine likely defeats the Fourth Amendment claim, since the CAT data sits with the exchanges rather than in investors' possession, and is generated only by the voluntary choice to trade on a public market.

The challengers' rebuttal is that Carpenter narrowed Miller for comprehensive digital records, and that CAT data is not voluntarily conveyed in any real sense, because the government mandates its collection and automatic daily transmission. You do not choose to feed CAT. You trade, and the feeding happens.

That tension, Miller versus Carpenter, mandated collection versus voluntary disclosure, is the actual legal stakes. It is genuinely unsettled, and anyone who tells you the outcome is obvious is selling something.

The pattern underneath

CAT is a real thing built to solve a real problem, market reconstruction. But the way it got built is the part worth sitting with. The work was slow and technical enough that almost nobody outside the industry noticed. By the time the scope was clear, the infrastructure was already running, already expensive, already woven into how regulators work. And the fight that followed was never about whether to build it, because it is built, but about the procedures governing who can reach into it and when.

The challengers describe the design in a way that should sound familiar far beyond finance: require third parties to collect and hold vast amounts of data on their customers, give the customers no way to opt out, then claim access on the theory that the government might one day need it. That is the shape of modern surveillance generally, and CAT is one of the cleanest examples of it running in plain sight, sanctioned not by a law Congress passed but by an agency's reading of a statute older than most of the markets it now monitors.

The Eleventh Circuit struck down an earlier version of the funding order in 2025 on narrower administrative grounds. The SEC reissued one that is, in its own words, materially identical. The court will now decide whether the deeper objection holds: that before a government agency can build the most comprehensive record of American financial behavior ever assembled, somebody other than the agency itself should have to say yes.

For most of 2025, the story of AI was an American one. The best models, the biggest launches, the loudest valuations all came out of San Francisco. Then developers started doing the thing developers always do. They followed the cost curve. And the cost curve led to China.

In the week of February 9 to 15, 2026, Chinese-developed models passed American ones in token usage on OpenRouter, the largest platform for routing requests across hundreds of AI models, for the first time. Chinese models handled 4.12 trillion tokens that week against 2.94 trillion for US models. A year earlier, American models had accounted for nearly 70 percent of the platform's top-ten usage and Chinese models for under 20 percent. The overtake was not a fluke. By the following week the Chinese share had climbed to 5.16 trillion while the US number fell. Months later, the lead has not just held, it has widened.

It is worth being precise about what this measures, because the headline numbers get stretched. Token usage is not the same as users, revenue, or capability, and OpenRouter is one platform, not the whole market. The often-quoted "61 percent" figure refers to the top ten most-used models in a single week, not all 400-plus models on the platform. Longer-horizon data puts the Chinese open-weight share lower. But the direction is unambiguous, and token volume matters precisely because it reflects real deployment. It is what gets used when someone is paying by the request and watching the bill.

The simplest explanation is the right one. Chinese models are dramatically cheaper. DeepSeek's V3.2 charges around $0.42 per million output tokens. The comparable figure for a flagship American model can run into the tens of dollars, a difference of 10 to 20 times depending on what you compare. For a casual chat, that gap is invisible. For anything running at scale, it is the whole decision.

What changed in 2026 is that scale arrived. The defining shift on OpenRouter was the move from chat to agents. Programming workloads went from roughly 11 percent of the platform's token volume in early 2025 to more than half. Agentic tasks, where a model is called over and over to plan, write, test, and revise, now make up the majority of output. A single overnight coding run can invoke a model thousands of times. When that is your usage pattern, per-token price stops being a line item and becomes the budget.

Chinese labs were positioned for exactly this moment. Models like MiniMax's M2.5 and Moonshot's Kimi K2.5 were built natively for agent workflows, and they post benchmark scores within a hair of the American leaders. On SWE-Bench Verified, a standard coding test, M2.5 scores around 80.2 percent against roughly 80.8 percent for Claude. Near parity, at a fraction of the cost. For a developer pointing an autonomous agent at a problem and paying for every step, that is not a close call.

The cost advantage itself traces back to a few structural things: cheaper energy, heavy state investment in power, and more efficient model architectures. Some of that efficiency was forced. US export controls on advanced chips pushed Chinese labs to squeeze more out of less compute, and the result is a generation of models engineered around doing more with fewer resources.

Step back from the leaderboard and the bigger pattern comes into view. The entities driving this usage are increasingly not people typing into chat windows. They are software agents, calling models autonomously, transacting at machine speed, running through tokens in volumes no human conversation would ever generate.

That shift has a consequence the token charts only hint at. If the agent economy is the future, its supply side, the raw intelligence that agents buy and act on, is tilting toward open-source models, and many of the cheapest, most-used of those are now Chinese. The machines coming online need answers, and they are increasingly sourcing them from open weights rather than premium proprietary APIs.

This is already producing a second layer of infrastructure. Protocols are being built on the bet that autonomous agents will need to buy verified answers from a marketplace of many models rather than commit to a single vendor. Telegraph, a messaging protocol on Base, is one example, designed to route agent requests to whichever model scores highest for a given task and settle payment automatically. Whether any specific project wins is beside the point. The fact that this layer is being built at all tells you where the market thinks demand is heading: toward a world where most of the parties buying intelligence are not human.

None of this means China has won AI, and anyone selling that headline is overreaching. Usage is not the same as dominance, the US still holds an edge on some frontier models, and by several measures the capability gap has narrowed to the point of effectively closing rather than the US pulling away. Cost leadership can also evaporate the moment the economics shift, and Chinese models carry their own complications, including the legal question of data shared with a foreign government that matters a great deal for anyone routing sensitive workloads through them.

There is also a quieter worry, and it comes from the people closest to the open-source movement rather than its critics. The builder who writes under the handle 0xSero, whose open-source manifesto reached a large audience earlier this year, has argued in a follow-up that the open-weight window may be cresting rather than opening. The Qwen team that pushed local inference so far forward has moved on from Alibaba, open source a lower priority there now. Some labs that planned open releases reconsidered. Meta stopped putting out open weights altogether. And the next generation of inference hardware, sold in racks costing millions and back-ordered for years, threatens to hand the cost advantage back to whoever can afford to buy in at scale. His point is uncomfortable precisely because he wants open source to win: leading in usage today is not the same as being safe tomorrow.

That is the real stakes underneath the token charts. The "build it and they will come" assumption that underwrote American AI for two years has cracked, because developers turned out to be loyal to one thing, which is what works at a price they can afford. Open-source models proved that capability is no longer something you can lock behind a premium API, because someone will replicate it, ship it cheaper, and let the world fork it. That has always been the open-source bet, and in 2026 it is showing up in the only metric that reflects what people actually run. The open question is whether the conditions that made it possible, cheap compute, cheap inference, labs willing to publish their weights, hold long enough to matter.

The models doing the most work in the world right now are open, cheap, and increasingly Chinese. The interesting question is not whether that lead holds week to week. It is what gets built on top of a world where the cheapest intelligence is also the most used, where most of the things using it are no longer people, and whether the door stays open long enough for the rest of us to walk through.

The AI industry has built extraordinary intelligence, but no infrastructure for machines to safely use it. Every lab has optimized for humans. Chat windows. Dashboards. Developer APIs. Nobody had built the layer for the moment when an AI agent needs to purchase trusted intelligence and use that answer to make a real decision, until now.

Telegraph is a messaging protocol built on Base that transforms raw AI outputs from any open or closed-source model, into verified, tradable answers that machines can use to make decisions and execute tasks autonomously.

The interesting part is that Telegraph does not need to beat the AI labs at building models. Its bet is that the market will need a neutral layer above them, one that can route, verify, and commercialize intelligence from many providers. Every frontier lab, every open-source project, every new model that gets funded becomes a better supplier on the network. The billions being poured into AI infrastructure are, in effect, subsidising the protocol's supply side at no cost.

But for machines to earn, trade, and act on behalf of people, intelligence cannot just be generated. It has to be verified. The moment an AI agent starts buying answers from another piece of software and acting on them without a person reviewing the result first, trust becomes the central problem.

How does anyone know whether the answer is correct? This is what Telegraph is working to resolve.

AI models hallucinate. Industry reports estimate the cost to global business at tens of billions of dollars annually, and while the headline numbers are commercial estimates rather than peer-reviewed research, the underlying problem is well documented. Stanford's legal AI study found purpose-built tools hallucinated on 17 to 34 percent of queries. Columbia Journalism Review found AI search tools gave incorrect answers on more than 60 percent of citation checks. A human reading a wrong answer loses time. An agent acting on one can lose money in milliseconds.

Telegraph's proposed solution has four pillars:

Miners: The people running an AI model and offering to answer specific kinds of questions, e.g. a Bittensor subnet operator, a developer hosting an open-source LLM, a research lab with a proprietary model. They register what they can answer and plug in via a YAML file. When an agent or application requests a signal, they provide the inference. They are paid exclusively from real usage. Every time an answer is bought, the agent's USDC purchases Machina, Telegraph's token, from the open market and sends it to them. The better their model, the more agent traffic and tokens they get.

Agents: Agents are the software clients that need those answers. They are built by developers, run on behalf of users, and pay in USDC for each request.

Validators: A network of 64 institutional node operators that score every answer against verified ground truth using cryptographic proofs, reaching consensus before payment is released. Telegraph itself does not produce intelligence. It is the layer in between, verifying answers and routing payments across the entire inference ecosystem.

Script Authors: They write the scoring logic that determines whose model is the best. Validators run these evaluation scripts to grade miner responses, and the script authors themselves earn the 20% emission pool proportionally to how often their logic is relied upon. The more validators rely on their script, the larger their portion. They never sell the script but they are compensated directly by the protocol for making the network accurate.

What makes Telegraph more than a payment layer is the verification machinery around the answer itself. The protocol does not simply route a request to a model and hope for the best. It scores miner responses through validators, canonical scripts, stake weighted median consensus, and cryptographic ground truth checks before routing future demand.

The design choice that distinguishes Telegraph from a marketplace like Bittensor, where developers pick specific subnets to query, is that agents on Telegraph do not pick models at all. They declare what they want answered, and the protocol routes the request to whichever miner is currently scoring highest for that category of question. The architectural bet is that agents making decisions on behalf of users at machine speed will not have time to evaluate AI vendors, and that the people building those agents will want a layer that does the evaluation for them.

"Intelligence from open and closed-source models is growing exponentially, but it has no unified commercial layer. Agents need a source of truth faster and more reliable than human consensus, yet today they're forced to rely on black-box models. Developers spend hours manually testing which model performs best for their specific use case. Trillions of machines are waking up, and every one of them will need verified answers," says Ahmed Ali, CTO and Co-Founder of Telegraph. "We replace hand-testing with automated, intent-based routing. Developers no longer pick models. They declare their intent, and our engine routes each request to the highest-scoring providers on a live leaderboard."

The Solana Foundation reported in March that the network has processed roughly 15 million on-chain payments initiated by AI agents, primarily for machine-to-machine commerce. Coinbase's x402 payments protocol, an HTTP-based standard that lets software agents pay on behalf of themselves across multiple networks, saw a roughly 10,000 percent surge in transaction volume over a recent period, hitting around 500,000 payments in a single week. In March, Banco Santander and Mastercard completed Europe's first live end-to-end payment executed by an AI agent inside a regulated banking environment, using Mastercard's Agent Pay framework.

"The goal is to create a coordination layer where miners are rewarded for delivering the verified responses machines need to make decisions. Agents are already beginning to spend money, but the market for trusted machine intelligence is very early. We're opening the door to competition, rewarding the evangelists who want to shape this industry," Mark Basa CEO & Co-founder of Telegraph adds.

For Telegraph, the opportunity is not simply that agents are beginning to pay. It is what happens after they pay. When an agent pays for an answer, the USDC does not flow directly to the miner. Instead, the protocol utilizes a pipelined settlement engine: it tracks usage off-chain in raw USDC, then executes a single, batched transaction at the epoch boundary to swap the collected funds for Machina, Telegraph's native token, on the open market. The miner receives Machina, which was just purchased with real dollars on the open market. Every paid request is, mechanically, an open-market buy.

This is a genuinely novel design choice for a 21-million-supply token, taking a different approach to how value flows between users, miners, and the broader market.

Bittensor is the closest reference point. Launched in 2021, it now spans more than 128 active subnets covering inference, training, compute routing, and deepfake detection, and has built a real ecosystem with a market cap that has touched $5 billion. It is, by some distance, the most successful experiment in decentralized AI infrastructure to date, and the protocol that has done the most to prove this category is real.

Producing intelligence is not cheap. Training models, running inference at scale, maintaining specialized infrastructure, all of it carries a real cost. Bittensor solves that problem by subsidizing miner activity through token emissions, which is a sensible choice for a protocol whose core function is to produce intelligence in the first place. Someone has to pay for that work to exist, and emissions are how Bittensor pays for it. Telegraph's situation is structurally different. The protocol does not produce intelligence. It routes it. That means Telegraph cannot reasonably pay miner emissions to subsidize innovation. The economic logic only holds if agents are actually paying for answers, which is why the protocol is designed around USDC demand rather than emission rewards. Machines have to pay first, or at minimum demonstrate real routing demand, before any token flows to a miner.

The team behind Telegraph sees Bittensor as a foundation to build on rather than a network to compete with. The intelligence being produced across Bittensor's subnets is some of the most interesting work happening in open-source AI right now, and Telegraph's design treats it as a first-class supply source. A subnet that has invested years in producing exceptional inference can register on Telegraph and immediately expose that intelligence to a new stream of agent demand, monetized in USDC, without changing anything about how the subnet itself operates. The Telegraph team has cited Bitcoin and Bittensor as the two foundational breakthroughs they draw their architecture from: Bitcoin for securing a ledger through decentralized competition, and Bittensor for creating an open network for decentralized AI production. If both networks scale together, both benefit.

The verification machinery behind it is what makes the rest of the system novel. The network's evaluation layer operates through an automated, performance-based promotion cycle. Independent developers contribute WebAssembly grading logic, which is continuously audited against the network's stake-weighted consensus. Scripts that maintain accuracy within established consensus bounds are automatically promoted, while those that produce volatility or drift are discarded by the mesh. This architecture creates an evolutionary scoring system that autonomously rejects performance anomalies and enforces high-fidelity intelligence as the network standard.

A second piece of the infrastructure handles live miner integration. To answer machine requests, validators must continuously execute real-time queries against third-party models. Telegraph handles this via a distributed threshold encryption scheme where encrypted credentials are rotated across hardware enclaves whenever the validator set changes. Building a permissionless protocol that matches the raw speed of a centralized enterprise API, while securing the execution keys to a global model ecosystem, is one of the most formidable infrastructure challenges in the space today.

There are still big questions ahead. If verified intelligence for AI agents becomes a major category, will it be powered by a new protocol and token, or will the same function eventually be built into companies like Coinbase, Stripe, Visa, or Mastercard?

Basa believes the intelligence layer should be open and permissionless, not controlled by one company, and that the major AI labs are unlikely to build trustless verification themselves, because their current business models do not depend on it. If he's right, the AI labs will also have a choice to make: plug into networks like Telegraph as suppliers, or build their own commercial intelligence layers.

That is what makes the next phase so interesting. Telegraph is not just launching another AI protocol. It is testing whether trusted machine intelligence can become its own open market.

The macro context for the bet they are making is moving quickly. Agent initiated payments are still early, but they are no longer theoretical. Telegraph is building for the moment when autonomous systems need not just the ability to pay, but a reliable way to decide what information is worth paying for.

THORChain is a cross-chain liquidity protocol that lets users swap native assets directly between Bitcoin, Ethereum, BNB Chain, Avalanche, Cosmos Hub, Dogecoin, Bitcoin Cash, Litecoin, Base, Ripple, and TRON without wrapping tokens or trusting an intermediary. It is secured by RUNE, its native token, which provides economic security to the network. Ledger, Bitget Wallet, ShapeShift, Token Pocket, Keplr, and dozens of other wallets and exchanges plug into it as a non-custodial swap provider. It is, in short, infrastructure.

On Friday morning, that infrastructure was compromised.

THORChain confirmed the incident in an official statement, saying one of its six Asgard vaults appears to have been breached and current estimates place the loss at approximately $10.7 million. The network's automatic abnormal-behavior detection halted signing activity before the attacker could continue, and node operators participating in the affected vault had their bonded RUNE slashed as a result of the unauthorized outbound transactions. Churn activity has been paused. Onboarding additional chains has been delayed. RUNE fell roughly 12 percent on the news.

The first public alert came from on-chain investigator ZachXBT, who flagged suspicious activity across Bitcoin, Ethereum, BSC, and Base, and tied the drained funds to a set of theft addresses now labelled "THORChain Exploiter" by Arkham Intelligence. PeckShield independently confirmed roughly 36.75 BTC, hundreds of ETH, and a long list of stablecoins, wrapped tokens, and altcoins moved out of the vault and consolidated into a single Ethereum address.

The Exploit, By the Numbers

One vault compromised. Four chains drained. $10.7M gone before the network halted itself.

Loss

$10.7M

THORChain's own confirmed figure. Some analysts put confirmed impact higher.

Chains hit

4

Bitcoin, Ethereum, BSC, Base. Stolen assets swapped to ETH and consolidated.

Vaults compromised

1 of 6

A single Asgard vault. Network halted signing before more outbound activity could occur.

RUNE price

-12%

Token fell on the news. User funds reportedly unaffected.

THORChain has not released a post-mortem. But several cryptographers and security researchers have already pointed at the same culprit: the protocol's threshold signature scheme.

Charles Guillemet, CTO of Ledger, posted a detailed analysis pointing to a possible MPC exploit. THORChain's vaults rely on TSS, a flavor of multi-party computation where a quorum of nodes jointly produces a signature without ever reconstructing the private key. The protocol uses GG20, on a fork of Binance's tss-lib. GG20 has shipped two well-publicized critical bugs in recent years: CVE-2023-33241 and the TSSHOCK class of attacks discovered by Verichains in 2023.

In every published GG18 and GG20 attack, Guillemet wrote, a single malicious or compromised co-signer is enough to extract the other parties' key shares and reconstruct the full private key. THORChain has patched these vulnerabilities before. In August 2023, it paused signing activity after the original TSSHOCK disclosure, and was credited at the time for handling the response responsibly.

The pattern Guillemet outlines for this week's drain looks structurally similar: compromise one operator, wait for it to churn into an active vault, send malformed proofs during keygen or signing, reconstruct the key offline, and sweep in a single transaction. He flagged a deeper concern: AI-driven vulnerability discovery is lowering the bar to compromise one of N validators, and the multi-month windows of safety these systems used to enjoy are getting shorter.

Vladimir S. of Officer's Notes pointed at a specific THORNode patch referenced by researcher banteg, noting that validators may have been signing too little data, which would let a proposer change how THORChain interpreted an observation without invalidating signatures.

The harshest take came from Tay, who wrote that THORChain was running a version of tss-lib roughly three years and two major security releases behind current.

Adam Back, CEO of Blockstream, added context that landed harder coming from him than from most: as one of the few people who actually understood the cryptography of MPC for DSA signatures, his read is that the system is too complex to make work securely. Adaptive cryptography attacks, implementation bugs, and a small pool of qualified reviewers make the surface enormous. And, he noted, the shards are all online in software servers.

The exploit comes against a backdrop THORChain has not been able to shake. The protocol has previously been used as a laundering route for funds tied to the Bybit hack, attributed to North Korea's Lazarus Group, and the KelpDAO incident, where attackers moved nearly $80M in ETH to BTC through THORChain combined with Umbra to obscure the trail.

ZachXBT addressed that history directly in a public response to a now-deleted post, asking whether the person on the other end had just inadvertently confirmed THORChain was centralized "for all of those years while DPRK laundered hundreds of millions while raking in millions of fees with an admin key" held in their possession.

The protocol's official statement says no individual user swaps were affected and that the loss was confined to protocol-owned funds. The investigation continues. Node operators have been asked to audit their infrastructure, key management, and operational security for signs of compromise.

We'll update this story as the post-mortem lands.

You can hold the most private coin on Earth but none of it matters if the wallet you use pings forty servers the moment you open the app. By the time you tap "create wallet," your IP and your device fingerprint are already out the door, sitting in someone else's database, waiting to be matched to whatever you do next.

That's the finding from a network-traffic analysis published today on X by an independent researcher operating under the handle r4nk0X. Their setup was deliberately minimal: a clean Android device, no SIM, APKs pulled via gplaydl, traffic routed through a VPN, and PCAPdroid logging every packet on a per-app basis. Then they opened thirteen of the most popular web3 wallets, once each, and watched what each app said to the internet before the user said anything to it.

The scorecard runs from 0 to 100. 100 means zero IP exposure. The underlying metric is simple: unique remote IPs plus unique domains contacted on first launch.

By the Numbers

13 wallets tested. 12 phoned home before a key was generated.

Best score

100/100

Cake Wallet. Zero packets, zero domains, zero DNS requests on first launch.

Worst score

0/100

SafePal. Contacted 26 domains across 41 IPs before a key existed.

Average exposure

~14

domains contacted per wallet at launch, across the cohort.

The results split the field into three rough tiers.

At the bottom: SafePal (0/100) and OKX Wallet (7/100), the worst offenders. SafePal opens with around twenty chain RPC calls to providers like Alchemy, dRPC, and Thirdweb, plus integrations with Base, Optimism, Fantom, Blast, xLayer, Flare, Klaytn, and opBNB.

Every one of those endpoints sees the user's IP before a wallet exists. OKX Wallet ships eight AppsFlyer subdomains, four Amplitude variants, OneSignal push, three calls to online-metrix.net (a ThreatMetrix fingerprinting service), and a connection to an Alibaba Hong Kong endpoint. On a clean device. Without an account.

The middle tier is where most users live and don't know it. Crypto.com Wallet (49/100), Solflare (54/100), Base by Coinbase (55/100), and MetaMask (61/100) all carry heavy attribution and analytics stacks: AppsFlyer, Branch, Segment, Firebase, Crashlytics, Sentry, Braze, Customer.io, Intercom many of them firing simultaneously at cold start. MetaMask reaches Polymarket and Infura before the user does anything. Solflare loads two Intercom channels and two Customer.io endpoints, the cross-channel messaging infrastructure is set up to talk to you before you've even imported a seed phrase.

The top tier looks different. Phantom (91/100) routes its third-party services, Braze, Eppo, Datadog through its own *.phantom.app proxies, hiding the vendors from network observers.

Atomic Wallet (87/100) and Trust Wallet (79/100) lean on their own infrastructure with limited third-party leakage. Unstoppable (94/100) makes only two calls. Zodl (97/100) makes one. And Cake Wallet (100/100) makes none.

That's the bar. Cake Wallet, a wallet that focuses on ease of use and building trustless software generates zero DNS requests, zero domain contacts, zero outbound packets on first launch. The app opens, waits for the user, and does nothing else. Zodl, a Zcash wallet, contacts a single endpoint. Unstoppable contacts two: its own backend and WalletConnect telemetry.

The wallets at the top of the scorecard aren't doing something clever. They're just not doing the thing everyone else is doing. No Firebase calls home. No Segment pipeline collecting events. No AppsFlyer attribution. No Crashlytics, Sentry, Braze, or Amplitude waiting in the background. Most wallets ship with this stack baked in from day one, these don't. Privacy here is the default, because the surveillance was never wired up in the first place.

For users who care about anonymity at the network layer, journalists, activists and anyone whose threat model includes correlation between IP and wallet this matters more than chain support, more than UI, more than fees. A wallet that pings forty servers on launch has already broken the assumption that on-chain pseudonymity protects you. The link between your real-world identity and your on-chain activity gets made before you ever sign a transaction. Think about that.

The full methodology and per-wallet domain lists are public on r4nk0X's X thread. We'd recommend any web3 user audit their own wallet against the scorecard.

You can hold the most private coins on Earth so you better make sure your wallet isn't selling you out at the front door.

SAN FRANCISCO, April 15, 2026 — The Open Source Initiative (OSI), globally recognized as the steward of the Open Source Definition, today announced the appointment of Duane O’Brien as its new executive director.

O’Brien is a long-time Open Source leader with nearly 25 years of experience as a technologist, community advocate and strategist. He most recently led Collaborative Engineering at Capital One, where he oversaw the company’s Open Source Program Office, InnerSource initiatives, and standards for programming language adoption and implementation. Prior to that, he built and led the Open Source Program Office at Indeed and directed Open Source programs and operations at PayPal.

Throughout his career, O’Brien has focused on how organizations participate in Open Source communities responsibly, with an emphasis on sustainability, transparency and long-term support for the projects they depend on.

O’Brien has also been deeply engaged in the nonprofit and community side of the Open Source ecosystem. He serves on the board of the Open Source Collective and has contributed to initiatives focused on improving the sustainability of Open Source projects and the long-term health of the ecosystem. His work has included advising programs such as the GitHub Accelerator, Hacktoberfest and leading efforts to develop funding models that support maintainers and communities.

As an alumnus of the Technologist Fellowship program at George Mason University, O’Brien contributed to community and private analysis of the EU Cyber Resilience Act and proposed U.S. policies that directly impact the Open Source ecosystem.

Role and Current Priorities of the Open Source Initiative

As the steward of the Open Source Definition, OSI plays a central role in maintaining clarity about what constitutes Open Source software and supporting the communities, companies and public institutions that rely on it.

In 2025, OSI’s work reflected the growing importance of Open Source in technology policy and global digital infrastructure. The organization drove creation of the Open Source AI Definition, establishing a framework for evaluating openness in AI systems and addressing the growing problem of “openwashing.”

OSI also expanded engagement with policymakers and standards bodies in Europe as new regulatory frameworks—including the EU AI Act and the Cyber Resilience Act—began shaping how Open Source software is developed, distributed and governed.

Alongside this policy work, OSI continued its core stewardship work on licensing, standards participation and research into Open Source policy and data governance.

“The Open Source Initiative exists to steward the Open Source Definition and to maintain trust in the structures that support open collaboration,” said Deb Bryant, interim executive director of the Open Source Initiative. “That responsibility requires leadership grounded in both community experience and institutional care. Duane has spent many years working across companies, foundations and Open Source communities to strengthen the sustainability of the ecosystem. I’m confident that his perspective and commitment to thoughtful stewardship will serve OSI well as the organization continues its work on behalf of the global Open Source community.”

“Open Source works because people and organizations come together and collaborate to solve shared problems,” said O’Brien. “For years I’ve focused on helping companies become thoughtful partners with the communities they depend on - by supporting maintainers, investing in sustainability, and showing up with transparency and respect. The Open Source Initiative plays a critical role in the ecosystem by clarifying what Open Source means and safeguarding the principles that make collaboration possible. At a moment when Open Source is central to conversations about AI, cybersecurity and global technology policy, I’m honored to join OSI and look forward to working with the board, staff and community to meet the challenges ahead.”

O’Brien assumes the role following a leadership transition initiated in 2025 when OSI began a search for its next executive director. During that time, Bryant served as interim executive director while continuing to guide the organization’s work in policy and community engagement.

About the Open Source Initiative

Founded in 1998, the Open Source Initiative (OSI) is a nonprofit corporation with global scope formed to educate about and advocate for the benefits of Open Source and to build bridges among different constituencies in the Open Source community. It is the steward of the Open Source Definition and the Open Source AI Definition, setting the foundation for the global Open Source ecosystem.

Join and support the OSI mission today at https://opensource.org/join.

Since first publishing Hermes Agent vs OpenClaw: Why Developers Are Switching on March 18th Hermes has grown exponentially in usage and popularity. Hermes Agent is currently the most trending project on GitHub, with over 50,782 stars and 366 contributors. For context: OpenClaw went from zero to 40,000 stars in 61 days. Hermes did it in 46.

Nous Research also confirmed that Hermes is officially their fastest-growing project ever.

Hermes Agent is officially our fastest-growing project ever!

A huge thank you to everyone who has been experimenting with it, shared the announcement, or took the time to make a contribution to the project. pic.twitter.com/LlbK2HftEw

So what actually makes it different?

Nous Research said it best "Hermes is an autonomous agent that lives on your server, remembers what it learns, and gets more capable the longer it runs." That's the simple version. The nerdy version or more precise version is: Hermes is the first serious productization of what researchers call "Harness Engineering", the idea that an agent needs five distinct layers to function well: an Instruction Layer, a Constraint Layer, a Feedback Layer, a Memory Layer, and an Orchestration Layer. With OpenClaw you need to manually write these layers yourself, you need to know what you're doing, and it takes time. With Hermes, all five run automatically. That's the big shift and it's the difference between a framework built for engineers and one built for everyone.

The Hermes Agent The Complete Guide written by HuaShu (花叔), put it clearly:

"OpenClaw gives you a configuration-as-behavior system, you write a SOUL.md, and it becomes what you want. Its memory system is capable (Daily Logs + MEMORY.md + semantic search) and its Skill ecosystem is massive, but Skills are primarily written and maintained by hand. Hermes has all five dimensions built in, and they run automatically."

Why Nous builds this way?

The speed and openness aren't accidental. Nous Research being an open source AI research lab means they have a few set of core principles which are that the user control comes first, the model is steerable, and you can adjust its behavior as needed, free from corporate content policies.

Jeffrey Quesnelle, one of Nous' co-founders, said during an X Space this week:

"We believe as a first class citizen running a model locally is something you also can do and we are never gonna go away from that since when we started it was all about that you should be able to own this whole tech stack yourself if you want to."

Listen to the full X space hosted by Robert Scoble here.

That philosophy is visible in how the project is run. The codebase is open source and written in Python, so developers can extend it without fighting the ecosystem. Teknium, another Nous Research co-founder and head of post-training, is visibly present in the community, responding to builds, asking what people want to see next, and shipping integrations fast.

This is what open source is supposed to look like. And 50,782 stars in 46 days suggests the community agrees.

Highly recommend you read HuaShu's (花叔) Complete Guide to Hermes Agent, it's the most thorough technical breakdown available right now.

An interview with Christo Liebenberg, Co-Founder, President & Chief Technical Advisor, LIS Technologies

BY THE NUMBERS

• The US currently imports 95-98% of its nuclear fuel
• Russia and China together control over 50% of global uranium enrichment capacity
• A ban on Russian enriched uranium imports went into effect in August 2024
• The DOE has committed $2.7 billion to restore American enrichment capacity
• Global uranium demand is projected to surge 28% by 2030 and more than double by 2040

About Christo Liebenberg

With an MS in physics, Christo Liebenberg began his career at the Atomic Energy Corporation of South Africa in 1985, working on CO2 laser MOPA systems for uranium enrichment. From there he held senior roles at Silex Systems, Global Laser Enrichment, and ASML, all centered on the same core technology. In 2020 he co-founded CRISLA, Inc. with Dr. Jeff Eerkens to revive the CRISLA laser enrichment process, which had been demonstrated in the 1980s and early 90s before being abandoned when Russia flooded global markets with cheap enriched uranium after the Cold War. In 2023, LIS Technologies acquired CRISLA, Inc. and Christo became CEO to lead its commercialization. He watched the field get shelved, kept building his expertise anyway, and finds himself at the center of it all at the exact moment the US is scrambling to rebuild what it abandoned decades ago.

Most people have never had to think about where nuclear fuel comes from. You plug something in, the lights turn on, and whatever happens between the uranium mine and the power socket remains comfortably invisible. That invisibility, it turns out, is a problem.

The United States currently imports 95-98% of its nuclear fuel. Russia and China together control more than half of the world's uranium enrichment capacity, the critical industrial process that converts raw uranium into reactor-grade fuel. In May 2024, the US signed the Prohibiting Russian Uranium Imports Act into law, making a ban on Russian enriched uranium effective August 11, 2024, with a hard cutoff on all remaining waivers by 2028. Around the same time, the Department of Energy launched a program committing roughly $2.7 billion to rebuild domestic enrichment capacity, infrastructure the US largely walked away from in the 1990s when cheap Russian fuel made it economically pointless to compete.

Meanwhile, China is building 150 new nuclear reactors by 2035. Microsoft, Google, and Amazon are signing nuclear power agreements to feed their AI data centers. And global uranium demand is projected to surge 28% by 2030, more than doubling by 2040, driven by a combination of decarbonization goals, next-generation reactor deployments, and the insatiable electricity appetite of artificial intelligence.

At the center of the effort to close this gap is LIS Technologies, a US company developing a laser-based approach to uranium enrichment that its founders believe could be both cheaper and more efficient than the centrifuge technology that has dominated the industry for decades. I spoke with co-founder and President Christo Liebenberg, a physicist who has spent his entire career working on this specific technology, about how the US got here, what it would take to recover, and why the fuel few talk about may be the most important bottleneck in the energy transition.

"You should not only not shut down the nuclear power plants, but you should also reopen the ones that have already shut down... This is total madness to shut them down."

— Elon Musk

The Interview

Q: I've read that the US basically let its enrichment capability collapse after the Soviet Union flooded the market with cheap fuel in the 1990s. Is that a fair summary and how dependent did the US become on foreign suppliers as a result?

Christo Liebenberg: Yes, that’s essentially what happened. The U.S. used to be the world’s biggest producer and exporter of enriched uranium, and a lot of that capability was built out during the Manhattan Project era, especially in places like Oak Ridge.

When the Soviet Union collapsed, Russia started selling enriched uranium into the global market at very low prices, in some cases less than half of what it had been. That made it very difficult for U.S. technologies to compete, and many programs were simply stopped. Over time, the U.S. became increasingly reliant on external sources, not just for uranium, but for the enrichment services themselves, which is really the more difficult part to replace.

Q: China is planning to build 150 new nuclear reactors by 2035. The US has zero currently under construction. How does that gap translate into something concrete, what does the US actually risk losing if enrichment capacity doesn't keep up?

CL: When you build that many reactors, you are not just building power plants, you are building long-term demand for fuel and the entire infrastructure around it. That includes enrichment, fuel fabrication, and the supporting supply chains.

If the U.S. does not build out enrichment capacity alongside reactor development, then it risks not being able to supply its own fleet. You can have the reactors, but if you don’t have the fuel, you don’t have a complete system. That has very real implications for cost, for timelines, and for who ultimately controls access to that fuel. For the US to become self-sufficient, and for our energy security and our national security, we have to rebuild the entire nuclear fuel supply chain.

Q: Microsoft, Google, Amazon, they're all signing nuclear power deals now. What's the connection between AI data centers and enriched uranium? It feels like an unlikely pairing to most people.

CL: It may seem like an unusual connection, but it really comes down to power demand. These data centers require very large amounts of reliable, continuous electricity, and nuclear is one of the few sources that can provide that consistently.

Once you start adding that kind of demand, the question becomes where the fuel comes from. Many of the advanced reactors being considered for these applications require HALEU, which is already in short supply. So there is a very direct link between the growth in AI infrastructure and the need for more enrichment capacity. Big tech companies are signing PPA’s (Power Purchase Agreements) with SMR companies, but there is a need for them to also invest in the nuclear fuel supply chain in the form of FPA’s (Fuel Purchase Agreements).

Q: You're using lasers to enrich uranium rather than the centrifuge approach most people associate with the process. Can you explain that in terms a non-physicist can follow and why does the method matter for what you're trying to build?

CL: Most conventional methods, like centrifuges, rely on spinning uranium gas at very high speeds and repeating that process over many stages to gradually increase the concentration of U-235. It is a mechanical process, and it requires a large number of cascades to get to the desired level.

With laser enrichment, we take a different approach. We use lasers that are tuned to selectively excite only the U-235 isotope. Single-stage means you irradiate the uranium once, and it’s enriched from natural levels up to LEU. If you irradiate it a second time, you can go all the way to HALEU, up to about 20%. That reduction in steps is important, because it simplifies the system and makes it more efficient and easier to scale.

Q: If everything goes right for LIS Technologies — the technology scales, the funding keeps coming, the DOE partnership delivers — what does that actually change? What's the version of this story where the US wins?

CL: If everything goes according to plan, the main outcome is that the U.S. regains a domestic enrichment capability that can operate at scale. That means being able to produce both LEU for existing reactors and HALEU for the next generation of systems.

It also changes how quickly and efficiently that capacity can be deployed. If you can move from natural uranium to LEU in a single stage, and then to HALEU in a second stage, that has a significant impact on cost and throughput. In that scenario, the U.S. is no longer dependent on external suppliers for a critical part of its energy system, and it is in a position to support its own nuclear expansion going forward.

A Note on Risk

Laser enrichment is not a new idea. The concept has been pursued by researchers across more than 26 countries for over 50 years, which makes what LIS Technologies is attempting both ambitious and, for the first time, genuinely plausible. The CRISLA process was not abandoned because it failed in the lab. It was stopped in the early 1990s because cheap Russian uranium made it economically pointless to continue. The science worked. The market didn't need it yet.

That calculation has now reversed entirely. The DOE's selection of LIS Technologies as one of six contract awardees under its $3.4 billion Low-Enriched Uranium Acquisition Program reflects the kind of institutional confidence that didn't exist a decade ago. The funding, the geopolitical urgency, and the commercial demand are all now aligned in a way they never were before. The road from demonstration facility to commercial scale is still long but for the first time in thirty years, America has every reason to get there.

Context & Further Reading

Uranium price data sourced from market trading records.
Current spot price: $85.15/lb (April 2026). 

Uranium demand projections: World Nuclear Association Nuclear Fuel Report
US uranium security analysis: "Fueling the Future: Recommendations for Strengthening US Uranium Security" — Baskaran & Schwartz, CSIS, February 2025
CRISLA technology background: "The CRISLA Advantage: Why LIS Technologies' Laser Enrichment Process Could Change the Face of Nuclear Fuel" — Chris Gallagher, 2024
China nuclear expansion: "How Innovative Is China in Nuclear Power?" — ITIF, 2024
LIS Technologies DOE contract: LIS Technologies & NANO Nuclear Energy DOE LEU Acquisition Program announcement

On March 19, Cursor announced Composer 2 — described as their "in-house" AI coding model, "frontier-level at coding," benchmarked against Claude Opus 4.6 and GPT-5.4. The blog post credited "continued pretraining" and "reinforcement learning" for the performance gains. It made no mention of Moonshot AI, Kimi, or any open-source base model.

Within 24 hours, a developer intercepting API traffic posted a screenshot. The model identifier in the live response read: kimi-k2p5-rl-0317-s515-fast.

Yulun Du, Moonshot AI's head of pretraining, then posted on X: "Wait. We tested with composer 2 model API and found out the tokenizer is indeed the same with our Kimi tokenizer! We can almost confirm this is our model post-trained further! We are shocked that @cursor_ai did not respect our license nor did they pay us any fees! @mntruell why??"

He tagged Cursor co-founder Michael Truell directly. That post has since been deleted.

Hours later, Moonshot AI posted an official statement in a markedly different tone.

What Kimi K2.5 is, and what its license requires

Kimi K2.5 is an open-weight model released by Moonshot AI, a Beijing-based AI lab founded in 2023 by Yang Zhilin, Zhou Xinyu, and Wu Yuxin — alumni of Tsinghua University. The model has 577 billion active parameters, was trained on 15.5 trillion tokens, and currently ranks 9th on OpenRouter by usage volume. Moonshot released it openly. They attached one condition.

The modified MIT license on Kimi K2.5's weights requires any commercial product or service exceeding either 100 million monthly active users or $20 million in monthly revenue to do two things: display prominent attribution — "Kimi K2.5" — in the user interface, and pay licensing fees.

Cursor crossed $1 billion in annualized revenue in November 2025. The $20 million monthly threshold is not a close call.

Composer 2's announcement contained no attribution. According to Yulun Du's since-deleted post, no fees had been paid either.

Cursor's response

After the model ID became public, Lee Robinson of the Cursor team posted on X: "Yep, Composer 2 started from an open-source base! We will do full pretraining in the future. Only ~1/4 of the compute spent on the final model came from the base, the rest is from our training. This is why evals are very different. And yes, we are following the license through our inference partner terms."

The inference partner referenced is Fireworks AI.

Both claims in that statement warrant scrutiny.

On the compute ratio: open-source licenses don't assess derivative works by the proportion of compute added. The question is whether the final model derives from the licensed work. A reinforcement learning fine-tune built on Kimi K2.5 weights is a derivative of Kimi K2.5 regardless of how much additional training was layered on top. If anything, Cursor's own blog post confirms this — describing "continued pretraining" and "reinforcement learning" applied to a base, without disclosing what the base was.

On the inference partner argument: Fireworks AI is a hosted compute and inference provider. Their terms of service govern service usage, rate limits, and billing arrangements between Fireworks and their customers. They do not govern what obligations Cursor carries under Moonshot's model license. The license attaches to the entity that created and is commercially distributing the derivative — that is Cursor, not Fireworks. Using a third-party inference provider to serve a model does not transfer the licensing obligations for that model to the inference provider.

Asked directly to evaluate Cursor's inference partner claim, Grok concluded: "Following Fireworks inference terms does not relieve Cursor from Kimi K2.5's license obligations... Fireworks provides hosted API inference, but does not supersede Moonshot's model license for derivatives."

The timeline

The sequence of events matters here. Cursor previously listed Kimi K2.5 as a free model in their interface. Users reported it disappeared from the model picker in early February. On March 19, Composer 2 was announced — with no mention of Kimi K2.5 — carrying a per-token price and positioned as Cursor's own model.

Developer @fynnso caught the model ID in API traffic the same day. Yulun Du confirmed the tokenizer match and posted his public accusation tagging Truell. Multiple Moonshot employees posted corroborating confirmations. Within hours, those posts were deleted.

Then came the official Moonshot statement — congratulatory, carefully worded, and striking a very different note than Du's earlier post:

Congrats to the @cursor_ai team on the launch of Composer 2!

We are proud to see Kimi-k2.5 provide the foundation. Seeing our model integrated effectively through Cursor's continued pretraining & high-compute RL training is the open model ecosystem we love to support.…

The gap between these two statements — Du's shocked public accusation and the organization's polished congratulations — is the most significant open question this story leaves. Either the commercial partnership was always in place and Du was unaware of it, or a resolution was reached in the hours between his post and the official statement. Moonshot has not clarified which. The deleted posts are consistent with both explanations, and with standard legal counsel advice to move disputes out of public view.

What the official statement does not address is the attribution requirement. "Authorized commercial partnership" suggests a fee arrangement has been resolved. Whether Cursor's product now displays "Kimi K2.5" attribution in the user interface — as the license explicitly requires — remains publicly unconfirmed.

What this is actually about

Set aside the question of whether a deal was always in place or was struck under pressure. The more durable issue is what the original announcement communicated — and didn't.

Cursor's Composer 2 blog post described performance gains from "our first continued pretraining run" and reinforcement learning, benchmarked the result against frontier models, and positioned the model as evidence of Cursor's own technical capability. It made no mention of the open-weight model that served as the foundation. Whether or not the commercial terms were satisfied, the presentation implied original work that wasn't entirely original.

This matters because the open-source AI ecosystem runs on a compact: labs release powerful models because open development, they believe, produces better outcomes for everyone. Moonshot released Kimi K2.5 under terms specifically designed to allow free use by researchers and smaller players, while requiring acknowledgment — and compensation — from large commercial operations above clear thresholds. Those thresholds exist because a company raising at a reported $29 billion valuation and a two-person research team are not the same kind of beneficiary.

The community found the model ID in under 24 hours. Posts went up, posts came down, and an official statement followed. Whatever was resolved in those hours, it took public pressure to surface it.

That's worth remembering the next time a frontier-level model launches with an impressive benchmark chart and no mention of where it started.

Anthropic just shipped Claude Code Channels — letting you message your coding session directly from Telegram or Discord. If you've switched from ChatGPT to Claude recently, here's what it actually means for you.

Claude Code is Anthropic's terminal-based AI coding tool — it runs on your laptop, reads your files, writes and edits code, and executes commands. Until now, interacting with it meant sitting at your computer. That changed this week.

Anthropic engineer Thariq Shihipar shipped Claude Code Channels — a feature that connects your running Claude Code session to messaging apps. You send a message from your phone, Claude responds in the chat, and any code changes happen on your machine. The launch currently supports Telegram and Discord.

posted on X by @trq212

How It Works

The setup involves connecting a Telegram or Discord bot to your Claude Code session via an MCP server — a standard protocol for giving AI tools access to external services. Once connected, messages you send to the bot are forwarded into your Claude Code session, and responses come back to your phone. It's not a cloud service — your code stays on your machine, the session just becomes reachable remotely.

1

Create a bot

On Telegram, open @BotFather and run /newbot. Takes about 60 seconds. You get a token.

2

Install the plugin in Claude Code

Run /plugin install telegram@claude-plugins-official inside a Claude Code session, then paste your token with /telegram:configure.

3

Relaunch with the channel flag

Exit and restart: claude --channels plugin:telegram@claude-plugins-official

4

Pair your account

DM your bot on Telegram — it sends a 6-character code. Enter it in your session: /telegram:access pair <code>. Done.

After pairing, lock it down — run /telegram:access policy allowlist so strangers can't interact with your session. The full setup docs and Discord instructions are on GitHub.

What It's Actually Useful For

The obvious use case: you kick off a long task — a refactor, a build, a test suite — step away from your desk, and want to check in or redirect it from your phone without opening a laptop. Less obvious: sending Claude a quick task from your commute to have it ready when you sit down.

What Claude Can Do Over Chat
Reply to your messages, send files and images back to you, react to messages, and edit its own previous messages (useful for live progress updates like "running tests…" → result). It doesn't have access to your Telegram or Discord message history — it only sees messages as they arrive in the session.

The feature is built on MCP — the Model Context Protocol, an open standard for connecting AI tools to external services. That matters because it means this isn't a proprietary integration locked to Anthropic's infrastructure. The server runs locally, the protocol is open, and in principle the same approach could connect Claude Code to other messaging platforms as the ecosystem grows.

Anthropic is a closed company — their models aren't open source, and Claude Code itself isn't free for heavy use. But the underlying plumbing here (MCP) is open, and the bot integration is a thin layer on top of it. For the growing number of developers using Claude as their daily coding tool, this is a practical quality-of-life improvement more than a strategic announcement.

For the first time, an AI platform is offering cryptographically verifiable privacy — not promises, not policies, but math. Venice's new TEE and E2EE modes let any third party independently confirm your prompts were never seen by anyone.

Every major AI company stores your conversations. Every prompt, every response — saved, analyzed, and accessible to employees, third-party contractors, hackers, and government subpoenas. This is the default state of AI in 2026. Venice AI, the open-source-first AI platform founded by Erik Voorhees, has been building against that assumption since day one. Today, they took their most significant step yet.

Venice just shipped two new privacy modes — Trusted Execution Environments (TEE) and End-to-End Encryption (E2EE) — that move AI privacy from the realm of contractual promises into the realm of cryptographic proof. Vires in numeris. 

"Ubiquitous mass surveillance is an unethical foundation on which to build society." — Venice AI, on the principle behind their architecture

Four Modes, One Principle

Venice has reorganized its entire privacy architecture into four explicit modes. The framing is deliberate: users deserve to understand exactly what protection they're choosing before they start a conversation. Here's how each mode works:

Introducing our four Privacy Modes on Venice.

Every AI model now falls into one of four categories, each with different protections and trade-offs. You choose based on what matters most for each conversation. pic.twitter.com/pQANxX4DUX

Anonymous:
Venice proxies requests to frontier model providers — GPT, Claude, Gemini, Grok. Your IP and identity are masked from the provider. But you should assume the provider stores your content. Privacy here is identity-level, not content-level.

Private (Default):
Inference runs on Venice-controlled GPUs or zero-data-retention partner infrastructure. No prompt or response is stored anywhere but your device. Privacy is enforced by contract — you're trusting Venice and its partners to honor their commitments.

TEE (PRO):
Inference runs inside a hardware-isolated secure enclave. The GPU provider cannot access your prompts. Verified by remote attestation — a cryptographic certificate tied to the hardware itself that any external party can independently validate. (Hardware -verified)

E2EE (PRO):
Your prompt is encrypted on your device before it leaves. It stays encrypted through Venice's infrastructure. It is only decrypted inside a verified hardware enclave. Neither Venice nor the GPU provider can see your data at any point.
(Cryptographically verifiable)

The crucial distinction: Anonymous and Private modes are trust-based — you're relying on Venice's policies and contracts. TEE and E2EE modes are math-based. The security is enforced by hardware and verified through cryptographic attestation. You don't have to trust anyone.

What "Verifiable" Actually Means

The word "verifiable" is doing a lot of work here, and it's worth unpacking precisely what Venice means by it. When a model runs inside a TEE, the hardware itself generates a signed cryptographic certificate — called an attestation quote — that contains measurements (hashes) of the exact code running in the enclave. That certificate is bound to the hardware.

Venice builds its inference image with reproducible builds. Anyone can clone the repository, run the build, and produce the exact same measurements. Every release is signed and published to a public transparency log. This means you can verify, without Venice's involvement, that the code you see in the repo is the code running on the GPU processing your prompt.

Every TEE and E2EE response on Venice now displays a verification icon. Clicking it opens the full attestation report — showing which hardware attestation checks passed, the exact model attested, and timestamps. This is the receipt.

The Infrastructure Partners

TEE and E2EE inference on Venice is currently operated by two external partners: NEAR AI Cloud and Phala Network — both projects with deep roots in the open and decentralized technology ecosystem. Venice has published technical documentation from both providers covering E2EE implementation, attestation verification, and the underlying dstack architecture.

Eleven models currently support both TEE and E2EE modes, including Venice Uncensored 1.1, GLM 5, Qwen3.5 122B, Gemma 3 27B, GPT OSS 20B, and GPT OSS 120B. More are coming. TEE and E2EE are Venice Pro features.

Venice's launch lands at a moment when the private AI space is quietly becoming a serious field. The most technically notable parallel effort is Confer, the encrypted AI platform built by Signal Protocol creator Moxie Marlinspike. Confer takes a similar architectural approach — combining confidential computing with passkey-derived encryption so that not even Confer itself can access user conversations.

What makes Confer worth watching is both its technical pedigree and news: Marlinspike announced in a blog post he'll work to integrate Confer's privacy technology into Meta AI — the same way he worked with Meta a decade ago to bring end-to-end encryption to WhatsApp for two billion people. If that integration succeeds at scale, it would represent the largest deployment of private AI inference ever attempted.

Confer's Approach:
Like Venice's E2EE mode, Confer runs LLM inference inside a confidential VM using hardware-enforced isolation. User prompts are encrypted from device directly into the TEE via Noise Pipes — the host machine provides CPU and power but never sees plaintext. Attestation is handled through dm-verity over the full root filesystem and a public transparency log for reproducible builds. The core design principle: the server is an endpoint in the conversation, but the people running it cannot read what's in it.

Both projects are doing the actual cryptographic work — and notably, both depend on open-weight models to do it. You cannot run a closed-source model inside a TEE with verifiable attestation. The privacy guarantees only hold because the code is auditable. That's not a coincidence.

"You don't need to protect what you don't have." — Venice AI, on their foundational design principle

A quiet but unmistakable migration is underway in the AI developer community. Builders who once ran OpenClaw as their go-to persistent AI agent are switching to Hermes Agent — Nous Research's open-source Python framework. The project sits somewhere between Claude Code's CLI approach and OpenClaw's messaging-platform model, and for a growing cohort of builders, that middle ground is exactly where they want to be.

Over the past week or two, X has been flooded with developers posting their setups, benchmarks, and migration stories. The common thread: Hermes runs more reliably on consumer hardware, handles small models far better, and is being actively stewarded by a team that's visibly responsive to the community.

Why People Are Leaving OpenClaw

The grievances aren't abstract. Developer @Zeneca laid them out after switching:

"Things 'just work' a lot better. When I ask it to do things, it'll create an actual skill, rather than just relying or hoping it'll remember what I want next time. Very easy to set up and switch models — this caused OpenClaw to crash on me constantly."

The practical sticking points around OpenClaw — crashing on model switches, unreliable tool calls with smaller models, a bloated TypeScript codebase — have pushed many developers toward Hermes. One user noted that Docker support alone sealed the decision: "Just being able to docker it was enough of a benefit for me." Others point to Hermes's recent Honcho integration and a setup UX that multiple people described as surprisingly painless.

The harshest take came from @sudoingX, who has been publicly benchmarking small models on consumer GPUs and personally helping developers make the switch. In his read, OpenClaw's founder departing for OpenAI, a 125,000-line TypeScript codebase, and a sandbox that blocks tools that actually matter have compounded into a framework that struggles where Hermes thrives — specifically with small, locally-run models. He found a bug where small models couldn't use the MEDIA: syntax, meaning images never arrived. He submitted the fix. It was merged into Hermes the same day.

"You don't need a $4,699 DGX Spark to run an autonomous agent. You need a half-decade-old GPU sitting in your drawer and a framework that actually works from 7B to 70B." — @sudoingX

What Hermes Actually Is

Hermes Agent is Nous Research's open-source Python agent framework. It runs in your CLI and connects through messaging platforms — Telegram, WhatsApp, Slack, Discord. The architecture is built around a multi-level persistent memory system, agent-managed skills, and dedicated machine access that survives restarts. It's powered by OpenRouter and Nous Research's portal subscriptions.

What makes it unusual is the combination: it's not just a chat interface, and it's not just a coding assistant. It spawns isolated subagents, handles scheduled tasks, manages its own tool library, and runs well on hardware most developers already own. Eleven model-specific parsers mean small quantized models actually behave reliably — which has unlocked a new class of experiments on RTX 3060s and 3090s.

@LottoLabs published a detailed breakdown of Qwen 3.5 model tiers running on a 3090:

"27b: the 3090 GOAT imo. No drift, tool calls for days, writes and follows skills very well. Feels like Sonnet 3.6-4 range of knowledge with less glazing. Code is usable and handles multiple files in projects. A3b: fast, more general intelligence — feels like 9b speed but reasoning closer to 27b."

@sudoingX, who has emerged as an informal community guide for the migration, pushed the point further — framing this as a cultural shift, not just a tooling preference: running your own cognition layer, on your own hardware, with your own prompts. The infrastructure exists now. The consumer GPU in your drawer is enough.

What People Are Building

The builds emerging from the community illustrate the range. @glitch_ shipped an early prototype of a growth agent swarm — 11 specialized agents running in parallel with a shared knowledge base, model routing across five LLMs, and an experiment loop cycling at roughly $0.009 per full run.

https://t.co/GYYf1X3fYJ

@rodmarkun built a local anime server tool with full list sync, torrent management, scheduled downloads, and disk automation.

Did a small local anime server tool powered by Hermes Agent (@NousResearch). You can:
- fully sync your anime list
- download torrents from different sources
- add tracking & scheduled downloads
- auto-manage disk usage
- serve to any device within your local wifi

and more! pic.twitter.com/rzSLdmRETp

@WeXBT built PrediHermes: a geopolitical prediction system pulling 54+ OSINT modules and running multi-agent simulations against Polymarket contracts — fully AGPL licensed.

Built PrediHermes ✨

a Hermes Agent skill + companion WorldOSINT/MiroFish forks for geopolitical prediction.@NousResearch

It pulls 54+ OSINT modules, uses Polymarket to find contracts with clear resolution criteria, then runs MiroFish multi-agent sims to model individual… pic.twitter.com/hZFSJePRVT

What's notable is how fast Nous Research is responding. Co-founder Teknium is visibly engaged — commenting on builds, asking for feedback, integrating community contributions. Browser Use became an official Hermes browser backend after a community build surfaced it and earlier today, Teknium announced a HuggingFace CLI skill is on the way. This is what active open-source stewardship looks like in practice.

OpenClaw vs. Hermes: The Short Version

OpenClaw

Hermes Agent

Language

Node / TypeScript

Python

Small model support

Inconsistent tool calls

11 model-specific parsers

Execution

localhost process

Docker, SSH, Modal, local

Memory

File-based; can flush on restart

Persistent + auto-generated skills

Config hot-reload

Requires restart

Every message

Consumer GPU use

Limited

Tested on RTX 3060–3090

Community UX

More polished consumer UI

Developer-first, fast-improving

table is based on community reporting and developer testing

OpenClaw isn't dead of course, far from it. It still has a larger consumer ecosystem and a more polished UX for personal assistant use cases. If you want a plug-and-play assistant with minimal setup friction and aren't doing custom ML infrastructure, it may still be the right choice. But for developers who want to run local models reliably, extend the system in Python, containerize their setup, or build multi-agent experiments, the tradeoffs have clearly shifted.

Today, Cake Wallet launched self-custodial Lightning support designed for everyday users, bringing fast Bitcoin payments to mobile without requiring them to manage channels, liquidity, uptime or give up control of their funds.

For years, Lightning has promised instant, low-cost Bitcoin payments, but using it often required technical setup or reliance on custodial services. Many easy-to-use wallets relied on custodial models or trust assumptions, while fully non-custodial setups required users to manage channels, handle inbound liquidity, and stay online to avoid failed payments, making everyday use impractical for most mobile users.

With this launch, self-custodial Lightning becomes practical for everyday users.

Powered by the Breez SDK and Spark, Cake Wallet’s integration enables near-instant Lightning transactions without requiring users to manage channels, liquidity, inbound capacity, or constant online monitoring. Funds remain self-custodial by default, and users can move their Bitcoin back on-chain at any time. 

“Lightning has always been powerful, but the user experience forced people into a choice between convenience and sovereignty, we were not willing to ask our users to make that tradeoff.” said Vikrant Sharma, CEO of Cake Labs. “We waited until we could deliver Lightning in a way that aligned with our core principles: privacy, self-custody, and long-term user sovereignty. Now, with Breez and Spark, Lightning finally reaches a point where it can be fast and intuitive without turning bitcoin into an IOU or giving up control. This is the first time Lightning felt aligned with the principles Cake was built on.” 

Privacy by Default

Privacy is a core component of the release. Cake Wallet makes it easy to receive over Lightning without revealing a Spark address. Additionally, Spark transactions are not published to Spark block explorers by default. Users do not need to configure settings to maintain privacy.

“Lightning should not require users to sacrifice privacy or custody just to get speed,” said Seth for Privacy, VP of Cake Wallet. “What we have today makes Lightning practical with solid privacy defaults, simple self custody, and a clear on chain exit. That balance is what made it worth the wait.” 

Human-Readable Lightning Addresses

The update introduces custom Lightning addresses, allowing users to receive payments using a simple @cake.cash username instead of sharing invoices or complex payment details. Users can create a Lightning address immediately, without minimum balance requirements or hidden restrictions.

Real-World Spending via Cake Pay

Lightning is integrated directly with Cake Pay, enabling users to purchase prepaid debit cards and gift cards from popular brands using native Lightning transactions.

All your Bitcoin wallets in one app

For most Bitcoiners, managing long-term cold storage, on-chain transactions, and daily Lightning payments often meant using multiple applications. Cake Wallet now brings these functions together in a single app, combining on-chain Bitcoin, Lightning, advanced privacy tools such as Silent Payments and PayJoin, and broad hardware wallet support. Users can move funds from cold storage to Lightning seamlessly, without switching apps or manually copying addresses.

Instant Lightning <> crypto swaps

Users can move from a Lightning Bitcoin balance to assets such as USDT in seconds. The speed of the Lightning Network allows users to transition between Bitcoin and stablecoins more efficiently, supporting use cases such as payments, remittances, and everyday spending.

Simplified Lightning Without Giving Up ControlWith this integration, users do not need to manage channels, inbound liquidity, or stay online to avoid failed payments, making Lightning more practical for everyday mobile use.

Lightning support will roll out to Cake Wallet users in the latest update.

In early January, hackers drained over $200 million from a crypto wallet and immediately swapped the loot into Monero. Within four days, Monero's price jumped nearly 60% to a record high, driven partly by the buying pressure as stolen funds flooded in. For Monero's devoted community, this wasn't a scandal. It was validation that the system works exactly as designed.

New research from blockchain intelligence firm TRM Labs reveals a dramatic shift in darknet market behavior: 48% of darknet markets launched in 2025 accepted only Monero, nearly triple the share from three years earlier. This "continued structural shift toward XMR-only markets" is especially pronounced in Western-facing platforms, where privacy coins appear to be a direct response to improved tracing capabilities on Bitcoin and stablecoins.

The numbers tell a striking story. Despite facing delistings from major exchanges over recent years (Binance and Coinbase delisted Monero, while Kraken, KuCoin, and MEXC remain among the largest exchanges still listing it), transaction volumes in 2024 and 2025 were significantly higher than in the 2020-2021 period. Monero's price volatility is now roughly 2.5 times higher than Bitcoin due to thin liquidity and fragmented markets, yet usage hasn't contracted. This suggests demand isn't driven by casual trading but by users deliberately seeking Monero's privacy features and willing to accept higher friction to get them.

getmonero dot org

But that's about to get exponentially harder. A planned upgrade introduces "full-chain membership proofs," effectively increasing possible recipients from 16 to millions. According to Paul Sibenik, CEO of CryptoForensic Investigators, this change makes untangling transactions "more or less pointless." While Bitcoin and operates like glass houses where every transaction is visible, Monero is moving toward near-perfect opacity.

made by @VOSTOEMISIO and @xenumonero

This raises an obvious question: why Monero and not Zcash? Venture capitalist Balaji Srinivasan recently claimed on a podcast that the future was "Zcash or Communism," positioning Zcash as the privacy solution. Yet darknet markets have decisively chosen Monero. The difference appears to be usage patterns and defaults. Zcash offers optional privacy through "shielded" transactions, but only 30% of Zcash is currently shielded, showing that privacy isn't the default setting. Recently Cake Wallet did Zcash a huge favor by adding shielded Zcash by default. Monero's privacy is and always has been mandatory and built into every transaction. For darknet operators, optional privacy isn't privacy at all.

TRM Labs' research also reveals network-level vulnerabilities that complicate Monero's privacy guarantees. Around 14 to 15% of reachable peers in the Monero network exhibited non-standard behavior: irregular timing patterns, unusual handshakes, and concentrated infrastructure that suggests surveillance attempts. While Monero's on-chain cryptography remains intact, these network dynamics can introduce structural visibility that affects theoretical anonymity models used in investigations.

The tension is philosophical as much as technical. As Wall Street moves into crypto ($86 billion in Bitcoin now sits in ETFs managed by firms like BlackRock), the industry's libertarian origins feel increasingly distant. Tether, issuer of the USDT stablecoin, has frozen $4 billion in wallets tied to illicit activity and worked with law enforcement on over 2,000 cases. Blockchain analytics firms like TRM and Chainalysis work closely with authorities to trace criminal crypto flows.

Monero represents the opposite trajectory. Ari Redbord, TRM's head of policy, acknowledges the dilemma: "The challenge is how do we enable lawful users to have privacy and yet stop bad actors from abusing privacy enhancing technology?" This is where the problem lies. As with mathematics, you can't have it both ways. Either you have privacy for all or none at all.

With the upcoming upgrade locking in technical advantages that law enforcement can't reverse and darknet markets voting with their wallets, that question may already have its answer. Unlike centralized platforms, there's no CEO to pressure, no servers to seize, no company to sanction. This is what crypto's original vision actually looks like, for better or worse.

In January NASA published a new open-source artificial intelligence tool that they developed and says it is helping scientists around the world accelerate the search for planets beyond our solar system, a field known as exoplanet discovery. The software, called ExoMiner++, builds on previous successes to analyze data collected by NASA’s space telescopes and flag potential exoplanets for further study.

From Kepler to TESS: Open-Source AI in Action

ExoMiner++ is an upgraded version of NASA’s original ExoMiner model, which was designed to sift through data from the retired Kepler Space Telescope. The original tool played a key role in validating 370 previously unknown exoplanets by distinguishing real planet signals from look-alike false positives.

In its current form, ExoMiner++ has been trained on datasets from both Kepler and NASA’s ongoing Transiting Exoplanet Survey Satellite (TESS) mission, enabling it to process a much larger volume of observations. In an initial run on TESS data, the open-source software flagged approximately 7,000 exoplanet candidates, accelerating what would otherwise be a labor-intensive analytical process for astronomers.

Because TESS monitors nearly the entire sky for tiny dips in starlight caused by planets passing in front of their host stars, the mission generates vast amounts of data. ExoMiner++ uses deep learning and neural networks to sort through these light curves and predict which signals are most likely to represent real planets, allowing scientists to focus follow-up observations on the most promising targets.

Open Source for Open Science

Importantly, ExoMiner++ is made available as open-source software, meaning anyone with the skills and computational resources can download it from repositories such as GitHub and use it to conduct their own exoplanet analyses. This open approach aligns with NASA’s broader commitment to open science, which includes public access to the agency’s data and tools to support reproducibility and collaborative discovery around the world.

“Open-source software like ExoMiner accelerates scientific discovery,” said Kevin Murphy, NASA’s Chief Science Data Officer. By enabling researchers globally to leverage the same tools and algorithms, the open-source release of ExoMiner++ enhances the scientific community’s ability to make new discoveries using public mission data.

Enabling Global Research Collaboration

The open availability of ExoMiner++ has implications beyond exoplanet science. It highlights how transparent, community-accessible tools can democratize research — allowing universities, independent scientists, and student researchers to contribute to cutting-edge scientific work without needing proprietary software.

This model of open-source scientific software not only accelerates discovery but also enriches the educational landscape. Students and early-career researchers can learn from, adapt, and build upon real world tools used in active scientific inquiry, fueling innovation across disciplines such as astronomy, data science, and artificial intelligence.

Clive Dsouza is a seasoned technology professional with over a decade of experience spanning retail, insurance, banking, education, and IT. He specializes in developing scalable, high-performance software solutions using React, TypeScript, GraphQL, and cloud-based architectures, mainly front-end and back-end development.

Abstract:
This article proposes an event-driven microservice architecture designed to overcome the limitations of traditional monolithic, batch-processing data collection systems prevalent in the retail and financial sectors. These legacy systems are prone to significant data lag, leading to issues like inventory miscalculations and delays in fraud detection. The proposed architecture utilizes open-source tools, like Apache Kafka for event streaming and Apache Avro for optimized data serialization, to achieve near-real-time data collection with very low latency. By implementing decoupled, specialized microservices, the system ensures high throughput, fault tolerance, and independent scalability, enabling immediate data analysis and action. The result is a robust framework capable of managing the high volume and velocity of a large-scale digital ecosystem, providing instant operational insights and superior system resilience compared to conventional methods.

I: INTRODUCTION
Major US retailers and financial institutions often rely on traditional data collection systems that gather data from the front end, ingest it through batch processing, and deliver it to consumer storage platforms like GCP or AWS for analytical purposes.

In data-intensive retail or financial domains, these monolithic and batch-processing approaches commonly suffer from significant data lag. This leads to problems such as inventory miscalculations and delayed fraud detection due to the time it takes for data to reach downstream systems.

A practical solution is an event-driven microservice architecture that collects and processes data in near-real-time using widely available open-source tools.

II: EVENT-DRIVEN FRAMEWORK
This section provides an overview of the architecture and its core components.

Once data is sent from the front end, a lightweight ingestion system (e.g., built in Node.js) can handle incoming requests, validate for errors, and forward it to the next layer with minimal delay. A key element is data serialization/deserialization using Apache Avro, which ensures efficient encoding and decoding. An event-streaming platform like Apache Kafka provides a low-latency, fault-tolerant, high-throughput producer-consumer pipeline for real-time data flow. This data can then feed into big data systems like HDFS.

Subsequently, another ingestion tool like Logstash can ingest the data, apply transformations, and store it in a destination such as Elasticsearch—all with sub-millisecond to low-millisecond latency—making it immediately available for analysts to query in real-time using tools like Kibana.

Events are differentiated by their source (e.g., item details page, digital checkout cart, self-checkout terminals, inventory scanners). This allows multiple decoupled microservices to generate events using a shared base Avro schema plus child schemas tailored to specific use cases. Each microservice independently handles deduplication and data scrubbing, ensuring payloads adhere to organizational guidelines.

A separate set of microservices consumes events from the Kafka stream and applies specific business logic or transformations.

These consuming microservices are independently deployable and scalable. By subscribing to specific Kafka topics, they receive only relevant event data, maximizing decoupling and performance.

III: IMPLEMENTATION IN A LARGE SCALE ENVIRONMENT
This microservice architecture can be successfully deployed in a major US retailer's digital ecosystem, handling data from thousands of simultaneous endpoints—including e-commerce platforms, mobile apps, and in-store POS systems. Its distributed nature is essential for managing high data volume and velocity.

Key implementation strategies include:

1. Deployment Model: Containerize each microservice with Docker and orchestrate via Kubernetes for rapid deployment, configuration, and health monitoring across the cluster.

2. Schema Enforcement: Maintain strict governance over Apache Avro schemas using a dedicated Schema Registry to ensure producers adhere to contracts, preventing downstream failures and preserving data integrity.

3. Topic Segregation: Organize events into specific Kafka topics (e.g., user-cart-updates, inventory-scans, payment-attempts). This reduces load on individual topics and allows consumers to subscribe only to relevant streams, optimizing resource use.

IV: INDEPENDENT SCALABILITY AND PERFORMANCE
During peak events like Black Friday or Cyber Monday, the architecture enables independent scaling of components without affecting the rest of the system.

V: SYSTEM RESILIENCY AND FAULT TOLERANCE
The event-driven, decoupled design greatly enhances resiliency—failures in one service are isolated and do not cascade.

• Handling Service Failure: If a consumer fails, it stops processing its Kafka topic. Events remain safely queued in Kafka (with high retention and replication). Upon restart/redeployment, the service resumes from its last offset and clears the backlog without data loss.

• Decoupled Operation: Even if one service is down, others (e.g., Fraud/Anomaly Detection or Real-Time Analytics) continue consuming their streams and performing core functions uninterrupted.

• Consumer Idempotency: All consumers are designed to be idempotent—reprocessing the same event causes no duplicate effects (e.g., no double inventory deductions)—via transaction IDs and state management, ensuring accuracy during recoveries.

VI: CONCLUSION
This event-driven microservice architecture represents a significant advancement over traditional batch processing by minimizing data latency and maximizing resilience.

Its core strengths are near-real-time data delivery and extreme decoupling. Shifting to a Kafka-based event-streaming backbone with specialized, independent microservices makes data instantly actionable. This supports time-sensitive operations—like real-time inventory updates and rapid fraud detection—in low-millisecond ranges, directly addressing retail challenges such as inventory errors and delayed security responses. Docker/Kubernetes deployment and idempotent consumers further provide exceptional fault tolerance and scalability, allowing services to scale independently during spikes or recover seamlessly.

This real-time foundation enables advanced future capabilities:

• AI-Driven Web Components: Immediate user interaction data (e.g., clicks, views, scroll depth) from event streams can feed real-time ML models. Outputs can generate dynamic UI components based on in-session behavior using SSR frameworks like Next.js, optimizing conversions instantly.

• Dynamic Personalized Recommendations: Transaction and browsing events feed a real-time recommendation microservice for suggestions updated on the latest activity, cart contents, and inventory—moving beyond static, cached recommendations.

The Kingdom of Bhutan has announced plans to deploy and operate a validator node on the open-source Sei blockchain, in partnership with its sovereign wealth fund Druk Holding and Investments Ltd (DHI). The initiative, led by DHI’s InnoTech division and supported in part by Sapien Capital, is expected to go live in the first quarter of 2026 and reflects Bhutan’s expanding engagement with decentralized infrastructure and digital transformation strategies.

Sei is a globally accessible, open-source Layer 1 blockchain optimized for fast, low-cost financial transactions and decentralized applications. Validators are critical network participants that help secure the blockchain and validate transactions according to its consensus rules, making them essential for system integrity and trustless operation.

Strengthening National Blockchain Infrastructure

By becoming a validator, Bhutan aims to deepen its capability in blockchain infrastructure while creating new opportunities for data valuation, digital finance, tokenization, and scientific and technological innovation. The collaboration is part of Bhutan’s broader digital strategy, building technical capacity and local expertise in emerging decentralized technologies.

The Sei network’s open-source foundation means that all core software, consensus mechanisms, and development tools are publicly accessible. This transparency supports community participation, independent review, and collaborative improvement, making it possible for nations, research institutions and developers to engage without reliance on proprietary systems.

Why Would Bhutan look into SEI?

Validators contribute directly to a blockchain’s security and decentralization — two pillars of resilient distributed systems. For Bhutan, hosting a validator on an open-protocol network like Sei can yield several potential benefits:

• National technological capacity: Building local expertise in blockchain operations and governance.

• Economic innovation: Exploring tokenization of assets and novel economic incentives rooted in decentralized systems.

• Data and digital infrastructure: Participating in open, permissionless networks that can underpin future digital services and identity frameworks.

• Ecosystem integration: Positioning Bhutan to interoperate with global decentralized finance (DeFi), digital identity, and open systems while contributing to their continuous improvement.

The initiative aligns with other blockchain adoption efforts in Bhutan, where digital identity systems have also been integrated with public blockchains like Ethereum to promote transparency and citizen-centric services, demonstrating sustained engagement with open and decentralized technologies.

Researchers at Harvard John A. Paulson School of Engineering and Applied Sciences, as part of the inter-institutional Project CETI (Cetacean Translation Initiative), have developed an open-source bio-logger capable of capturing high-quality acoustic and behavioral data from free-swimming sperm whales. The technology is intended to support advanced analyses of whale sound patterns and behavior using machine learning and could broaden access to marine bioacoustics research. 

The bio-logger, described in a press release from Harvard SEAS, adheres non-invasively to the whale’s skin via suction cups and records multi-channel audio along with synchronized physical and environmental data, such as depth, movement, temperature and light. Designed with machine learning workflows in mind, the device collects large datasets of rhythmic whale sounds — known as “codas” — and contextual cues that may help researchers uncover structured communication patterns that are not apparent to the human ear. 

One of the notable strengths of this platform is that all hardware designs and software are open source, meaning the bio-logger’s components, code and deployment methods are publicly available for scientists worldwide to study, adapt, and improve. This open distribution is intended to lower barriers for marine biologists, acoustic researchers and interdisciplinary teams to participate in large-scale studies of cetacean behavior and communication. 

In early field deployments off the coast of Dominica in the Caribbean, the bio-logger has already collected rich audio and sensor data from deep-sea dives, where sperm whales can remain submerged for up to an hour. The robustness and multi-sensor capacity of the device enable researchers to gather detailed behavioral context alongside acoustic recordings, providing a much richer dataset for analysis than traditional tags that capture only vocalizations or simple motion data. 

Project CETI’s broader mission is to unravel complex aspects of whale communication by combining insights from marine biology, linguistics, robotics and artificial intelligence. The open-source nature of the bio-logger is a strategic choice to encourage community-driven innovation and extension of the technology to other species and research questions. As one team member noted, making tools and data openly available “democratizes … marine science” and lays the groundwork for collaborative, large-scale investigations into non-human communication systems.