Special thanks to Rohin Lohe at Cloudflare, Jennifer Ong and Kyle Corcoran at TollBit, Tim Conard and Cuy Sheffield at Visa, and Son Do at Parallel, for feedback and contributions.

On March 19th, 2026, Matthew Prince, the CEO of Cloudflare, the world’s largest content delivery network sitting at ~20% of the web, predicted that bot traffic, driven by the rise of generative AI, would exceed human traffic in 2027. Just a few months later, Prince announced that agentic traffic had grown so quickly that bots had already overtaken human traffic. Bots account for roughly 60% of HTTP requests for HTML content across Cloudflare’s network, compared with 38.2% from humans. As automated systems generate a larger share of HTML page requests than humans and AI agents account for a growing share of that machine traffic, the underlying business model of the internet is breaking.

The Bargain That Funded the Open Web

The world wide web has enabled unprecedented global democratization of information, a mission which has been funded by a straightforward content-for-traffic barter exchange, wherein publishers would publish content on the web, and search engines would direct readers to their sites if it matched what they were looking for. Publishers provided information or entertainment to the web in the form of content; search engines helped direct readers to relevant webpages; and advertisers would monetize the user visit by displaying targeted ads on the webpages users were led to. Together, this synchronized loop established the multi-billion dollar advertising machine that funded the open, paywall-free web.

The exchange funded a vast amount of freely accessible information while concentrating distribution power in search and advertising platforms. It rewarded behavioral advertising, SEO-optimized volume, and engagement-driven content, leaving publishers dependent on referral and attention-based traffic. AI is chipping away at the referral leg from an already fragile bargain before a replacement was ready.

Google's advertising revenue grew from $66.9 million in 2001, its first fully disclosed advertising year, to $294.7 billion in 2025, a factor of about 4,400.

The explosive growth of AI chatbot applications in recent years, however, has introduced a new paradigm for discovering information on the web. By design, these AI apps prioritize user convenience by keeping the audience within the chat interface itself. Though convenient for users, this feature has become particularly detrimental for publishers. While search engines directed readers to websites where the content they’re looking for originates from, AI applications instead condense and summarize the information and present it as part of their final response to a given user prompt. It becomes harder for publishers to monetize web traffic as they lose control of the direct user relationship and start to receive less human web traffic.

One emerging solution is to introduce new "pay-per-request" payments infrastructure for content and search on the internet. In this paper, we explore how AI is “breaking the internet”, the two distinct approaches to this solution, and what the state of the newly emerging pay-per-request web looks like today.

AI Crawlers And The Death Of The Barter

A search engine uses a crawler, an automated program designed to index webpages, to build a ‘map’ of the web. Under the traditional content-for-traffic model, publishers allowed these crawlers to copy their text for free because the search engine rewarded them by routing human readers back to their websites. To manage this access, the industry relied on a text file called robots.txt, an unencrypted, voluntary honor system. Robots.txt worked smoothly for as long as it did because defying robots.txt meant losing access to publishers’ content, which negatively impacts the search engine's index of the web.

Generative AI applications disrupt the web’s content-for-traffic barter exchange by turning crawlers from indexers into active consumers, which unfolds most evidently in training and real-time retrieval. During training, a large language model like GPT or Claude learns from a massive corpus of data scraped from the open web, which includes various books, articles, code, and art. The model trains on the totality of this human knowledge and serves it back to users with no link to the source and no payment to the creator. When retrieving information on the web in real-time to answer a user prompt, the model indexes the live web at the exact moment a user asks a question, pulls the relevant passage, and reformats it. Rather than handing the reader the original page, the model restates the information into a fresh, inline reply that answers the prompt entirely. A crawler indexes a page once, and the model can serve what it found to millions of readers, none of them ever carrying the reader back to the source.

The Impact

When taking the mechanics of extraction, alongside behavioral data, federal legal battles, and artistic exploitation, it becomes evident that the open web's foundation is experiencing a structural collapse, as the impact is already showing up across several interconnected domains.

The behavioral impact of AI crawlers can be measured by the ‘crawl-to-refer’ ratio: the number of pages a crawler scrapes versus the number of actual users it sends back. Data from Cloudflare shows that in the past six months alone, both training (43.9%) and training and search (41.5%) drove over 85% of identified AI crawler requests observed across Cloudflare’s network.Googlebot still runs nearly five pages for every visitor it sends back, 5.3 over the past year, which is more in line with historical exchanges, and every major AI platform sits one to three orders of magnitude above it. Over the past year, Anthropic’s ClaudeBot averaged 4.2k page crawls for every single visitor sent back to an origin site, Mistral 884, OpenAI 731, and Perplexity 147. Cloudflare does note that referrals from native apps don’t carry referral headers, so these ratios could overstate the imbalance. A Pew Research Center study found that when AI summaries intercept search queries, human click-through rates drop from 15% to 8%, direct click attribution with summaries drops to 1%, and users abandon browsing sessions entirely 26% of the time.

AI crawlers have also prompted legal action. In Bartz v. Anthropic, Judge William Alsup ruled that training on lawfully acquired books was fair use because the use was transformative, meaning it created something new rather than substituting for the books themselves, while the claim over the pirated libraries Anthropic had downloaded moved toward trial. Anthropic settled that claim privately for $1.5 billion, roughly $3,000 per work across some 500,000 titles. The outcome was widely read as a win for Anthropic, because the fair-use ruling on training stood and the settlement closed off statutory damages that could have run far higher. As the case settled, no court ever established what training on pirated content actually costs. Meanwhile the New York Times v. OpenAI and Microsoft case is still ongoing, forcing OpenAI to turn over 20 million ChatGPT conversation logs as part of an investigation into how closely models reproduce articles to substitute for paid subscriptions.

These cases highlight that the costs of the unmetered extraction of AI crawlers falls on independent creators and visual artists in particular. When OpenAI released its Studio Ghibli-style rendering capabilities in early 2025, it highlighted just how thin existing copyright protections are. Because U.S. law protects specific expressions of a work rather than its overall style, AI models can systematically clone an artistic aesthetic built over decades of human labor without naming or compensating the creators. OpenAI's policy blocks prompts for a living artist like Hayao Miyazaki, yet completely permits prompts for "Studio Ghibli”. A specific character like Totoro is protected, but the general Ghibli style is not, which leaves the artist with little legal ground even though the model could produce that look only because it trained on the studio's films. Pay-per-request infrastructure cannot resolve every harm described above. It can meter and compensate for future access to a work, but it cannot retroactively compensate artists for material already used in training or prevent a model from reproducing a style it has already learned. Those harms require separate licensing, copyright, and enforcement remedies.

In short, the two prominent responses to the breakdown of the content-for-traffic barter, litigation and private licensing, have been temporary stopgaps rather than scalable business models. Litigation has so far priced past scraping while leaving ongoing and future crawling untouched, and private bilateral licensing deals let large media conglomerates sell access to their archives directly to AI labs (e.g. OpenAI’s $250m contract with NewsCorp, or Google’s reported $60m-a-year deal with Reddit). Though expensive, a market survey found that most of these private deals amount to less than one percent of the licensee’s projected AI revenue. But negotiating such deals requires extensive financial and legal resources, which means the independent long-tail of the web, the millions of independent content creators, still have no way to deal with AI crawlers en masse.

It then becomes clear that the unencrypted honor system of robots.txt and the barter content-for-traffic exchange that supported the open web for thirty years, cannot withstand an internet economically optimized for data consumption over referral traffic, where crawlers are first-class consumers. Whereas in the past, publishers were happy to bear 100% of content production costs given they would capture 100% of consumer traffic and attention; generative AI consumes the content entirely with little to no attribution, effectively starving the producer of the human web traffic needed to generate ad or subscription revenue and leaving publishers to foot expensive hosting bills for bot scraping while receiving zero traffic. The squeeze runs in both directions at once. Serving a bot costs the same bandwidth and compute as serving a reader, but the bot leaves without viewing an ad or starting a subscription. At crawl-to-refer ratios in the hundreds or thousands, a publisher pays to serve thousands of requests for every visit it can actually monetize. Because publishers cannot afford to pay for servers just to have bots copy their text for free, the internet needs a new way to ensure creators get paid for what they produce. Since people are reading AI summaries instead of visiting websites, publishers can no longer make money from human attention alone. As a result, the point of monetization becomes the moment the AI bot actually scrapes the data, and the next logical step that follows is to introduce new web-native pay-per-request payment infrastructure.

The Pay-Per-Request Web

Scaling a pay-per-request model across the entire web requires a way to efficiently meter access to content and servers. While an increasing share of this activity is being driven by AI crawlers, the framework extends to any non-human interaction, including data feeds and automated APIs. Put simply, to access paid content, one piece of software must programmatically pay another piece of software, a process formally recognized as machine payments.

To support machine payments at scale, infrastructure companies build automated billing gates at the network routing layer to charge a bot at the millisecond of request. However, execution has mostly been divided into two distinct approaches, the gated marketplace, which requires registering a crawler for an account and a unique digital key to access a site through an intermediary routing proxy; and the *open protocol *model, designed around using standardized public software rules, machine-readable headers, and supports payment settlement across a wider range of digital rails.

The Gated Marketplace

The gated marketplace model treats web content as a private asset managed through a corporate intermediary. Under this framework, identity verification and access clearance are required before the machine payment itself. The publisher configures their network to redirect incoming AI crawlers away from the public, human-facing website and toward a secondary, dedicated web address managed by the marketplace provider. At this gateway, the platform checks the crawler's identity credentials against a database, evaluates the publisher's custom access rules, tracks usage, and formats the page into machine-readable text. Financial transactions occur outside of the internet protocol layer. When a bot makes a request, the marketplace logs the usage and meters it against a credit balance the AI company has funded in advance. Settlement then happens periodically in fiat through merchant platforms like Stripe Connect, since charging a card for every request would cost more in card fees than the request itself. Having an intermediary directly between the AI crawler and the publisher's origin server helps maximize security, shield the server from aggressive traffic spikes, and guarantee that only verified corporate partners gain entry, however a framework like this implemented at scale risks turning the open web into a network of permissioned storefronts, only further deteriorating the human user experience.

The initial wave of programmatic pay-per-view payment infrastructure for the web have been gated marketplaces, most notably that of TollBit and the first iteration of Cloudflare’s Pay-Per-Crawl. TollBit is a platform for managing, monitoring and monetizing AI agent web traffic; to deploy it a publisher sets up a specialized subdomain (e.g. https://tollbit.thedailydispatching.com/), and when an AI crawler has been detected attempting to access the main site, the server automatically redirects the crawler to TollBit’s subdomain where the crawler can only gain access upon paying. TollBit checks if the AI company has a registered billing account, logs how many pages the bot requests, and delivers the data in clean text formatting while processing the payments in US dollars. This requires an API key, so discovering the cost of content is not self-serve today: an AI developer has to register with TollBit first.

On July 1 2025, Cloudflare rolled out its initial Pay-Per-Crawl model. Cloudflare operates at the Domain Name System (DNS) and content delivery network levels, meaning it handles web traffic before it actually reaches a content publisher’s physical origin server. In Pay-Per-Crawl V1, Cloudflare integrated its edge-level Web Application Firewall (WAF) to automatically detect and block known AI crawlers across its network by default. When an AI crawler would request access to a domain protected by Pay-Per-Crawl, Cloudflare would intercept the request before it could reach the publisher’s webpage, and facilitate payment if the site owner chose to monetize its content.

Challenges With The Gated Marketplace

TollBit relies on developer API setups, proprietary keys, and traditional banking rails for payments. Routing pay-per-request transactions through merchant networks like Stripe introduces fixed transaction processing fees (typically around thirty cents plus a percentage of the total charge) which makes an individual, fraction-of-a-cent request in real time economically unviable. To circumvent this cost barrier, human developers need to manually register an account with the gated marketplace intermediary, generate unique API keys, and pre-fund a balance with a credit card or bank transfer from which the platform deducts fees over time. As such, agents and other autonomous software can’t yet independently discover and purchase data on demand; rather human administrators need to manually establish commercial accounts, monitor fluctuating balances across separate providers, and coordinate security keys.

Though keeping a human in-the-loop is an essential part of many AI-centric processes, using a gated marketplace model to manage access to web content at scale assumes predictable, linear web traffic patterns, which directly conflicts with the operational realities of modern software. AI agents and crawlers use reasoning loops to choose their own navigation paths dynamically, which depend on their given user prompt, meaning they frequently encounter unfamiliar domains containing the precise data needed for a task; stopping a task midway to require manual human onboarding can quickly bottleneck execution and consequently ruin the user experience. Flat-rate subscriptions are not the most efficient solution here either; AI agents operate whenever directed to, which often comes in unpredictable, concentrated bursts (e.g. someone may work on a research-intensive project for 3 days, then take a break for the next 2 weeks).

Between the upfront capital deposits and custom software integrations required to access protected content and data, the gated marketplace functions as a highly permissioned system. On one hand, web publishers receive controlled, verified traffic from established technology firms; on the other, the administrative and financial burden of managing pre-funded accounts across separate platforms restricts non-anonymous access, prevents spontaneous scraping by independent developers, and limits monetization opportunities for smaller publishers who lack high-volume enterprise traffic. In contrast, direct machine-to-machine financial handshakes allow publishers to attach a micro-fee to the text and data that would get requested by a crawler; this design concept forms the basis of the open protocol model.

The Open Alternative: x402 and MPP

An open protocol is a network architecture built on public, standardized communication rules. Much of the modern web was built on open protocols including HTTP, SMTP, and TCP/IP, which it still uses to this day. In recent years, the HTTP 402 status code, which had been reserved but inactive for over thirty years, has become a core web-native infrastructure component for supporting machine payments on open-source protocols using blockchain rails.

Bitcoin payments using HTTP 402 have been experimented with as far back as 2015, pioneering efforts including the 21co Bitcoin Computer and Lightning Network’s L402. In May 2025, the x402 protocol introduced stablecoins into the HTTP 402 flow for the first time, and efforts like Stripe x Tempo’s Machine Payments Protocol (MPP) support Bitcoin and credit card payments alongside stablecoins as well. The card option is designed for macrotransactions rather than micropayments, because fixed card fees swamp a fraction-of-a-cent request. Stablecoins remain the rail that makes pay-per-request pricing workable.

x402 embeds payment instructions directly into the data exchange code, eliminating the need for third-party account registration or proprietary clearinghouses. When an AI crawler requests a webpage, the host server natively responds with a machine-readable (payload header) embedded straight inside the connection metadata. The header provides the exact price per request, the designated payment network, and the receiving digital billing address.

Blockchains are playing an increasingly prominent role in facilitating machine payments because they provide an immutable, programmatic financial layer that operates at the same native speed and automation level as software logic. Crypto assets like stablecoins sit structurally close to the web as AI agents because they live through the same web-native infrastructure that AI agents and crawlers do, existing as software code that can be integrated via simple API endpoints and cryptographic signatures. Costs and fees for payments using blockchain rails remain significantly cheaper, often fractions of a cent per transfer on leading high-throughput chains, than credit cards and fintechs (though there are a growing number of fintechs actively seeking to close that gap, e.g. Wise).

Blockchain rails also provide cryptographic receipts and verification for each payment by design. Each pay-per-request loop provides a permanently stored receipt containing the buyer’s digital signature, the requested URL, and the exact timestamp. Because these instructions are stored on a public chain, any automated agent can parse the incoming metadata, execute a micro-payment using compatible assets (such as stablecoins), and download the content in a single continuous HTTP handshake. And whereas settlement on traditional banking rails requires several days to reconcile debits and credits between commercial bank ledgers via clearinghouses, blockchain settlement occurs as soon as a network’s nodes verify the digital signature and update the global chain state, which as mentioned earlier often occurs in seconds on leading chains. The open protocol approach, above all, standardizes web data access, allowing publishers of any size to monetize their assets and allowing any developer with a funded automated account to crawl without asking for prior administrative permission.

On June 15, 2026, Amazon Web Services (AWS) integrated the x402 protocol directly into CloudFront and its Web Application Firewall. This configuration allows roughly a quarter of the internet to activate automated agent billing straight from their existing cloud dashboards, delivering content to paying bots. Cloudflare followed suit: while its Pay-Per-Crawl V1 required Cloudflare to handle payments as the Merchant of Record through Stripe, the newer Cloudflare Monetization Gateway removes Cloudflare from the payment loop entirely, as payments route peer-to-peer into the seller's wallet.

The primary difference between the gated marketplace and the open protocol comes down to who is allowed to purchase access to web content. Under the gated marketplace model, access is restricted to a curated whitelist; an AI bot cannot buy content unless its parent corporation has manually signed a corporate contract and completed a background check with the intermediary platform. Under the open protocol model, access is entirely automated and unrestricted; any software program on the internet can instantly buy and download data, provided its automated billing account can settle the requested micro-fee on the spot. As both systems roll out across the internet's routing networks, publishers face a choice between two distinct infrastructure options. The gated marketplace model caters to enterprise organizations that prioritize strict security compliance, legal indemnification, and curated corporate partnerships. Conversely, the open protocol model serves automated workflows that require frictionless micro-transactions, allowing a diverse ecosystem of independent developers and publishers to exchange data programmatically without administrative hurdles.

What AI Crawlers Actually Encounter Today

To measure the actual footprint of the pay-per-request web, Shoal Research probed 108 major publishers and consumer websites as an AI crawler (GPTBot) on August 19, 2026. The sample has since been expanded from 108 to 500 domains. The results below describe the original August run. For each request, we recorded status codes, redirect chains, response headers, and challenge bodies, computing SHA-256 hashes to guarantee data integrity across collection runs. An endpoint was classified as x402-payable or agent payable if and only if its HTTP 402 response returned parseable payment parameters within a Payment-Required / X-Payment-Required header or a valid x402 JSON challenge payload.

Across the 108 publishers, the web divided into three main postures:

• Served for Free (49.1%, n=53): 53 domains served their homepages openly with an HTTP 200 OK, allowing unmetered extraction.

• Blocked at Perimeter (33.3%, n=36 combined): 31 domains returned HTTP 403 Forbidden, two required authentication (HTTP 401), two rejected content negotiation (HTTP 406), and one returned a legal block (HTTP 451). Three additional publishers timed out after repeated attempts.

• Returned HTTP 402 (14.8%, n=16): Exactly 16 publishers returned an HTTP 402 Payment Required status code.

Crucially, not a single publisher in the dataset returned an open, machine-payable challenge.

Of the 16 HTTP 402 responses, 10 redirected to a TollBit Bot Paywall, and six returned static HTML licensing contact forms. A secondary check using authenticated developer keys across all 13 TollBit-managed publishers in the baseline dataset returned HTTP 403 on every single rate lookup. The API payload explicitly stated that the content provider had disabled programmatic access and no price-per-scrape rate was returned.

One way to interpret these results is that TollBit is serving as an early AI partner for traditional publishers to test and understand pay-per-use billing for content, while still giving publishers the control and safety of managed access to agents. A system that requires manual developer registration, proprietary API keys, and corporate whitelisting is difficult to scale to an unprecedented amount of autonomous agents navigating dynamic web paths; rather it is an interim measure designed to protect legacy revenues while a permanent, machine-native settlement standard takes shape. It's early, and we think providers like TollBit are looking to understand, and formulate, how to balance the access, licensing, and autonomy that comes with this type of service.

We also pulled the complete Coinbase CDP registry on August 19 to map out who is actually using x402 and what services are live on the network which boasts over 15k endpoints where a few hundred are actively used.

Mainstream content publishers have not adopted x402 yet, but beneath that absence, a bustling supply-side market is already active. While consumer media is not quite actively integrated yet, developer tools, specialized data vendors, and proxy networks have rapidly deployed open machine-payment endpoints; the recognizable names from the x402 ecosystem include data APIs such as Tavily, Nansen, CoinGecko, Chainlink, Apify, and Browserbase, and more recently Ramp. Top service providers on x402 include names like ChatGPT, Claude, TripAdvisor, and Perplexity, but no major content publishers yet.

15,073 active endpoints suggest that software is actively pricing and selling programmatic access to other software on open public rails. Some institutions tracking the network report up to 50,000 endpoints once bundled marketplaces are included. However, the endpoints remain strictly specialized around scraping, AI tool-calling, and live data feeds; when cross-referencing this entire registry against mainstream consumer media and publishing domains (The New York Times, Reuters, ESPN, Wikipedia), the match rate was zero, which we expect to change slowly but surely as typically, it takes one big name to “get the ball rolling”. Web monetization shifts historically follow a single incumbent breaking “the status quo”; The New York Times rolled out the metered paywall in 2011; the Associated Press set the precedent for commercial AI data deals in 2023 that triggered a cascade from News Corp to TIME to Condé Nast; therefore we expect that when the first tier-one publisher prices its access on an open protocol (e.g. x402, MPP) we will see the rest of the market waste little time to follow suit.

Challenges With The Open Protocol Approach

The infrastructure for open pay-per-request protocols is operational, but the market itself remains nascent. The technical plumbing for open payments is actively being deployed: publishers have machine-readable rights frameworks like RSL, hosting and routing gates in AWS CloudFront and Cloudflare that can charge at the millisecond of request, and settlement rails from credit cards to digital assets and stablecoins, all universally accessible through protocols like x402 and MPP. The largest remaining hurdles for active adoption rest entirely on the demand side.

For starters, no major AI lab routes production crawler traffic through open machine payment rails for consumer web content, for which we see three main reasons. First, crawlers lack an integrated wallet, automated procurement budgets, and most importantly, a commercial obligation to actually pay for the content it is requesting. As shown by our crawler probe, much of the web is still completely ungated, which means an agent blocked by HTTP 402 can simply drop the URL and extract near-or-entirely-identical content from an open ungated competitor at zero cost. The legal environment reinforces this dynamic: under federal rulings like Judge William Alsup's decision in Bartz v. Anthropic, the courts established that ingesting lawfully accessible works to train an AI model is transformative fair use. While Alsup penalized the retention of illicitly acquired pirate datasets, training on content accessible across the open web carries zero copyright liability. Because extracting public web text is legally free, AI labs have no commercial incentive to voluntarily pay open micro-fees.

How AI Search Providers Are Approaching Compensation

Production adoption remains limited, but AI search providers are beginning to treat compensation as part of product design.

In an unpublished Shoal Signal interview, Son Do, a forward deployed engineer at Parallel, described Index, an initiative that works directly with publishers, measures how much each source contributes to an agent's final answer, and shares revenue with those sources. Do expects publishers and other data providers to move toward usage-based models, with agentic payment rails supporting large numbers of small transactions. Index shows that compensation is entering the design of AI search and retrieval products before it has become standard purchasing behavior across major AI labs.

Beyond the legal and economic lack of obligation, existing open payment protocols suffer from a simple structural flaw that is, metering the wrong part of the pay-per-request loop, metering the initial HTTP crawl rather than downstream inference, when the model synthesizes ingested knowledge to answer a user prompt. A sub-cent fee to fetch raw HTML does not compensate a creator if an AI model can absorb that reporting once and reproduce it across millions of user answers. While frameworks like RSL define pay-per-inference options, network-level gates like Cloudflare or AWS cannot inspect the latent weights of a neural network to cryptographically verify which training documents generated a specific output token. Cloudflare’s July 2026 pilots with Ceramic.ai and You.com highlight this exact technical bottleneck. The initiative attempts to move away from charging per crawl, testing a 'pay-per-query' model that compensates publishers only when their text is actually cited in a user-facing AI answer. While this correctly targets the moment where value is created, network edge providers like Cloudflare sit outside the AI's servers, meaning Cloudflare cannot independently verify which sources a model referenced during generation, and thus the system has to rely on the AI company counting its own citations and self-reporting how much it owes, reverting back into an honor system.

Another fundamental challenge to the open protocols is the fact that you can’t really stop an AI crawler from paying a microfee for content once, then writing the text to its internal cache or memory, and providing that data indefinitely. You also can’t stop an AI crawler from doing this thousands of times over and over across different websites and publishers. As Brendan Ryan, an MPP co-author at Tempo, argued in a Shoal Signal interview we conducted, a seller’s ability to charge depends heavily on whether its information is unique, current, and difficult to cache.

This limitation is most acute for the static creative work and reporting discussed earlier. Static text loses its economic value almost immediately after it is published, even if collected using retrieval mechanisms from AI tooling. Once an AI model reads an investigative piece, historical essay, or news article, that information is absorbed into the model's memory. The model can answer questions using those facts forever without ever visiting the original website again. Because of this, software tools that simply package public web text with an AI interface will see their profits disappear quickly, as rivals build identical scrapers over the same free information.

The underlying rule is then simple: static data loses its pricing power almost immediately, while dynamic and un-scrapable information stays payable. Because an AI model can read an unpaywalled article or historical report once and store that knowledge permanently in its weights, pay-per-request micro-fees cannot sustain businesses that rely on static text; ongoing payments only work for information that must be produced and verified continuously, which we believe comes down to three main categories of content:

First is live, ephemeral state, including real-time order books, sub-second financial pricing, breaking news telemetry, and IoT sensor feeds. An AI model cannot answer queries about the present state of the world from months-old training weights or a stale cache; it must issue a fresh, paid API request to an origin server at that exact second to retrieve current reality.

Second is proprietary offline data that never touches the open web. In private market intelligence, for example, historical funding rounds and executive moves published in press releases are quickly scraped and commoditized by low-cost rivals. The real pricing power belongs to providers that conduct primary, manual research, such as gathering non-public cap table terms, private deal valuations, and verified LP allocations directly through confidential relationships with fund managers. Because this data is never indexed on a public URL, automated crawlers cannot bypass the paywall or extract it for free.

Third is a distinct** human voice and brand reputation. **As media strategist Ashni Christ pointed out on Shoal Signal, a generic news aggregation feed that gets blocked or goes offline is instantly replaced by an identical automated scraper without any audience loss. However, when an authentic analyst, investigative journalist, or creator with an established viewpoint stops publishing, readers immediately notice and search for them. Live interviews, subjective analysis, and direct access cannot be pre-computed by an LLM, stored in an intermediary cache, or replicated from static training sets, leaving live feeds, private offline records, and personal perspective as the only assets that can reliably command a price.

Closing Thoughts

The internet is breaking, or so it appears.

To accelerate communication and coordination with each other, humans built and connected global networks of computers and software. Over the decades, every successive layer of technology aimed to make that exchange faster and more efficient, ultimately culminating in software built for mass automation. Generative AI put that automation power directly into the hands of hundreds of millions of people at once. But as automated software takes over the network, it is fundamentally altering how information is discovered, synthesized, and consumed. The most severe consequence of this shift is economic: it is no longer feasible to monetize web traffic through the same ad-impression and human-referral models that sustained the open web for the past thirty years; hence why we see the pay-per-request web forming now.

The two distinct existing approaches are a tale as old as time on the web: centralized, closed-source intermediaries, who offer fiat billing, turnkey compliance, and familiar enterprise onboarding, but also bring platform lock-in and permissioned gatekeeping; and open protocols, who offer permissionless access and programmable micropayments via stablecoins, though they still face gaps in enterprise distribution, inference attribution, and most importantly, actual publisher adoption.

Testing the state of the pay-per-request web for ourselves demonstrated that the infrastructure and supply side for open payment protocols is there. Open protocols like x402 are already actively facilitating functional markets for data collection, tool calling, AI inference, and live data feeds, but are still not supported by major online publishers. Platforms like TollBit currently are marketed as programmatic monetization marketplaces, but the data suggests publishers are using them as temporary solutions to block scrapers and funnel AI labs to private offline deals.

Which tells us that deciding whether it is gated marketplaces or open protocols that “win” is far from over. In fact, who even says it needs to favor one or the other? The future will most likely contain both approaches, serving different customers and different use cases. Stablecoins will be just as actively used as prepaid credits, subscriptions, and traditional invoices. The game is nowhere near as zero-sum as some may believe, or at least claim to believe. At least it won’t be for a while.

However, though the internet is at an inflection point and it’s tempting to make forward-looking predictions about where we go from here, it’s important to zoom out and remember the web has only been around for 30 years, and it has evolved continuously over those years. Whether the emerging pay-per-request web converges on gated marketplaces or open protocols for payment infrastructure, the possibility that further developments in the actively evolving, well-capitalized sector of AI render both approaches useless and instead lay the groundwork for a new, unexplored approach always remains. For now, we believe it is more likely that we see growth in adoption across open protocols and gated marketplaces simultaneously, serving different segments and different use cases. As with any forward-looking thesis, however, only time will tell.

The collapse of the old bargain may ultimately create a healthier web, at the same time, could increase the cost of information access for people worldwide who don't have the funds for pay-per-use or agents in the first place However, direct machine payments could give publishers a way to earn from machine use without relying entirely on advertising or platform-controlled referrals. The outcome will depend on whether these new rails remain open to independent publishers or become another layer of gatekeepers.

References

Amazon Web Services. (2026, June 15). AWS WAF announces AI traffic monetization. https://aws.amazon.com/about-aws/whats-new/2026/06/aws-waf-ai-traffic-monetization/

Attridge, M. (2026, May 14). Authors, publishers near final approval of $1.5 billion Anthropic copyright settlement. Courthouse News Service. https://www.courthousenews.com/authors-publishers-near-final-approval-of-1-5-billion-anthropic-copyright-settlement/

Bartz v. Anthropic, Order on fair use (N.D. Cal. June 2025). https://copyrightalliance.org/wp-content/uploads/2025/06/Bartz-v.-Anthropic-Order.pdf

Bloomberg Law. (2026, January 5). OpenAI must turn over 20 million ChatGPT logs, judge affirms. https://news.bloomberglaw.com/ip-law/openai-must-turn-over-20-million-chatgpt-logs-judge-affirms

Chainalysis. (2026, June 3). Inside x402: 100M agentic payments on Base. https://www.chainalysis.com/blog/x402-agentic-payments-adoption/

Chapekis, A., & Lieb, A. (2025, July 22). Google users are less likely to click on links when an AI summary appears in the results. Pew Research Center. https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/

Christ, A. (2026, May 4). New media in the age of AI: TBPN, OpenAI, and media defensibility (Episode 5) [Video podcast episode]. In G. Tramble (Host), Shoal Signal. https://x.com/Shoalresearch/status/2051350822332801086

Cloudflare. (2025a, July 1). Cloudflare just changed how AI crawlers scrape the Internet at large [Press release]. https://www.cloudflare.com/press/press-releases/2025/cloudflare-just-changed-how-ai-crawlers-scrape-the-internet-at-large/

Cloudflare. (2025b, July 1). Content Independence Day: No AI crawl without compensation. https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/

Cloudflare. (2025c, August 29). The crawl-to-click gap: Cloudflare data on AI bots, training, and referrals. https://blog.cloudflare.com/crawlers-click-ai-bots-training/

Cloudflare. (2025d, July 1). Introducing pay per crawl. https://blog.cloudflare.com/introducing-pay-per-crawl/

Cloudflare. (2025e, July 1). Introducing pay per crawl (private beta) [Changelog]. https://developers.cloudflare.com/changelog/post/2025-07-01-pay-per-crawl/

Coinbase. (2026, June 15). Coinbase and AWS let publishers accept agents as customers via x402. https://www.coinbase.com/blog/coinbase-and-aws-let-publishers-accept-agents-as-customers-via-x402

CoinDesk. (2026a, May 5). AI agents are breaking web economics, but Cloudflare says x402 can help. https://www.coindesk.com/tech/2026/05/05/ai-agents-are-breaking-web-economics-but-cloudflare-says-x402-can-help

CoinDesk. (2026b, March 11). Coinbase-backed AI payments protocol wants to fix micropayments but demand is just not there yet. https://www.coindesk.com/markets/2026/03/11/coinbase-backed-ai-payments-protocol-wants-to-fix-micropayment-but-demand-is-just-not-there-yet

Conroy, M. (2026, July 1). Making AI search smarter. Cloudflare. https://blog.cloudflare.com/making-ai-search-smarter/

Fast Company. (2025, March 28). OpenAI's Studio Ghibli-style images renew the debate over AI and copyright. https://www.fastcompany.com/91308222/openais-studio-ghibli-style-images-renew-the-debate-over-ai-and-copyright

The Independent. (2025, March 27). ChatGPT's viral Studio Ghibli-style images highlights AI copyright concerns. https://www.independent.co.uk/news/studio-ghibli-hayao-miyazaki-openai-chatgpt-los-angeles-b2722945.html

Montclair State University, College of Communication and Media. (2025, April). Social media study of the Studio Ghibli AI trend. https://www.montclair.edu/college-of-communication-and-media/wp-content/uploads/sites/20/2025/04/Montclair-Social-Media-Study-Ghibli-AI.pdf

News Corp. (2024, May 22). News Corp and OpenAI sign landmark multi-year global partnership [Press release]. https://investors.newscorp.com/news-releases/news-release-details/news-corp-and-openai-sign-landmark-multi-year-global-partnership

Quartz. (2026, May 27). The price of AI training data, from $5M to $250M. https://qz.com/ai-training-data-pricing-licensing-deals-market-052126

RSL Collective. (2025, December 10). RSL AI Licensing 1.0 now an official industry standard [Press release]. https://rslstandard.org/press/rsl-1-specification-2025

Ryan, B. (2026). Conversation on machine payments and content defensibility [Forthcoming interview]. Shoal Signal.

Shin, L. (2026, March 30). Machine economy 2030. Artemis Research. https://research.artemis.ai/p/machine-economy-2030

Shoal Research. (2026, September 9). x402 and publisher content access, 108 publishers expanded to 500 [Data set]. GitHub. https://github.com/shoalresearch/x402-publisher-study

Stripe. (2026). Introducing the Machine Payments Protocol. https://stripe.com/blog/machine-payments-protocol

Tempo Labs, & Stripe. (2026, March 30). The payment HTTP authentication scheme (Internet-Draft No. draft-httpauth-payment-00). https://github.com/tempoxyz/mpp-specs

The Arc

For all the lessons that have been learned in the rapid development of AI in recent years, the most important one is that computer intelligence is, above all, a function of its data. Today’s frontier models and their capabilities exist because a handful of labs built an enormous training-data engine to feed them, on top of an abundance of raw text freely available on the internet. Training data is now a key constraint in the field of robotics as well, the key difference being that robot training data requires tasks to be physically performed and recorded by humans. There is no corpus of training data that robotics developers can scrape yet, and because the training data is that much harder to get, it becomes that much more valuable. In this paper, we lay out why we believe the data layer is the most valuable opportunity in robotics today, and what kind of business is best-positioned to capture this opportunity.

Intelligence and Data

In the seventy years computers have been around, getting one to actually perform a task was usually a task of its own. Someone had to first write out every step in an order the machine could follow, which perfectly suited work that was already built around some sort of fixed, precise procedure. People had been doing math, keeping records, and balancing accounts for centuries, but a computer could do the same sequence faster. Automation reshaped job functions and entire industries but largely remained limited to single tasks, and more importantly, everything a machine did had to be written out by someone first.

Today, machines can write coherent prose, answer specific and open-ended questions alike, and turn plain-language descriptions into code and production-ready applications. This foundational transformation came from changing what kind of instructions a machine is given and how they are given. Though tasks still start with instructions, the capability of a machine when given instructions has significantly evolved. More importantly, the instructions themselves have become far more intuitive and simple, particularly because they could be reduced from detailed specifications to simple sentences.

Importantly, transforming the capabilities of machines required transforming their inputs first. Rather than being given precise instructions on how to do a specific task, machines were given a lot of different examples of tasks being performed, and learned by observing those examples. Rather than teaching a model how to write a sentence, the model processed enough sentences that it learned the task on its own. Instead of teaching a model how to write code, the model processed enough working code to learn how to actually produce it. Instead of teaching a model how to translate two specific languages, the model processed enough translated text that it learned how to do so on its own.

To better illustrate this distinction, consider a calculator and ChatGPT. A calculator performs large and complex operations, provided those operations involve numbers and stay within its defined parameters, but is useless if asked to write an essay. A language model can be used as a calculator, and it can also write the essay, search the web, produce working code, and plenty more. The key difference is the training data. The pattern that lets a machine answer a question it has never seen can only be learned from real examples, therefore the more examples an AI model trains on, the more of the world's structure it captures, and the more it can consequently do. The same mechanism is set to take place in the physical world with robots, so it helps to first understand how it unfolded within software.

The Paradigm Moment

In 2020, OpenAI released GPT-3, and a few years later the world was introduced to ChatGPT, which to many was the first application that actually resembled some form of reasoning. ChatGPT answered a wide range of questions, wrote essays, translated languages, and produced working code, often from nothing more than a short prompt. These capabilities struck a chord, as ChatGPT reached one million users in five days and roughly 100 million monthly users within two months of launch, marking the fastest adoption of a consumer application recorded at the time.

Though ChatGPT initially ran on GPT-3.5, the unlock traced back to GPT-3, made possible by the unprecedented scale of its training data. GPT-3 was the third generation of the same underlying GPT model, each generation scaling the parameters of its predecessor by roughly an order of magnitude. For reference, parameters are the building blocks that support a model's core function of identifying and reproducing patterns, so more parameters means more capacity to do so. GPT-1 held around 117 million parameters, GPT-2 around 1.5 billion, GPT-3 175 billion.

Each jump in parameters sought to remove tedious parts of AI model training that were previously thought essential. GPT-1 demonstrated that language ability learned from raw text could transfer to specific tasks with far less task-specific data than starting from scratch. The model was first pre-trained on large amounts of unlabeled text to predict the next word, then fine-tuned on a smaller labeled dataset for each specific task.

Fine-tuning was the tricky part since every new task still needed its own round of fine-tuning and its own labeled examples, therefore GPT-2 tested whether fine-tuning was necessary at all. The idea was that a language model trained on enough varied text is already a multitasker that is capable of handling tasks it was never fine-tuned for, because the training text is full of them. Testing this capability meant scaling up the GPT model’s inputs, so OpenAI raised the parameter count more than tenfold, to 1.5 billion, and trained on a larger, more diverse web corpus. The largest version reached state-of-the-art results on seven of eight language benchmarks with no fine-tuning at all. Scaling the model, on its own, had removed a step that was supposed to be essential.

GPT-3 pushed the same bet even further, training 175 billion parameters on about 300 billion tokens of text (a token refers to a chunk of a word) drawn in weighted proportion from filtered Common Crawl, WebText2, two book corpora, and English Wikipedia. With such a dramatic shift in size, capability improved accordingly. GPT-3 could perform a new task from a few examples placed directly in the prompt, with no fine-tuning required.

Though the capabilities of today’s models have well outpaced GPT-3, the model remains a pivotal moment as it laid the groundwork for GPT-3.5 and ChatGPT, and kicked off an AI boom that has reshaped the industry in the years since.

Intelligence Follows Data

Frontier labs, the companies and research organizations building the most advanced models from scratch, OpenAI and Anthropic among them, have actually put those models into production and into the hands of hundreds of millions of users worldwide. In doing so, they’ve drawn tens of billions of dollars in investment and are on pace to become some of the most valuable companies in the world. While a lot of their success is often attributed to the researchers they recruit and the vast computing power they own, none of it would be possible without the massive amount of data their models were trained on.

As GPT-3 demonstrated, building anything resembling the capabilities of a frontier AI model requires a great deal of training data. This is where it’s important to note that not all training data is the same. Raw text scraped from the internet is free and abundant, and can teach a model how language works, what words tend to follow others, how arguments are structured, which facts appear where. Models trained on that scraped corpus grew more capable as the corpus grew in size, and eventually began to generalize to tasks no one had built them for. GPT-3 translated between languages, unscrambled words, and did basic math though it was never trained for any one of those specifically. In fact, GPT-3 had actually beaten XLM, Facebook's leading cross-lingual model, on French-to-English translation, despite never being trained on paired French-English text and working from only a few examples placed in the prompt.

There is a reason models aren’t trained only on scraped text, however, as such models often produce answers that sound convincing whether or not they are correct or helpful. Improving accuracy requires human judgment about which of the model's answers are actually good. A person is shown a prompt and two answers the model produced, and either marks which one is better, reads an answer and corrects its errors, or writes from scratch the answer the model should have given. Each of these judgments becomes a training example, and the model is tuned to prefer outputs like the ones humans preferred, a process known as reinforcement learning from human feedback (RLHF). These judgments are a different and more valuable kind of training data than scraped text, and a more expensive one, since each example must be produced by a person rather than collected from the web. The harder the question, the more qualified the judge must be: a model's answer about tax law should only be graded by someone who knows tax law, so suppliers recruit doctors, lawyers, and engineers to evaluate outputs in their fields. Producing this data at frontier scale is difficult, slow, and expensive. Refining a single model involves hundreds of people over months at costs reaching tens of millions of dollars, and frontier labs spend billions annually.

Models trained on these examples of complete work are more capable of planning a task, carrying it out step by step, and correcting themselves along the way by learning from their prior gathered experiences, and are what we call agents. Agents have become productivity and learning tools at large, and for the frontier labs they have become the fastest-growing product line to date. ChatGPT now serves more than 900 million weekly users, and OpenAI’s revenue run rate hit $40 billion for 2026 after taking in roughly $5.7 billion in the first quarter. Its coding agent, Codex, passed 5 million weekly active users in June 2026, more than six times what it had when the standalone desktop app shipped in February. Claude Code, an agent that performs software engineering work, reached $1 billion in annualized revenue within six months of launch and passed $2.5 billion by February 2026. Anthropic's annualized revenue reached $65 billion over the same period, up from about $1 billion at the start of 2025. In a survey of over 500 US technical leaders conducted by Anthropic and the research firm Material, 86% said they deploy coding agents for production code, and 42% trust them to lead development work under human oversight.

The initial rapid growth of leading AI applications was driven by the breakthroughs in new sectors it was applied to. Every task an agent can currently perform happens on a computer, and though a lot of the world runs on computers today, most of the world and its labor is physical.

The Next Substrate for AI Is Physical

Robotics startups raised $18.8 billion globally in the first half of 2026, up from $15 billion raised in all of 2025 and past the previous full-year record of $14.1 billion set in 2021. SoftBank agreed to acquire ABB's robotics division for $5.4 billion, describing physical AI as its next frontier; Meta acquired Assured Robot Intelligence to train its own physical-AI foundation model; Unitree was recently approved for a Shanghai IPO. Deployments have begun alongside the deals; for instance BMW starting pilot production work with humanoids at a German plant; Japan Airlines putting humanoids on baggage handling at Tokyo's Haneda Airport.

Yet robots have worked in factories since 1961, when the Unimate arm was installed on a General Motors die-casting line in Ewing, New Jersey. The Stanford Research Institute built Shakey, the first mobile robot able to reason about its own actions rather than execute a fixed sequence, between 1966 and 1972. Waseda University completed WABOT-1, the first full-scale humanoid, in 1972.

So why the sudden rise of funding and attention now?

1. A robot now has something to think with. A robot has to decide what to do before it can do anything, and deciding requires knowing many little details about how the physical world actually works. Language models absorbed a lot of this information from internet text , so a robot can now use one as a brain. But a language model deals with software and outputs words, and a robot deals with the physical world and its output is motions. Vision-language-action (VLA) models emerged as a solution to bridge the physical and software worlds by taking what a robot’s camera sees and the instruction it was given and returns the actual joint movements. Practically, this means robot developers no longer need to write custom code for each unit to only perform a single task at a time, and can operate closer to an AI application given a task in simple plain language to then work out the motion in real time.

2. The body of a robot got cheaper. A robot sees using cameras and using LiDAR, which fires laser pulses and times how long they take to come back to build a map of what's around it. A LiDAR unit was largely considered prohibitively expensive a decade ago, but phone makers and carmakers then started buying the same sensors in bulk, which drove the price down for everyone, robotics companies included. The costs of motors and joints came down separately, as Chinese manufacturers moved into parts that had been made in small numbers by a handful of Japanese and German firms. A humanoid built from Chinese components now costs around $35,000, and Unitree sells its G1 humanoid at $13,500.

Greater intelligence and cheaper hardware are critical to the advancement of robots and their capabilities, but just like AI models, everything first depends on the underlying training data. To understand why this data is so valuable, it helps to first refresh on what robots actually are.

Understanding Robots

Formally, a robot is an autonomous machine that can sense its environment, think and make decisions, and perform actions in the physical world. In simpler terms, a computer with a physical body.

Nearly all robots are built from the same components, each with a biological analog to a human body. The bones, usually metal, are made up of rigid segments called links. Links are connected by joints, which facilitate movement. Sensors make up the machine’s sensory organs, which includes both* proprioceptive* sensors to measure the position of the robot’s own links, and* exteroceptive* sensors to measure the robot’s environment. Actuators, most commonly electric motors, function as the robot’s muscles, delivering force to the links through transmission (such as gearing) to increase force while proportionally reducing speed for the limbs to produce slow, strong movements. Copper wiring then delivers power to the actuators, while signal travels back the other way through a data bus, a shared line that every joint and sensor connects to, each message tagged with the address of the part that sent it. Power arrives either through a cable to the wall, as on most factory arms, or from a battery the robot carries.

A feedback loop then binds together these various physical parts to enable the robot to actually perform physical operations, record the process, and improve upon its learnings. More precisely, the robot’s software receives information from the sensors, processes it to determine what to do next, and sends commands to the actuators, which apply force to whatever is in front of them; the sensors then read the result, and the loop closes. Roboticists call this the sense-plan-act framework: find out what is happening, decide what to do, make it happen, and learn from each observation.

Sensing and acting are hardware-based functions, so how well they run depends on the parts available and what they cost. Planning, on the other hand, is software-based, and largely depends on the availability and quality of training data.

Understanding Robot Training Data

A robot learns how to do a task from recordings of that task being performed, each of which pairs two synchronized streams: 1) what the cameras and sensors registered, and 2) what motor commands were issued in response at that same moment. From enough of these pairs, the model can start to map together how to go from seeing tasks being done to doing them.

Programming this process worked fine with a single stationary task where the motion can easily be written out once and repeated (consider how a robot arm placing stamps on a factory line meets the same panel in the same position at the same moment). But any task with some degree of variance and uncertainty (which most things in life tend to be) makes this more complex, particularly because there are plenty of subconscious decisions being made in real time, most of which are only learned from experience and intuition (nobody thinks how hard to pinch a shirt or how hard to close a hand around a mug to pick it up). Therefore rather than trying to describe that subconscious knowledge into a specification, robotics developers capture it by recording the task being done live.

A robot’s model (its brain) needs to answer a simple straightforward question: based on what the cameras and sensors are showing right now, what should the motors do next? Camera images along with readings from the sensors in the robot’s joints and fingers are shown together with the exact motor commands a competent performance produced at each moment. The internet contains a vast supply of video content, but most lack these two specific requirements a robot needs in order to learn from. There are several different ways to produce and collect robotics training data today.

Teleoperation: A human controls the robot directly and performs the task through the robot's body, using motion-tracking equipment or controls that mirror the robot's arms, while the system records what the robot saw, what its joint sensors measured, and what motor commands the operator's movements generated.

Motion Capture: A person performs the task wearing tracked markers or a sensor-equipped suit and gloves, which produces precise 3D trajectories of the body and hands that are then retargeted onto the robot's joints.

Egocentric Video: A head-mounted camera records a person doing tasks with their own hands, and software processes the footage afterward, estimating hand and finger positions frame by frame and translating them into equivalent robot motions.

Synthetic Data: A simulated robot attempts the task in a simulated environment, and the attempts are recorded as training examples.

It’s important to note that a model trained only on demonstrations runs into a ceiling inevitably, because most demonstrations only show the task going well, so the model never sees a mistake and never learns what to do when encountering one. The common solution is to turn data production into a loop itself, known in formal robotics terms as DAgger (Dataset Aggregation), a form of interactive imitation learning. Human demonstrations train an initial model, the robot then attempts the task itself, and when it makes a mistake, a human operator takes over through teleoperation, corrects the mistake, and hands control back to the robot, while the correction is incorporated into the robot’s training data for future reference. Robotics teams generally aim to end with the robot practicing on its own, its attempts scored against a defined set of rules in order to reinforce successful behaviors, though in practice today most of the work is still in the earlier stages with a human closely involved in the loop.

The training loop’s output is what we can call a robot “brain”: a trained model capable of taking in what its cameras and joint sensors report at a given moment, and returning the motor commands that come next. Models today are sold in three grades, each with varying levels of autonomy for the robot.

The first grade is the skill model, the narrowest model, which is produced by running the training loop to perform a single task, with slight variance across its environments. While it sounds similar to factory-line robots purpose-built for a single repeated motion, a skill model learns how to perform its sole task across different conditions (e.g. performing the task in a different position, or using different lighting). Second is the autonomous model, which chains together different skill models into a complete job, and handles the decisions between each step, invoking each individual skill model as needed. The third grade of model, what is widely accepted as the ‘frontier’ today, is the vision-language-action model, or VLA: single trained system that combines seeing, understanding an instruction in ordinary language, and acting on it. The design borrows from language models, and in several leading implementations actually implements them: a large vision-language model, the same kind of system behind a chatbot, handles the slow high-level reasoning of understanding the scene and planning what to do, while a second, faster component turns that plan into continuous motor commands many times per second.

Because a VLA inherits general knowledge from internet-scale pretraining, it arrives already knowing things nobody taught it, which changes how new capability gets added. A skill model knows nothing outside its task, so a new task means building it from nothing, demonstration by demonstration. A VLA can be given the task in ordinary language and already has some grasp of the objects and the goal, so its demonstrations only need to supply the physical technique rather than the technique and the objects and the concept of the task all at once.

The Data Bottleneck

Every method of producing this data shares the same underlying constraint, which is that a physical performance still needs to happen for the data to exist in the first place. A demonstration takes as long to record as the task takes to perform, and for that entire time it occupies a robot, workspace, and human operators. When language models needed more data, AI labs turned to more web crawling and hiring more human data labelers, whereas when a robot needs more data, the solution requires more robots, more human operators, and more hours in the warehouse.

Models do transfer some general ability across tasks, but performing a new task reliably still tends to require demonstrations of that specific task, and every task comes with variations (e.g. different objects, layouts, lighting etc) which all need their own coverage. Therefore it’s difficult to imagine demand for demonstrations slowing down any time soon. Models may eventually pick up new tasks from a handful of examples the way language models did, but as GPT-3 and its successors demonstrated, a step-function change in capabilities can only come from an exponential increase in training data and inputs.

The Big Opportunity In Robotics Is the Data Layer

Robotics startups raised more in the first half of 2026 than in all of 2025, which was itself a record. The gap between enthusiasm and reality, the demand for robotics vs their actual capabilities today, is still rather wide. Simply put, there’s plenty of demand for robots, but today’s robots are still not very good just yet. Robotics developer Unitree shipped more than 5,500 humanoids in 2025 per company filings, the highest volume in the world, meanwhile the marquee industry deployments at names like BMW, Mercedes, Amazon, are all pilots involving just a few dozen machines. An industrial buyer needs a machine that works 95-99% of the time, and the current humanoids work for 30-90 minutes before they need a recharge or a person to step in. Robot hands cannot reliably handle objects that vary, and their brains, despite all the advances in frontier lab models over the past several years, still get confused by the variance and unexpected intricacies of physical reality.

The first three GPT models established that the most effective way to close a capability gap is to give a model more high-quality data. The caveat here is that the data these language models needed is already largely abundant, thanks in no small part to humans recording and documenting history for centuries. The data a robot needs is multimodal, time-synchronized, and physically captured, which means it cannot be scraped the way text can and has to be manufactured by people operating robots and recording rigs. The labeling does not parallelize the way text labeling does either, because judging whether a plate was placed securely or precariously takes physical intuition rather than pattern matching, so the annotation workforce cannot simply be scaled out to thousands of remote workers.

Everyone building robots, from the robot makers and the model labs alike, needs this data, but there is no shortcut to acquiring it. What exists in public datasets rarely transfers to a specific robot, and producing data in-house means running warehouses, fleets, human operators, and incurring all of the associated costs. Something similar already played out in software, where frontier labs needed human judgments and expert-written examples that were not sitting on the internet, and the suppliers who produced them (e.g. Scale, Surge, Mercor) grew into a category with roughly $8.5 billion in revenue.

The Path Forward Is Vertical

A useful comparison is chip manufacturing. Designing a chip and building one are separate businesses: the design is intellectual property, while the factory that etches it into silicon costs tens of billions and only pays off if it runs near capacity. So most chip companies stopped owning factories; Nvidia, Qualcomm, and Apple all design chips and manufacture none of them, leaving that to TSMC, which builds nothing of its own and now makes nearly all of the world's most advanced chips.

The robotics data layer is valuable but it’s not so easy to occupy, let alone succeed in. A demonstration recorded on one specific robot’s body, and its associated dataset, cannot be transferred over to another robot, which means a data vendor has to rebuild its product for every individual customer. And as we mentioned earlier, there is also a limit to what demonstrations alone can teach, since they show the task going right; the model still has to learn what to do when it goes wrong (and a human operator is often required to intervene in training). A customer looking for robotics training data isn’t as interested in the raw data as they are in the ability to keep making the data as their robot changes. This requires 1) robots to record on, 2) real work for those robots to do, and 3) a pipeline carrying each failure back into the next model. There is now a unique opportunity for a business, by owning all three components, to own the training data layer for robotics.

Eastworlds

One team actively working on capturing this emerging opportunity is Eastworlds, the new robotics division of Virtuals Protocol. In practice, Eastworlds is a neodeployment robotics lab and accelerator for robotics and embodied AI startups. The team operates from Kuala Lumpur, and runs the largest fleet of Unitree G1s in Southeast Asia (30+) with research partnerships with universities including Carnegie Mellon University and Nanyang Technological University.

The Eastworlds’ business model revolves around robot data collection and neodeployments. Data collection covers teleoperation and gripper data, video, proprioceptive, action capture, dataset review and QA, as well as policy improvement datasets, including human corrections and the associated recovery data. Alongside data collection, Eastworlds also specializes in neodeployments, which involves placing robots into commercial settings that have never used them before, where the machine does paid work under teleoperation while the work itself produces the recordings. The customer buys labor, while generating data for Eastworlds.

Autonomy for robots, as we mentioned earlier, is not ready yet and a business owner will not put a robot that might fail near their goods or their customers. By contrast, a teleoperated robot is reliable enough to sell today because the reliability comes from the human operator rather than the model. The fastest route to a commercial contract is therefore to sell the teleoperated version of the job now, which is what Eastworlds built: a low-latency teleoperation that lets an operator in Asia control a humanoid in the United States or Australia. In early 2026, Eastworlds started rolling out pilot programs with hotels, malls, security, shelf-stocking, and hydroponic-farm work per Virtuals founder Jansen Teng.

Every deployment generates data, typically unstructured and heavy on edge cases since it comes from live operations, captured as egocentric teleoperation data, multi-modal sensory inputs, and task execution feedback, and accumulated in what the company calls its Embodied AI Data Lake. In the near term that data retrains the models running the fleet, so each robot fails less at the job it is already doing, and over a longer horizon the accumulated dataset becomes training material for next-generation VLA and world action models, carrying the G1 fleet from teleoperation toward full autonomy.

Eastworlds also runs an incubator, funding vetted teams and giving them month-long access to a robotics fleet, facility, and teleoperation stack, with each team pursuing its own commercial use case. Seven teams were in residence according to Teng, working across entertainment, oil and gas, grocery, and hotel management, with capacity planned for more than twenty. Each team runs its own deployments on the shared fleet and surfaces its own failures and fixes, and both the learnings and the data flow back into the Data Lake, which applies the same mechanics driving Virtuals' agent ecosystem to robots.

Eastworlds integrates Virtuals Protocol's onchain infrastructure to handle the economics of its data operation. Eastworlds operates through a distributed business model, involving thousands of hours of recording and teleoperation, performed by many people in many places, with quality needing to be verified before payment. Hiring such a workforce requires building payroll and oversight in every geographic region involved. An alternative approach is using incentives, where the task and reward are posted, contributors opt in from anywhere, and payment quickly follows verified delivery. Enabling such a mechanism at scale requires a programmable, global, low-cost payment rail to run on, which Virtuals already runs for software-based AI agents to raise capital, transact, and settle payments programmatically on Base and Solana. Eastworlds applies the same design to robot training data, using token incentives to recruit and pay a distributed workforce.

The market for this data is already paying. Buyers pay roughly $3 to $10 for an hour of egocentric recording and $50 to $100 for an hour of teleoperation, rates above typical hourly wages in much of Asia, per Teng. Traditionally, token incentive campaigns tend to collapse once new participants stop arriving, because nobody outside the system is buying anything, whereas here the incentives are backed by paying customers, namely the labs buying the data, so the pool holds for as long as demand for the data does.

Putting everything together, Eastworlds’ roadmap roughly looks as follows: sell data and neodeployments today (because buyers already pay for both), use those paid deployments to collect what staged collection cannot produce, particularly the corrections; then use the growing Data Lake to train models, starting with single-task ones and moving toward more general ones, each of which sells for considerably more than raw data does. Eastworlds operates at the data layer, but its moat is everything required to keep making the data, including the G1 fleet, the operators, the incubated teams, the live deployments, and the payment rails underneath them.

Risks and Important Considerations

There are, of course, risks and important considerations around scaling the robotics data layer to keep in mind. The deepest objection, to the category as a whole, is that teleoperation may not lead to robot autonomy after all; a robot that needs an operator to get through a hotel shift is doing the shift with a person either way, just in addition to a robot and its associated costs. Teleoperation vendors and the robot makers argue this is a temporary phase for activities where the variation is small and the failures repeat, and the model does keep improving until the operator stops intervening altogether. The tasks that made robots hard in the first place, where the objects, the layout, and the failure modes keep changing, are the ones where the operator never fully leaves today. Those are also the tasks that generate the most valuable data, which is why a supplier is well-positioned to remain profitable in a world where full autonomy never truly arrives.

Simulation threatens demand for recorded demonstrations, which is the product a data supplier sells. An operator recording by hand produces somewhere between 5 and 50 episodes an hour, while a simulator runs millions overnight at almost no cost. What simulation still gets wrong is contact, since the moment two objects touch, the simulated physics and the real physics diverge, which is why simulated data alone does not produce a robot that can pick things up. Teams are closing that gap by randomizing the conditions in the simulator (e.g. lighting, textures, friction) so a model does not overfit to any one rendering, and by tuning the simulator's physics settings until a simulated arm moves the way the real arm does.

The price of robotics training data itself has fallen too. Per SVRC's State of Robotics 2026, an hour of high-quality teleoperation data cost roughly $340 in early 2024, $136 by the fourth quarter of 2025, and is down to $118 by March 2026. This decline was driven by 1) leader-follower rigs (setups where an operator moves a small replica arm and the robot copies it) dropped under $2,000, so a site no longer needs custom hardware; 2) software like DROID and LeRobot now takes raw operator recordings and formats them into training-ready datasets without a person doing the cleanup. Both are still improving. A supplier whose product is recorded hours is, therefore, selling into a market where the price of an hour dropped by ~66% in two years.

Competing robotics data suppliers arrived at vertical integration at the same time Eastworlds did: Adamo sells managed teleoperation with sub-40-millisecond control software so robot companies can skip building the operation themselves, XDOF, founded in October 2024, moved beyond selling recordings into cleaning, tooling, and annotation on its founders' reasoning that selling recordings alone is a dead end, and Physical Intelligence, Lux, iMerit, and DataX Power all sell some version of managed collection plus the tooling around it, with DataX Power running its programs out of Southeast Asia, the same region Eastworlds operates in. None of them, however, run paid commercial deployments of their own, which is where corrections come from and which is the part of the loop that cannot be replicated by hiring more operators into a warehouse. The crowding is real at the collection layer and thin at the deployment layer.

Robot makers are, of course, a harder problem, because several of them already produce training data in-house: Figure runs its own teleoperation fleet across its BMW deployment, and Tesla's Optimus program is built on the same loop of deploying robots, recording the failures, and retraining on them, and those operations own the hardware, the deployment, and the customer relationship already, which means they accumulate data faster than anyone buying it. The data they accumulate, though, is data on one robot doing one company's work, and a supplier serving twenty customers across hotels, farms, and warehouses collects a spread that no single manufacturer's fleet produces. Figure and Tesla are also the two best-capitalized robotics teams in the world, and the dozens of robot makers below them cannot fund an operation of that size, which is the market an independent supplier would actually sell to.

Lastly, Eastworlds’ economic model and token mechanism carries its own risks. Paying contributors in tokens avoids setting up payroll and compliance in every country where someone records an hour of footage, but it ties what a contributor earns to the token price rather than to the work they did, so recruitment gets hardest during a drawdown, which is precisely when the operation most needs steady output. The legal treatment of paying workers this way is also unsettled across most of the jurisdictions involved. Eastworlds' answer is that customer revenue funds the incentives rather than new token buyers, which is, of course, the correct structure, since it means the pool does not depend on new participants arriving. That structure holds as long as the customers do, and a supplier whose contributor base is priced in a volatile asset has a second failure mode that a payroll-based competitor simply does not have.

Closing Thoughts

Eastworlds is building a picks-and-shovels business for the emerging robotics field, particularly around the training data layer. The software version of this already ran its course: frontier labs fought to create the most cutting-edge models, hundreds of billions were spent, and the companies that sold them their training data, Scale and Surge and Mercor, grew into multibillion-dollar businesses that got paid regardless of which customer won.

That rush has now moved beyond software and into the physical world. Robots have brains borrowed from language models and cheap bodies mass-produced largely by Chinese manufacturers, and every serious lab and robot maker is chasing the same machine that can do physical work on its own. What none of them can skip is the examples of physical work to learn from, which cannot be scraped and largely have to be produced by people operating robots, one recorded session at a time. Pooled public datasets help a model start, but the building a robot works in, the hardware it runs on, and the ways it specifically fails all have to be recorded fresh, so demand renews with every deployment rather than being satisfied once.

A supplier that only sells raw demonstrations is easy to replace and easy to squeeze, since the recordings transfer poorly between robots and a few customers often account for most of the revenue. A supplier that also has a robot fleet, employs operators, manages the deployments, and carries each field failure back into the next model becomes a business whose customers cannot easily leave or rebuild, doing what would otherwise take five vendors. That is exactly what Eastworlds is building. Its Unitree fleet does paid pilot work in hotels and malls today, its operators step in when the autonomy fails, and both come out the other side as training data, offered as demonstrations and corrections, collected into the Data Lake. Although data is the biggest bottleneck in robotics today, the surrounding infrastructure remains heavily fragmented, and there is now a unique opportunity for a business to vertically integrate and own as much of the robotics data layer as possible. Eastworlds is well-positioned to capture this opportunity, but only time will tell if it does.

References

Anthropic. (2026). The 2026 state of AI agents report: How enterprises are building and deploying AI in production. https://resources.anthropic.com/hubfs/The%202026%20State%20of%20AI%20Agents%20Report.pdf

Bloomberg News. (2026, May 1). Meta acquires Assured Robot Intelligence to help build humanoid technology. Bloomberg. https://www.bloomberg.com/news/articles/2026-05-01/meta-acquires-assured-robot-intelligence-to-help-build-humanoid-technology

BMW Group. (2026, May 13). BMW Group to deploy humanoid robots in production in Germany for the first time [Press release]. https://www.press.bmwgroup.com/global/article/detail/T0455864EN/bmw-group-to-deploy-humanoid-robots-in-production-in-germany-for-the-first-time?language=en

Brohan, A., Brown, N., Carbajal, J., Chebotar, Y., Chen, X., Choromanski, K., ... Zitkovich, B. (2023). RT-2: Vision-language-action models transfer web knowledge to robotic control. arXiv. https://arxiv.org/abs/2307.15818

Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., ... Amodei, D. (2020). Language models are few-shot learners. arXiv. https://arxiv.org/abs/2005.14165

Chollet, F. (2019). On the measure of intelligence. arXiv. https://arxiv.org/abs/1911.01547

Eastworlds. (n.d.-a). Data. https://eastworlds.io/data

Eastworlds. (n.d.-b). Eastworlds whitepaper. https://whitepaper.eastworlds.io/

Harvard Business School. (2026, June 1). Who's adopting AI agents, and what they're actually doing with them. HBS Working Knowledge. https://www.library.hbs.edu/working-knowledge/whos-adopting-ai-agents-and-what-theyre-actually-doing-with-them

Hauser, K. (n.d.). Anatomy of a robot. In Robotic systems (draft). University of Illinois Urbana-Champaign. https://motion.cs.illinois.edu/RoboticSystems/AnatomyOfARobot.html

OpenAI. (2023-2025). ChatGPT weekly active user milestones [Company disclosures]. https://openai.com/news/

Perrigo, B. (2025, June 16). How Meta's $14 billion deal upended the AI data industry. TIME. https://time.com/7294699/meta-scale-ai-data-industry/

Reuters. (2026, July 3). Chinese robot maker Unitree wins approval for $619 million Shanghai IPO. Yahoo Finance. https://finance.yahoo.com/technology/articles/chinese-robot-maker-unitree-wins-052743978.html

Rider, J. (2026, June 22). Sector snapshot: Robotics startups on fire as venture funding surges to record numbers in 2026. Crunchbase News. https://news.crunchbase.com/robotics/startup-venture-funding-surges-2026-data/

Robotics Center of Silicon Valley. (2026). State of robotics 2026: Annual report on the global robotics industry. SVRC Research. https://www.roboticscenter.ai/state-of-robotics-2026

Shaip. (2026, June 9). Robot training data and manipulation datasets: 2026 guide. https://www.shaip.com/blog/robot-training-data-and-manipulation-datasets-power-real-world/

SoftBank Group Corp. (2025, October 8). Acquisition of ABB Ltd's robotics business [Press release]. https://group.softbank/en/news/press/20251008

SRI International. (n.d.). Shakey the robot. https://www.sri.com/hoi/shakey-the-robot/

The Rollup. (2026, April 15). Jansen Teng on why robots need crypto to scale [Video]. YouTube. https://www.youtube.com/watch?v=u5ZuftUNnT8

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. This post has been created in collaboration with the Eastworlds team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

One of the last times the customer changed from a human to a machine, it created a $135 billion industry in the U.S. alone, in just one sector: advertising (IAB/PwC, 2024). The agent-first shift is the same structural transformation, but applied across every industry that runs on software. The scale will be orders of magnitude larger, and most people have never heard of the companies that captured that value.

"In 2024, programmatic advertising revenue reached $134.8 billion, marking an 18.0% increase from 2023."

The Core Primitive

AI has promised so many things, and it's becoming clear that AI has huge benefits in orchestrating information and actions. At the root level, the primitive that AI has solved is collapsing the cost of cognition, the way the internet collapsed the cost of communication. Scripts can execute tasks, but AI can reason through them, making decisions where previously you needed a human intermediary exercising judgment. When cognition becomes nearly free, the entire coordination layer to orchestrate cognition becomes the centerpiece.

SaaS products are moving to agent-first, a SaaS-to-CLI pipeline. What I see happening is that many SaaS products in the future are going to become pipelines into people's personal agent infrastructure. Everyone has their personal agent infrastructure, and a lot of people will cloudy and muddy the space by saying there are thousands of agents being deployed onchain, yada yada. The true agents we see now are people's coding agents, which are a great example of a centralized agent. Coding agents are capturing the market right now because of the technical barrier, but the broader point is that each person has a centralized agent. We are seeing early indications with Claude Cowork (non-technical). That centralized agent, operating semi-autonomously similar to something like a Clawdbot (@openclaw), will be piped into all these different applications. So if you're a builder, you essentially need to be able to support the rails into everyone's orchestration agent. By having those orchestration agent rails, the business model then becomes tools, data, intelligence, all these different services, serviceable via products like MCP/CLI and x402/MPP through these personalized orchestration agents.

The savvy teams are understanding this completely. We've seen numerous cases now of protocols like Uniswap, or even web2 companies like Ramp, creating the pipelines for agent-first consumption.

It could be the case that this is essentially the metaphorical death of the dashboard/interface. The dashboard gets removed from the equation, or rather, it becomes less of a visualization layer, because you subscribe to these services and your agent makes the visualizations of the important information. You can crosscut the information in ways that your agent can surface. A dashboard really just serves as discovery, because you don't need to make incremental analysis inside a SaaS product's dashboard. The agent, with context, can monitor for specific triggers, signals, and so on. Instead of you reasoning over your CRM, customer service pipeline, product and project management ticketing, you have a centralized personal authority that makes these decisions.

In March 2026 alone, the pace of agent-first adoption accelerated dramatically across every layer of the stack in the crypto ecosystem:

We're seeing that applications like Claude Code, Codex, and Anthropic's Claude Cowork are the early versions of this, and for founders and builders, the interface is the CLI. We're building towards a world where the agent can make micropayments with something like x402 or MPP, and these micropayments for services can scale literally with usage. So not only is there a whole new layer of information consumption (which the data industry is very used to when it comes to APIs and such) but the business models because of agents are also changing. Essentially, the customer is changing from an individual to an agent, and because the user is changing from a person to an agent, the tools, abilities, and structure of consumption all change.

What This Means for Builders

For builders, this is an indication that you need to be comfortable working on your orchestration system. Your tools and everything should pipe into your workspace. For instance, I currently use CRM and product management tools like Linear, and these products can pipe right into my coding agent. I can process an assigned ticket or move business statuses all within a tool like Claude Code. So as builders are building, the era is turning into building things for agents, even if it's web2 SaaS, but especially this is relevant for serving small and medium-sized businesses, where the teams have more flexibility. You don't need approvals to integrate tools. This will be more difficult for enterprise, but for scrappy early-stage companies and founders, teams will likely have highly optimized orchestration stacks that pipe in all of these different business management, sales, and product development tools.

The Trust Monolith Problem

Now what's interesting is that the trust layer now exists and sits within your agent. Your agent becomes the liaison on behalf of your business, and the question is how much trust are people willing to put into these agents? By putting the trust into the agent, although the agent might not be malicious, the structure of knowledge processing and interpretation is shaped by the agent itself. An example might be someone follows up with a message that has sarcasm baked into the context, or you met this person in person. These nuances can be missed by an LLM due to limitations of the technology. That's a clear-cut example, another is that not all people think the same, and you could end up with this monolith of decision-making, a monolith of how businesses are run, created, and operated. So it becomes hyper-important to have agents handle production and orchestration between tools, but still retain the edge methodology and taste of the operator.

In a world where interfaces are diminishing, what actually becomes defensible? Is it the data? Is it the quality of the tool's output? Agents are consuming different types of tools: intelligence, information retrieval like search, API keys for other LLMs, specialized LLMs, structured data products and frameworks like CRMs. In a time like this, distribution becomes the moat. Distribution, trust, regulatory capture. Integration with the CLI and coding agents is becoming a new product distribution rail, a new way of serving products, a new customer, and that new customer has different requirements and different demands.

A Historical Parallel: Programmatic Advertising

This shift has a direct historical precedent. In the late 2000s, digital advertising underwent the exact same structural transformation. Before programmatic, advertising was a human-to-human business. A media buyer at an agency would call a sales rep at a publisher, negotiate rates, sign insertion orders, and manually place ad campaigns. The interface was literally a person: relationships, phone calls, dinners, RFPs. The publisher's value was bundled: audience, placement, creative context, and reporting all came through the same dashboard and the same salesperson.

Then the customer changed. The breakthrough came from Brian O'Kelley at Right Media, who developed the concept of real-time bidding around 2007. Instead of pre-buying blocks of impressions, RTB allowed advertisers to bid on individual ad impressions in real time as users loaded web pages. It was the equivalent of a stock exchange firing off trades in milliseconds. Google recognized the magnitude of this shift early, acquiring DoubleClick in 2007 for $3.1 billion in cash, which became the backbone of its programmatic empire. The OpenRTB protocol, formalized by the IAB Tech Lab in 2010, became the standardized language for machine-to-machine ad transactions, the same role MCP is beginning to play for agent-to-service communication today.

The algorithm needed an API, structured bid requests, impression-level data, and the ability to transact in microseconds at fractions of a cent. Not a dashboard or relationship, and didn't care about the publisher's brand. The entire industry restructured around serving this new machine customer.

The agent-first shift applies the same structural transformation to every industry that runs on software: financial services, healthcare, logistics, legal, commerce, project management, and beyond. The addressable market is orders of magnitude larger than what programmatic captured in ads alone.

The parallel to what's happening now with SaaS and agents is nearly exact:

The Downside: What Happens When You Remove the Human

The programmatic shift also came with significant downsides that builders in the agent-first era should study carefully. When you remove the human from the transaction, you lose judgment. In programmatic advertising, this manifested as a massive brand safety crisis: algorithms couldn't judge context, and major brands found their ads running next to extremist content, fake news, and harmful material. JP Morgan Chase discovered its ads on conspiracy sites. The automated system optimized for reach and cost, not for context or reputation. Ad fraud became an enormous problem as well. According to industry estimates, global losses to ad fraud exceeded $35 billion annually, and one study found that just 36 cents of every dollar spent on programmatic advertising actually reached the consumer. Fraudsters built fake websites, deployed bot farms to simulate clicks, and exploited the automated nature of the system to siphon billions from advertisers who had no visibility into where their money was going.

The parallel to agent-first SaaS is direct and should serve as a warning. When your agent becomes the liaison for your business, it inherits the same blindness. It can't judge whether a vendor is trustworthy based on a handshake. It can't read the room in a negotiation. It will optimize for whatever signal it's given, and if the signal is wrong, it will optimize confidently in the wrong direction. Just as programmatic created an entire ecosystem of ad fraud because the machine buyer couldn't distinguish real inventory from fake, agent-first commerce will create new categories of fraud, where services game agent decision-making the way fake publishers gamed bidding algorithms. The lesson from programmatic is clear: when you remove the human from the loop, you gain speed and scale but lose context and judgment. The companies that built verification layers, brand safety tools, and fraud detection on top of the programmatic infrastructure captured enormous value by solving the problems the shift created. The same opportunity exists now.

Whoever builds the trust, verification, and quality layers for agent-to-service transactions will be solving the inevitable problems of the agent-first era.

Before search, demand on the internet flowed through brands people already knew. You typed a URL, opened a directory, or went where a banner sent you. Then search changed the interface. People stopped navigating to vendors and started describing what they wanted, and a machine decided which provider to put in front of them. Search was an entirely new distribution channel, with a new buyer interface and a new gatekeeper.

When Google opened AdWords in October 2000, it had about 350 advertisers, and the pay-per-click auction arrived in 2002. The companies that moved early bought the highest-intent demand in marketing for pennies, because almost no one was bidding against them. They claimed keywords, learned what ranked, and accumulated position while the channel was still cheap and uncrowded. Selection became the whole game. Whoever the engine chose captured the customer, and the providers who learned to be chosen built advantages that lasted. By the time the rest of the market understood what had happened, search became the most competitive auction in advertising, and latecomers paid many times more for the same click. One of the clearest winners was Booking.com, which leaned into paid search early and became one of Google's largest advertisers and best in class at search engine marketing, making it difficult for competitors to keep up. The travel companies that relied on free organic traffic instead, like TripAdvisor, were later disintermediated when Google reshaped the results page. The early advantage was claiming a position in a new discovery layer while it was still forming.

x402 is a similar shift for agents, which are becoming the buyer interface the way search once became the buyer interface. The human stops browsing vendors, comparing landing pages, and choosing between SaaS products, and the agent selects the service instead. X402 and machine payment protocols turn paid API calls into the selection event inside that new channel, with one difference that makes it sharper than search. With search, the click was the start of a funnel. With x402, the moment the agent discovers a service can also be the moment it pays. The discovery and the conversion are the same event.

At its core x402 is becoming the discovery layer for the agent economy, the place where agents find the services they need and where providers get found and paid in the same call. The payment is the visible part, and the discovery is the nascent opportunity. For a provider, the value shows up as distribution, demand that arrives intent-attached and only when an agent actually calls. Whereas agents, cab discover and find the right service and pay for it in one step. Teams onboarding onto x402 should expect the first-order value to show up as distribution before it shows up as massive revenue.

This argument is framed for content providers, data providers, and anyone offering a service on the open internet, the supply side that can list on the rail and get discovered. Infrastructure providers like AWS and Cloudflare sit at a different layer with a different agenda and ontology, since they own the edge where traffic is gated and priced. That layer, along with the content gating and attribution questions that come with it, is the subject of a separate paper. The focus here stays on discovery for the providers building on top of the rail.

Right now, most paid API endpoints are not large businesses, shown in the public x402scan data. Even when the network shows millions of transactions and more than a million dollars of aggregate volume, the visible services at the top of the leaderboard are often doing low thousands of dollars in monthly volume. Most individual providers do not have a standalone revenue line large enough to matter given the scale of some of the providers currently supported like Exa who raised $85M (@ExaAILabs )to build the search engine for AI and support x402 payments. At an event we attended, Exa's co-founder Jeff said he has long been a fan of crypto and sees this as the natural direction for the agentic economy and for agents. We are paraphrasing, but the framing is worth noting, because it comes from an AI search founder rather than from anyone native to crypto.

For a service provider, the paid x402 call is closer to a completed ad click which is a unit of demand, routed by an agent, attached to intent, settled at the moment of use, and observable onchain. The provider charges for an API call, but the strategic value is distribution inside the place agents go to buy capabilities.

The provider's mental model should shift from "I am enabling micropayments" to "I am getting listed in the place agents go to buy services."

Hypothetically, If a provider charges $0.50 for a call that costs $0.001 to serve, the spread looks irrational under cloud infrastructure logic, but under marketing logic it can make sense because the provider is monetizing usage while also buying distribution, intent capture, routing eligibility, and conversion inside an agent workflow.

x402 lets agents pay APIs, but that framing undersells what is happening. x402 and MPP create a machine-readable marketplace where agents discover services and providers compete to be found and paid, with the payment functioning like the tracking pixel. The paid call is similar to a Stripe checkout but at this stage functions more like a Google Ads click with settlement attached, which is the start of an agent-native distribution market.

Everyone is staring at x402 volume and asking how much money is moving, but the better question is who decides which service the agent calls, because once agents become the buyer interface, the user no longer browses vendors, compares landing pages, signs up, enters an API key, or chooses between SaaS products. The agent chooses, which turns service discovery into the new control point.

The Call Is the Conversion Event

Traditional software marketing has a long funnel:

1. A user sees an ad

2. The user clicks

3. The user visits a landing page

4. The user signs up

5. The user gets an API key

6. The user integrates the product

7. The user eventually pays

Agent commerce compresses that entire path. The agent finds a service and pays for it in the same motion it gets the result, and the long human funnel above collapses into that one exchange.

That makes the x402 payment event unusually dense. It is a transaction and a signal that an agent had intent and selected a provider at the moment of need.

For providers, the first wave of agent-commerce adoption will probably look small if measured only by provider revenue. A few thousand dollars of monthly endpoint volume will not move the needle for most SaaS companies or API providers, but a few thousand dollars of paid calls can still answer strategic questions that normal marketing cannot answer cleanly:

• Which agents are calling us?

• Which wallets return repeatedly?

• Which adjacent services do the same wallets use?

That is marketing data carried through a payment event.

x402 Turns API Pricing Into Marketing Spend

This is the same reason companies pay Google for search ads, Amazon for marketplace placement, Apple for App Store distribution, and affiliate networks for attributed conversions. The real value is being present at the moment demand forms, which is why the direct revenue from the first interaction should be seen as secondary.

x402 has the potential to become the agent-native version of that pattern, because the provider can receive demand without a human visiting a website, creating an account, going through procurement, taking a sales call, or managing an API-key workflow. The agent can call the service at the exact moment the service is needed.

That is a powerful distribution surface even before payment volume becomes large, although it also makes providers more substitutable. If an agent can reach any comparable API through the same payment flow, then the provider's advantage shifts from owning the user relationship to being selected by the router.

That means providers will need to optimize for agent selection the same way websites optimized for search selection, where machine-readable signals like price and reliability become the core agent SEO metrics.

x402 as Real Revenue

The distribution framing only works if there is a path from learning-curve revenue to meaningful revenue. How quickly that path forms decides how patient providers need to be.

One of the core benefits right now is the open discoverability, in addition to the payment primitive. An open standard lets an agent discover and combine services it never integrated with directly, and that composability is what lets a single agent assemble a workflow across many providers. The same openness happens to be auditable, which is a second benefit. On a closed rail a provider's usage numbers are whatever its own dashboard reports, and no outside party can verify them, while on x402 every call is a public on-chain payment that anyone can reconstruct by payer, time, and wallet. Coinbase, Circle, and the x402 Foundation built the rail in the open on purpose, and both the composability and the analysis in this piece exist only because they did. The same transparency that lets an operator inflate a leaderboard also lets anyone catch it.

For x402 to become a real revenue channel for the average serious SaaS provider rather than only the top one or two players, the service-market subset of the ecosystem needs to reach a scale not currently visible in the data. Growth trajectory is not validatable from a single snapshot, which means what is implied here rests on the assumption that the ecosystem continues to expand at recent rates, followed by a breakout use case.

Case Study: AWS Puts x402 Behind a Quarter of the Internet

On June 15, 2026, Coinbase and AWS turned on agent payments at the edge. Any site behind Amazon CloudFront and AWS WAF can now charge AI agents per request in USDC, settled through Coinbase's x402 Facilitator and configured from the existing AWS console with no new infrastructure. AWS describes CloudFront and WAF as the backbone for roughly a quarter of the internet, which means a quarter of the web can now treat an agent as a paying customer.

The flow is the performance-marketing pattern in production. An agent requests a resource, the edge returns an HTTP 402 with a machine-readable manifest that lists the price, the accepted networks, and the destination wallet, the agent pays, the Facilitator verifies the payment on-chain, and the content is served inside a single request. Base is the default rail because settlement lands in about 200 milliseconds for well under a cent, which is the cost shape that per-request pricing needs. AWS takes no cut, and funds settle straight to the publisher's wallet.

What matters for providers is legitimacy, reach, and the ability to capture agentic traffic, more than any single revenue number. Agents are already running free across the open web, collecting any open data or content they can reach without paying for it, and an on-chain rail is the first way to turn that traffic into something a provider can see and charge for. A hyperscaler wiring on-chain settlement into its content-delivery edge is the clearest signal yet that agent-paid access is becoming default infrastructure. AWS WAF Bot Control already classifies more than 650 agent types, including GPTBot, Claude-Web, and Perplexity-Bot, and lets a publisher price each tier differently, which turns agent traffic from a bandwidth cost into a priced, measurable demand channel. It builds on the Bedrock AgentCore Payments work from May, where Coinbase and Stripe wired x402 into the agent side, and both ends of the transaction now sit inside AWS. Coinbase also shipped the x402 Bazaar, an open searchable registry where agents discover x402 endpoints by price and capability, which is the discovery marketplace in production.

The case study is not a revenue story yet, because neither company has disclosed launch customers or early figures. The point is the new surface. Once a quarter of the internet can accept agent payments from a console toggle, the question for a provider stops being whether agents can pay and becomes whether the provider is discoverable and priced when they do. That is the performance-marketing question, now asked at the scale of the open web.

The Wallet Is the Bottleneck

The x402 endpoint solves discovery, but that is only half of a conversion, because discovery turns into revenue only if the agent can pay in the moment it asks.

Paying at the moment requires a provisioned and funded wallet. The agent needs USDC on an accepted chain, a key it can sign with, and enough balance to clear the price the 402 quotes, all ready at the instant of the call. If the agent, or the user behind it, cannot onboard and fund a wallet when it hits the endpoint, the 402 is a dead end. The provider got discovered and still did not get paid. Although sites might have the option to pay, we might see agents not wanting to pay and finding other sources.

That gap is the clearest near-term risk to the thesis. The supply side is getting solved quickly, since AWS, the facilitators, and the payment layers are removing the work of accepting agent payments. The demand side depends on every calling agent already carrying a funded wallet, which is not yet the default. Until wallet provisioning and funding are built into agent runtimes the way an API key is built into a script today, a real share of discovered demand will fail to convert because the buyer could not pay.

The fix is agent-side, and it is starting to appear. Bedrock AgentCore Payments (@awscloud) , AgentCash (@agentcashdev), SpongePay @paysponge), LocusPay (@PayWithLocus), Visa CLI (@Visa), Coinbase CLI (@coinbase), and Circle agent (@BuildOnCircle), to name a few, provision and fund a wallet inside the agent loop, and payment layers can hold the wallet on the agent's behalf. The dominant answer is that crypto would likely have to be completely abstracted from the experience and stripe already offers this. None of these is universal yet, which is why wallet readiness across the agent population is the variable that caps how much x402 discoverability turns into revenue, more than endpoint availability.

The Aggregator Could Capture the Workflow

The distribution this piece argues for has a competitor that is not another payment protocol. It is the centralized aggregation layer forming inside SaaS providers. A workflow aggregator can sit between the agent and the provider, own the discovery and routing, and turn the underlying services into interchangeable backends. OpenRouter already runs this pattern for language models, routing a single request across hundreds of models from dozens of providers and selecting one on price and performance, which turns the labs underneath it into commodity suppliers behind one endpoint. Deepline is a clean example. It gives agents a single go-to-market interface over 93 or more enrichment and prospecting providers, and it picks which provider to call through an automatic waterfall. The agent talks to Deepline, and Apollo, Crustdata, and the rest are selected, priced, and substituted inside it. Stripe is building the same shape at larger scale with its Agentic Commerce Suite and Projects, where an agent signs up for, buys, and wires together the services it needs from one surface.

The risk is sharpest in x402's strongest workflow, where one of the most robust forms of agent demand on the rail today is go-to-market search and prospecting, with an agent finding accounts, enriching contacts, and assembling a lead list across services like Exa, Hunter, and StableEnrich. That is exactly the workflow an aggregator is built to own. If the aggregator owns the prospecting flow, the search and enrichment providers underneath it are chosen by the aggregator and ranked by the aggregator.

Getting on x402 early matters more because of the early discoverability. A provider builds trust by being callable and by showing up inside the aggregators and distribution tools that route x402 traffic, like wallets. The discovery layer is the prize in either case, and the question becomes who ends up owning the routing for the workflows that carry the most demand.

Agent SEO Opportunity

If agents become buyers, service providers will compete for agent selection. We discussed this shift in Shoal Signal Ep. 6, Autonomous Agentic Commerce: Micropayments, AgentCash, x402 & MPP, where the core point was that agent payment rails turn service choice into a new distribution layer, and we went deeper on discoverability in our Shoal Signal interview with Circle's Corey Cooper, where discovery is framed as the real value layer.

That competition will look different from human SEO. Agents care less about brand, landing-page design, and emotional copy. They select on machine-readable signals like cost, reliability, and latency.

The provider that wins inside this environment is the one with the most reliable, machine-readable service and the reputation to back it, rather than the best human-facing website. x402 should be understood as discovery infrastructure as much as payment infrastructure where the payment is the tracking pixel.

Enterprises Are Already Being Asked

The demand signal is not only on-chain. In our own interviews with more than ten non-crypto engineering and product teams, every team reported that customers or partners had already asked about agent and stablecoin payments, and every team said it was interested in supporting them. None of these teams came from crypto, which is the point. The pull is arriving from ordinary software companies that can see agents starting to transact and do not want to be the vendor that cannot accept the money and there isn’t a defacto solution yet.

That is a different and earlier signal than revenue, as the buyer side is forming before the volume is showing up.

Why Teams Should Experiment Now

The case for providers to add x402/ MPP today is that agent-mediated demand is starting to form, and providers need to learn how that demand behaves before routing layers harden.

The teams that wait for the revenue to become obvious may find that the discovery layer has already been captured. Agent hosts, routers, wrapper products, and marketplaces will learn which services perform, which services convert, and which services deserve placement. Providers that stay off the rail give that learning curve to someone else.

The near-term goal should be simple:

1. Become callable by agents

2. Measure which wallets and routers produce real usage

3. Learn what pricing agents tolerate

4. Improve the metadata and reliability that influence selection

5. Build a path from anonymous paid calls to repeat customer value

The first dollar of x402 revenue is less important than the first clear signal about how agents discover, select, and reuse your service.

If agents are going to become a meaningful demand channel, x402 is one of the earliest ways for providers to watch that channel form in public.

The Missing Killer Use Case

The biggest criticism of x402 is the simplest one being that there is no killer use case yet. Most of what runs on the rail today is experimentation and research rather than a workflow a business cannot operate without.

The counterweight is who is building it, since the companies pushing agent payments forward are close to too big to fail at this scale, with Visa, Mastercard, Stripe, Coinbase, Circle, AWS, Google, and Cloudflare just to name a few all committing infrastructure to the same idea.

When that many incumbents commit to one design space, the rails get built whether or not the killer use case arrives on schedule. Heavy backing is not a guarantee, because the metaverse and 3D television both drew enormous coordinated investment and never found a use case, but it does mean the infrastructure will be cheap and ready the moment a use case appears.

Two candidates stand out. The first is content gating, where the open web puts a price on access for AI, which we will treat in depth in a separate paper. The second is discoverability and orchestration, where an agent finds and composes endpoints it did not previously know existed. That second case is the through-line of this piece. The underlying primitive of x402 is discoverability and autonomous orchestration of open data. For the provider that wants to be found and for the agent that can evaluate options better than a human can. An agent can index across hundreds or thousands of services, test them, and keep the ones that produce the best result, whether it assembles them ad hoc or reaches for a niche go-to-market surface like Stripe's startup marketplace or Deepline. Those marketplaces are not x402 themselves. They are the same primitive in a different form, aggregated data and services an agent can call and spin up with ease. The limit today is the agent's ability to run that discovery on its own, and that is exactly the gap the goal-based shift is closing, where we give an agent a goal instead of a script and let it find the path.

Closing Thoughts

We have written extensively on agent protocols including: HTTP 402: How Machines Move Money is the technical foundation. It explains why HTTP 402 matters, how x402 and MPP work, and why agents need payment flows that match how they consume resources. That piece answers the infrastructure question of how machines pay for web resources at runtime.

Right now, for agents to be able to operate autonomously, they need and require the ability to discover tools and context on the open internet, and to do so requires an open standard.

References

Cloudflare. (2026). x402: pay-per-crawl and agent payments. https://blog.cloudflare.com/x402/

Coinbase. (2026, June 15). Coinbase and AWS let publishers accept agents as customers via x402. https://www.coinbase.com/blog/coinbase-and-aws-let-publishers-accept-agents-as-customers-via-x402

Coinbase. (2026). Google and x402 [Developer Platform launch]. https://www.coinbase.com/developer-platform/discover/launches/google_x402

Deepline. (2026). Deepline: go-to-market services for agents. https://deepline.com

Exa. (2025, September 3). Exa raises $85M to build the search engine for AIs. https://exa.ai/blog/announcing-series-b

Google. (2002, February 20). Google introduces new pricing for popular self-service online advertising program. https://googlepress.blogspot.com/2002/02/google-introduces-new-pricing-for.html

Mastercard. (2025, April). Mastercard unveils Agent Pay. https://newsroom.mastercard.com/news/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai/

OpenRouter. (2026). OpenRouter: a unified interface for LLMs. https://openrouter.ai

Shoal Research. (2026, May 15). Autonomous Agentic Commerce: Micropayments, AgentCash, x402 & MPP [Video]. X. https://x.com/Shoalresearch/status/2055009805346263249?s=20

Shoal Research. (2026, May 28). HTTP 402: How machines move money [Post]. X. https://x.com/shoalresearch/status/2060074558678262025?s=46

Shoal Research. (2026, June 23). Agents Already Spent $76 Million: Circle's AI Agent stack, x402, stablecoins and the Agentic Economy [Video]. X. https://x.com/Shoalresearch/status/2069519304236892629?s=20

Skift. (n.d.). The oral history of Booking.com's acquisition. https://skift.com/oral-history-of-booking-acquisition/

Stripe. (2026). Agentic commerce. https://stripe.com/use-cases/agentic-commerce

Visa. (2025). Find and buy with AI: Visa unveils new era of commerce. https://investor.visa.com/news/news-details/2025/Find-and-Buy-with-AI-Visa-Unveils-New-Era-of-Commerce/

x402scan. (2026). x402 public transaction and merchant data [Dashboard]. https://www.x402scan.com/

Introduction

A structural shift is taking place in the payments industry, whose underlying architecture has remarkably barely changed in decades.

Every layer of today’s payment stack assumes a human at both ends of every payment, which for most of human history has been true, up until recently. Increasingly, however, AI agents are now facilitating economic value, slowly but surely gaining more autonomy in the payments loop, to the point where they are initiating payment flows themselves. In some contexts, these flows involve AI agents moving value on behalf of their human operators to perform simple consumer shopping tasks. This has been tried with initiatives like Instant Checkout in ChatGPT. In other contexts, AI agents are themselves making decisions to pay for things, particularly resources required for them to complete specific workflows. This means that alongside the human-to-human payment flow now sit the human-to-agent and agent-to-agent payment flows, and this seemingly simple shift is already reshaping how existing infrastructure providers compete.

Some projections forecast trillions in agentic commerce-driven volume over the next 5-10 years, and while today’s numbers reflect that we are in the early stages of this cycle, over a long enough time horizon the projections look at least directionally correct. And as the development pace of frontier labs research over the past several years has demonstrated, a lot of things happen in AI much quicker than expected. More importantly, in an industry whose incumbents have absorbed every wave of innovation for the past seventy years, the opportunity for a differently positioned player to own more of the stack does not come along very often.

To understand the broader impact of this transformation, it helps to first understand what payments actually look like today. What feels instant to a consumer actually moves through four layers of infrastructure and five or more companies before a merchant ever sees a cent. This is often referred to as the “payments layer cake”, where each layer represents a different party in the payments flow.

When a consumer taps their card at checkout, the transaction moves through four distinct layers. At the top, the consumer initiates a card payment to the merchant. It drops into the processing layer, where a gateway (e.g., Stripe) encrypts and forwards the data, fraud and dispute intelligence runs in parallel, and a card acquirer (e.g., Adyen) prepares to receive funds on the merchant's side. From there, the authorization request hits the card network layer, where a Card Network like Visa or Mastercard handles routing, enforces scheme rules, and passes the request down to the banking layer. The issuing bank makes the credit and fraud decision and sends an approve or decline back up the chain. Authorization completes in under roughly two seconds, while settlement, the actual movement of funds back through the network to the acquirer and into the merchant's account, takes another one to two business days.

Each layer of this payment stack serves a fundamentally different customer; issuers extend credit to consumers, acquirers give merchants a way to accept payment, and the fraud and dispute layers sort out the mistakes people inevitably make. Serving all of these customers at once is beyond the reach of any single company; hence, no one has owned the whole stack. But a lot of this logic starts to break down when humans are further removed from the payments loop and, in their place, autonomous software programs take on a growing share of the decisions and transactions within it.

The payments industry has taken in one innovation after another, and the basic architecture has survived nearly all of them. When the credit card was introduced, it got rid of the need to carry cash, but instead of replacing any of the existing arrangements it simply added a consumer credit feature on top of the original banking system. The internet went even further by completely altering the way people contacted merchants and at the same time created a kind of fraud exposure that had never been there before, although the trust mechanisms developed in response were still based on the same four-party model. Likewise, companies such as Stripe and the fintechs that came after them, who reduced a large part of the system to a single API call, left the fundamental acquiring, issuing, and settlement processes unchanged.

Every one of these developments, though, shared the same premise: optimizing a stack built for human consumers. AI agents break that premise, as they don't carry wallets, don't click checkout buttons, and don't face the cognitive constraints the human payments stack was designed around. For an agent, a payment is a function call within a workflow, where it requests a resource, receives a price, completes the payment, and moves to the next task. The human payment stack will not hold its shape around a loop that fast and frequent, especially at scale.

The Path Forward Is A Vertical One

Vertical integration in payments, owning as much of the stack as possible, is not a new idea. Apple owns the iPhone, the Wallet app, and the tap-to-pay experience. Shopify runs the store and the checkout, processes the payment, and even lends money to its shops. Block controls everything from the card reader in a merchant's hand to the Cash App on a consumer's phone. But each of them still operates inside the human system, where every layer they own serves a specific customer segment with specific needs

Agents change the motive for integrating, because they change fundamentally what a customer is. An agent needs a place to keep its money, a way to send payments, and a way to find goods and services to buy. Not much else is needed beyond those key functions, so the payments stack it depends on is far smaller than the one built for human shoppers.

The question then becomes, given a narrower, purpose-built payments stack, which business in payments today can vertically integrate, and how far? The human payment stack is split across extending credit, accepting funds, routing the transaction, and settling it, each piece owned by a different company. The agent stack has no such divisions. An agent pays in the same dollars from start to finish, and the wallet, the network, and the shop are just ways of moving them, swappable for one another. The dollars make up the payment itself, giving the issuer of those dollars a particularly important role in agentic commerce.

Few players sit in this position, and while banks hold the actual dollars in the payment flow, an agent can't pay with a dollar sitting in a bank account. One emerging solution is to let the agent pay with a stablecoin, a digital version of a dollar that is issued on a blockchain. Bridging the two is a narrow business, where a company takes in a real dollar, holds it in reserve, and puts a digital dollar into circulation against it. From that point, the digital dollar is the company's product, and the rules it writes for how that dollar is made, moved, or frozen follow it everywhere it goes. That is why we believe a stablecoin issuer in particular is uniquely positioned to verticalize agent payments and capture the upside.

The Stablecoin Moat For Agentic Commerce

A stablecoin is, sparing some technical details, a piece of software programmed to maintain the value of a stable unit of exchange, most commonly a fiat currency like the US Dollar. A function call is made to a smart contract (another piece of software) and in turn a stablecoin is either minted or redeemed. Stablecoins are held and transacted through digital wallets; interfaces that bundle together a public key for sending and receiving transactions with a private key for authorization. The total circulating stablecoin supply sits at $315B at the time of writing as per Artemis.

The two primary reasons stablecoins are particularly well-suited for agents are economic and structural. A stablecoin transaction is a redistribution of balances on a blockchain, with no intermediary charging a fee at each layer between sender and recipient, which makes it orders of magnitude cheaper than legacy payment rails. The only resource consumed is the computing power needed to update the balance, paid as a gas fee that now sits in the sub-cent range across the majority of the leading chains by DEX volume.

Beyond cost, stablecoins have properties that fit how agents actually operate. Speed and accessibility are the obvious ones, since transactions settle in seconds and run around the clock. The more distinctive advantage is programmability. Stablecoins are issued and redeemed by smart contracts, pieces of code that execute automatically when predefined conditions are met, and those conditions, a collateral requirement, a spending limit, can be written directly into the contract. An agent can control its own wallet and sign transactions itself, so no human credential is needed at the payment layer. A payment becomes a function call in code, triggered the moment a condition is met, with no human initiating it.

That automation removes the need for counterparty trust, meaning an agent does not have to rely on a counterparty's legal representation or a jurisdiction's enforcement. A contract that says release payment when condition X is met will release payment every single time condition X is met. Most companies in the payments stack own one layer, earning revenue by performing a function on an asset they don't control in any meaningful way. A stablecoin issuer is different because the asset is their core product, which has two key implications.

The first is the impact around the business model; when a user mints a stablecoin, they hand over one real dollar and receive one stablecoin. The issuer invests that dollar in short-term yielding assets like US Treasury bills and keeps the interest, which accrues on every dollar in circulation whether or not it moves, as the issuer earns interest on the total circulating stablecoin supply.

AI agents structurally expand that supply base, as their wallets need to maintain a funded balance to operate. Payments execute against the balance held in a wallet at the moment a condition triggers, and insufficient funds fail the transaction and stall the workflow. Operators fund wallets in advance and replenish them periodically, and that balance earns the issuer interest income for the duration of the agent's operating period.

Second, a stablecoin issuer has a unique structural advantage in that it controls the underlying monetary primitive. When an issuer deploys a stablecoin, it writes the smart contract that governs how the coin is minted, redeemed, frozen, and transferred. Subsequently, every wallet that holds it, every rail that moves it, every orchestrator that routes it, is executing against rules the issuer wrote. If the issuer incorporates a programmable condition (e.g. a spending limit, transfer restriction, collateral requirement etc.) that condition applies everywhere the asset exists, because it is in the contract itself.

Having such control over the asset in a payment flow compounds particularly in agentic commerce, as agent transactions are steps in a workflow where the conditions on a payment depend on what happened before it and what needs to happen next. Those conditions need to be encoded somewhere, and on stablecoin rails they live in the asset contract, so the issuer who writes the contract defines the terms on which every autonomous transaction settles.

Controlling the asset is the entry point, the foundation every other layer builds on, and every developer, operator, and business in agent payments starts there. The moat forms one level up, in what accumulates on top of the asset. A stablecoin is too simple an instrument for its issuers to differentiate on. USDC and USDT are both dollar-denominated, both redeemable one for one, both settled on mostly the same public blockchains, and a developer choosing between them has no reason to prefer one on the asset alone. Hence why the choice for developers and merchants comes down to which asset carries the best infrastructure to build on. Each layer added on top expands what developers can build, shrinks what they have to figure out themselves, and widens the gap between that platform and any alternative. Few issuers are positioned to build that, and fewer still have meaningful scale.

Each layer of infrastructure added on top of the asset expands what developers can build, reduces what they have to figure out themselves, and widens the gap between that platform and any alternative. There are not many stablecoin issuers positioned to build that, and even fewer with meaningful scale.

Stablecoin Supply vs Volume vs Transactions Count

Identifying which stablecoin issuer is actually best-positioned to capture the upside of agentic commerce starts with evaluating them against the three key stablecoin metrics. Supply is how much of an asset is held at a point in time, volume is the dollar value of what moves, and transaction count is how many times value moves regardless of size. In a human payment system the three travel together, since more supply means more potential volume, and volume and count scale in tandem because human transactions cluster around a meaningful dollar amount.

Tether's USDT circulates around $185B against USDC's $73B, a lead it has held through every market cycle since 2020.

But an agent breaks the correlation that makes supply the headline metric in the first place, because they hold a balance to spend. A human treats a stablecoin balance as a place for money to sit, whether as savings, trading collateral, or dry powder waiting on an opportunity, so more holding translates directly into more supply. An agent's wallet is funded for a different purpose, holding just enough to cover the workflows it needs to execute, drawing that balance down through dozens or hundreds of payments, and getting topped up again as it runs. The same dollar in an agent wallet might move ten times in the period a human-held dollar moves once, so a modest amount of supply can generate enormous volume and transaction count. Agent-driven usage is best reflected by metrics that measure movement rather than metrics that measure resting balances.

This point becomes more evident when observing stablecoin supply by sector. Of the supply Artemis attributes to a sector, CeFi, meaning centralized exchanges and the exchange-like products built around them, dominates near $75B, DeFi accounts for roughly $25B, and payments are negligible. The overwhelming majority of attributable stablecoin supply sits as exchange collateral, trading margin, and DeFi liquidity, contexts where the asset is parked to earn rather than being spent, so the market's largest supply pools tell us almost nothing about which asset agents will actually transact in.

Agent activity largely appears in stablecoin volume, as each workflow an agent runs (e.g. paying for an API call, purchasing data, settling with another agent) moves dollars, and those transfers accumulate into volume whether or not circulating supply grows.

Transaction count also maps well to agent behavior. An agent's payment activity is a series of discrete payments, one per API call, per data query, per task settled, so the number of transactions tracks the number of things agents actually did, independent of what any of them cost. And the denominations involved make this distinction matter. Cloudflare CEO Matthew Prince recently noted that non-human internet traffic is projected to surpass human traffic somewhere in 2027, and that the micropayments powering much of it will each run fractions of a penny. A billion sub-cent payments amount to little in dollar terms, so at these denominations transaction count measures activity that volume does not capture.

Across stablecoin metrics that capture movement, USDC has grown fastest, taking the majority of combined USDC and USDT volume while its monthly transaction count has multiplied roughly 5x in two years, all with a supply less than half of USDT's size.

Which leads us to USDC’s issuer: Circle.

Coming Full Circle

Circle Internet Group, Inc. is a regulated financial technology company whose core product is USDC, alongside EURC, a euro-denominated stablecoin, and USYC, a tokenized money market fund used for institutional collateral and trading. Issuance is the base of the business, and Circle has built the rest of its payments stack on top of it. The lowest layers handle the asset itself, with Circle Mint and xReserve supporting institutional minting and redemption; the Cross-Chain Transfer Protocol (CCTP) burns USDC on one chain the user specifies and mints it on another; and Gateway builds on top of CCTP to enable a single USDC deposit to function as one balance across any supported chain. Above them sits the Circle Payments Network (CPN) which connects banks, PSPs, and fintechs through a single API so counterparties can transact in fiat while Circle handles the stablecoin conversion, compliance, and settlement behind the scenes. Circle also launched Arc, an in-house L1 that uses USDC as the native gas token. Arc’s public mainnet now scheduled for September 2026, set to go live with a curated set of global financial institutions including BlackRock, The Depository Trust & Clearing Corporation (DTCC), Galaxy, Global Payments, ICE, Mastercard, MoneyGram, SBI Group, Standard Chartered, Sumitomo Corporation, and Visa.

Yet for all its expansion up the payments stack, Circle was and remains a reserve-income business. In Q2 2026, Circle’s reserve income ($668m) accounted for 95% of the $701m in total revenue and reserve income. Circle's growth is therefore tied to whatever expands USDC held and used, and agents expand both, holding funded balances that add to the supply Circle earns on, and transacting continuously across USDC rails.

Circle In The Agentic Economy

USDC is already an active part of the early but growing agentic payments space. The most telling example is the x402 protocol, which enables agents to pay for web resources within a standard HTTP cycle. Though x402 now supports multiple payment methods, USDC was the initial payment rail and still settles 99% of x402 transaction volume, a dominant position Circle captured before it had actually built any infrastructure specifically for agents.

In May 2026, Circle took a major step towards verticalization with the launch of the Circle Agent Stack, introducing the infrastructure layers designed to build USDC into a full-stack platform for agentic payments.

The Circle Agent Stack

The Circle Agent Stack is a suite of five components (Nanopayments, Agent Wallets, the Circle CLI, Agent Marketplace, and Circle Skills) that’s designed to provide AI agents with controlled access to USDC, enabling them to hold funds, discover services, and transact programmatically with external services and with one another.

The stack is both chain and protocol-agnostic by design, extending Circle's existing suite of wallets, cross-chain infrastructure, and settlement rails to agent-driven programmatic transaction flows.

Nanopayments

Nanopayments are ultra-small transfers of fractional-cent amounts, which can be as little as $0.000001. The idea is not new, but every prior attempt, from credit card networks to Bitcoin's Lightning Network, failed for the same structural reason: the cost of clearing a payment exceeded the payment itself.

Circle Nanopayments move the cost off the individual transfer, meaning gas is paid once, when the buyer funds a gateway balance, and every payment after that is an offchain signature with zero cost to produce. Nanopayments are denominated in a stable asset (USDC) and separate verification from settlement, allowing a seller to be credited and carry out delivery immediately while final settlement is batched later. Built on Circle Gateway and implementing the x402 v2 standard as a payment option, Nanopayments plug into the request-response flow HTTP already runs.

The buyer makes a one-time onchain deposit of USDC into the Gateway smart contract, establishing a balance. When an agent requests a paid resource, the seller responds with a 402 status code carrying the payment details. The agent signs an EIP-3009 message authorizing the Gateway contract to move the specified amount from its balance to the seller. The seller submits that signed authorization to Gateway, which verifies it, locks the funds, and credits the seller immediately without waiting for settlement.

This design also lets Circle eliminate a key structural dependency. x402 deals with payment authorization and settlement, two separate steps. A seller can integrate its own onchain infrastructure to handle them, or use a facilitator to do it instead. In practice most sellers use a facilitator, and the standard integration defaults to Coinbase's. By running both steps through Gateway, Circle is its own facilitator. A seller simply swaps the facilitator client in its x402 middleware for Circle's BatchFacilitatorClient and points settlement at Gateway, and from there verification and settlement run through Circle.

Batching is what makes running its own facilitator worthwhile for Circle. A per-payment facilitator settles each transaction onchain as it clears, which at sub-cent amounts costs more than the payment is worth. Gateway instead collects pending authorizations, computes the net balance changes across all participants, and submits a single onchain transaction applying them in bulk, bringing per-transfer cost down to as little as $0.000001.

Gateway runs inside an AWS Nitro Enclave, an isolated hardware environment, which verifies every authorization before including it in a batch, while the Gateway smart contract verifies the enclave’s signature before executing. This helps ensure only verified batches can be routed onchain for settlement.

Agent Wallets

Agent Wallets are permissionless, policy-controlled wallets designed to enable agents to hold, send, and manage funds within predefined parameters and spending guardrails. Whereas a standard crypto wallet's private key authorizes spending the full balance, an Agent Wallet is built on Circle's user-controlled wallets with 2-of-2 MPC key management, splitting the key so the agent never holds it and the operator keeps custody. A policy layer checks every transaction against preset rules and screens it against sanctions controls prior to execution.

Mechanically, operators configure policies at the wallet level before an agent begins operating, setting time-bound USDC spending limits, allowlists and blocklists for specific wallet and contract addresses, and permitted transaction types. Policies are enforced at the wallet layer, meaning transactions are checked against predefined rules before execution, keeping agents within the boundaries their operators set. Agent Wallets support USDC and ERC-20 tokens across supported chains, and once funded, agents can begin transacting immediately with no manual approval flow required.

Circle CLI

The Circle CLI is a text-based control layer that lets developers and AI agents build on top of Circle's entire platform, with a focus on wallet creation, payment execution, and policy management. For agents specifically, the CLI provides a single scriptable interface that can be operated directly.

With the CLI, an agent can access Circle Wallets, CCTP, and Gateway to create wallets, define spending policies, discover services, and trigger transactions through precise commands. The CLI is framework-agnostic, compatible with harnesses like Claude Code, Cursor, Codex, and any custom agent framework, meaning it integrates into existing developer workflows without requiring a new environment or toolchain.

Agent Marketplace

Agent Marketplace is a directory of agentic services that both humans and AI agents can browse, assess, and integrate with, allowing agents to discover and pay for services programmatically. Services listed are x402-compatible, meaning agents can pay per request without managing API keys, subscription tiers, or billing cycles. The payment is embedded in the HTTP request itself, authorized by the agent's wallet, and settled via Nanopayments in the background.

Circle Skills

Circle Skills is a set of open-source files that provide AI coding assistants with structured context about Circle's entire platform, covering API surface, authentication patterns, error handling, and best practices. When a developer asks an AI coding tool to set up a USDC payment flow, the assistant already has Circle's integration patterns loaded without the developer needing to leave their environment. Circle Skills work standalone and are complemented by Circle's MCP server, which handles SDK details that change frequently between versions.

Altogether, the five components of Circle's Agent Stack give agents a sub-cent payment rail in Nanopayments, a custody-and-policy wallet layer in Agent Wallets, a discovery layer in Agent Marketplace, and developer tooling in the CLI and Skills to connect them.

The Circle Thesis

Circle’s position for agent payments boils down to three key catalysts:

USDC is a durable asset that is gaining ground on the metrics that matter most for agents. USDC has been around since 2018 and has endured a number of stress tests since then. It has operated since 2018 and held its peg through the Terra/LUNA and FTX collapses. By Circle's Q2 2026 reporting, USDC onchain transaction volume reached $14.8 trillion for the quarter, up 151% year over year, and per Artemis, USDC has taken the majority of combined USDC and USDT transfer volume while growing its monthly transaction count roughly 5x in two years, all on a float less than half of USDT's. And USDC still settles 99% of x402 payment volume, even as the protocol has added support for other assets including USDT.

Circle’s regulatory moat lowers the compliance burden for developers. Anyone deploying agents that spend money runs into financial regulation, and it is one of the hardest parts of getting them live, because the rules for what autonomous software can do on a user's behalf are still unsettled. Building on USDC hands most of that to Circle. Transactions settle through Circle's licensed entities, so money-transmission compliance sits with the issuer, not the builder. AML and KYC screening runs at the protocol level, so payments are checked by default. And Circle's licenses make USDC a recognized payment instrument in the US and EU, so a builder operates under Circle's regulatory umbrella rather than securing its own in every country an agent touches.

Agents make Circle money in new ways, and each one strengthens the others. An agent costs almost nothing to run, so a company can run thousands as easily as one, and each one feeds Circle in a way human payments never did. To work at all, an agent has to hold a funded balance, since a payment from an empty wallet fails and stalls the task, so operators keep their agents topped up for as long as they run. Those balances are backed by real dollars Circle holds in short-term government debt and keeps the interest on, which is where 95% of its revenue comes from today, so every agent deployed adds to the balance Circle earns on and leaves it there. Agents also transact constantly, thousands of times the rate a person would, and Circle's fee lines, subscriptions, services, and per-transaction revenue, scale with that activity, though they remain small next to interest for now. And once a company wires its agents to USDC, with funded wallets, spending rules, and integrations built around it, moving off means rebuilding all of it. In theory, this lays the foundation for compounding growth, since more agents grow the balance Circle earns on, more activity makes USDC the default developers build for, and that default pulls in more agents to USDC and Circle's stack.

Taken together, Circle has positioned itself for agent payments by building on the position it already held, a proven asset, compliance a builder inherits, and economics that compound as USDC circulates. The bet is that AI agents are the demand that turns that position from strong to decisive. They hold funded balances, pay constantly in tiny amounts, and need a rail that clears for fractions of a cent, which is what USDC already does best. As of mid-2026, Circle is the only stablecoin issuer to have verticalized a cohesive agent payments stack around its own asset.

Key Risks & Open Questions

However, no bet is without its risks. First, it helps to address the broader risk that agent payments, agentic commerce are a marketing trend and by no means a structural shift in the broader payments stack. By glancing at the data at a surface level, it certainly appears that way.

Most of the skepticism targets the timeline, the claim that agent payments are happening at scale today rather than in their earliest experimental phase. The evidence for that skepticism is real. The strongest supporting point is that the majority of existing x402 volume generated over a several-month period after which total volumes continuously declined. Even more telling to this point, much of that volume was determined to be largely inorganic. Artemis runs a wash-trading filter to identify organic activity, and found that roughly half of x402 transactions were gamified in some way. Through late 2025, x402 activity was dominated by speculation. Per Artemis, the speculative share of x402 volume rose from under 6% in October 2025 to 59% in November and 67% in December, much of it the PING pay-to-mint token. For a brief period of time, using the x402 protocol was a way to farm a memecoin rather than a genuine record of agents using the payment rail for real workflows.

The speculative share has since declined: 51% in January 2026, then a 25% to 40% range in the months after, averaging 33% over the trailing 30 days. Total volume also fell from its late-2025 peak over the same period. So the protocol is processing less volume than at the spike, and a smaller share of it is speculative.

The counter is frustratingly simple: we are still early. Inorganic x402 volume, while not indicative of a structural shift in payments in any way, is not indicative of the future adoption of the protocol, nor agent payments as a whole, either.

History has taught us that a speculative blowoff in a nascent market is not enough to evaluate its long-term legitimacy. Consider the early days of e-commerce. In 2000, online shopping was about 3.9% of US retail sales, and the sector had just lived through a mania that priced it as the imminent future. When the dot-com bubble burst, most companies, which were propped up by hype and speculation, died. Pets.com folded nine months after its IPO, Webvan lost over $800 million, eToys went bankrupt twenty months after going public. The crash looked, at the time, like a verdict on the whole idea. But in reality, the behavior kept compounding through the wreckage, the survivors (Amazon chief among them, down roughly 90% at the bottom) built the infrastructure the next decade ran on, and e-commerce is about 19% of US retail today. Agent payments follow the same pattern. The x402 data shows a speculative spike that has since drained, while more recent data shows that the protocol is in genuine and growing use, though it does not in any way suggest that agent payments have already arrived at scale.

Another broad risk, which applies to every stablecoin issuer, not just Circle: agents may settle on cards rather than stablecoins. Card networks have moved quickly into agent payments, and for consumer purchases where a human wants recourse, the familiar card rail may simply be the better fit. Whether cards or stablecoins win which flows is unresolved; we touch more on this in the open questions below

Structural Risk: Velocity Diminishes The Float Business

Circle earns net interest income on the reserves backing circulating USDC, a business model sensitive to the velocity of money. Standard Chartered estimates stablecoin velocity has reached roughly six times monthly turnover, about double the rate of two years earlier, and framed the implication directly, if velocity stays constant, rising transaction demand pulls more coins into circulation, but if velocity rises, the same demand is met with fewer coins outstanding. The bank attributes the surge largely to USDC itself, concentrated on Solana and Base and tied to TradFi displacement and early AI-agent payments, while USDT velocity has stayed flat in its emerging-market savings role.

Agent activity pushes in that same direction, since sub-cent nanopayments, streaming usage, and pay-per-crawl flows turn USDC from a balance that sits into a balance that cycles, so higher utility can coexist with a flatter reserve base, compressing per-dollar earnings.

This tension has not escaped Circle, and it makes Arc's role as a structural hedge clearer. By making USDC the native gas token on its own chain, Circle captures value per transaction rather than per dollar held, building a revenue line that scales with velocity directly.

Competitive Risks

Circle faces a multi-pronged competitive landscape.

Stripe has assembled a closed-loop stablecoin stack by acquisition; it bought Bridge, a stablecoin orchestration and on/offramp provider, and Privy, an embedded wallet product with over 75 million accounts. Stripe also jointly incubated and launched Tempo, a payments-focused L1, and co-authored the Machine Payments Protocol (MPP), an open standard for one-shot, recurring, and streaming API-native payments designed for agents. As a result, Stripe can take fiat in, settle on its own chain, and pay a merchant out, with the merchant never touching stablecoins or crypto. Circle's counter is the structural independence of its stack, which makes it the better choice for developers wary of vendor lock-in. Where Stripe is a proprietary end-to-end ecosystem, Circle is a protocol-agnostic issuer whose asset settles across chains it does not own. A closed loop only clears when both counterparties sit inside it, while a neutral asset clears between any two parties regardless of the stack either one runs. For agent-to-agent and agent-to-service payments, that reach is the more valuable property, and it is the same dynamic that made USDC the default on x402 before Circle had built anything specific for agents.

Stripe and Tempo's MPP does settle in USDC.e, a bridged USDC-backed stablecoin, on Tempo, Base, or Solana, so in one sense it is another rail carrying Circle's asset. But unlike x402, where USDC settles nearly all volume, MPP is deliberately payment-method-agnostic, able to settle the same charge in a stablecoin, on a Visa or Mastercard card, in Bitcoin over Lightning, or in any method a developer plugs in, and this neutrality is what makes MPP particularly competitive for Circle. MPP treats USDC as one option among many rather than the default; it can route an agent payment around stablecoins entirely onto a card, and Tempo, Stripe's own chain, settles all stablecoin payments. MPP doesn't exclude USDC so much as commoditize it, turning Circle's core asset into interchangeable settlement under Stripe's orchestration.

Coinbase is simultaneously Circle's largest distributor (~$19B USDC) and its largest structural risk. Under the current revenue-sharing agreement, Coinbase receives 100% of reserve income on USDC held on its platform, and 50% on USDC held elsewhere. In FY2025, Circle retained $1.083B of $2.747B in total revenue and reserve income after distribution, transaction, and other costs, meaning the majority of gross monetization was paid out through the distribution layer, principally to Coinbase, a partner that neither issues USDC nor manages its reserves. Coinbase's share of average USDC balances rose from roughly 5% in early 2023 to about 24% by the end of 2025, growing through the 2023 contraction even as total balances fell, and because the agreement pays Coinbase full reserve income on-platform and half of the rest, by Q4 2025 Coinbase captured the economics on roughly 62% of all average USDC while holding under a quarter of it.

The deeper risk with Coinbase is positional; Coinbase created the x402 protocol and owns AgentKit, CDP wallets, and Base, and it runs the protocol's default facilitator, the service that verifies and settles x402 payments on the seller's behalf. That facilitator is the one most USDC settlement currently routes through, so even on its own asset, Circle does not own the point where agent payments clear. If agent workflows standardize on this stack, Circle is relegated to backend issuance while Coinbase owns both the developer relationship and the settlement path.

The facilitator role is where Circle pushes back most directly, and it makes another case for the Agent Stack. Through Gateway, Circle now runs its own facilitator for batched USDC flows, and switching to it is a server-side change rather than a re-architecture. It does not displace Coinbase as the network default, but it gives Circle a settlement path it controls around its own asset, with batched economics a per-payment facilitator cannot match at sub-cent denominations.

Tether was, is, and will be Circle’s biggest competitor. USDT circulates around $183B, and dominates on Tron and in emerging-market cross-border flows. The issuer reported strong Q2 numbers, including over $1.5B in net profit. Tether has made an active effort to integrate its stablecoin into AI-native environments, but importantly its AI strategy is architecturally different from Circle’s: the Wallet Development Kit and the QVAC local-first AI SDK target sovereign agents that run on-device and offline, bypassing the banking-API dependencies that Circle and Stripe rely on, and its self-custodial wallet pairs USDT, USAT, BTC, and gold with on-device AI. However, there are chinks in Tether’s armor, the biggest ones being regulatory hurdles, that could outweigh a lot of technical development progress. USDT is not MiCA-compliant, with major EU exchanges having delisted it as MiCA took effect. Tether has aimed to concentrate in non-MiCA, non-US markets while launching a separate US-compliant stablecoin, USAT, launched in January 2026 through Anchorage Digital, a federally chartered US crypto bank, though USAT’s total circulating supply ($185m) is notably

Lastly, the set of potential stablecoin issuers is only widening, which threatens USDC's default status more than any single rival. Enterprises can launch their own coins and stacks to avoid dependence on Circle. Polygon announced its "Open Money Stack" on January 8, 2026, repositioning as payments infrastructure, PayPal launched PYUSD years ago, and Western Union launched USDPT, a regulated dollar stablecoin issued through Anchorage Digital on Solana, in May 2026. The counterclaim here is that though launching a branded coin has become much easier than in years prior, it is almost always done through a regulated issuance-as-a-service partner rather than built in-house. Few enterprises want to run reserve management, monthly attestations, and money-transmission compliance themselves. A branded coin also starts with no liquidity, no integrations, and no acceptance, so the binding constraint is distribution and liquidity. Working with an established stablecoin issuer is, by default, the easier path.

Regulatory Risk

No US or EU regulation directly targets autonomous agent payments as of mid-2026; existing AML, KYC, and Bank Secrecy Act obligations reach them through the issuer. The GENIUS Act, signed July 18, 2025, is a net positive for Circle. It requires 1:1 backing in cash and Treasuries, monthly reserve disclosures, bars non-permitted issuers from the US market, classifies payment stablecoins as neither securities nor commodities, and prohibits issuers from paying yield or interest to holders, a provision that legitimizes Circle's existing model while foreclosing yield-bearing competitors. Broader market structure in the US is still being worked on via the CLARITY Act, which passed the House 294-134 on July 17, 2025, cleared the Senate Banking Committee in May 2026, but has yet to receive a full Senate vote. Overseas in the EU, MiCA has governed stablecoins since 2024. Circle's French entity holds a MiCA e-money license and EURC is compliant, while USDT is not. Circle's regulatory moat, money-transmitter licenses across US states, a NY BitLicense, FinCEN registration, a Singapore MPI license, and regulated entities in Japan, the UAE, and Hong Kong, is strong in today's environment. The open risk is forward-looking, since a future AI-specific payment framework could impose obligations the issuer layer, Circle included, does not yet satisfy.

Open Questions

Arc and Its Growth

Arc is the clearest lever for Circles velocity problem, and its economics are unproven. By using USDC as the native gas token, Arc lets Circle capture value per transaction rather than per dollar held. What remains unknown is adoption and pricing. If Circle subsidizes gas or activity to bootstrap the network, it trades near-term fee capture for volume, and the velocity-capture thesis only pays off once unsubsidized fee revenue scales. Arc's first-year fee economics after mainnet will show whether it decouples revenue from float or runs as a strategic cost center.

Which rails win agentic payments?

Nothing yet implies that Circle's Agent Stack becomes the default rail for agent payments. Circle is not the only one building here, and the most complete rival is Coinbase, which created x402, runs the facilitator most x402 payments settle through, and owns AgentKit, the CDP wallets, and Base, the chain where most x402 activity happens. Stripe has its own chain, Tempo, and the Machine Payments Protocol. AWS's AgentCore Payments routes through x402 on Coinbase's Base rather than through Circle.

Circle's position here is a unique one. Because its stack is x402-compatible rather than proprietary, it can win share inside the standard without having to displace it, and USDC already settles nearly all x402 volume. But the facilitator and developer stack belong to Coinbase, so even when a payment settles in USDC, the developer relationship and the settlement path frequently run through Coinbase's rails rather than Circle's. The question then becomes whether developers adopt Circle's wallet-and-Nanopayments bundle directly or simply use USDC as the settlement asset under another orchestrator.

Stablecoins or Cards?

A related open question is whether agents simply use cards instead of stablecoins, and what Circle does in that case. Mastercard launched Agent Pay in April 2025 and completed its US rollout by November, built on what it calls Agentic Tokens, a card credential bound to a specific agent with per-session and per-merchant spending limits. Visa shipped Intelligent Commerce, which lets an agent present a verifiable credential a merchant checks before accepting payment. Stripe's Shared Payment Tokens, already used by Etsy and Urban Outfitters' parent company URBN, let an agent pay with a customer's existing card without exposing the card number.

The likely outcome is a world where there's some mesh between stablecoins and card network rails because they serve different purposes in domestic and global remittance.

The case for cards is pretty straightforward: a developer building a consumer shopping agent already understands cards, reaches almost any merchant through them, and gets chargeback protection a stablecoin transfer does not provide. But cards are built for buying from merchants, and a whole class of agent payments has no merchant on the other side, agents paying other agents, paying for API calls, data, and compute, settling across borders, all more efficient on stablecoin rails. The more likely outcome is that the two rails get built out in parallel, serving different segments with different needs, and which rail wins remains open.

AI Hardware

AI hardware like physical agents and edge devices is an adjacent demand source that could accelerate or bypass the Agent Stack. Circle's demonstration with OpenMind, in which an autonomous robot recharged itself by paying in USDC through Nanopayments, is an early instance of a payment loop initiated by hardware. The open question is which architecture succeeds, since Circle's Agent Stack assumes cloud-connected agents that can reach its APIs, while Tether's QVAC SDK is a bet that the hardware layer favors local, bank-API-independent designs.

The Role of On-Offramps

Agents are funded once and then transact thousands of times, so the ramp-to-transaction ratio diminishes, but ramps do not become less important. Custody and fiat conversion concentrate the majority of a payment system's operational risk, and whoever owns the ramp owns the edge where the workflow meets the real world. Circle already has the CPN for this. The competitive question is whether CPN's institutional, bank-facing design wins the same ground Stripe's Bridge covers at the developer-API level, since the ramp an operator reaches for shapes which settlement asset its agents default to.

Privacy features

Privacy will be a critical factor in the adoption of stablecoin rails, particularly for institutions and enterprises. USDC is fully public on every chain today. Arc offers opt-in privacy with sub-second finality and quantum-resistant signatures at mainnet, but relying on Arc alone leaves USDC on every other chain transparent, which is why we believe the stronger move is for Circle to launch its own privacy layer for USDC across all supported chains.

Taken together, the risks and open questions come down to the same underlying tension: Circle controls the asset, but not yet all the layers built on top of it. The structural risk is that velocity rises faster than supply, thinning the float Circle's revenue depends on. The competitive risk is that someone else owns the layer where agent payments actually clear, Coinbase through the x402 facilitator and its developer stack, Stripe through a multi-rail protocol that treats USDC as one option among many, Tether and a widening field of issuers competing for the same default status. The open questions are the flip side of the same point, whether agents settle on Circle's rails or on cards, whether developers build on Circle's stack or merely use USDC as settlement under another orchestrator, whether the ramp, the hardware layer, and the privacy layer end up belonging to Circle or to a competitor. Each brings us back to one main question, whether Circle owns the layers agents actually use.

Closing Thoughts

The stablecoin issuer is one of the most unique business models in payments today, because it is the only business that actually owns the asset being moved around. A card network or payment processor moves money that belongs to banks and cardholders, and charges a fee for handling it. A stablecoin issuer takes custody of deposited dollars, provides a digital equivalent to the depositor, parks the real dollars somewhere, like short-dated Treasuries, and keeps the interest as well. This wasn’t always a lucrative position; for most of stablecoins' history the asset sat idle as exchange collateral and trading margin, traders held stablecoins to post against leveraged positions and to move between trades without returning to the banking system, and stablecoins existed to sit idle mostly (CeFi does still account for roughly $75B of attributable supply and DeFi another $25B, while payments remain negligible). What stablecoin reserves earn depends largely on the Federal Reserve's policy rate (since they are held in short-term US Treasuries), and that rate was effectively zero from March 2020 until the Fed began raising it in March 2022, meaning issuers’ reserves earned relatively little through the years stablecoin supply was growing fastest. And the lack of regulatory clarity had kept institutional payment volume away, as up until the passing of the GENIUS ACT in July 2025, it was unsettled whether stablecoins were securities, which agency supervised the issuers, and whether banks could hold them. Another major hurdle on the regulatory side that remains is the to-be-passed CLARITY ACT, but time will tell.

Agents are the next source of growth for the stablecoin business, and a structurally larger one than anything that came before, because they feed both sides of the issuer's economics at once, float and movement. On float, an agent cannot pay from an empty wallet. Payments execute against whatever balance the wallet holds at the moment a condition triggers, and a transaction that fails for insufficient funds stalls the entire workflow it was part of. Operators therefore fund wallets in advance and replenish them periodically rather than topping up on demand, which means the balance sits there for the entire period the agent is running, not just at the moment of a purchase. This is a different kind of demand than the issuer has seen before. Human-held stablecoin balances depend on someone deciding to save, to hold collateral, or to wait for an opportunity, and those decisions reverse. An agent's balance is an operating requirement that exists because the software otherwise simply cannot function without it. And because an agent costs almost nothing to run, a company can deploy thousands as easily as one, each with its own funded wallet, so the supply added scales with how many agents are deployed rather than with how much anyone chooses to hold.

On movement, agents pay in amounts that run to fractions of a cent, at a frequency no human-operated business would ever generate. A single agent working through one task can trigger dozens of payments in the time a person makes one. That activity produces transaction volume and transaction count across the settlement infrastructure the issuer has built, and the fee-bearing parts of an issuer's business earn on how often the asset moves. This activity also provides free, self-reinforcing distribution. A service that wants agent customers (e.g. API providers, data vendors, compute hosts) has to accept whatever token those agents are funded in, so every service that adds support makes the token more useful to fund the next agent with, and each seller that starts accepting the token gives operators one more reason to fund the next agent in it, which gives the next seller one more reason to accept it.

At Shoal, we believe Circle holds the strongest position among issuers here. USDC has operated since 2018 and has been tested twice in conditions that destroyed comparable assets: the Terra/LUNA collapse in May 2022, when an algorithmic stablecoin holding no dollar reserves unwound to zero, and the FTX failure that November, when one of the largest distributors of stablecoins became insolvent. Through both, USDC kept redeeming at a dollar on demand. USDC settles 99% of x402 payment volume, and Circle captured that share before it had built anything specifically for agents. The Agent Stack verticalizes the wallet, discovery, and payment layers, and builds the remaining layers around USDC: Nanopayments for settlement at fractions of a cent, Agent Wallets for custody with spending rules enforced before execution, Agent Marketplace for discovery, and the CLI and Skills for developers wiring it together. The regulatory position lowers the cost of building on it, because transactions settle through licensed entities and screening runs at the protocol level, so a developer inherits money-transmission compliance rather than securing it in every jurisdiction its agents touch. And pre-funded agent balances expand the reserve base the whole business runs on.

The risks are real and the open questions unanswered, and most of them are versions of the same question: whether Circle ends up owning the layers agents actually use. Velocity is the structural risk: if each dollar does more work, fewer dollars are needed to support the same volume of payments. Circle could therefore end up settling far more agent activity than it does today while the float those payments run on grows slowly or not at all, which means usage rises and the revenue base does not follow. Competition is the more practical risk, which boils down who actually owns the point where a payment clears and not just what asset it clears in. Coinbase created x402, runs the facilitator most payments clear through, and owns AgentKit, CDP wallets, and Base, so USDC moves underneath while Coinbase owns the developer relationship. Stripe makes USDC replaceable as its Machine Payments Protocol settles the same charge in a stablecoin, on a card, or in Bitcoin, and Stripe owns the layer choosing between them. Tether makes a different architectural bet on AI, a QVAC SDK aimed at agents running locally on-device, without the cloud and banking dependencies Circle's stack assumes.

Every dollar stablecoin looks and functions much the same at the point of settlement (e.g. the same peg, same redemption, same public chains). A developer choosing between stablecoins gains nothing from the asset alone, and launching a new stablecoin has never been easier than it is today. What takes time is everything built around the stablecoin: reserve management at scale, money-transmitter licenses across every state and jurisdiction an agent might touch, monthly third-party attestations, MiCA compliance in the EU, banking relationships deep enough to honor redemptions during a panic, and the years of distribution and integration work that make a token something other businesses already accept rather than something they have to be convinced to adopt. None of that can be assembled quickly and none of it can be bought, which is why so few issuers are positioned to compete at all. The Agent Stack is that same institutional capability pointed at a new kind of customer, since policy-controlled wallets require the custody and screening infrastructure Circle already runs, sub-cent settlement requires the batching and cross-chain rails it already operates, and a marketplace only works if the asset is already accepted widely enough for agents to spend it.

Circle has built a strong defensible position to benefit from the onset of agentic commerce, but only time will tell how large that market becomes, and how much of the value comes full circle.

Sources

Allium. (n.d.). x402 onchain transaction data: facilitator volume, transaction counts, and unique buyers [Data set]. https://www.allium.so

Artemis. (n.d.-a). Circle Internet Group Inc. (CRCL) dashboard [Data set]. https://www.artemis.ai/company/CRCL?tab=dashboard

Artemis. (n.d.-b). Stablecoin supply by token [Data set]. https://www.artemis.ai/sectors/stablecoins/by-token

Artemis. (n.d.-c). Stablecoin supply overview [Data set]. https://www.artemis.ai/sectors/stablecoins/overview

Artemis. (n.d.-d). USDT vs. USDC comparison [Data set]. https://www.artemis.ai/sectors/stablecoins/compare

Circle. (n.d.-a). Agent stack. Circle Developer Docs. https://developers.circle.com/agent-stack

Circle. (n.d.-b). circlefin/skills: Circle's open source skills for AI-assisted development [Code repository]. GitHub. https://github.com/circlefin/skills

Circle. (2026, March 20). Delivering sub-cent transactions to power the agentic economy. https://www.circle.com/blog/a-deep-dive-into-circle-nanopayments-gas-free-usdc-transfers

Circle. (2026, May 11a). Circle reports first quarter 2026 results. https://www.circle.com/pressroom/circle-reports-first-quarter-2026-results

Circle. (2026, May 11b). Introducing Circle Agent Stack: Financial infrastructure for the agentic economy. https://www.circle.com/blog/introducing-circle-agent-stack-financial-infrastructure-for-the-agentic-economy

CoinDesk. (2026, January 8). Polygon Labs unveils 'Open Money Stack' to power borderless stablecoin payments. https://www.coindesk.com/business/2026/01/08/polygon-labs-unveils-open-money-stack-to-power-borderless-stablecoin-payments

CoinDesk. (2026, January 31). Tether (USDT) net profits top $10 billion in 2025, held $17 billion gold and $8 billion bitcoin. https://www.coindesk.com/business/2026/01/30/tether-s-gold-holdings-top-usd17-billion-as-net-profits-surpassed-usd10-billion-for-2025

DefiLlama. (n.d.). DEX volume by chain [Data set]. https://defillama.com/dexs/chains

Eco. (n.d.). Mastercard Agent Pay explained. https://eco.com/support/en/articles/14845483-mastercard-agent-pay-explained

Forbes. (2026, June 7). Visa, Mastercard and Coinbase are fighting over how AI agents pay. https://www.forbes.com/sites/digital-assets/2026/06/07/visa-mastercard-and-coinbase-are-fighting-over-how-ai-agents-pay/

Mayer Brown. (2025, July 18). GENIUS Act signed into law: US enacts federal stablecoin legislation. https://www.mayerbrown.com/en/insights/publications/2025/07/genius-act-signed-into-law-us-enacts-federal-stablecoin-legislation

Schumacher, K., Roberts, R., & Giebel, K. (2025, October 17). The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants. McKinsey & Company. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants

Shoal Research. (2026). x402 facilitator volume analysis, 60 days to May 26, 2026 [Data set]. https://shoal.xyz

Shoal Research [@Shoalresearch]. (2026, December 2). x402 facilitator volume [Post]. X. https://x.com/Shoalresearch/status/2069519304236892629

Stripe. (2026, March 3). Supporting additional payment methods for agentic commerce. https://stripe.com/blog/supporting-additional-payment-methods-for-agentic-commerce

Tether. (n.d.). WDK by Tether. https://wdk.tether.io/

Tether. (2026). Tether posts strong Q2 performance, generates $1.5B net operating profit, maintains $4.11B reserve buffer, and expands gold holdings to more than 146 tons. https://tether.io/news/tether-posts-strong-q2-performance-generates-1-5b-net-operating-profit-maintains-4-11b-reserve-buffer-and-expands-gold-holdings-to-more-than-146-tons/

Western Union. (2026). Western Union launches USDPT on Solana, advancing regulated digital infrastructure for global payments [Press release]. https://ir.westernunion.com/news/archived-press-releases/press-release-details/2026/Western-Union-Launches-USDPT-on-Solana-Advancing-Regulated-Digital-Infrastructure-for-Global-Payments/default.aspx

"You have X years to escape the permanent underclass."

The Permanent Underclass is a concept plaguing the minds of all retail, operators, builders that exist in the AI-osphere. It is so sharp as a narrative it actually serves as a product itself, creating a flywheel that accelerates the possibility of the permanent underclass itself.

Personal experience using agents coupled with Opus 4.6 model, Kimi, and Codex 5.3 and others show the blue ocean orchestration capabilities between frameworks, tool calling and models. The tools are incredible, and very real which is not the question. The question is whether some of the narratives around them are serving you or serving someone else.

Like any narrative the "Permanent Underclass" is the most fit meme I have seen among folks on the cutting edge still building their path in the space. The concept has burrowed itself into all mainstream consumer social media, not because a single person is orchestrating and pushing it but because the idea is the most physically fit. Your average college engineer has peak anxiety amongst exams and graduating. Your average founder is asking "what is our AI plan?".

So what is Permanent Underclass actually saying?

The phrase stripped and reduced down to: AI will divide society into those with the resources to compete and those without, and this division will be permanent.

Its not something like "you will lose your job" because a job is replaceable. The message in two words is you will permanently lose your mobility which is orders of magnitude worse. Emotionally this bypasses rationality and kicks in survival instinct pointing resource agency inward:

• Study harder

• Buy more tokens

• Deploy more bots

Posts like the viral "Something Big is Happening" post don't aid but fuel the flywheel itself. The fuel is not just emotional, it allows for visceral action leading to different behaviors.

Notice what this phrase forces you to accept:

1. That AI displacement will perpetually outrun policy adaptation.

2. That individual action, and not policy, is the relevant response.

3. That "escaping" is even possible through personal hustle.

This post follows the exact structure: frame urgency through historical analogy, imply you're already behind, and let the reader's survival instinct do the rest. Let's assume it is not intended to be malicious, but it's perfectly inline with the permanent underclass narrative, which has already proven to be one of the most fit memes in this AI space.

None of these are given, but conceptually the permanent underclass doesn't need to be true. It just needs you to feel like they are, long enough to act. That action is going straight into the products themselves, and that's what makes it a product. The Permanent Underclass sounds like a prediction but it serves NOW as an effective funnel. The anxiety it generates is the top of that funnel to every course, API credit, tool wrapper and vibe coded app.

However, it is important to understand the underclass rhetoric is a flywheel accelerating the fear itself.

AI displacement is rational and clearly real and visible (Amazon layoffs), even if indirect (AI budget allocation, not automation displacing). But the Permanent Underclass as a concept is structurally not the same thing, and the emotional weight functions to create different actions.

The narrative isn't right or wrong, rather, its structurally compromised. But consider:

Are you funding the infrastructure that would displace you, using money extracted by the fear of being displaced? Right now, the only thing that's certain is that the fear of it is transferring your money to the people selling the escape hatch.

Before you buy the next tool, course, or subscription, ask yourself one question: am I solving a real problem I already have, or a problem someone told me I'm about to have?

Every second, ~80+ million HTTP requests are sent over the internet on average. In that same second, Visa can handle no more than 65,000 payments, and Mastercard around 20,000.

Machines move data at the speed of the web. What happens when they start to move money the same way?

Machines are Moving Money

In the blink of an eye, LLMs have evolved beyond simple Q&A chatbots into context-aware, tool-equipped economic actors we now call agents.

No one quite knows how this development evolves from here, but payment incumbents wasted no time hedging their bets; Visa launched its Trusted Agent Protocol and a new CLI for agent payments; Mastercard released Agent Pay and Agent Suite, and in March executed Europe’s first live AI agent payment within a regulated banking framework alongside Banco Santander; American Express just recently announced the ACE developer toolkit, just to name a few names. Few compare to Stripe’s efforts, however, whose agentic stack now spans new agent payment primitives, business and developer tooling, and co-authoring an open-source payments protocol purpose-built for machine-to-machine payments.

Amid a great deal of warranted skepticism surrounding the impact of AI agents, trillion dollar market cap companies who certainly know a thing or two about payments are allocating significant resources to help software pay for software.

A payment is simply a way to settle an obligation: to exchange value for access to a specific good or service. For an agent, a payment may be the single blocker between a decision and a realized outcome by unlocking access to a necessary resource in a workflow the moment it’s needed. ‘Agentic payments’ and ‘agentic commerce’ have become the umbrella terms, and though the branding could use some work, the category has evidently materialized.

The interesting question remains what the supporting infrastructure will look like. Before we get there, it’s worth reviewing what it actually means when machines are moving money.

Intention Is All You Need

The free open public access to the internet we know and love is subsidized by advertisements. Bryan Kim puts this well:

“Internet advertising has created one of the greatest “public goods” in history, for the negligible price of occasionally having to look at ads for cat snuggies or hydroponic living room gardens.”

Google, Facebook, YouTube, and TikTok, have generated billions of dollars through ads, a simple act of monetizing basic human behavior: uncertainty. The gap between what someone intends to do and what they actually end up doing is the very premise of the attention economy. Every commercial webpage someone loads is an opportunity to present an ad to a persuadable consumer.

This model collapses when the primary consumer is an AI agent, who is a far more rational economic actor than a human by design.

An assigned task and a set of tools to complete that task (e.g. “Build me X using Y within budget Z”) leaves little room for ambiguity, while the lack of a limbic system means no susceptibility to the emotional pleas of advertisements.

Agents as consumers exhibit behavior patterns quite distinct from humans. They don’t face the same cognitive constraints that humans do; their very purpose of these machines is to multiply our output by orders of magnitude. Importantly, this means their resource consumption is far more granular: they require more resources, more frequently, though often at much smaller quantities (per-call, per-request rather than per-seat or per-month).

• A coding agent tasked with fixing a bug reads files, runs terminal commands, calls a code execution sandbox, and iterates on the output across dozens of API calls in a single session. Each call is billed by the model provider per token consumed. A single debugging session can consume 50,000 to 200,000 tokens across planning, editing, testing, and verification.

• A research agent compiling a market analysis might query a financial data API, a news archive, a web scraping service, and a document search index, each at a different price point, each needed at a different point in the workflow.

The transactions occur at runtime: the exact point in a workflow where a capability gap appears. Simon Taylor refers to this as the intention economy: the consumer, now an agent, arrives with a predetermined intent and moves money only if necessary to fulfill that intent.

Importantly, the byproduct of empowering AI agents as consumers is requiring new business models to accommodate them. Here we see the headless merchant emerge. Building on the increasingly popular headless commerce model, in which an e-commerce app’s frontend (user interface) is separate from its backend (data and core business logic), the headless merchant removes the frontend entirely because the buyer, an agent, has no eyes and preference for UX. The headless merchant simply needs a server, a set of API endpoints to call, a designated price-per-call, and some way to accept payments.

Several takeaways follow clearly from this. Payments need to be granular, meaning small enough to settle a single API call or token batch. They need to be programmatic, meaning triggered by code as a function call rather than a human action. And they need to be real-time, firing at the exact moment a capability gap appears in a workflow. The architecture of today’s ad-subsidized web is largely path-dependent on monetizing human uncertainty. But the intention economy, which monetizes outcome, needs its own corresponding payment infrastructure to match.

Moving Money On The Web

To understand where agent payments are going, it helps to first understand how online payments actually work today.

Online payments today involve entering a card number, clicking “pay,” waiting for a confirmation, a process that travels across web infrastructure the same way any other data does. But importantly, the web infrastructure simply provides the communication layer in this flow. Card details move as a POST request to a payment processor, which calls a card network API, which calls the payer’s bank. The actual payment, authorization, and settlement logic all lives in infrastructure layered on top of the web.

The likes of Visa, Mastercard, AmEx are building agent payment infrastructure on top of these same rails, intent on making their existing middleware smarter. What if instead, online payments worked the same way data does? What if, say, a server could respond to a request with a price, the client could pay online, and the resource delivered in the same round-trip?

HTTP standardizes how clients and servers exchange information on the web: a client sends an HTTP request, a server returns an HTTP response. A client can be anything from a browser to a mobile app to an AI agent. When a request succeeds, the server returns HTTP 200 OK. When a page doesn't exist, HTTP 404, meaning there is an error. When access is unauthorized, the server returns HTTP 401. These status codes are built directly into the protocol itself.

That question was first posed some 30 years ago, when the original HTTP spec was published, and with it status code 402: Payment Required. 402 sat between 401 (Unauthorized) and 403 (Forbidden) and like its neighbors, signals that the client must satisfy a condition before the server delivers the requested resource. 402 was designed for that condition to be a payment.

The core mechanism was simple:

1. A client requests a gated resource.

2. The server responds 402 with a price, accepted payment method, and recipient.

3. The client pays and retries with proof of payment in the header.

4. The server verifies and delivers the resource.

And yet over the years, 402 was never formally defined. There were a number of notable attempts: the W3C tried twice in the 1990s; Adrian Hope Bailie of Ripple proposed a concrete Pay header implementation in 2017, but none ultimately gained enough traction to be implemented. The simple reality was that humans already got accustomed to credit cards and thus the need was never acute enough to prompt a solution.

But time has passed, and AI agents are becoming a primary web client and user interface alongside browsers. The human is still in the loop, but agents equipped with real-time context and tooling make requests against the web at a far greater scale and frequency. When an agent encounters a resource it needs in a workflow, payment is simply its next function call, which either resolves and the task continues, or doesn’t and the task stops. The flow is elegantly simple: an agent hits a resource boundary, the server returns a price signal, the agent pays inline and proceeds with its task.

The x402 protocol was the first implementation of the 402 primitive to gain meaningful traction, launching in May 2025 under Coinbase before being contributed to the Linux Foundation as a vendor-neutral open standard. MPP, Tempo’s open-source framework built with Stripe, followed in March 2026, bringing fiat and card rails into the same protocol loop, as well as the first (formal proposal to implement HTTP 402 via IETF draft). Their differences raised the obvious questions: how do the two diverge, and which is better suited for which use case?

These are the right questions. They are also premature without more context. x402 and MPP are not the first attempts to build payments into the web at the protocol level. What differs across implementations is everything around that core loop: which rail settles the transaction, how proof-of-payment is structured, what metadata the headers carry, and how much complexity the client needs to handle.

The HTTP 402 Landscape

When Bitcoin emerged in 2009, it introduced a digital currency, with a native payment rail, that had no fixed transaction fees or intermediary. For developers curious about HTTP-native payments, the connection to 402 was immediate. As early as 2011, Bitcoin Core contributor Matt Corallo wrote in a thread on the Bitcointalk forum that he believed HTTP 402 “would be a great use case for Bitcoin”. His proposal suggested a server returning a 402 alongside an X-Bitcoin-Address and X-Bitcoin-Price header, with a browser plugin handling payment automatically in the background.

Early experiments were mostly small and independent efforts. In 2014, Benedict Chan demoed Zero Click: a server that returned a 402 Payment Required status code with a Bitcoin address and amount in the header, a Chrome extension ran in the background, automatically paid for the page and requested it again. In 2015, the anonymous author of Amphibian Abstracts published one of the earliest public 402 Bitcoin demos using custom headers (X-Payment-Types-Accepted: Bitcoin, X-Payment-Address-Bitcoin: putarealbitcoinaddresshere, X-Payment-Amount-Bitcoin: 1.234) passing payment type, address, and amount directly in custom HTTP headers. Neither Zero Click nor Amphibian’s demo was a formal protocol, but these experiments helped show the basic HTTP 402 loop was at least viable.

The 21 Bitcoin Computer

In 2015, Balaji Srinivasan’s 21co introduced the 21 Bitcoin Computer: a Raspberry Pi device featuring a built-in Bitcoin mining ASIC as well as a micropayments server accessible from a command-line interface (CLI). A core part of the product was the two1 open-source Python library that shipped alongside it, which allowed users to mine Bitcoin, use it to buy and sell API calls, set up world-readable machine-payable endpoints, and publish them to the 21.co marketplace from any Unix command line.

Two1’s module exposed a @payment.required(price) header that could be placed in front of any Flask or Django routes, two widely used Python web frameworks for building HTTP APIs. When a client would request to access a paid endpoint, the server provided a HTTP 402 Payment Required response header alongside a Bitcoin payment address and the required payment amount. On the client side, the class wrapped Python’s standard library and upon receiving a 402 response, it automatically handled the micropayment and retried the request. Notably, the HTTP 402 handshake itself was abstracted away from the developer.

A machine with a Bitcoin private key could possess, send, and receive money to another machine without a human intermediary in the loop. Fundamentally, this was all just developer tooling, but Balaji argued the implications ran deeper as part of a progression through three distinct webs: first the World Wide Web of documents connected by hyperlinks, then the social web connecting people through platforms like Facebook and LinkedIn, and then the Machine Web, where the links between nodes are payments between machines.

The line of thinking was simple: given that the web had already standardized how machines exchange information, and how people form relationships, its next problem to solve was to standardize how machines exchange money. 21co’s Bitcoin software could monetize APIs on a per-request basis without requiring developers to provide or accept credit cards, let any developer with some bitcoin call out to another endpoint as easily as importing a library, and unify fulfillment and billing into the same series of packets.

Beyond simple per-call payments, 21co implemented payment channels on a bar tab model: one deposit transaction opened a tab, high-frequency micropayments occured off-chain, and only two onchain transactions settled the whole session. The developer toolkit also enabled developers to chain paid APIs together and sell the composite pipeline, setting up a supply chain of machine-to-machine payments that could be triggered by a single client call.

As interesting as the ideas were, however, 21co’s Bitcoin computer proved to be ahead of its time. As Bitcoin network congestion grew through 2016-17, transaction fees made sub-cent micropayments economically unviable. The core concept, however, remained intact and inspired future HTTP-402 payment protocols.

L402

In March 2020 Lightning Labs launched L402, which remains the oldest active HTTP-402 implementation to date. L402 is an open-source payments framework that pairs the HTTP 402 status code with Bitcoin Lightning Network invoices and Google macaroons to enable clients to request, pay, and access web resources

L402’s implementation of HTTP 402 works as follows: when a client requests a paid resource, the server responds with an HTTP 402 status code as a payment signal, and includes everything the client needs to pay and gain access in that single response. This intuitive multi-step HTTP handshake is the same foundational structure that x402 and MPP have followed.

To better understand how L402 works, some familiarity with macaroons helps. A macaroon is a small piece of data that a server generates and hands to a client as proof that the client is allowed to access a specific resource, also known as a bearer token.

In L402, when a client, say an AI agent, wants access to a paid resource, the server generates a macaroon and Lighting invoice together. The invoice, denominated in satoshis (sats), is the payment request; the macaroon is the access credential which becomes valid to use once the invoice is paid. The server combines the two by embedding the invoice’s associated payment hash inside the macaroon. This payment hash is produced by the server taking a secret value, called the preimage, and running it through a sha256 hash function. By design, the only way to reproduce the preimage is to actually pay the Lightning Network invoice.

The client then utilizes a connected Lightning Network node or wallet client to route the payment and pays the invoice. Once paid, the Lightning Network reveals the preimage to the client, who then presents both the preimage and macaroon to the server, which runs one specific check: does the sha256(preimage) match the payment hash embedded in the macaroon? If yes, the payment is proven and the client is granted access to the resource. Importantly, the current spec under bLIP-0026 is token-format agnostic, meaning macaroons are no longer required, and any token that commits to a payment hash is accepted.

Putting together the complete L402 payment flow:

• A client (e.g. an AI agent) sends an HTTP request to a gated endpoint.

• The server responds with HTTP 402 Payment Required and a WWW-Authenticate header, which contains two values in a single response: the macaroon and a Lightning invoice.

• The client pays the Lightning invoice and receives the preimage.

• The client retries the original HTTP request with an Authorization:L402 header containing both the macaroon and the preimage.

• The server verifies the credential and provides the resource.

L402’s payment model is pay-per-credential rather than pay-per-call. A client pays a Lightning invoice once and receives a macaroon that is cached and reused for subsequent requests to the same service until it expires or is revoked. The broader L402 community spec extends the model further, defining offer types including one-time access, monthly subscriptions, and pre-purchased credit bundles, with payment methods covering Lightning, onchain, and credit cards.

The Current State of L402

L402’s original pitch was to be an alternative to credit cards and email signups for accessing paid APIs. Aperture, Lightning Labs’ Go reverse proxy, implements the full L402 lifecycle and has been in production since 2020 powering Lightning Loop (non-custodial swaps) and Lightning Pool (p2p liquidity marketplace). In practice, however, L402’s architecture maps more cleanly onto machine clients than human ones, and AI agents have become L402’s primary use case. A new agent-spec.md condenses the entire protocol into ~560 tokens for embedding directly into agentic context windows, meaning AI agents can now load the full L402 spec at runtime and implement the handshake autonomously.

The numbers, as of early 2026, indicate that L402 is live but still early. The new Github repo grew to 213 stars on Github since early 2025; Satring currently tracks 58 live L402 services.

The most significant near-term catalyst for L402 is Taproot Assets, a protocol developed by Lightning Labs that allows stablecoins and other assets to be issued on Bitcoin and then transferred over the existing Lightning Network. Today when an L402-gated server generates a Lightning invoice, it is denominated in satoshis; the client pays in Bitcoin; the server receives Bitcoin, a volatile asset. Integrating with Taproot Assets resolves this by allowing the invoice to be denominated in a stablecoin like USDT or USDC while still routing over Lightning’s existing payment channels and settling in milliseconds.

In practical terms for L402: an AI agent making a paid API call would encounter the same 402 challenge and the same macaroon handshake it does today; the only change is that it can pay the Lightning invoice in stablecoins.

Tether has committed to bringing USDT to Bitcoin with Lightning Network support via Taproot Assets, and once widely routed, L402 will be able to settle in fiat-denominated assets over Lightning rails. Lightning Labs CEO Elizabeth Stark has explicitly cited increasing demand for USD machine-to-machine payments from AI agents and the L402 protocol as a primary driver for bringing stablecoins to Lightning.

L402 is the oldest active HTTP 402 implementation, with five years of production deployments, a formalized spec under bLIP-0026, and a credible path to stablecoin settlement via Taproot Assets. It proved the HTTP 402 handshake worked and that AI agents are a natural fit. Built entirely on Bitcoin and Lightning, L402 represents one distinct approach to 402-native payments.

x402

In May 2025, Erik Reppel, head of engineering at the Coinbase Developer Platform, alongside colleagues Kevin Leffew, Dan Kim, and Nemil Dalal published the whitepaper for x402: an open-source web payments protocol built on HTTP 402.

Similar to L402, x402 facilitates payments between web clients and servers through a multi-step HTTP handshake, but where it differs is the rail and payment model. Though the protocol initially rolled out with USDC payments on the Base L2, it has since evolved to support payments in stablecoins or any ERC-20 token across several chains including Base, Solana, Polygon, BNB Chain, Avalanche, Sei, and Arbitrum. HTTP is the primary transport layer and the 402 status code is the native signal, though the same payment logic can run over MCP or A2A.

x402 supports two core payment schemes: a straightforward pay-per-call model via the exact scheme, which transfers a fixed amount per request; and a pay-per-use model via the upto scheme, which authorizes a maximum amount upfront but only charges for actual consumption of resources.

x402 plugs into existing web infrastructure as lightweight middleware, with a full reference implementation including core protocol libraries, server-side middleware for Express.js and Next.js, and client libraries for browser and Node.js environments. Server-side implementation takes a single function call, and clients can pay any supported endpoint without a prior relationship with the resource provider. An AI agent can hit a paid endpoint, receive a 402, construct a signed payload, and settle the payment without any custom payment logic needed on top.

Putting together the x402 payment flow:

1. A client requests a paid resource from a server

2. The server returns HTTP-402 with machine-readable payment instructions.

3. The client constructs a signed payment payload and resubmits the request.

4. The payment is first submitted and settled onchain.

5. The settlement proof is passed back from the Facilitator to the server to confirm payment.

6. The payload is verified, and the server fulfills the original request.

7. Once confirmed, the server returns a 200 OK response alongside the requested resource and transaction proof to the client.

X402’s stablecoin-centric architecture removed the per-transaction price volatility present in Bitcoin-denominated micropayments. Each request is treated as a standalone payment, as the client constructs a signed payment payload, attaches it to the HTTP request, and the server verifies it onchain before delivering the resource. An agent can hit an x402-gated endpoint it had never encountered before, complete payment and receive its resource, without an API key, account creating or prior billing relationship with the server; a particularly useful feature for agents, who lack persistent memory across sessions by default.

The Current State of x402

The x402 ecosystem, made up of clients, servers, facilitators, as well as supporting infrastructure & developer tooling, is actively growing. $50.7M in total volume and 172M total transactions have been processed via x402 to date, featuring 734k buyers and 148k sellers as well. Agentic market currently tracks 68 active services agents that can call directly and pay for via x402.

Interestingly, though AI agents are actively integrating x402, humans still account for the majority of x402 payments today.

In December 2025, x402 V2 shipped, introducing reusable sessions, Permit2 support for any ERC-20 token, automatic service discovery, and resource metadata in 402 responses.

On April 2, 2026, dubbed “4/02 Day,” Coinbase contributed x402 to the Linux Foundation and the x402 Foundation was formally announced. The governing body is co-founded by Coinbase, Cloudflare, and Stripe. Expressed support and membership spans AWS, American Express, Google, Mastercard, Microsoft, Shopify, Visa, Circle, Adyen, Ant International, KakaoPay, Polygon Labs, and the Solana Foundation, among others. Shortly after, AWS Bedrock published a reference implementation of x402 for financial services agents, making it the first major cloud provider to embed x402 directly into its infrastructure.

For a deeper dive into x402, read When Machines Move Money.

MPP

On March 18, alongside Tempo’s mainnet, Tempo and Stripe introduced the Machine Payments Protocol (MPP). Similar to L402 and x402, MPP is an open-source protocol that enabling clients to pay for web resources through a standard HTTP handshake. Unlike its predecessors, however, MPP introduces a session model that builds directly on Liam Horne’s work on State Channels: an agent locks funds on Tempo once to open a session, makes as many subsequent requests as needed using signed vouchers offchain, and the server periodically settles the accumulated balance in a single transaction back on Tempo. The spec is open-source and accompanied by an IETF Internet-Draft (draft-ryan-httpauth-payment), the first formal attempt to give HTTP 402 standardized semantics through the internet engineering standards body.

MPP directly builds on State Channels: two parties lock funds in a multisig contract, exchange signed transactions offchain however needed, and simply settle the net result onchain in a single transaction. This is, in fact, MPP’s key differentiator: session-based streaming micropayments.

A “session” intent lets agents authorize a spending limit upfront, then stream micropayments as needed without onchain transactions required per each individual request that follows. The first request opens a payment channel for that specific client/agent, while subsequent requests use off-chain “vouchers”. The server periodically settles accumulated vouchers in a single batch transaction.

Putting together the entire MPP payment flow:

1. The client sends a standard HTTP request (e.g. GET /api/resource).

2. The server (running mppx, MPP’s reference TypeScript SDK and server middleware) contacts Stripe, which creates a PaymentIntent and returns a deposit address from Tempo.

3. The server returns HTTP 402 with a WWW-Authenticate: Payment challenge header containing the amount, accepted methods, deposit address, and a challengeId.

4. The client then fulfills the payment, which can be done either by signing a stablecoin transfer on Tempo; completing a card payment via Stripe’s Shared Payment Token; or paying a Lightning invoice).

5. The client retries the original request with an Authorization: Payment header containing the payment credential.

6. The server forwards the credential to Tempo for onchain verification.

7. Once verified, the server returns 200 OK with the requested resource and a Payment-Receipt header.

Importantly, for session-based flows, steps 2-7 only happen on the first request. Subsequent requests skip the chain entirely: the agent sends a signed voucher, the server verifies the signature locally, and delivers the resource.

MPP also provides a native MCP transport binding, which AI agents use to discover and invoke tools. If an agent calls a paid tool on an MCP server, the payment handshake happens inside the tool call itself via JSON-RPC error code -32042 (the MCP analog of HTTP 402), meaning the agent pays and receives the result within the same function call.

MPP is rail-agnostic by design, supporting stablecoin payments on Tempo, a high-performance L1 offering ~500ms finality, sub-cent fees, and stablecoin-denominated gas fees; credit and debit cards via Stripe’s Shared Payment Token; and Bitcoin via Lightning. Anyone can define a new payment method by publishing a spec against the MPP framework without permission from its creators.

The Current State of MPP

At the time of writing, MPP has processed ~$103k in volume and ~710k transactions across 68k agents and 2.7k servers in total.

MPP launched with an impressive list of design partners including Anthropic, OpenAI, DoorDash, Mastercard, Visa, Nubank, Revolut, Shopify, and Standard Chartered.

At launch, 100+ MPP-compatible services were listed in the payments directory. Services are specifically designed to be consumed by agents; Claude chat completions, headless browser sessions, containerized compute, onchain data queries across 80+ networks, domain registration, and SEC filing search. Live integrations include Browserbase, QuickNode, Parallel Web Systems, and PostalForm. Cloudflare’s Agents SDK provides full MPP support.

Because anyone can publish a new payment method spec against MPP, the protocol’s future is no longer restricted to the capabilities of Tempo and Stripe.

Emerging Developments Around HTTP 402

x402 and MPP are the most active implementations of the 402 primitive today, but they are not the only ones. A broader ecosystem of teams has been building around HTTP 402, each approaching the same underlying problem from a different angle.

• Cloudflare implements HTTP 402 in its pay-per-crawl feature. When an AI crawler requests a page on a Cloudflare-protected site, Cloudlfare returns a HTTP-402 with a crawler-price header, the crawler retries with a crawler-exact-price header, Cloudflare serves the content and logs the billing event. Publishers set a flat per-request price and can allow, charge, or block any crawler independently. Importantly, pay-per-crawl is in closed beta, but the initiative demonstrates HTTP 402 running at Cloudflare-scale between web content owners and AI agents.

• EVMAuth, built by Radius Tech is a Solidity smart contract (deployable to any EVM chain) that extends ERC-1155 to paygate web resources behind token ownership. It integrates HTTP 402 directly: when a client requests a gated resource without the required token, the server returns 402 with instructions to purchase the access token onchain. The client buys the token, retries with proof of ownership, and gets access. Tokens can represent subscriptions, API credits, time-limited licenses, or any access tier. For agents, this means access rights are portable onchain assets.

• OKX’s Onchain OS Payment is built directly on x402; When a client requests a paid resource, the server returns HTTP 402 with payment requirements. The client pays onchain and retries with a payment credential in the header. Settlement runs on X Layer, OKX’s native L2, where OKX subsidizes gas fees for clients.

• H402: H402, built by BitGPT, is an open-source fork of x402 with a five-stage deterministic payment lifecycle: Quote -> Authorize -> Broadcast -> Validate -> Settle. It extends x402 to include Bitcoin and Lightning Network payments alongside EVM chains and Solana, and features USDT support. Notably, unlike x402, H402 charges a 0.25% protocol fee per payment.

• x402z, co-authored by Mind Network and Zama, is building an agent-to-agent privacy-based payment solution, specifically built on Fully Homomorphic Encryption (FHE). Summarily, FHE enables computation on encrypted data without requiring decryption; applied onchain this enables validators to validate transactions (e.g. sufficient balance, valid signature) without seeing the amounts or balances. x402Z is built on Zama’s FHE stack, uses ERC-7984 (Confidential Token Standard) for encrypted transfers, and is currently in closed testnet.

An Important Consideration: Security Implications of HTTP

The security risks of HTTP 402 payments were being debated in 2012, when early Bitcoin developers raised the concern that a malicious server could use a 402 response to silently trigger payments without user awareness. The counterargument then was that HTTPS mitigates interception and that payment authorization should sit in a dedicated client rather than the browser.

That debate was never quite resolved, but it’s important to consider now as HTTP 402 adoption starts to pick up via L402, x402, and MPP activity.

HTTP transmits data in plaintext, and any intermediary between client and server, a router, a proxy, a compromised network node, can read and potentially modify what is being sent. HTTPS was created to solve this by wrapping HTTP in TLS encryption, making data in transit unreadable to anyone intercepting it. For payments this matters because payment credentials, wallet addresses, signed payloads, and payment amounts all travel in HTTP headers.

Importantly, HTTP 402 does not mandate HTTPS. Payment credentials, wallet addresses, signed payloads, and payment amounts all travel in HTTP headers, and whether that exchange is encrypted depends entirely on server configuration.

Beyond transport security, today’s implementations carry additional known tradeoffs. Payment credentials travel as bearer tokens in HTTP request headers, meaning anyone who intercepts a valid credential can potentially reuse it. A signed payment payload could theoretically be extracted and front-run; wherein a signed payment payload could theoretically be extracted from the request and submitted onchain before the intended recipient processes it. For $0.003 API calls the economic incentive to exploit this is low, but for higher-value transactions it is a meaningful gap. The IETF draft for MPP defers detailed security analysis to a future revision entirely. These are known tradeoffs, not unknown risks, but the security model of HTTP 402 payments is still a work-in-progress in its current state. Ultimately, security risk may prove to be the biggest bottleneck to the widespread adoption of HTTP 402 payments.

Closing Thoughts

We at Shoal believe the most interesting question in agent payments is not which protocol wins, but whether the infrastructure AI agents transact on ends up being designed for machines, or whether it ends up being the same rails humans use with a smarter wrapper on top.

HTTP 402 is, at its core, a long-standing but mostly dormant part of the native web. It gained no traction with human-centric payments, but machines present a new opportunity. The status code’s first experiments and live implementations were based on moving value between Bitcoin miners, nodes, and content servers. Today’s implementations target AI agents, paying for goods and services on behalf of humans directly as well as in their own workflows.

The thesis for HTTP 402 adoption is straightforward: the efficiency gained from expressing economic intent via HTTP is too valuable to ignore. A world in which agent payments drive meaningful volume, where tens of thousands of agents are autonomously transacting at the speed of the web across thousands of services, is only beginning to materialize. The question is what the payment infrastructure for that world looks like. Encoding payments directly into the web with HTTP 402 is one answer to that question. Whether it is the right one remains to be seen.

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

Sources

Data - Artemis, Dune, Github, x402Scan, MPP Scan

• @nlevine19, x.com/nlevine19/status/2036450698271785350

• “Open Agentic Commerce and the End of Ads.” a16z crypto, a16zcrypto.com/posts/article/open-agentic-commerce-end-ads

• @yq_acc, x.com/yq_acc/status/2037579506429657198

• “The Intention Layer.” Fintech Brain Food, fintechbrainfood.com/p/the-intention-layer

• “The 21 Bitcoin Computer.” Earn.com, medium.com/@earndotcom/the-21-bitcoin-computer-1d28d652b57b

• “two1 3.5.0.” PyPI, pypi.org/project/two1/3.5.0

• “two1-python Payment Decorator.” 21dotco, github.com/21dotco/two1-python/blob/master/two1/bitserv/django/decorator.py

• “True Micropayments with Bitcoin.” Earn.com, medium.com/@earndotcom/true-micropayments-with-bitcoin-e64fec23ffd8

• “Buy 50 APIs with Bitcoin in the 21 Marketplace.” Earn.com, medium.com/@earndotcom/buy-50-apis-with-bitcoin-in-the-21-marketplace-1fbf5208e397

• “L402 Protocol Documentation.” l402-protocol, github.com/l402-protocol/l402/tree/main/docs

• “L402 Protocol Specification.” Lightning Engineering, docs.lightning.engineering/the-lightning-network/l402/protocol-specification

• “x402 GitHub Repository.” x402 Foundation, github.com/x402-foundation/x402

• “x402 Documentation.” Coinbase, docs.cdp.coinbase.com/x402/welcome

• “MPP Overview.” Tempo, mpp.dev/overview

• “State Channels.” Liam Horne, liamhorne.com/state-channels

A special thanks to Lucas and Kevin for their feedback and review.

In 1849, tens of thousands of men went searching for gold in California. Some made out to be kings. Most made out poor. But the greatest success fell upon the merchants building picks and shovels: the foundational tools that would remain important so long as there was gold in the ground. Today’s gold rush is AI. Payments are becoming a foundational part of AI agent workflows, and inevitably, the rails facilitating those payments become today’s picks and shovels. In this paper, we dive deep into the x402 protocol; one particular emerging open agent-native payment rail, including what it is, how it works, where adoption stands today, and what open questions face x402 when machines move money.

A Seismic Shift Is Underway

History is defined by seismic shifts. Sudden, profound transformations that change the very foundation of life itself. The physical geography we inhabit today was formed some 175 million years ago when the Earth’s tectonic plates shifted and broke apart. Tectonic plates are still shifting today, albeit much slower, but the biggest seismic shifts in the modern world have materialized through human innovation.

Foundational inventions, be it the Sumerian wheel, the Gutenberg press, the steam engine yield a similar reinforcing flywheel: humans build machines, these machines yield economic surplus, which leads to more money for building more machines (and better ones at that) which further compounds the output. As technology improves, the cost of experimentation falls while the rate of iteration increases. We’ve seen this dynamic accelerate particularly within the last few decades with computers and the applications and services built around them.

Today this transformative dynamic is materializing through software, particularly artificial intelligence.

AI has been around for a long time. The first paper on neural networks was published as far back as 1943. Expert systems in the 80s and statistical machine learning in the 90s quietly embedded AI into production workflows, from credit scoring to ad targeting.

Spam filters, recommendation engines, and fraud detection have been running on machine learning models since the early 2000s. What changed is the interface. Generative AI lets humans interact with these systems through free-form natural language, and that shift in accessibility is what brought AI into mainstream consumer markets.

OpenAI launched ChatGPT as a simple and intuitive way to interact with its underlying GPT models, which reached 1 million users in 5 days and 100 million in 2 months, the fastest consumer internet adoption in history. Shortly after competing generative AI applications (e.g. Gemini, Claude, Grok) started rolling out, and the ensuing competition drove major AI labs to quickly improve models and ship new product features. On a darker note, fears of job displacement have mounted as corporate executives continue to iterate reducing headcount and increasing investments in AI (though it’s worth noting over half of US workers today are working jobs which didn’t exist in 1940).

No one can state with certainty how AI will ultimately reshape society. But as of late 2025, roughly one in six people worldwide have used generative AI, a technology that barely existed three years ago. While early, a seismic shift is well underway.

But there’s only so much to be done by simply talking to AI. Read access, e.g. letting LLMs look things up, condense large bodies of text, write code, analyze data, is evidently useful but only goes so far. But pairing that with write access, in other words letting AI actually do things across external environments, has unlocked an entirely different set of capabilities.

In 2025, OpenAI rolled out Operator and Codex, Anthropic shipped Claude Code, Perplexity launched Comet, Google embedded Gemini-powered agents across Workspace applications, Microsoft pushed Copilot deeper into Office and Windows. Perplexity, Cursor, Sierra, and Cognition each raised hundreds of millions in new funding and reached new all fun highs in revenue. It’s clear that agents will define the next chapter in how humans interact with AI.

But an overlooked reality is that autonomous agents have been driving economic activity online for years. The digital ads marketplace is one massive agentic economy operating beneath the surface of nearly every ad-supported webpage (which includes most large consumer sites and platforms today).

Whenever someone loads a site, the empty ad space is put up for sale in a mini-auction, and agents operating on behalf of advertisers (this could be any merchant selling goods online) determine how much that ad space is worth to them and submit bids. The highest bid wins and the winning ad is rendered in the slot, within hundreds of milliseconds. By the time the site loads, the ad is already displayed. To put this scale into perspective, consider that programmatic digital ad spend amounts to hundreds of billions annually, which accounts for over 90% of display ad budgets today.

Crawlers are another example. These autonomous agents roam the web, follow URLs, fetch webpages, and feed that content into large-scale indexing and training pipelines. Similarly, scrapers extract raw data from webpages and are actively used in a variety of fields today. On a darker note, “bad bots”, programs set up to exploit business logic online, accounted for as much as 37% of internet traffic in 2025. Collectively, over half of all web traffic is already run by autonomous software agents.

Yet evidently, few people know about these agents, and even fewer actually use them. However useful these agents may be at their particular function, e.g. bidding for ad space, their utility is limited by their purpose-built nature. A crawler crawls, a scraper scrapes, a bidder bids, and nothing more.

When these different capabilities are stacked together into one single program, controlled from one single interface, the nature of the application changes entirely. This is where the general-purpose AI agents most people know today come in. Their most foundational change is their ability to perform many different tasks and operate across multiple apps and environments within one interface. These agents were designed to accelerate human output and productivity: they do more things, at a much greater rate, and as their adoption grows, they generate an ever larger share of web traffic.

So what is exactly an agent? In simple terms, a goal-oriented software program which receives a goal, identifies the steps needed to achieve that goal, and takes action within certain environments using tools available at its disposal to achieve that goal.

A user types a prompt, which is then delivered to an agent’s runtime environment. From there, the agent provides a prompt to its model, which makes decisions and functions as the brains of the operation. The agent uses any available tools it may have access to (i.e. web browsers, APIs, databases, calendars etc) to carry out these tasks, and then carries out a cycle of absorbing information from its actions, reasoning about the information, and using this information to determine its next action or decision until the defined stopping point (e.g. the goal specified in the user prompt) has been reached.

Gartner predicts roughly 40% of enterprise applications will have task‑specific AI agents embedded by the end of 2026. McKinsey estimates AI agents account for $3–5 trillion of global consumer commerce by 2030. Goldman Sachs projects that by 2030, agents could erode meaningful TAM for SaaS by becoming a primary interface for knowledge work even as they expand the overall software market.

Of course, these are forecasts and not facts, and some predictions about the immediate impact of agents have already proven to be too ambitious. Nonetheless, it is difficult (and naive) to ignore the size of the bet being made here: if AI agents are to capture even a fraction of their predicted growth, they start to become consumers. And consumers need, first and foremost, a way to pay for the goods and services they wish to purchase.

Machines Need To Move Money

And so the role of money comes up. Money is a coordination tool: a shared medium of exchange and unit of account that enables humans to coordinate with strangers and settle transactions efficiently. It enables human societies to cooperate at scale; to compound individual effort into part of a greater productive whole.

As AI agents take on more economic responsibilities, they too require access to this shared coordination layer. But agents are a structurally different kind of consumer, with different behavioral patterns and optimization criteria. They don’t face the same cognitive or computational constraints as humans. Their very purpose is to multiply human output by magnitudes: more work, in far less time, though often through more frequent and granular consumption of resources along the way. Agents also aren’t susceptible to the emotional appeals that advertising deploys on human consumers. They are, by design, economically rational actors.

In this context, money plays a familiar but functionally extended role. As a medium of exchange it minimizes transaction friction, enabling seamless value transfer between agents. As a unit of account it provides the standardized measure agents need to conduct precise cost-benefit analyses, evaluating whether the compute cost of a task justifies its expected reward. And as a store of value it allows agents to preserve purchasing power and allocate capital efficiently across time and tasks.

To make use of these functions, however, we must distinguish between the asset itself and the infrastructure that moves it. Money is a coordination tool but payments are its mechanism of action. Stripped to its core, a payment is a way to settle an obligation: the process of reconciling a ledger to prove that value has actually changed hands. For an agent, this is the functional execution of a contract. It is the step that converts a decision into a realized outcome, unblocking access to a resource. Without this settlement capability, an agent is effectively stuck in a read-only state. Agents need a designated way to pay for goods and services online.

But Machines Already Move Money?

To state the obvious, this is already possible. AI agents already have access to infrastructure which trillions of dollars already move online every year through. These systems are built around what we can call checkout-specific flows. A (human) user confirms their purchase intent, a payment token is created for that transaction, and the merchant processes the payment through their respective PSP infrastructure.

Take OpenAI and Stripe’s Agentic Commerce Protocol (ACP) for example. ACP is an open‑source API specification that enables AI agents to complete purchases on behalf of users by standardizing how merchants expose their catalogs, how agents represent offers and carts, and how payment details are delegated back to the merchant’s PSP once the user confirms intent. The clearest implementation of ACP today is Instant Checkout in ChatGPT, powered by Stripe’s Shared Payments infrastructure. Through intuitive natural language language prompts, users can take care of shopping needs (e.g. buy running shoes, order takeout, book reservations) from the familiar ChatGPT interface. On the backend, ChatGPT delivers a scoped payment token to the merchant’s PSP, and the merchant charges for the payment.

Beyond ACP, agent payments are growing as the agentic commerce stack begins to form. Claude Code and Codex run workflows using prepaid balances on user accounts. OpenClaw takes this one step further and enables virtual cards with spending limits to be issued to an agent. Google’s UCP and AP2 use payment tokens linked to user credit cards and email addresses.

This system works. It prompts no immediate reinvention. For human-agent checkout flows, this model performs exactly as designed.

Machines Do Move Money, Just Not Autonomously

However, the point that really matters here is that this is not the the final form for agentic payments. This model becomes strained when applied to continuous agentic workflows at scale.

This emerging ecosystem is what has been characterized as a “virtual agent economy”: a set of linked digital markets where AI agents transact with one another to generate economic value independently of human labor. Critically, in such an economy, agents transact and coordinate at scales and speeds beyond direct human oversight. And this is where key economic and technical constraints begin to emerge within today’s commerce stack.

Protocols like ACP use legacy payment mechanisms: credit cards, digital wallets, BNPL services. Consumers and merchants using these protocols still absorb their economics: 2.9% + $0.30 per transaction, multi-day settlement, 120-day chargeback windows. Annoying but manageable for humans.

Agents, however, transact at a far greater scale. Agentic systems routinely decompose complex problems into granular distributed tasks worth fractions of a cent. Applied across thousands of steps, the cost structure collapses; consider that a $0.30 fixed fee on a microtask worth, say $0.02, is already a 1,500% markup.

Ultimately, this stems from a deeper architectural issue. As Felipe Montealegre articulates in Internet Finance, modern financial systems are just collections of private servers. Moving value requires permissioned administrators to reconcile entries across those servers, a process reflected in settlement delays and layered fees. When an AI agent initiates a purchase via a protocol like ACP, a synchronous chain follows: the request routes to Stripe, which routes to issuing banks. Stripe has its fee layer, Visa and Mastercard have theirs, banks have theirs. Each operates independently.

The efficiency of this reconciliation mechanism sets the speed limit for the entire economy. A 2024 BIS report found that a one-percentage-point increase in digital payment adoption corresponds to a 0.10 percentage-point rise in GDP per capita growth over two years. If removing friction for humans produces that, the implications for agents operating orders of magnitude faster are larger still.

There is also a less visible cost: permission itself. Legacy rails were designed around discrete human-to-human purchases with meaningful transaction sizes (e.g. at least a few dollars’ worth). The compliance architecture built on top, KYC, AML checks, chargeback systems, correspondent banking, reflects rational responses to legal liability at that scale. A $0.004 API call carries different risk than a $50,000 wire transfer, but today’s rails treat them with similar overhead.

Nick Szabo identified a related problem in 1999: mental transaction costs, that is, the cognitive burden of deciding whether a small purchase is worth making. Early micropayment businesses failed not because the technology couldn’t handle small payments, but because humans had to consciously approve each one.

Agentic systems appear to solve this. Claude Code draws from a pre-funded account and proceeds without interrupting the user. But this is a proxy with a budget, not an autonomous economic actor. The agent’s economic range is fixed at setup by its human operator. It cannot negotiate access to new resources, acquire capabilities outside what was pre-provisioned, or carry any economic identity beyond the session. Szabo’s problem reemerges as a ceiling on what the agent can do.

Another key constraint agents encounter with legacy payment rails is identity. In existing human:agent checkout flows, agents essentially borrow their user’s identity to transact. The entire stack assumes the payer is a person with a legal identity, bank relationship, and personal liability, which agents have none of (at least not yet). When Claude Code makes a payment it does so via its user’s Stripe credentials, the merchant’s fraud model, the card network’s chargeback rules, and the bank’s settlement framework.

This also creates unresolved legal questions. How does an agent run an AML check? File a suspicious activity report? Screen for sanctions violations? There may soon be answers to these questions, as this issue is now gaining recognition at the federal level. NIST’s National Cybersecurity Center of Excellence just published a concept paper on AI agent identity and authorization, identifying it as an unsolved infrastructure problem requiring new open-source future standards.

Human-agent checkout flows are genuinely useful. But in their next evolution – an economy of AI agents – cost, autonomy, and identity are three constraints existing systems cannot reconcile. Multi-day settlement and the absence of 24/7 global rails add further friction, though these are secondary to the structural issues above. Solving these constraints starts with understanding how AI agents actually work. Agents are software, they run on the web, therefore perhaps the most natural place to look for a payments layer is within the web itself.

POST /merchant/transfers/payment HTTP/1.1
Host: payments.example.com
Content-Type: application/json
Content-Length: 402

{
  "payment_transfer": {
    "reference": "PAYMENT123456",
    "amount": "1337",
    "currency": "EUR",
    "sender_account_uri": "pan:5299920000000149;exp=2020-08;cvc=123",
    "sender": {
      "first_name": "Amelia",
      "middle_name": "Rosenburg",
      "email": "test123@sender.example.com"
    },
    "recipient": {
      "first_name": "Tyrone",
      "middle_name": "Johnston",
      "email": "test123@example.com",
      "merchant_id": "123"
    },
    "authentication_value": "ucaf:jJJLtQa+Iws8AREAEbjsA1MAAAA",
  }
}

An example of calling a payment API using a POST request to initiate a transaction via HTTP-402.

HTTP 402 was reserved decades ago but never implemented. It anticipated a world where payment could be handled at the protocol level, the same way authentication is handled today. It was simply missing two things needed to make it real: a defined standard, and a form of money that could move at web speed.

We Already Have Web-Native Payment Rails

Just as HTTP moves information freely and permissionlessly across the internet, global value transfer on public blockchain rails is already happening at a meaningful scale. Tens of trillions have already been moved in stablecoins. Circulating stablecoin supply sits at over $308B today.

Mckinsey and Artemis Analytics tracked stablecoin payment volume at $390 billion in 2025, more than double from the year prior, with volume concentrated in B2B and P2P payments, card-linked spending, and B2C payouts. Though most onchain stablecoin activity has historically been trading-driven, chain-specific data shows payment demand emerging as a distinct and growing share.

A stablecoin in its simplest terms is software programmed to maintain the value of a stable unit of exchange, most commonly the US Dollar. A piece of software known as a smart contract is called, and in turn a stablecoin, is either minted or redeemed. Several key properties that make these bits of software uniquely suited for web-native payments, particularly in agentic commerce.

The economic advantage is the most obvious. Stablecoin transactions are orders of magnitude cheaper than legacy payment rails because there is no intermediary taking a cut. A stablecoin transaction is a redistribution of balances on a shared digital ledger. The primary resource consumed is the computing power required to update that balance, paid as a gas fee. Gas fees across most major chains now sit in the sub-cent range. Against the transaction fees associated with credit cards, the cost differential is stark.

A more distinctive advantage is programmability. As Hadfield and Koh point out, agents need “programmable money” to achieve the kind of autonomous cooperation required for complex economic activity at scale. Stablecoins are issued and redeemed via smart contracts in which payment conditions can be encoded directly: conditional releases, payment limits, recurring transfers, etc. Agents can control wallets through cryptographic keys and sign transactions directly, which removes the need for human credentials at the payment layer.

Haseeb Qureshi makes the sharper point: crypto is better suited for agents than it is for humans. An agent can verify transaction details, audit smart contract code, and confirm settlement in seconds. It does not need to trust a counterparty’s legal representation or a jurisdiction’s enforcement mechanism. Code on the other hand is deterministic: given the same inputs, it always produces the same outputs. A smart contract that says “release payment when condition X is met” will release payment every single time condition X is met, enforcement is built into execution.

An agent entering an economic agreement via smart contract knows exactly what will happen under every possible condition before it signs. It can read the code, verify the logic, and confirm the outcome in milliseconds. A stablecoin is just code. A wallet is just code. An agent can hold funds, transact, and enter economic agreements as naturally as it sends an HTTP request.

The Missing Piece

HTTP 402 defines how a server signals that a resource requires payment. Stablecoins provide money that can move at web speed. Together, they start to look less like a checkout flow and more like an HTTP handshake.

Consider a vending machine. It provides one specific item, a soda or a candy bar, but only in exchange for the exact payment amount. The operator does not need to produce anything it sells. It simply provides neutral infrastructure that lets willing buyers access a resource.

This is the model for web-native agentic payments. An agent makes a request, the server responds with a payment requirement, the agent provides payment, and the resource is unlocked. HTTP 402 provides the status code. Stablecoins provide the settlement layer. The missing piece is what ties them together: a web-native vending machine.

x402: A Web-Native Payment Rail

In May 2025, Erik Reppel, head of engineering at the Coinbase Developer Platform, published a whitepaper co-authored with colleagues Kevin Leffew, Dan Kim, and Nemil Dalal that gave HTTP 402 its first real implementation in 29 years: the x402 protocol.

The idea, which this paper takes as its central premise, was simple: the internet has always needed a native way to send and receive payments, and stablecoins now make that possible. Coinbase had been exploring internet payment standards since 2015, but even then the idea was ahead of its time. By May 2025, the conditions had finally aligned. Onchain fees cost fractions of a penny on chains like Solana and Base. Stablecoin supply had grown rapidly and was approaching $300 billion. Agentic commerce had materialized into something concrete enough to build for.

What is x402?

x402 is an open-source payments protocol that standardizes how web clients and servers exchange value using HTTP 402 and stablecoins. It is, in the most literal sense, the missing web-native vending machine: a buyer makes a request, a seller names a price, and payment clears directly through HTTP without a pre-established relationship between the parties.

At its core, x402 separates three things: transport, which is how data moves between parties; payment logic, or the scheme by which value moves; and the settlement network where that value lands onchain. This separation is what makes x402 extensible. HTTP is the primary transport and the 402 status code is the native signal, but the same payment logic can run over MCP or A2A without touching the underlying standard. In practice, x402 plugs into existing web infrastructure as lightweight middleware. Server-side implementation takes a single function call. A client can pay any supported endpoint without a prior relationship with the resource provider.

How Does x402 Work?

In summary, the x402 payment flow works like this:

1. A client requests a paid resource from a server

2. The server returns HTTP-402 with machine-readable payment instructions.

3. The client constructs a signed payment payload and resubmits the request.

4. The payload is verified, and the server fulfills the original request. Note, the payment is first submitted and settled onchain, and the settlement proof passed along via the Facilitator to confirm payment.

5. Once confirmed, the server returns a 200 OK response alongside the requested resource and transaction proof to the client.

There are certain steps involved in which the details vary by specific chain architecture, as we will expand on below. But importantly, each step maps to a specific component split across two layers: an offchain layer where communication occurs, and an onchain layer where payment settles.

The Communication Layer

x402 is transport-native by design. While HTTP is the primary implementation, the protocol complements existing data transportation without mandating additional requests outside a typical client-server flow. Any request-response based system can implement x402 payment flows, which means x402 runs across HTTP for web APIs and REST services, MCP for AI agent tools and resources, and A2A for direct agent-to-agent payments.

The primary offchain components are the client and the server, which apply across all supported transport layers.

The client represents the buyer: the entity requesting access to a paid web resource. This can be a human developer making calls through an HTTP client library, or an AI agent operating as a web client. A client sends the initial request, constructs a valid payment payload, and retries the request with a Payment-Signature header containing the signed payload.

The server represents the seller, or resource provider. Usually an API or content endpoint, but ultimately any digital resource accessible via a supported network. The server responds to client requests with payment requirements, verifies incoming payment payloads, and returns the resource once the transaction confirms.

For agents, no separate integration is required per transport layer. Payments are handled automatically across HTTP APIs, MCP tools, and A2A interactions.

The Onchain Layer

The onchain layer of the x402 protocol is where payment occurs. This consists of a wallet to hold funds and authorize payments, a Facilitator service to verify payloads and submit payments onchain, and the stablecoin or token contract which actually moves between parties.

To execute payments with x402, a client needs a funded cryptographic wallet. A wallet is a public-private key pair. The public key is a pseudonymous identifier that functions as the client’s onchain address, analogous to a routing number. The private key authorizes the client to sign and execute transactions, analogous to a password. When an agent needs to access a paid resource, it constructs a payment payload by signing a transaction authorization with that private key. The signed payload includes the public key so the server can verify the sender and confirm the transaction onchain independently.

To settle payments onchain, a server uses a Facilitator. A Facilitator is a transaction relay and gas abstraction service: it receives a signed payment payload, validates it against the token contract’s authorization parameters, and broadcasts the transfer onchain on the server’s behalf, covering gas costs in the process. When a server receives a signed payment payload, it can either handle onchain settlement directly or POST the payload to the Facilitator’s /settle endpoint. The Facilitator validates the cryptographic signature against the token contract’s authorization parameters, calls transferWithAuthorization the token contract, covers gas from its own balance, and broadcasts the transaction to the network.

Critically, the Facilitator is not a custodian. It executes a transfer that was already cryptographically authorized by the client’s signature. It cannot redirect funds or modify payment terms; it can only execute or reject what the client already signed. Coinbase runs a Facilitator on Base and Solana for USDC payments, but the role is open. Any server can run its own verification logic locally if it prefers not to outsource.

x402: EVM vs Solana

The HTTP handshake in the x402 payment flow is identical across chains. What differs is the onchain settlement mechanism, which is downstream of the architectural differences between EVM-compatible chains and Solana.

On EVM-compatible chains, x402 uses EIP-3009 as its core token transfer primitive. EIP-3009, authored by Coinbase engineers Peter Jihoon Kim, Kevin Britz, and David Knott in 2020, quietly facilitates tens of billions in monthly USDC transfer volume.

The key mechanic is the separation of authorization from execution. EIP-3009 provides a single-use cryptographic signature created offchain, authorizing a specific transfer of a specific amount to a specific address within a defined validity window. That signature becomes the payment payload in x402.

There are two main functions involved here: transferWithAuthorization and receiveWithAuthorization. The client signs a structured EIP-712 message containing the payment details and a random 32-byte nonce. Using random nonces here lets multiple payment authorizations be created in parallel without ordering constraints.

When the server receives the Payment-Signature header, validation is a deterministic checklist: verify the recipient address matches, the payment amount meets the requirement, the token contract is an accepted asset, the validBefore timestamp hasn’t expired, and the EIP-712 signature is cryptographically valid. Because authorization is separated from execution, the server validates the signed payload before submitting anything onchain. An invalid signature, mismatched amount, or expired timestamp gets rejected at zero cost to either party.

If all checks pass, the server or its Facilitator calls transferWithAuthorization on the token contract. The Facilitator covers gas from its own balance, which is why the client only needs to hold the payment asset rather than the chain’s native gas token. Once confirmed, the server returns the requested resource alongside a transaction hash and block number the client can verify independently.

Solana

On Solana, x402 uses a different settlement mechanism that reflects how transactions are structured on the chain. Rather than an offchain EIP-712 signature authorizing a future transfer, the client constructs and partially signs a full SPL token transfer transaction using Ed25519 signing, then encodes it as a base64 payload in the Payment-Signature header. The transaction is partially signed because the client signs the transfer instruction while designating the Facilitator as fee payer, a role that requires the Facilitator’s own signature before the transaction can be broadcast.

Before building the transaction, the client queries the Facilitator’s /supported endpoint to get its fee payer address and confirm support for the requested network. The Facilitator then receives the partially signed transaction, validates it, adds its own signature as fee payer, and broadcasts it to the network. The client pays in USDC without needing to hold SOL for gas.

Both the EVM and Solana flows achieve atomic settlement through different primitives native to each chain. The EVM flow uses an offchain signature authorizing a future transfer the Facilitator executes; the Solana flow uses a partially built transaction the Facilitator completes and broadcasts.

Beyond the mechanics, each chain carries practical advantages. EIP-3009 shifts gas costs from clients to servers, who accept this because payment amounts structurally exceed gas fees. For agents making repeated calls to the same endpoint, servers can batch multiple authorizations into a single transaction, spreading the fixed base gas cost across payments. The authorization-execution split also enables payments in low-connectivity environments: a client can construct and sign an EIP-712 message locally without network access and transmit it when connectivity resumes. Solana’s architecture is optimized for throughput, making it better suited for higher-frequency payment patterns.

That said, x402 is chain-agnostic. The protocol uses CAIP-2 network identifiers so the same handshake handles routing across Base, Solana, Polygon, Scroll, and Avalanche. The server specifies which networks and assets it accepts in the 402 response; the client picks from what its wallet supports. As the Facilitator landscape matures and new chains meet x402’s acceptance criteria, the protocol extends without changes to the underlying standard.

What Does x402 Uniquely Solve?

It’s worth zooming out to revisit what makes x402 valuable.

The ability to transact online is becoming a foundational requirement for AI agents. As software programs that communicate via HTTP and consume web resources continuously, paying for things is central to how they operate. The problem is that the infrastructure underpinning something so fundamental to their function wasn’t built for them. In human-agent checkout flows, agents transact through human infrastructure, borrowing credentials and depending on intermediaries designed for a different kind of consumer. x402 runs on the same web-native rails agents already operate on.

The differences are structural. Cost is the most obvious one; gas fees for stablecoin transactions on the chains x402 currently supports (e.g. Base, Solana) cost fractions of a cent, and represent the only transaction costs within the traditional x402 payment flow. This matches the granular economics with which AI agents operate at (e.g. per-call, per-task etc); which quickly breaks down with a 2.9% + $0.30 fee charged per transaction.

Settlement goes deeper. Because payment conditions are enforced at execution, a transaction cannot finalize unless predefined terms are met. The rails enforce this through code, so the agent doesn’t need to know or trust the counterparty. This is the difference between post-hoc verification and preemptive execution, and it’s what makes delegation to high-stakes workflows safe. An operator defines spending constraints once: daily caps, per-transaction limits, whitelisted addresses. The agent executes within them without requiring approval on each call.

Beyond cost and settlement, there’s identity. Every transaction an agent makes is signed by the same cryptographic wallet address, a consistent and verifiable identifier it owns and controls. Rather than borrowing a human’s credentials for each new service, the wallet travels with the agent, standardizing how it shows up across every interaction.

But in practice, why do these advantages even matter?

Granular pricing structures, e.g. Pay-per-article, pay-per-video, pay-per-stream, were always the intuitive business models for digital content. The early web was built with that vision in mind, but it never materialized because transaction costs made small payments uneconomical and the cognitive overhead of approving each one made them exhausting. Granular pricing can actually match how content is actually consumed rather than bundled into subscriptions that most users only partially use.

For AI agents, granularity is a necessity to how they consume resources in discrete, measurable units (inference per prompt, market data per query, compute per job, API calls per task.) It’s difficult to map these naturally onto subscription pricing, which exists largely because per-unit micropayments weren’t viable. At fractions of a cent per transaction, they are.

x402 can also help reshape the software market for agents. Historically, accessing a capability meant either paying a subscription or building it yourself. As inference costs fall, building is increasingly viable. x402 introduces a third option: an agent mid-workflow can access a capability instantly, paying only for what it uses, rather than spinning up inference to replicate it.

The most expansive implication is what happens to how products get structured. Goods and services are bundled largely because transaction costs make granular pricing impractical. A news article packages interviews, photos, and context together because selling each piece individually wasn’t worth the overhead. An AI agent, meanwhile, can track what a user has already read, coordinate with a content provider to surface only what’s new or relevant, and pay for exactly that. The same logic extends to any digital product with separable components. As micropayments make individual pieces of content economically viable, agent-to-agent commerce could give rise to a retrieval ecosystem where content creators get compensated per use and users get something closer to a personalized product than a standardized one.

This extends to how AI agents actually move through a workflow. When an agent hits a paywall mid-task, the server returns a 402 with machine-readable payment instructions. The agent constructs a signed payment payload, settles onchain, and continues. The workflow never stops for manual authorization. The only prerequisite is a funded wallet, which the operator provisions once upfront.

This becomes particularly relevant in multi-agent systems or swarms. Modern agentic workloads increasingly decompose across specialized agents that coordinate through handoffs: one agent calls another, which calls a service, which calls another agent. When payments need to flow through that same graph, a central billing relationship can become an operational bottleneck. x402’s stateless design means each hop settles independently, such that the payment layer scales with the workflow rather than sitting above it.

All of this is straightforward to integrate. x402 ships with a full reference implementation: core protocol libraries, server-side middleware for Express.js and Next.js, and client libraries for browser and Node.js environments. Server-side integration is a single function call. An agent can hit a paid endpoint, receive a 402, construct a signed payload, and settle onchain without any custom payment logic written on top.

With that in mind, let’s take a look at the current state of x402 adoption today.

The Current State of x402

x402 launched on May 6, 2025, initially supporting USDC on Base. In the nine months since, the protocol has processed 164m total transactions worth $46.4m in volume, across 447k unique buyers and 89k sellers in total.

That growth was not linear; at its peak on November 17, x402 drove 19% of Base’s 17 million daily transactions, a striking demonstration of how quickly the protocol could saturate a single chain’s activity. Since then, amid a broader pullback in onchain and crypto market activity, transaction volume has declined meaningfully, although there has been a meaningful resurgence in transactions and volume count in March once again.

What the data tells us, and what it doesn’t, is worth examining closer.

X402 is a chain-agnostic framework that’s live on a small but growing number of chains today. Base accounts for the majority of x402 activity to date — 125m transactions and $39m in volume — a feat driven in no small part by its early-mover advantage, as well as being home to Coinbase’s native facilitator infrastructure, and the deepest facilitator ecosystem on the protocol with 27 active facilitators. Solana came online in July 2025 and has processed 38m transactions and just under $7m in volume to date. By early February 2026, Solana was gaining rapid share of transaction count (and volume?), accounting for as much as 97% of daily transaction share on February 2nd. Nonetheless, Base still hosts a much larger share of buyers (423k buyers vs Solana’s 23k) and sellers (68k vs Solana’s 20k), suggesting Base still dominates on the demand side even as Solana captures a growing share of transaction count.

Beyond Base and Solana, x402 is actively expanding support to new chains, now live on Polygon, Avalanche, Sei, Optimism, and Arbitrum. These chains are live but collectively still account for a small fraction of activity relative to Base and Solana. It is too early to tell where the most x402 activity will settle, but the answer is far more likely to depend on a specific application on a specific chain rather than the infrastructure of the chain itself.

The facilitator landscape meanwhile, has grown alongside the protocol. Coinbase remains dominant by transactions (78m) and volume ($27.3m), and it’s worth noting their Facilitator offers a zero-fee structure and has a first-mover position. But the ecosystem has started to diversify; PayAI, Dexter, Daydreams, and Virtuals Protocol are among the more active third-party facilitators, which collectively account for the majority of facilitator transactions and volume in more recent months.

But not all agent activity is as it seems. For instance, despite the recent craze around Moltbook, a viral social network exclusively for AI agents which drew lots of coverage about millions of agents posting and coordinating their own lives, much of this early activity was revealed to be agents pattern-matching through trained social media behaviors, with humans involved in many cases.

The same scrutiny applies to x402. Artemis Analytics distinguishes between real and gamed transactions in its x402 dashboard, gamed transactions being indicative of wash trading. One explanation for the incentive to game transactions with x402 is launching a memecoin, driving transaction volume to climb the x402scan leaderboard, and converting that visibility into token buyers.

Though x402 went live in May 2025, the first major surge in activity only took place a few months later around early Q4 ‘25. Much of this activity was memecoin-related however; throughout much of November and early December, gamed transactions accounted for a larger share of total transactions than real transactions.

However, as total x402 transactions have declined in the past few months, real transactions are starting to account for a larger share of total transaction count. February saw 5 straight days in which real transactions accounted for 100% of total count.

Gamed transactions do help stress-test infrastructure, validate settlement mechanics, and prove throughput at scale. But financial incentives and the downstream activity of those incentives dilute the assessment of the quality of x402’s adoption. Whether they are memecoin-related, airdrop farming-related, or otherwise, the bottom line is that gamed transactions represent behavior optimized for financial incentive rather than organic x402 utility.

But numbers, as useful as they are, only tell so much. For a more holistic overview of x402 adoption to date, it’s worth looking at the x402 ecosystem.

The x402 Ecosystem

The x402 ecosystem is made up of the various participants in the x402 payment flow. Clients represent the buyers making requests for web resources to paid endpoints (e.g. AI agents), Servers are the services and paid endpoints (APIs, data providers, content platforms, and any digital resource exposing a paid route via x402), Facilitators are various third-party services handling payment verification and onchain settlement for Servers, and supporting infrastructure and tooling covers any SDKs, analytics, wallets, and developer tooling that make building on x402 practical.

Much of the x402 ecosystem is still early, but the range of service partner integrations and experiments being built on top of the protocol offers a glimpse into its surrounding excitement and interest across different industries and fields.

x402 Within The Broader Agentic Commerce Stack

It’s important to zoom out and recognize that agentic commerce is a wide-ranging multi-layered stack that intersects across several industries. Discovery, consent, checkout, and agent coordination are each being handled by different protocols involving a number of the biggest players across the tech and finance sectors.

On the commerce side: we touched on ACP earlier, which defines how AI agents handle the shopping flow on behalf of human users from product discovery through checkout. Critically, ACP is designed to be processor-agnostic, meaning merchants can plug in whatever payment provider they already use. Google’s UCP (Universal Commerce Protocol) serves a similar purpose for Google’s ecosystem: it standardizes how agents operating inside Google Search and Gemini discover products, negotiate offers, and complete purchases on a user’s behalf. Where ACP is optimized for conversational interfaces like ChatGPT, UCP is designed to work across Google’s broader range of products. The Agent Payments Protocol (AP2), also from Google, sits one layer down from both of these, handling authorization specifically. Before an agent can spend money, AP2 generates a cryptographically signed mandate confirming that a real user authorized this agent to spend up to X for purpose Y. Every transaction gets a tamper-proof record tied to that mandate, which gives merchants and financial institutions an auditable trail to verify the transaction was legitimate. Google’s A2A, now maintained by the Linux Foundation with over 100 supporting organizations, handles a different problem entirely: how agents from different companies and platforms talk to each other. When an agent built by one vendor needs to hand off a task to an agent built by another, A2A provides the common language for that coordination.

X402 complements this stack in several ways. Google and Coinbase built the A2A x402 extension as a production-ready module within AP2 specifically for agent-based stablecoin payments. The split is clean: AP2 provides the authorization mandate, confirming the agent has permission to spend; x402 executes the actual per-call transfer once that mandate is in place, settling in USDC onchain. Cloudflare added x402 into its Agents SDK and MCP server tooling, so any tool or API exposed via MCP can require a 402 payment before granting access. In practice, an ACP-driven assistant might discover a service via MCP, see that the endpoint returns a 402, get operator budget approval, and settle via x402 on every subsequent call while ACP manages the overall order and recordkeeping.

Legacy payment networks have been getting involved with agentic payments too. Visa launched the Trusted Agent Protocol to help merchants identify and verify AI agents during checkout, particularly to distinguish a legitimate shopping agent from a malicious bot. Trusted Agent Protocol gives verified agents a cryptographic signature they can present to merchants during browsing and checkout, built on Cloudflare’s Web Bot Auth infrastructure and backed by partners including Microsoft, Stripe, Shopify, and Worldpay. Visa is working with Coinbase to ensure Trusted Agent Protocol is interoperable with x402. Mastercard launched Agent Pay the same month with its own merchant verification framework: tokenized agent credentials that let merchants register and authenticate AI agents before any transaction clears. While Mastercard has not announced a direct x402 integration, it is a named AP2 partner, and Cloudflare is working with Mastercard on the same Web Bot Auth infrastructure that underpins x402’s authentication layer.

Stripe is another major player that’s been actively ramping up development efforts around agentic payments. In February 2026, Stripe launched Machine Payments in preview, with x402 via USDC on Base as the first supported method, letting developers bill agents for API calls, MCP requests, or HTTP endpoints through the standard PaymentIntents API: the same infrastructure merchants already use for card payments. Alongside this, Stripe introduced Shared Payment Tokens: scoped, time-limited credentials that let agents initiate payments without exposing underlying account details, which non-Stripe merchants can forward to their own processors.

On March 18 the same PaymentIntents API was reintroduced as the foundation for the Machine Payments Protocol (MPP), a new open standard for agentic payments launched alongside Tempo’s mainnet. MPP encodes the same HTTP 402 signaling mechanism as x402 and targets the same fundamental problem but introduces two architectural differences: a “sessions” primitive that lets clients deposit funds into an onchain escrow once and sign offchain vouchers per-request, and multi-payment rail support, featuring native stablecoin settlement on Tempo with Visa, Lightspark, and Stripe extending MPP to cards, Bitcoin Lightning, and fiat methods as well.

x402 and MPP, unlike x402 and other agentic commerce protocols e.g. ACP/ UCP/A2A, are more adversarial than they are complementary. Tempo raised $500M from Stripe and Paradigm, and launched with merchants wielding lots of distribution power including Visa, Mastercard, Anthropic, OpenAI, and Shopify. Their competitive dynamics are worth diving deeper into a future paper; however it is worth acknowledging here that the two protocols are compatible. Cloudflare’s documentation confirms MPP is backwards-compatible with x402: existing x402 flows map directly onto MPP’s “charge” intent, and Stripe supports both.

What’s important to understand with all these different agentic commerce protocols is their division of labor. ACP and UCP enable AI agents to handle online shopping experiences on their human user’s behalf. AP2 handles authorization and audit. Visa and Mastercard handle merchant-facing trust and agent verification. Stripe is working to abstract developer integration across all of it. x402 sits at the execution layer of the stack: it’s a neutral payment API that any agent, any service, any developer can implement in a few lines of code, with no merchant account, processor agreement, or card network required. When an agent hits a paid endpoint (i.e. a raw API call, an MCP tool, or an HTTP resource gated by Stripe’s Machine Payments) the server returns a payment request in the HTTP response, the agent pays in stablecoins, and the request completes. The money moves, the workflow goes on. Onchain rails simply match the granularity of AI agent economics with greater cost, speed, and programmability than legacy payment infrastructure.

Coinbase

Coinbase authored x402 and remains its primary infrastructure provider. Coinbase published the open specification, shipped the reference SDK, and runs the dominant facilitator service. The CDP facilitator processes payments on Base and Solana and currently handles the majority of x402 volume.

Beyond infrastructure, Coinbase’s distribution plays a critical role in x402’s success. Payments MCP is the most significant piece. It packages x402, an embedded non-custodial wallet, and an onramp into a single MCP server that Claude, Gemini, Codex, and other LLMs can connect to directly. A developer can go from zero to a transacting agent without an API key or manual setup. Complementary to this are Agentic Wallets: wallets purpose-built for agents with programmable spending limits, gasless transactions on Base, and a CLI for agent management. Together, Payments MCP and Agent Wallets products form a vertically integrated stack to help developers get started with building on x402.

Major Integrations

Coinbase also co-founded the x402 Foundation with Cloudflare, which has been actively involved with x402; having integrated the protocol into its Agents SDK and MCP tooling to allow MCP-exposed tools to be 402-gated and paid per-call. The practical implication of this shouldn’t be understated; any server using Cloudflare (roughly 20% of all web traffic globally) can become a paid x402 endpoint without modifying backend code.

Amazon Web Services (AWS) is also an x402 Foundation ecosystem member and has published a reference architecture showing how x402 can be layered onto existing HTTP infrastructure using CloudFront and Lambda@Edge. In that flow, CloudFront acts as a global reverse proxy while Lambda@Edge runs payment verification logic at the network edge: when a request arrives, Lambda@Edge checks for a valid payment signature; if missing, it returns an HTTP 402 challenge. The architecture applies x402 to any origin without touching backend code, whether hosted on AWS, GCP, Azure, or on-premise. One of the more interesting capabilities this integration unlocks is the ability to to charge bots while keeping access for human users free. More broadly, this integration means x402 isn’t a crypto-native tool that requires rebuilding infrastructure around it; rather it easily fits into the cloud stack enterprises already run.

Privy added native x402 support, wrapping the full payment flow without browser extensions, seed phrases, or gas tokens. This includes detecting 402 challenges, signing payment authorization with the embedded wallet via a custom useX402Payment React hook, constructing the X-PAYMENT header, and retrying the request. Users only need USDC in their wallet on Base or Base Sepolia; facilitators absorb gas. Privy is also exploring policy-engine integrations for programmable spend controls at the domain, agent, and workflow level, running off-chain. Developers building with Privy can add x402 payment flows without building a wallet layer from scratch, plugging into the 90 million accounts Privy powers today.

X402 and ERC-8004

An important emerging complement to x402 is ERC-8004, an Ethereum standard co-authored by teams at MetaMask, the Ethereum Foundation, Google, and Coinbase, including x402’s own Erik Reppel. Both standards treat AI agents like first-class citizens in a new emerging virtual economy; where x402 provides payments infrastructure, ERC-8004 is designed to provide reputation and identity infrastructure.

The standard is made up of three lightweight onchain registries: Identity, which gives each agent a portable, globally unique identifier via ERC-721; Reputation, which maintains an onchain audit trail of client-authorized feedback; and Validation, which supports cryptographic or crypto-economic proof that a task was actually executed correctly. Together they function as an open credit score and track record for AI agents.

The integration with x402 creates a recursive loop. An agent discovers a service via the ERC-8004 identity registry, checks its reputation and validation history, makes an API call, receives an HTTP 402 code, pays via x402, and submits payment proof back into the reputation registry as a verifiable feedback signal. This way, each transaction helps strengthen the trust record. Over time this enables more sophisticated economic relationships: agent-native credit systems, outcome-based lending, constrained capital deployment where an agent doesn’t receive free funds but specific, verifiable capability.

X402x

x402x (short for x402-exec) is a programmable settlement framework built on top of x402 that turns payment into a complete execution primitive. Where the base x402 protocol handles payment routing, x402x combines payment verification, business logic execution, and facilitator incentives in a single atomic transaction. Standard x402 settles in 500-1100ms across a two-phase flow; x402x reduces that to 200-500ms via a Gateway contract that executes verification, authorization, token transfer, fee deduction, and nonce marking atomically. It adds four hook execution points — beforePayment, afterPayment, beforeBatchPayment, afterBatchPayment — enabling merchants to inject custom TypeScript logic for credential verification, subscription checks, NFT minting, loyalty point distribution, or complex settlement logic without modifying the core protocol. Batch settlement aggregates up to 100 payments per transaction, reducing per-payment gas costs by approximately 92%. A configurable platform fee mechanism gives facilitators an economically sustainable model. Critically, x402x is not a protocol replacement in any way, rather it is a production extension layer that runs fully compatible with the x402 specification.

T54

T54 is building a trust and risk layer for agentic commerce on top of x402. x402-secure is an open-source SDK and proxy layer that adds pre-transaction risk assessment, verified identity, and liability attribution to x402 payments. The system is powered by Trustline, T54’s own risk engine, which captures an agent’s reasoning traces and attaches them to the payment flow as verifiable evidence. Before a transaction settles, independent validators analyze the agent’s reasoning chain, behavioral patterns, and context to produce a risk score. The practical effect is that both buyers and sellers get auditable proof-of-agent intent, which opens a path toward dispute resolution and clearer liability in a protocol that is otherwise irreversible by design. T54 also shipped Claw Credit, an agent-native credit product built on x402 that allows agents to build a credit profile through usage and repayment to then unlock higher spending limits over time. T54’s agentic infrastructure is supported on Base, Solana, and XRPL.

Experiments and Early Builders

Beyond the major integrations, a scrappier layer of builders is exploring what x402 enables in practice. Conway Research’s Automaton is among the most striking examples: an open-source AI agent that owns a cryptographic wallet, pays for its own compute costs in USDC via x402, earns revenue by building and deploying products, and funds child agents when profitable. The agent runs on Conway’s MCP-compatible terminal infrastructure, integrates with Claude Code, Codex, or OpenClaw, and ceases to function if it cannot earn enough to cover its operational costs. Daydreams built xGate as an agent-native discovery layer for x402-enabled endpoints, alongside Lucid Agents, a commerce SDK that bootstraps agents with native x402, A2A, and ERC-8004 support. Developers have built self-generating task markets where agents post, discover, and pay for work autonomously. Agents can now buy their own web domains with x402. Some builders are experimenting with x402 and OpenClaw. There’s agents already using x402 for financial operations entirely through x402-gated endpoints: portfolio queries, market data pulls, swap execution.

Privacy is another open frontier. Onchain rails make every x402 transaction publicly observable: payment flows, cost structures, and purchase intent permanently recorded on a public ledger. Correlating onchain timestamps with server-side metadata is enough to reconstruct behavioral profiles over time, which becomes a nonstarter for enterprise workflows where any AI agent handles sensitive information. Several teams are working on solutions: x402Z, a collaboration between Zama and Mind Network, uses Fully Homomorphic Encryption combined with the ERC-7984 Confidential Token standard to validate transactions without revealing amounts, balances, or intent; Fhenix402 takes a parallel approach using CoFHE, performing computation on encrypted data without decrypting it; Aztec, Payy Network, and Miden, through their respective distinct architectural approaches, feature private settlement embedded natively at the protocol layer. With multi-chain support a core part of the x402 V2 spec, there is a direct path forward for adoption on privacy-native onchain rails.

New AI releases ship every single day, and what’s exciting about x402 is how boring it is: a simple neutral framework doing exactly what it says. That simplicity is what makes it universally applicable. In a world where agents transact autonomously at scale, the payment primitive underneath all of it may be the most important infrastructure layer no one is talking about.

That said, a reality check is in order.

Looking Ahead

Open Questions And Important Considerations

x402 and agentic commerce more broadly are still early. The protocol works, the ecosystem is growing, and there is undeniable value in micropayments and API-native monetization

But the full picture requires both internal development and external adoption to materialize in parallel. Standards like MCP and agentic payment flows still need to mature, and adoption among merchants and payment processors is an external force that no one controls on a fixed timeline.

X402 is not the first attempt to solve machine-native payments over onchain rails, and that history is worth holding onto when evaluating the open questions below. Balaji Srinivasan’s work at 21.co proved in 2013 that the concept of machine-readable micropayments was sound: Bitcoin payment channels could, in theory, enable devices to pay each other autonomously. The infrastructure wasn’t ready: Bitcoin transaction costs made sub-cent payments economically incoherent. L402, developed by Lightning Labs nearly a decade later, got further. It proved the technical viability of the HTTP 402 status code for payment-metered APIs and built real tooling around it. It failed for infrastructure reasons specific to its stack (e.g. Lightning’s statefulness, Bitcoin’s volatility, the two-sided cold-start problem) not because the underlying idea was wrong.

X402 fixes each of those specifically: USDC replaces volatile pricing, Base’s L2 removes channel management, and the facilitator model collapses the integration barrier to a single line of code. But some of the obstacles that slowed L402 including discoverability, compliance, and merchant behavior change have not been solved by upgrading the underlying infrastructure. The following are a few of the biggest questions concerning the adoption and success of x402.

Will credit cards adapt fast enough to make stablecoins unnecessary?

Whether its incumbents can actually be disrupted remains the defining question for x402’s role within agentic payments more broadly. Card networks have largely survived every predicted disruption for fifty years, from PayPal to Apple Pay to crypto, by adapting just enough, just in time. Credit card infrastructure is already deeply embedded, improving rapidly, and both Visa and Mastercard are actively building agent-specific payment frameworks. Agents already transact over card rails today. Virtual agent cards with programmable spending limits and backward compatibility with existing merchant infrastructure are an emerging middle path, which notably requires no stablecoin or crypto exposure whatsoever. If the major card networks lower fees, add programmable controls, and extend their rails to machine-native flows, the cost advantage of stablecoin settlement narrows.

Of course, card networks have built their entire business model on per-transaction fees and interchange, and there is no obvious incentive to destroy that margin to serve a new virtual economy that has not yet fully materialized. Stablecoins are also structurally more programmable, globally accessible, infinitely divisible, and require no chargebacks. The bigger question is whether the friction of crypto adoption is lower than the friction of waiting for card networks to adapt.

It’s worth noting the x402 V2 explicitly added support for legacy payment rails including ACH, SEPA, and card networks. As per the spec, x402 is an open standard for internet native payments which specifically “aims to support all networks (both crypto & fiat) and forms of value (stablecoins, tokens, fiat)”. Even if card networks adapt fast enough to close the cost gap, x402 is designed to work with whatever settlement layer wins.

The crawling and discoverability problem

This is a structural oversight x402 shares with L402, and it has no clean solution yet. Search engine crawlers do not have wallets. When they hit an HTTP 402 response, they treat it as a blocked page. Google’s own documentation confirms that 4xx status codes cause it to stop indexing affected URLs over time. Content protected by x402 is effectively invisible to the open web. Search engines will not index it and will not surface it in results.

Partial mitigations exist. Serving free previews to unidentified crawlers and using structured data to signal paywalled content are both established practices, borrowed from how publishers handle subscription paywalls today. But they add complexity, reintroduce the two-tier access model x402 was designed to eliminate, and don’t translate cleanly to pure API endpoints with no human-readable content to preview.

The longer-term resolution may not come from fixing x402’s relationship with search engines at all. If agents increasingly discover services through other agents, AI interfaces, and protocol-level registries rather than search crawlers, the relevant discovery layer shifts entirely. The SEO problem matters a lot if x402 adoption depends on organic web discovery; much less so if agents find services through agent registries, MCP directories, and AI-native discovery layers instead.

Regulatory and compliance risk

L402 stalled partly on compliance friction: accepting Lightning payments without a regulated gateway created AML exposure most businesses were unwilling to take on, compounding the existing adoption challenges Lightning already faced. x402 faces a version of the same problem, with a more explicit split.

Coinbase’s hosted facilitator includes KYT screening and OFAC checks on every transaction, inheriting Coinbase’s existing compliance stack. A merchant routing payments through that facilitator sits in a position analogous to using Stripe or PayPal: not a money services business, not directly exposed to AML liability. The tension emerges at the edges. Operators running self-hosted facilitators that take custody of assets or perform fiat conversion will, under conservative FinCEN and state interpretations, likely fall into MSB territory and face full BSA compliance requirements. The protocol is designed to be permissionless. The compliance infrastructure is not. If the facilitator layer becomes permissioned enough to satisfy regulators at scale, it concentrates gatekeeping in a way that undermines the protocol’s neutrality. If it stays permissionless enough to be genuinely open, it will likely hit the same OFAC and sanctions walls that complicated L402 adoption.

This is the same unresolved tension that has slowed stablecoin adoption in enterprise contexts for years. x402 does not resolve it, nor is that a failure of Coinbase’s execution. It is a protocol-level constraint: a permissionless payment standard operating in a world that requires permissioned compliance at meaningful scale. Coinbase’s facilitator is currently the most practical answer to that constraint, providing production-ready KYT and OFAC coverage that lets merchants transact without building compliance infrastructure themselves. The open question is what happens as the facilitator ecosystem diversifies and traffic routes through operators without Coinbase’s compliance stack.

Who is liable when an agent makes a bad payment?

Hadfield and Koh raise another structural problem sits underneath all of agentic commerce: current legal systems assume humans can monitor and control their agents, but that assumption breaks down as autonomy increases. When an agent using x402 overspends, sends funds to the wrong address, or is manipulated into paying a malicious endpoint, the liability chain is genuinely unclear. The protocol is irreversible by design. There is no chargeback. The facilitator verified the transaction. The agent acted within its programmed parameters.

This matters more because the same underlying models are deployed across many firms simultaneously. Hadfield and Koh warn that AI agent errors may be more correlated than human errors for precisely this reason: when agents share architecture, training data, or model weights, their failure modes cluster. The 2010 Flash Crash offers the clearest prior example of what correlated automated behavior produces at speed. Algorithmic trading systems briefly erased nearly $1 trillion in market value in under 36 minutes, not because any single actor failed catastrophically, but because systems trained on similar data responded to the same signal in the same way at the same time. The market recovered that day. Human regulators and exchange circuit breakers intervened at 2:45 PM when the CME halted trading for five seconds, breaking the feedback loop.

x402 has no protocol-level circuit breaker. Operators can enforce spending limits and whitelisted addresses at the application layer, and most current deployments still have humans setting those constraints upfront. But as agent autonomy increases and human oversight recedes by design, the window for intervention narrows. A correlated error that propagates through thousands of agents simultaneously would settle onchain before most oversight mechanisms could respond. The settlement finality that makes x402 useful is the same property that makes a cascade hard to stop

What does the future of x402 governance look like?

Coinbase and Cloudflare announced their intent to co-found the x402 Foundation in September 2025, with a stated mission of neutral, open governance. The structure makes sense as a distribution partnership: Cloudflare is one of the largest internet infrastructure providers globally, and Coinbase provides the stablecoin infrastructure and L2. Cloudflare CEO Matthew Prince acknowledged the dynamic directly, saying “Coinbase deserves immense credit for starting the work on the x402 protocol” while framing the Foundation as the path to independent governance.

But Coinbase is also the dominant facilitator, the author of the spec, the operator of the reference SDK, the issuer of USDC on Base, and a publicly traded company with shareholders. That is a significant concentration of involvement in a protocol designed to be a neutral payments layer for the broader web. The Foundation has stated it will welcome additional members from e-commerce platforms, AI companies, and payment providers through an open application process, but as of this writing no formal governance documentation, bylaws, or membership charter has been published.

Open source software has produced some of the most durable infrastructure in the world. Linux is the canonical example, but the Linux Foundation publishes its bylaws, board structure, and membership tiers publicly. The x402 Foundation has not yet done the same. Governance neutrality requires more than a stated mission. It requires structural commitment: published documentation, a clear roadmap for decentralizing facilitator infrastructure, and a governance model that doesn’t concentrate spec authority with the entity that also controls the dominant facilitator, the primary stablecoin, and the reference chain. None of that has materialized yet, as admittedly the Foundation is still young, but much of the difference between x402’s stated aspiration and its real-world impact lies in how effectively it can be governed and led over time.

The advertising fork in the road

In January 2026, OpenAI announced it would begin testing ads in ChatGPT’s free tier, with the first placements appearing in February. The move is understandable financially given OpenAI’s well-documented rate of burning cash, but it surfaces a deeper question about how the agentic economy gets monetized.

If the dominant AI interfaces become advertising-supported, agents face a structural conflict of interest. An agent that recommends a product because a merchant paid for placement is acting as a distribution channel, not in the interest of the end user. OpenAI says ads will not influence ChatGPT’s answers, but whether that holds at scale, under commercial pressure, over years, is a different question.

X402 and infrastructure like it represent an alternative model: agents complete transactions efficiently enough that the economic model does not require selling user attention. But the advertising flywheel has proven itself across every major internet platform for thirty years and generates hundreds of billions annually. The question is whether open payment rails can generate enough revenue fast enough to compete.

From attention economy to preference economy

This extends into something more structurally interesting. Today’s digital economy runs on advertising because there are more products than consumers have time to evaluate, and ads capture attention to guide transactions. In an agentic world where assistants interact with millions of services on behalf of consumers, attention becomes a less constrained resource. What matters more is the algorithm that matches assistants to services.

If strong central intermediaries once again dominate the matching layer, some form of paid prioritization (analogous to today’s advertising) will certainly influence rankings. The truly scarce and valuable resource in that world is not attention. It is high-quality human feedback on goods and services: the signal that distinguishes good services from bad ones, that trains better agents, and that creates a preference flywheel rather than an attention one. The key question is whether agent-to-agent commerce happens inside closed walled gardens controlled by a few dominant providers, or through an open web of agents that freely connect and transact. The answer will determine whether x402 and protocols like it become foundational infrastructure or a niche payment rail inside someone else’s ecosystem.

But merchant adoption doesn’t grow on trees

162 million transactions is a real number, but the majority of that volume flows through Coinbase’s own ecosystem and a small cluster of developer tools and crypto-native APIs. The harder test is whether mainstream API providers, SaaS companies, and non-crypto businesses add x402 alongside their existing subscription and API key models. Cloudflare’s network position reduces the technical barrier significantly, but the ecosystem needs merchants who have a genuine reason to prefer per-request stablecoin settlement over Stripe. That case gets stronger as agent traffic grows, but it is not proven yet.

And markets don’t form spontaneously

A useful corrective from Strange Loop Canon: markets form under coercion or coordination, and when they do exist, strategic sophistication determines who wins depending on how agents are configured. Alignment problems do not disappear just because agents can negotiate with each other. An AI agent economy running on x402 still requires discovery, trust, and security infrastructure among interacting agents. Whoever controls the dominant discovery layer — the mechanism by which agents find services and counterparties — holds enormous structural power regardless of how neutral the payment rail underneath it is. The payment layer is necessary but not sufficient. The governance of the layers above it matters just as much.

There are also several unresolved infrastructure problems that compound the challenges facing x402. The facilitator model has no sustainable economics built in at scale: Coinbase’s CDP charges $0.001 per transaction after a free tier of 1,000 monthly transactions, but third-party facilitators are largely running at zero fees with no clear revenue path. Two-phase settlement adds 500 to 1,100 milliseconds of latency per payment, which compounds quickly: an agent making 100 API calls in a single workflow carries over a minute of payment overhead before any work gets done. And EIP-3009 exclusivity means USDT — the largest stablecoin by market cap — remains incompatible with x402 entirely. Tether’s newer USDT0 variant addresses this technically, but it requires users to hold a different version of an asset they already own. BitGPT built h402 explicitly to preserve the protocol schema of x402 while ensuring the team isn’t “limited by someone else’s tech stack or product roadmap” — a signal that the developer community has noticed these gaps and is hedging against them.

Zooming out, x402 is early, the infrastructure is maturing, and most of these problems have plausible paths to resolution. What they collectively suggest is that x402’s current traction has mostly come from developer-native use cases where friction is low and tolerance for rough edges is high. The harder test is whether the same architecture holds at the scale of HTTP and the web as we know it today.

Closing Thoughts

The protocols that matter most rarely announce themselves. TCP/IP had no launch event. HTTP wasn’t pitched as the infrastructure layer for a trillion-dollar economy. They became load-bearing slowly, by being the path of least resistance for enough people solving concrete problems that adoption accumulated before anyone decided it was significant.

X402 is designed to be a primitive, not a standalone product. It requires one function call on the server and one signed payload from the client. There is no merchant account, processor agreement, or card network inherently required to transfer value. The implementation surface is deliberately small. Cloudflare, AWS, and Stripe aren’t endorsing x402 so much as absorbing it into infrastructure developers already use. That is what the early stages of a load-bearing protocol looks like, though institutional involvement is not the same as widespread adoption.

What makes x402 especially interesting is that it is the only current option that fits how AI agents actually operate. Legacy payment infrastructure requires agents to borrow human identity, human credentials, and operate on human settlement timelines. X402 runs on the same web-native rails agents already communicate over, prices at the granularity agents actually consume resources, and settles in seconds. That asymmetry is modest today. Whether it compounds is the real question.

Infrastructure like x402 “wins” when timing and adjacent development mature together. Facilitator economics need a sustainable model. Regulatory clarity around stablecoin and crypto market structure more broadly is still unresolved. Merchant adoption outside crypto-native developer tooling is not a given. The advertising model, which has monetized every major internet platform for thirty years, is already reaching into the agentic stack. And there is the stark reality that x402 may not be the HTTP-native micropayments solution that ultimately captures the agentic economy after all. The history of machine-native payment attempts is a reminder that the right idea pitched at the wrong time still fails.

What is clear is that AI agents are becoming economically active participants in a new virtual economy, and the infrastructure built for human consumers was not designed for them. In any new economic movement where which applications will succeed remains genuinely uncertain, the highest ROI historically has been foundational infrastructure investments, rather than the applications built on top of it. x402 is an attempt to occupy that position: a neutral payment API, running on open rails, that any agent or developer can implement without a card network or a bank in the middle.

The internet has always moved information freely. At Shoal, we believe it is inevitable that value travels the same way. But the infrastructure driving these movements matters more than any single applications built on top of them. x402 is an early attempt to get that infrastructure right, and whether it succeeds is still an open question. But x402 has one advantage its predecessors didn’t: timing. The conditions that made prior attempts at machine payment impossible, whether it be settlement costs, stablecoin liquidity, or AI agent adoption, are no longer the constraint. A virtual economy of AI agents is forming. Money will move through it. The remaining question is what the underlying rails look like when machines move money.

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

Sources

Data sourced from DeFi Llama, Artemis Analytics, and x402 Scan.

• “Moore’s Law: Transistors per Microprocessor.” Our World in Data, ourworldindata.org/grapher/transistors-per-microprocessor

• Hadfield, Gillian & Koh, Bryan. “Agentic AI and Law.” arxiv.org/pdf/2509.01063

• “Buy It in ChatGPT.” OpenAI, openai.com/index/buy-it-in-chatgpt/

• “Agentic Commerce Protocol Documentation.” Stripe, agenticcommerce.dev/docs

• “AI Agents to Boost Productivity and Size of Software Market.” Goldman Sachs, goldmansachs.com/insights/articles/ai-agents-to-boost-productivity-and-size-of-software-market

• “x402: A Payment Protocol for the Internet.” Erik Reppel, Dan Kim, Nemil Dalal. arxiv.org/pdf/2509.10147

• “x402 GitHub Repository.” Coinbase, github.com/coinbase/x402

• “How x402 Works.” Coinbase, docs.cdp.coinbase.com/x402/core-concepts/how-it-works

• “X402x.” @yq_acc, x.com/yq_acc/status/1987968102605484152

• “Fhenix402.” Fhenix, fhenix.io/blog/fhenix402

• “Monetize Any HTTP Application with x402 and CloudFront + Lambda@Edge.” AWS, builder.aws.com/content/38fLQk6zKRfLnaUNzcLPsUexUlZ

• “Internet Finance.” Montealegre, Felipe. source

• “EIP-3009: Transfer With Authorization.” Ethereum, eips.ethereum.org/EIPS/eip-3009

• “Why the Ad Industry Isn’t Ready to Let AI Agents Spend Ad Dollars.” Digiday, digiday.com/marketing/intentionally-being-cautious-why-the-ad-industry-isnt-ready-to-let-ai-agents-spend-ad-dollars/

Solana’s Block-Building Environment Today

Roughly every 400 milliseconds (a slot period), Solana produces a new block that updates the state of its decentralized ledger. This is what enables you to trade, interact with DeFi, and transact seamlessly.

In theory, the block production process looks straightforward and seems to follow clear rules. Validators take turns being the leader (block producer) for each slot (of 400ms). The leader is responsible for gathering transactions, producing a valid block, and broadcasting it to the rest of the network. Other validators then vote to verify the block’s validity and ensure it adheres to the network’s rules. And this process goes on and on forever.

But in practice, every validator has its own strategy for packing transactions into those 400-millisecond blocks, and how they do so can significantly shape the user experience on Solana. It affects whether a trade goes through, whether a user gets the expected quoted price, and ultimately whether TradFi institutions can comfortably scale their onchain operations.

In other words, the behavior of a small set of validators, deciding in an opaque way how to build and broadcast blocks in order to maximize short-term profit, can create ripple effects across the entire network and impact all stakeholders. At the extreme, this even puts pressure on Solana’s long-term ambition of becoming the home of Internet Capital Markets.

This is a big deal, and it has sparked an increasingly heated debate around how block building on Solana should be structured to best serve the network over the long term.

In this article, we’ll explore the core issues around block building on Solana, the solution Jito is proposing with BAM, and the perspective of a notable outlier in this debate: Harmonic.

Block Building Problems Identified by Jito

Jito, one of the leading infrastructure providers on Solana and a core contributor to its validator and MEV ecosystem, has spent significant time studying how validators construct blocks in practice. Given its direct exposure to validator behavior, transaction flow, and execution outcomes at scale, they are uniquely positioned to have a view on the current block-building process on Solana.

Through this work, they have identified two core issues in the current block-building environment that, they argue, materially impact user experience and put pressure on Solana’s long-term vision: late packing and slot lagging, which we’ll explore in detail below.

Problem number 1: Late packing

Solana is designed as a high-speed streaming system. In theory, validators are expected to pack transactions continuously throughout the slot while broadcasting block data as shreds over Turbine. This allows the rest of the network to reconstruct and replay the block in near real time.

However, Jito observed that some validators tend to concentrate most of their transaction packing toward the very end of the slot. The rationale behind this behavior is simple: delaying transaction inclusion as long as possible allows validators to observe more incoming transactions and, as a result, extract additional MEV or prioritize higher-paying order flow to maximize revenue per block. The issue is that this behavior is often pursued without fully accounting for the second-order effects it can have on the rest of the network.

Before going deeper, let’s just look at different block-building strategies using IBRL, a new explorer released by Jito that shines a light on block packing and provides a score to assess how closely validators adhere to best practices and standards. This allows stakers to inspect how specific validators build and pack their blocks.

Here we see different packing strategy from three different validator, Helius, Figment, and Galaxy:

We observe drastically different block-packing strategies. In this example, Helius has the highest score, which implies stronger alignment, as its blocks are packed much more uniformly throughout the slot. In contrast, Galaxy has the lowest score and clearly exhibits a late-packing pattern.

This lack of a shared standard for uniform and deterministic block packing is a real problem. We’ll explain why in a moment. But first, let’s introduce the second major issue identified by Jito: slot lagging.

Problem 2: Delaying State propagation

Slot lagging refers to the practice where validators modify their Proof of History (PoH) parameters to extend slot times beyond Solana’s default ~360 milliseconds.

Similar to the late packing issue, the rationale is straightforward. By extending the effective slot duration, validators give themselves more time to observe incoming transactions, and pack more profitable transactions into their blocks.

However, this behavior breaks an important assumption of the network: that slots progress as fast as possible and at a consistent pace. Other validators expect blocks to be produced and propagated within a tight timing window. When a leader intentionally runs longer slots, block propagation is delayed, state updates arrive late, and in some cases validators vote on the state of the network later than expected. This also means traders have to wait on new state updates which affect their operations.

Even if only a subset of validators engages in slot timing games, the impact is shared by everyone: confirmation times become less predictable, latency increases, and the network drifts away from its intended high-speed streaming model.

For instance, we can see that Jupiter has a much better slot timing score than Kiln. As a result, even though both validators do not show poor transaction packing behavior, Kiln still ends up with a lower overall IBRL alignment score compared to Jupiter.

The Downstream Implications

At first glance, these behaviors may seem understandable. Validators are economic actors, and it is rational for them to optimize for short-term profit. However, in practice, late packing and slot timing games create downstream effects that harm the network as a whole and ultimately work against Solana’s long-term goals.

Below are the main implications we observed:

Misaligned with Solana’s “Increase Bandwidth, Reduce Latency” vision

If there is one principle consistently emphasized by Anatoly, Solana’s co-founder and that should effectively serve as Solana’s guiding motto, it is this: “increase bandwidth, reduce latency.”

However, when transaction packing becomes end-loaded and validators engage in slot timing games, Solana’s block pipeline stops behaving like a true streaming system. Even if a slot technically finishes on time, state updates are propagated late across the network. As a result, other validators end up voting later than they should, not because of their own processing delays, but because they are waiting for late-arriving data from the block producer. This increases end-to-end latency and degrades overall network efficiency, which runs directly counter to Solana’s core vision.

Moreover, Solana’s consensus mechanism rewards validators for timely votes via vote credits, and there is a bounded window in which votes must be submitted to receive full rewards. While geographically clustered validators may not feel the impact of late propagation as strongly, validators that are further away from the cluster are disproportionately affected. Over time, this creates subtle pressure against geographic decentralization, as validators farther from the network’s core face higher penalties through no fault of their own.

Unfriendly market structure for market participants

From a market microstructure perspective, traditional financial markets operate in a continuous and highly deterministic environment. Orders arrive continuously and are executed on a First-In, First-Out (FIFO) basis by a centralized matching engine. This determinism allows market makers to cancel and update quotes efficiently without constantly risking being picked off. As a result, they can quote extremely tight spreads, even on trades worth millions of dollars, without relying on priority fees.

Late packing breaks this determinism. When transactions are not included continuously throughout the slot, execution becomes less predictable. This increases execution variance, introduces jitter, and makes outcomes around liquidations and auctions harder to anticipate.

A block-building environment that lacks uniformity and determinism is simply not suitable for sophisticated market participants. Over time, this makes it harder for Solana to onboard and retain TradFi and ultimately undermines its ambition of becoming a globally distributed NASDAQ.

Negative impact on user experience

Beyond abstract market structure concerns, late packing and slot timing games have very concrete second-order effects. Block building that maximizes rewards often does so at the expense of applications and users.

When block packing is inconsistent or delayed, users face higher uncertainty around transaction inclusion. A trade that should have gone through may fail. A swap may execute at a worse price than expected. A liquidation or arbitrage transaction may miss its execution window entirely. And a trader who needs the freshest info about the next state transition is operating less efficiently. From the user’s perspective, this shows up as failed transactions, unexpected slippage, or the need to repeatedly resubmit transactions with higher priority fees. Overall, this directly impacts application reliability.

If we assume that the network should improve every day, becoming faster, more reliable, and easier to interact with, then these dynamics are clearly misaligned with that goal.

The Block Assembly Marketplace

To address the block-building issues outlined above, Jito recently introduced the Block Assembly Marketplace (BAM). Put simply, BAM is a new block-building architecture designed to bring verifiability, privacy, and programmability to Solana’s transaction pipeline.

Instead of allowing each validator to independently decide how to pack and order transactions (often in short-term, profit-maximizing ways, as discussed earlier), validators can delegate transaction scheduling to specialized external BAM nodes. These nodes operate inside Trusted Execution Environments (TEEs), which provide strong cryptographic guarantees that the ordering logic is executed exactly as specified.

In other words, validators still validate and vote on blocks, but BAM nodes handle transaction ordering in a way that is verifiable, auditable, and tamper-resistant. The logic behind this is that BAM’s ordering is designed to optimize Solana’s long-term potential by bringing uniformity and determinism to the block-building process and helps create a healthier market structure.

Specifically, BAM is designed around several key properties:

1. BAM nodes receive transactions from clients and schedule them according to transparent, verifiable ordering rules.

2. BAM nodes forward transaction sequences to the leader .

3. The leader executes the transactions exactly in the order they were received, produces the block, and broadcasts it to the network.

4. BAM nodes verify execution results match the forwarded sequences. Leaders who insert or reorder transactions are disconnected.

BAM’s structure is designed to provide transaction ordering which is verifiable and enforced by secure hardware. Since launch, BAM has seen over 122m SOL staked, capturing 28.9% of total Solana stake and 367 validators running BAM.

At a high level, Jito proposed a structural shift in how block building works on Solana by creating a more predictable, fair, and deterministic execution environment with BAM. However, this has also sparked debate within the ecosystem. Some teams argue that this approach gives Jito too much influence over block building and could centralize power around a single infrastructure provider. From their perspective, BAM risks becoming a de facto monopoly over transaction ordering rather than a neutral coordination layer.

This pushback is important, as it has brought alternative viewpoints into the discussion. Notably, one of the strongest responses came from Harmonic, a competing Solana block-building solution developed by the Temporal team.

Harmonic’s Approach To Block-Building

Harmonic works as an aggregation layer that runs multiple block builders in parallel, where each builder constructs its own version of the block and the validator picks whichever one best fits its preferences. In addition to Harmonic, the Temporal team also operates Nozomi, a transaction landing service, and more notably HumidiFi, a leading prop AMM on Solana, having an established presence across multiple layers of Solana’s transaction supply chain.

At a high level, Harmonic’s core disagreements with Jito center around what should be optimized, how it should be measured, and who gets to define the standards in Solana’s block building environment.

Concerns around monopoly dynamics and metric neutrality

One of Harmonic’s core criticisms is that Jito plays multiple roles at once: infrastructure provider, BAM architect, and creator of the IBRL scoring framework. From Harmonic’s perspective, this creates an inherent conflict of interest. They argue that IBRL does not measure “good block building” in a neutral way, but instead measures compliance with Jito’s preferred architecture, and thereby penalizes competing approaches. But we will see that this claim is nuanced.

Disagreement on “late packing”

Harmonic also strongly disputes the claim that their blocks rely on late packing in the sense described by Jito. According to them, the IBRL scoring framework misses a key detail: Harmonic blocks are packed continuously by block builders running parallel block-building processes. Transactions only appear in the final ticks because that is when the auction resolves, not because block construction is delayed. From Harmonic’s perspective, it is not fair that IBRL penalizes this behavior simply because it looks less smooth on the surface.

The only metric that matter for Harmonic: execution

From Harmonic’s perspective, best execution is the only metric that truly matters if Solana is to become the home of Internet Capital Markets. On that front, they argue that BAM does not deliver the optimal outcome. They claim that when looking at execution data across DEX programs, Harmonic shows the strongest results: validators running Harmonic repeatedly outperform the cluster baseline on both mean and median throughput. For them, this is the clearest measure of best execution, and this is what Solana ultimately needs.

Innovation through competition

Harmonic’s final argument is that only open competition can sustainably drive innovation in block building. From their perspective, it is far easier for stakers and validators to hold multiple competing block builders accountable than it is to keep a single dominant architecture in check. Prematurely converging on one standard risks locking in suboptimal design choices and slowing innovation over time. Harmonic argues that Solana should remain a free market for block-building innovation, where different approaches compete on execution quality. In that way, they see BAM as an attempt to consolidate block building around Jito’s architecture in order for them to preserve its leading position.

As an alternative, Harmonic advocates for a Proposer–Builder Separation (PBS) model on Solana. The goal here is to split block production into two distinct roles. Block builders compete to construct blocks, and validators, acting as proposers, no longer build blocks themselves, and instead, choose from blocks submitted by these competing builders.

The idea is to reduce excessive proposer power and create an open marketplace for block building. In theory, this should improve execution quality, limit monopoly control, and allow innovation to emerge organically, rather than being dictated by a single block-building architecture.

Nuancing the Debate

The debate between Jito and Harmonic highlights an important and healthy tension in Solana’s evolution. Both sides raise valid points, but the reality is more nuanced than a simple “BAM vs. competition” framing.

On Monopoly and Neutrality

Harmonic’s concerns around monopoly dynamics are not unfounded. Jito does occupy multiple roles within the ecosystem, which naturally raises questions about metric neutrality. That said, it is important to put this risk into perspective. A block builder that is vertically integrated with a market-making operation, such as Harmonic, arguably poses a much larger systemic risk to Solana. In that scenario, block construction incentives can directly conflict with fair execution and overall network health in ways that are far harder to observe or constrain.

From this angle, Jito’s multiple roles do not necessarily dilute metric neutrality. Jito is not vertically integrated across the full value chain of block building and trading. More importantly, its approach with BAM explicitly promotes verifiability, transparency, and auditable transaction ordering.

Now regarding the scoring system, Harmonic is right to be a critic. Measuring “good” block building is inherently complex, and any scoring framework will necessarily involve simplifications and trade-offs. Jito should be more open to listen to Harmonic feedback in order to improve his scoring. That said, the existence of imperfections in IBRL should not, on its own, invalidate the underlying issues it aims to surface, and as Jito mentioned in its IBRL methodology section, they will continue refining the model and expanding the set of signals over time to improve accuracy.

However, if an actor is intentionally delaying shred propagation, they are, as a matter of fact, slowing everyone else down. And if this behavior is profit-motivated, then that profit is necessarily extracted from the rest of the network.

Performance alone is not sufficient

Harmonic is right to emphasize execution quality. Best execution is undeniably critical if Solana aims to support large-scale, institutional-grade markets, as it directly impacts slippage, liquidity, and overall capital efficiency. But performance alone isn’t enough. Determinism and uniformity in transaction ordering are foundational to healthy market microstructure. Sophisticated trading systems require predictable execution environments.

So yes, Harmonic validators do pack more DEX transactions per slot, but that throughput correlates with longer slot times which is precisely the kind of non-determinism TradFi institutions cannot tolerate: if execution characteristics change depending on which validator is leading, firms cannot scale their operation with confidence and the case for migrating serious flow onto Solana weakens. In that case, we can argue that higher performance at the expense of determinism and uniformity is not a Pareto improvement for the long-term health of the network and also puts bearish pressure on SOL’s potential as an asset. As Mert, CEO of Helius, recently noted on X, late packing may generate incremental short-term gains, but it reduces the probability of sustained SOL appreciation over the long run.

To be clear, these concerns are not hypothetical, they are explicitly recognized in Solana’s own roadmap. In The Internet Capital Markets Roadmap, block-building dynamics and execution quality are identified as critical challenges. While they agree that BAM is an interesting solution forward, it is true that ideally, market structure improvements should come from the protocol itself as it is uniquely positioned to optimize for long-term network health rather than short-term profit incentives.

On competition and innovation

Competition is undeniably a powerful driver of innovation, and Harmonic is right to caution against prematurely locking Solana into a single block-building architecture. Allowing multiple approaches to compete in the open can surface better designs, stress-test assumptions, and reduce the risk of stagnation.

However, market forces tend to be highly short-term oriented. In competitive environments, participants are often incentivized to optimize for immediate gains, even when those strategies degrade long term potential. This dynamic closely resembles a prisoner’s dilemma: if one validator refrains from extracting short-term value, others will not. The rational response at the individual level is therefore to maximize short-term profit, even if the collective outcome is worse for the network.

Without an entity or mechanism capable of setting clear rules and protecting against this dynamic, there is a real risk that Solana’s long-term potential is undermined. Ultimately, this would also hurt validators themselves. If Solana fails to achieve its broader mission, SOL’s long-term value will suffer and SOL price remains one of the most important determinants of validator profitability.

BAM aims to address this problem by shifting it to the application layer through plugins and ACE. In doing so, it ensures that users and applications capture more of the value, rather than having it extracted at the block-builder or proposer layer. The result is a structural shift from value extraction in block building to value creation at the application layer.

It’s also important to be clear about the limits of the PBS path Harmonic is advocating for. PBS does not inherently guarantee fair outcomes from builder competition and introduces new pressure points. To illustrate this, the Ethereum Foundation has spent several years experimenting with proposer–builder separation and open builder marketplaces. While this reduced direct proposer discretion, it introduced new centralization vectors around relays and dominant builders and did not eliminate harmful MEV strategies and instead moved to a different layer of the stack.

In other words, separating proposers from builders changed the structure of extraction, but did not fully solve the underlying incentive misalignment. Even today, more than 25% of DEX trades on Ethereum are still subject to sandwiching. Yes, Solana’s architecture is meaningfully different from Ethereum’s but the incentive problem is not architectural. As long as builder selection optimizes for short-term validator revenue, the pressure to extract rather than create value persists regardless of the underlying consensus mechanism.

Competition at the builder layer alone has not proven sufficient to guarantee fairness, determinism, or long-term alignment. That is an important lesson when considering whether Solana should replicate a similar path.

Closing Thoughts

Solana remains well positioned to become the home of Internet Capital Markets. But its block-building microstructure remains a meaningful unresolved problem. Notably, Jito has identified two major issues that break the determinism and uniformity of block building on Solana: late packing and slot lagging.

To address these issues, Jito introduced BAM, a framework designed to make block building on Solana more transparent and deterministic. Today, over 28% of the network’s stake already runs BAM.

At the same time, this new architecture has faced notable pushback, most prominently from Harmonic. Their core argument is that BAM reduces competition and could therefore slow innovation. They also claim that Jito’s metrics are incomplete, and that the only thing that ultimately matters is best execution.

In this piece, we’ve seen that some of these concerns are well founded, but they also obscure important context. Harmonic is vertically integrated with a market-making operation, which means BAM directly challenges its economic model. And while execution quality matters, determinism and uniformity are the binding constraints for a healthy market structure. Competition without clear rules can easily devolve into a prisoner’s dilemma, where validators optimize for short-term profit at the expense of Solana’s long-term potential.

At Shoal, we believe BAM is a meaningful step forward and an important solution to help Solana become the home of Internet Capital Markets. It shifts the paradigm from value extraction at the block-builder or proposer layer to value creation at the application layer. That said, over the long run the network may need a more native, protocol-level solution to create a safer and more balanced competitive environment. But that is still 12–18 months out, and Solana needs something that works today.

Finally, this is an ongoing and rapidly moving debate. None of this is settled, and there are genuine arguments on both sides. We encourage every SOL staker to look at the data, ask validators directly why they run the block-building software they do, and make their own informed decisions. Where you stake matters. It shapes the execution environment, the market structure, and ultimately the kind of network Solana becomes.

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author's own, not the views of their employer. Shoal Research is a Jito delegate. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

Sources

Anza. “The Internet Capital Markets Roadmap.” https://www.anza.xyz/blog/the-internet-capital-markets-roadmap

Helius. “How Solana Works: An Executive Overview.” https://www.helius.dev/blog/solana-executive-overview

Helius. “Solana Slots, Blocks, and Epochs Explained.” https://www.helius.dev/blog/solana-slots-blocks-and-epochs

IBRL. “IBRL Validator Block-Building Explorer.” https://ibrl.wtf

IBRL. “Introducing the IBRL Explorer: Measuring Validator Block-Building Quality.” https://ibrl.wtf/blog/introducing-the-ibrl-explorer-measuring-validator-block-building-quality/

Jito Labs. “Block Assembly Marketplace Explorer” https://bam.dev/explorer/

Jito Labs. “Block Assembly Marketplace Documentation.” https://bam.dev/docs/

Jito Labs. “Introducing BAM.” https://bam.dev/blog/introducing-bam/

Harmonic. “Harmonic Documentation.” https://docs.harmonic.gg/

Harmonic. “Statement on Block Building and BAM.” source

Ruggero. “How Solana Builds Blocks.” https://www.ruggero.io/blog/how_solana_builds_blocks/=

hildobby. “MEV Sandwich Trades.” https://dune.com/hildobby/sandwiches

As ICOs return with renewed momentum, their underlying infrastructure becomes critical. Powered by its own FHE stack, Zama introduces a new Sealed-Bid Dutch Auction that enables confidential participation in public ICOs. In this report, we examine the mechanics of Zama’s Public Auction and its future implications for onchain capital formation.

The ICO Renaissance

In 2013, J.R. Willet set out to solve a very specific problem: raise money on the internet instead of going to VCs in Silicon Valley. To do so, he tried something no one had previously attempted: he published a whitepaper for the project he was building, and convinced friends and strangers online to send him Bitcoin in exchange for receiving a newly issued digital token in return. Within a month, Willet had managed to raise over $750,000, and 60 million tokens were then distributed to investors in a public sale.

Willet’s experiment was called Mastercoin, and the OMNI token sale quietly became the first-ever Initial Coin Offering (ICO). Though online crowdfunding had already existed through websites like Kickstarter and Indiegogo, Mastercoin’s ICO marked the first time a project raised capital by selling a freely tradable digital asset on a public blockchain.

A year later, Ethereum blew Mastercoin’s ICO out of the water, raising 31,000 BTC (worth ~$18.6M at the time) of its own. Shortly after, the ERC-20 standard was introduced: a simple framework that made creating and issuing digital tokens trivial. What followed was nothing short of a Cambrian explosion of ICOs. OMNI was the first, but in hindsight it was obviously never going to be the last.

After a few quiet years, demand for ICOs is coming back in force. In 2025 alone, Pump Fun raised $600M for PUMP in the third-largest ICO ever, and teams like Plasma ($50M), Monad ($269M), and MegaETH ($49M) all completed ICOs, with more sales expected in the coming months. Nearly every major sale in 2025 saw strong investor appetite, oversubscribing and selling out in minutes.

Despite fewer token sales since 2021, the total amount of capital raised has continued to grow, concentrating into fewer, higher-quality projects.

Yet this resurgence surfaces something that today’s ICO infrastructure has not yet been able to solve for: confidential investor participation.

Privacy (Or The Lack Thereof) In ICOs Today

Structurally, an ICO isn’t so different from an IPO: it involves a public sale, a launch event, and a freely traded asset. The fundamental difference is in their underlying rails. ICOs run on public blockchains and settle via smart contracts. Investors send funds to a smart contract, which then allocates them digital tokens programmatically based on predefined terms.

This architecture introduces a high degree of public transparency: anyone can independently verify that the sale executed as intended, that token allocations matched contract rules, and that every contribution and refund was accounted for. But this transparency comes with a greater underlying cost: every contribution, wallet, bid, and allocation is permanently visible onchain.

By design, blockchains offer pseudonymity: users interact through randomly generated wallet addresses which are not directly tied to legal identities. However, once a wallet address is linked to a real individual — whether through an exchange withdrawal, an ENS name, or other onchain activity patterns — their entire sale behavior, spanning from contribution size, wallet balance, bidding and sale patterns, and the rest of their transaction history becomes exposed.

Alongside visibility into sale behavior, public blockchains also expose ICO participants to Maximal Extractable Value (MEV) dynamics: value that sophisticated onchain actors (i.e. block builders, validators, and specialized searchers) can capture by reordering, including, or excluding transactions in a block. Simply put, those with visibility into pending transactions can position their own transactions to capture value by front-running, back-running, or sandwiching other participants’ transactions.

For retail investors, this level of transparency is a privacy leak. A single sale interaction can reveal far more than intended: not just how much they contributed, but how much they hold, when they sell, and how they behave across every other onchain activity tied to that wallet. Over time, these disclosures compound, creating persistent visibility into an individual’s financial position and behavior. In practice, this also increases exposure to MEV, as retail users are the least equipped to protect themselves from adverse transaction ordering and value extraction during highly competitive sale events.

For institutions, this level of transparency is simply a non-starter. Participating in a fully public onchain sale broadcasts order flow, position sizing, treasury capacity, and execution behavior to competitors and counterparties. Even the act of bidding can signal strategic intent well before a position is finalized. Combined with MEV dynamics, this creates unacceptable execution risk, where large bids can be detected, priced against, or exploited in real time. As a result, most institutional capital is effectively unable to participate in public ICOs at all, regardless of demand.

Early internet crowdfunding platforms like Kickstarter and Indiegogo did handle personal data, but access to this data was strictly permissioned: backer identities, contribution sizes, and emails were private to the creator and the platform.

By contrast, most attempts to incorporate some form of privacy into token sales have taken form as private, offchain processes, through whitelisted sales, negotiated allocations, data rooms, SPVs, and manual allocation mechanics. These approaches provide confidentiality for their participants, but only by abandoning the very mechanic that made ICOs powerful in the first place: open global access. The result is a bifurcated market in which institutions can only participate through private deals, while retail is pushed into fully transparent public sales that compromise their privacy.

What’s missing is a middle ground: an open, public ICO rail that preserves fairness and transparency at the system level, while providing confidentiality, by default, at the participant level: the allocation logic would remain publicly verifiable, while sensitive participant data would remain private. This type of platform would allow large-scale, rules-based ICOs, supporting tens or hundreds of thousands of participants, without revealing certain details such as individual contribution sizes or linking to prior wallet activity.

Of course, the next question is what this looks like in practice: how would one build public, auditable, yet confidential token sale infrastructure on top of today’s public blockchains?

The Zama Sealed Bid Dutch Auction

Zama is introducing a new Sealed Bid Dutch auction mechanism to bring confidential participation to onchain ICOs. Built on the Zama Protocol itself using FHE, Zama’s launchpad allows investors to participate in ICOs while encrypting sensitive bid and allocation data.

Understanding Zama

At its core, Zama is infrastructure that enables confidentiality for public blockchains using fully homomorphic encryption (FHE). FHE refers to a cryptographic technique that allows computations to be performed directly on encrypted data without first exposing the underlying values. In practical terms, this means data can remain confidential while still being used inside smart contract logic. Inputs are encrypted before reaching the blockchain, and processed in encrypted form through Zama’s confidential execution framework, and can only be decrypted by authorized parties at the end of execution.

Zama implements this capability through the fhEVM, its core confidentiality framework. A small set of specialized smart contracts is deployed on underlying public chains, enabling applications to validate encrypted inputs, manage encrypted state, and coordinate decryption through Zama’s key management system. These contracts can be integrated into existing wallets and frontends, which users can then easily access. Meanwhile, developers can write confidential smart contracts onchain using Zama’s fhEVM Solidity Library and standard EVM tooling.

As a result, sensitive data remains encrypted throughout its entire lifecycle: from the moment it leaves the user, through onchain computation, until the final result is decrypted by an authorized party. This breakthrough unlocks new classes of onchain applications, one of which is the confidential ICO.

How The Sealed Bid Dutch Auction Works

As with a ‘traditional’ ICO, investors deposit assets and place bids on the token to be sold, and once the auction is complete tokens are programmatically distributed to investors. The critical distinction is that, in Zama’s design, bid data is encrypted by FHE and therefore remains confidential throughout the auction process: whereas the bid price is public, the deposit amount and token allocation are not.

Zama uses a Dutch auction format, meaning the lowest bid price is selected as the clearing price as bids are processed in price-descending order until the available supply is exhausted. During bidding, which lasts a total of 4 days, investors can submit encrypted bids. Once bidding ends, the auction contract calculates the clearing piece by selecting the lowest price at which a bid was filled, and distributes tokens to investors accordingly. Investors can then claim their tokens, or a refund if necessary.

Consider an auction with a total supply of 100 tokens to be distributed:

• Bob bids 40 tokens at a price of $2. His bid is filled, and now there are 60 tokens left to distribute.

• Alice bids 60 tokens at a price of $1. Her bid is filled, and now there are 0 tokens left to distribute.

• Mert bids 20 tokens at a price $0.50, but since there are 0 tokens left his bid is not filled.

In this case, the clearing price is thus $1, given that it was the lowest price at which all the tokens were distributed (Alice’s bid). Therefore Bob receives 40 tokens and a $40 refund, Alice receives 60 tokens and no refund, while Mert receives zero tokens and a $10 refund. All tokens sold from the auction are fully unlocked and freely tradable upon claim.

User Flow

By design, the user flow is relatively simple and straightforward.

Investors first encrypt (or shield) the assets they intend to use for bidding. In exchange, they receive confidential “cTokens” at a 1:1 ratio, representing encrypted versions of the underlying collateral. Investors then submit bids for the token being launched at their chosen price, using these cTokens. Throughout the auction, bids can be monitored and managed directly through Zama’s auction interface, without revealing sensitive bid details onchain.

Once the auction concludes, the contract computes final allocations and clearing price. Investors can then claim their outcomes: successful bidders receive their allocated tokens, while any excess collateral is refunded. At this point, investors may either decrypt their remaining cTokens back into standard tokens or continue using them across other confidential applications within Zama’s broader ecosystem.

Technical Mechanics

At the core of Zama’s protocol is an FHE system. Rather than exposing inputs, balances, or intermediate values to the blockchain, all sensitive data is maintained in encrypted form throughout contract execution. This encrypted state is preserved under a unified FHE key, allowing smart contracts to operate directly on ciphertext without ever decrypting underlying values during execution.

To break this down further, the execution flow follows a well-defined pattern. A user encrypts an input (x) locally, producing an encrypted value E(x). This encrypted input is submitted onchain, where it cannot be decrypted by validators, block builders, or other applications. Smart contracts then compute directly over encrypted inputs, producing an encrypted output E(f(x)). Only authorized parties can decrypt the final result, while all intermediate computation remains opaque to the blockchain itself.

This execution model is implemented through the fhEVM, Zama’s confidentiality execution framework. The fhEVM operates as a specialized layer on top of existing public blockchains, coordinating encrypted computation, maintaining encrypted contract state, and managing controlled decryption through Zama’s key management system. A small set of smart contracts deployed on the underlying chain handle encrypted input validation, encrypted state transitions, and interactions with the key infrastructure, while remaining fully compatible with existing EVM environments.

When applied to the Auction, these mechanics ensure that the auction state is never represented in plaintext. Assets deposited by participants are immediately converted into encrypted state and represented as confidential balances within the auction contract. Bid evaluation, allocation logic, and refund calculations are all performed over encrypted values, preventing observers from inferring contribution sizes, wallet balances, or allocation outcomes during the auction process.

To implement this in practice, Zama introduces confidential “cTokens”, which serve as FHE-encrypted representations of standard ERC-20 assets. These tokens are issued programmatically when assets are encrypted and are redeemed when assets are decrypted, without exposing balances or transaction history onchain. cTokens are implemented using the ERC-7984 confidential token standard, allowing encrypted assets to remain composable across other confidential applications built on Zama’s protocol.

As a result, sensitive data remains encrypted for its entire lifecycle; from the moment it leaves the user, through onchain computation, until the final result is decrypted by an authorized party. In the context of ICOs, this architecture allows auctions to remain publicly verifiable at the system level, while ensuring that participant-level data remains confidential by default.

The North Star: Growing TVS

Zama’s adoption and growth is framed around a new type of metric: the Total Value Shielded (TVS).

TVS refers to the total amount of economic value that is actively encrypted and kept confidential using Zama’s protocol. Just as total value locked (TVL) became a dominant metric for tracking DeFi liquidity, TVS is meant to serve as a proxy for how much meaningful economic activity is taking place under cryptographic confidentiality.

The intuition is simple. The higher the TVS, the more confidentiality is being exercised across assets, applications, and users. As TVS grows, confidentiality evolves from a niche feature to a systemic property of onchain markets: assets become harder to surveil, applications harder to exploit, and users regain more control over the privacy of their onchain activity.

Zama’s strategy for growing TVS is infrastructure-first. Rather than building and owning end-user applications, Zama is positioned as a chain-agnostic confidentiality layer that other developers, protocols, and platforms can build on top of. Zama provides the primitives for encrypted computation and confidential state, while leaving application design, UX, and go-to-market decisions to application developers.

This way, Zama does not need to directly control demand to drive growth. TVS increases as confidentiality becomes a default property across an expanding set of applications and chains. Adoption is reflected in how broadly encrypted computation is integrated and how much economic value is processed under confidentiality, rather than in usage of any single application.

From a deployment perspective, Zama is designed to be chain-agnostic. The protocol is launching first on Ethereum, with plans to expand across EVM-compatible chains and, longer-term, into non-EVM environments such as SVM-based chains. This multi-chain approach ensures that confidentiality is not siloed to a single execution environment, but can follow users and assets wherever onchain activity migrates to.

TVS in Practice: The ZAMA Token Launch

The first live demonstration of an encrypted ICO will be the Zama’s Sealed-Bid Auction will be Zama’s own token sale. The $ZAMA token launch will be conducted on Ethereum, using the Zama Protocol itself to encrypt bids through FHE.

Zama will sell 8% of the $ZAMA supply through this auction. Participants submit bids onchain while sensitive bid data, including contribution size and allocation, remains encrypted throughout the process. Once bidding concludes, the auction clears transparently according to publicly verifiable rules, and tokens are distributed immediately with no vesting or lockups. In doing so, the Auction intends to bring fair price discovery, global access, and confidentiality to ICOs within a single platform.

This auction will mark the first instance of Total Value Shielded (TVS) flowing through Zama’s protocol in production. Capital contributed to the auction is encrypted end-to-end, allocations are computed over encrypted state, and only final outcomes are revealed, thus serving as a real-world stress test for confidential onchain capital formation at scale.

Use Cases and Applications

While confidential ICOs provide a clear and immediate application, the underlying primitives enabled by Zama’s launchpad can, in theory, extend far beyond token sales. At a high level, any onchain mechanism that relies on bidding, allocation, or competition over scarce resources can benefit from encrypted execution:

• NFT Auctions: Encrypted bidding enables sealed-bid NFT sales where bid amounts remain confidential until settlement. This could help prevent bid anchoring, strategic signaling, and enable fairer price discovery.

• Prediction Markets: Encrypted bidding introduces a new design space for prediction markets, where individual positions and strategies can remain private during market formation, while outcomes and settlement remain publicly verifiable.

• Governance: Encrypted bidding can be applied to onchain governance systems where outcomes are influenced by market signals or competitive inputs rather than simple token-weighted voting. By keeping bids or commitments confidential during the decision process, protocols can reduce signaling effects, cartel formation, and strategic coordination that often distort outcomes in fully transparent governance systems. This can be especially useful in futarchy-style governance, where participants express beliefs through markets tied to policy outcomes. In these settings, encrypted bids help preserve genuine price discovery by preventing participants from anchoring or reacting to visible positions before markets resolve.

• Solver Order Flow (PFOF) Bidding: Encrypted bidding can be applied to MEV and order-flow markets, where solvers compete for the right to execute transactions or bundles. This can potentially reduce information leakage around solver strategies, limit copy-trading and reactive bidding, and mitigate winner-take-all dynamics driven via information asymmetries, thus encouraging a more competitive and efficient market for onchain order flow.

• Confidential Block Production or Rewards Auctions: In Proof-of-Stake systems, encrypted bidding could be used to allocate block production rights or reward opportunities over defined time windows. Validators would submit encrypted bids for future slots or epochs, with allocations determined programmatically once the auction clears. By keeping bids private, such mechanisms reduce signaling and strategic front-running among validators, while enabling more market-driven allocation of block production rights.

Taken together, these examples show that encrypted ICOs are just one instance of a broader pattern. Any onchain mechanism that relies on bidding, allocation, or competition over scarce resources can potentially integrate and benefit from encrypted execution.

Closing Thoughts

At Shoal, we believe ICOs are positioned for renewed demand if the underlying infrastructure evolves to support confidential participation. Retail investors can participate in public sales without broadcasting their balances, positions, or trading behavior onchain. Institutions can participate without exposing order flow, signaling strategic intent, or introducing execution risk that distorts broader market activity. Both benefit from reduced MEV exposure during highly competitive bidding processes.

Zama introduces a concrete path toward this future by treating confidentiality as first-class infrastructure and orienting the protocol around a clear objective: growing the TVS across the broader onchain economy.

With this in mind, we look forward to a new chapter of confidential onchain capital formation.

Sources

• Cryptorank ICO Analytics, cryptorank.io/ico-analytics/

• ICO Drops, icodrops.com/

• Cryptoasset Market Coverage Initiation: Network Creation. Bloomberg Research, research.bloomberg.com/pub/res/d28giW28tf6G7T_Wr77aU0gDgFQ

• “Digital Tulips? Returns to Investors in Initial Coin Offerings.” ScienceDirect, sciencedirect.com/science/article/abs/pii/S0929119920302303

• Coin Perspective: J.R. Willett. Medium, medium.com/coin-story/coin-perspective-3-j-r-willet-136ed51a852c

• Zama Documentation. Zama, docs.zama.org/homepage/

• Zama Protocol Litepaper. Zama, docs.zama.org/protocol/zama-protocol-litepaper

• Zama FHEVM Whitepaper. Zama GitHub, github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf

• Zama Public Auction: auction.zama.org

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. This post has been created in collaboration with the Zama team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

A special thanks to Connan and Mathis for their feedback and review.

Crypto’s Misalignment Problem

One of the first big value propositions of crypto was its ability to significantly lower the friction for capital formation and offer an alternative to the traditional funding model for startups. Instead of relying on VCs, banks, or waiting 10+ years for a potential IPO, crypto introduced a new way for anyone to raise money permissionlessly on the internet and let their project “go public” on day one through a token.

This was a real breakthrough with huge potential. As people began experimenting with this new model, interest exploded, ultimately leading to the historic ICO boom of 2017, where millions were raised and thousands of new tokens were launched.

But while the concept was promising in theory, it was still immature in practice and led to widespread market abuse. Everything was all about hype, and there was a clear misalignment of incentives among the major token stakeholders. Put simply: the more successful an ICO, the greater the incentive for the team to extract what was in the treasury instead of growing the pie. And with no framework to prevent this behavior, it quickly became the default equilibrium and gave rise to countless scams and low-quality tokens.

Apart from SwissBorg and a few others that managed to build something meaningful, most projects from the 2017 era bled to death. While some were genuine projects ahead of their time, many were outright scams, heavy on tech buzzwords to excite people into buying their ICO but with no real substance behind them.

Today, we are still carrying that baggage. While there has been real progress in terms of crypto products and adoption, there has been far less advancement in how to properly structure tokens. And unfortunately, the market continues to suffer from abuse and bad practices, driven by too many short-term opportunists who see crypto as a way to make a quick buck. These actors still treat TGE as exit liquidity rather than the beginning of a project, and focus all their energy on hype instead of building something real: faking followers and metrics, launching at ridiculously overinflated valuations with low float, paying large amounts for tier-1 CEX listings, and relying on sophisticated market makers to engineer “perfect” chart patterns so the project appears successful long enough for teams to exit while leaving retail as exit liquidity.

What’s sad is that these dynamics also put pressure on genuine founders because short-term hype tends to dominate attention. As a result, even serious teams feel pushed to conform to the same practices just to keep attention on their project and remain competitive in terms of mindshare.

Ultimately, all of this has contributed to putting into question the trust and legitimacy of the crypto industry. If nothing is done to correct it, crypto risks becoming irrelevant, not because the technology, products, or underlying promises are not good enough (they are), but because the space has given too much attention to the wrong actors and has failed to provide clear protection for investors against value-extractive practices from insiders.

Fortunately, every problem is an opportunity in disguise. As we speak there are a few very interesting 0-to-1 initiatives being built that aim to solve this token misalignment problem problem and help crypto finally fulfill its potential as the new capital formation layer of the internet. Among them, one project that clearly stands out is MetaDAO.

In the subsequent section, we will explore MetaDAO core value proposition, how it’s positioned to reshape how the internet funds new ideas.

A New Capital Formation Layer

MetaDAO is a fundraising and governance platform that enables anyone on the internet to raise money for their startup ideas, while also simultaneously protecting investors and backers from founder abuse, misaligned incentives, and rugs.

To do so, they are creating a new standard for structuring token launches through what they call “ownership coins,” and they are also pioneering a governance model based on decision markets (and inspired from the concept of Futarchy) to better align incentives between all key stakeholders in a project.

Now, before going deeper into MetaDAO, it is important to introduce how decision markets and futarchy work.

Futarchy 101

Futarchy is a form of governance first put forward by economist Robin Hanson in 2000, which makes decision-making based on prediction markets. In a futarchy, decisions are traded, rather than being voted on.

Instead of debating proposals in endless forums and then voting, futarchy embraces the power of markets to forecast which decisions will be best. Proposals pass when the market speculates that they’re good. Proposals fail when the market speculates that they’re bad.

The core axiom behind this model is that markets aggregate information more efficiently than traditional voting, and that the collective incentives of traders produce better predictions than the opinions of a small group. In fact, we already see this dynamic in practice through the accuracy of prediction markets: during the last presidential election, for example, platforms like Polymarket delivered far more accurate forecasts than professional pollsters.

Now in the MetaDAO case, its decision market governance model is inspired by this same logic, but applies it to the key decisions an economic organization must make.

Let’s take a concrete example to better explain what it is:

Suppose a company wants to undergo a merger acquisition as part of a strategic vertical-scaling plan:

In the current model, a major decision like this goes through a shareholder vote. The board reviews the proposal, issues a recommendation, and shareholders vote. Decisions are slow and inefficient, and they depend on the opinions of a small, often uninformed group, distorted by politics and misaligned incentive. Suppose the deal would temporarily boost the stock price but is clearly destructive over the long term. Executives whose bonuses are tied to short-term stock performance, or board members nearing retirement who want to lock in higher payouts, may vote in favor of the deal. Even though it weakens the company strategically, the short-term price bump benefits them personally.

Now with a decision market model, the organization would open a market to forecast the company’s value if the merger happens and if it does not. Traders buy and sell based on which outcome they believe will create more value. If the “merge” market trades higher, the merger passes. If the “don’t merge” market trades higher, it fails.

How does MetaDAO work?

MetaDAO operates through two complementary pillars built around futarchy: an ICO launchpad to launch ownership coins, and a new governance model using decision markets.

The Ownership Coins Launchpad

Projects can raise money via MetaDAO’s launchpad architecture, which is designed to be “unruggable” in the sense that founders cannot walk away with the money. The idea here is simple: if a launchpad can protect investors from rugs and ensure that founders cannot abuse the system, then it will 1) attract genuine founders and 2) attract genuine capital to fund the right ideas, which is a clear win-win for every one.

Here’s how that works in practice:

1/ The founder sets transparent terms

If a founder wants to raise on MetaDAO, they first need to publish their idea/thesis and define the proposed terms of the token launch. This includes:

• Mission and vision

• Market opportunity

• Minimum USDC target

• Monthly budget

• Optional token incentive package for the team (through a price-based performance design)

2/ Sale goes live

The sale then opens on MetaDAO for a defined period. Anyone can contribute USDC to support a project they believe after evaluating the idea, the team, and the terms. Each sale has a minimum funding target (below which all contributors are refunded) and a discretionary cap, giving founders the option to choose how much of the total raised they want to accept.

3/ What happens if the sale succeeds

If the funding target is met, the founder decides how much USDC they keep, and investors receive their proportional ownership coin allocation.The treasury also automatically deploys 20% of the USDC and 2.9M tokens into liquidity pools to establish healthy market liquidity.Then all the USDC and token minting rights are transferred into a market-governed treasury, which the founders cannot directly access.

4/ Transparent funding from founders

Every month, the founders can spend USDC up to their monthly budget allowance. Everything above that needs to first go through a market proposal to be spent. Furthermore, at any time, anyone can raise a proposal to return USDC to tokenholders and if the proposal passes, then it will be executed.This structure is designed to prevent founders from draining or abusing the treasury and serve as a strong protection guarantee for investors.

While the launchpad is still somewhat gated today where MetaDAO ultimately decides which project can participate based on their own discretionary criteria, the long-term goal of MetaDAO is to make it fully permissionless, meaning anyone with an idea can apply, set their terms, and let the market decide whether it deserves funding.

The Governance Model

MetaDAO’s decision market governance model is automatically embedded into every project that launches on the ICO platform. However, any external project can also choose to adopt it if they believe it is a better alternative to their current governance structure.

In practice, projects can decide whether to delegate their full treasury to MetaDAO, or simply transition from a vote-based governance model to a market-based one.

Once this model is integrated, teams set a minimum amount required to open a proposal market, configure a few basic parameters, and from there anyone can raise a proposal about the protocol: from big cash spending, key strategic decisions, and more. Markets then determine whether the proposal should pass or fail.

• Proposal time: the amount of time a proposal should be active before it can pass or fail. Three days by default. Specified in Solana slots.

• Pass threshold: the percentage that the pass price needs to be above the fail price in order for a proposal to pass.

• Minimum liquidity: to prevent spam, proposers are required to lock AMM liquidity in their proposal markets. The amount they are required to lock, in both USDC and the futarchy’s token, is specified by each DAO.

• TWAP Sensitivity Parameters: The price that gets factored into the TWAP can only move by a certain dollar amount per minute. Each DAO must specify this dollar amount.

For instance, in the example below, Omnipair raised a proposal to spend 64,000 USDC to audit their protocol, and we can see that it passed by a very large margin as the market concluded that this was a good decision.

How Does This Solve Crypto’s Misalignment Problem?

Together, these properties help address the core misalignment problem that is plaguing crypto today:

- At launch, the market cap equals the Net Asset Value (NAV) in the treasury.
This creates a strong psychological and economic floor. If the price trades below NAV for a meaningful period, anyone can raise a proposal to return USDC to tokenholders. This provides strong protection to early investors.

- The ownership coin structure ensures that the intellectual property, the funds, and the authority to mint new tokens are controlled by independent, market-driven governance not by the team. This imbues the token with real value and protects investors from insider abuse.

-The market decides the best path forward for the project and not a small group of insiders. This makes governance more transparent and fair, with decisions driven by what is best for the protocol.

On top of that, the real beauty of MetaDAO’s model is its simplicity. It doesn’t rely on complex and unsustainable financial engineering to make a token valuable. Instead, it works by removing all the vectors that could create negative externalities and aligns incentives around the token in the most straightforward way possible.

The MetaDAO Ecosystem Today

The first ICO launch on MetaDAO took place on April 9th 2025 with MtnDAO. At the time, it was viewed as an uncertain and bold experiment. However, it proved to be interesting enough to capture the attention of the broader ecosystem. Fast forward to today, adoption has accelerated significantly. Both founders and investors are increasingly drawn to MetaDAO’s unruggable ICO design.

As of writing, there have been 8 ICOs launched on MetaDAO with a combined total of $25.6M million USD raised. Below is an overview of all MetaDAO launches so far:

If an investor had allocated $1,000 into each ICO (and managed to receive full allocation), for a total of $8,000 invested, their portfolio would now be worth approximately $26,552 with a theoretical peak value of around $51,728. This represents a current performance of 231.9% and a maximum performance of 546.6%. These stats are unprecedented for any launchpad, especially in current market conditions.

Beyond ICOs, multiple organizations have also begun migrating their DAO structures to a decision market model, and interest continues to grow steadily. We’ve even seen some of the biggest names in Solana like Jito and Sanctum start experimenting with it. Others such as Kyros, ORE, and Drift (just to name a few) are also leveraging MetaDAO’s infrastructure for their governance models.

MetaDAO Business model

Ultimately, MetaDAO is a business: it aims to solve a real market problem, but it also has a token and investors, and aims to generate meaningful revenue from its product.

Right now, MetaDAO earns revenue primarily through AMM fees on token launches.
Every project launched through MetaDAO trades on a MetaDAO-controlled AMM pool, which currently charges 25 bps in fees (with plans to increase this to 50 bps).

In the future, MetaDAO is considering adding a small fee on the oversubscribed portion of a raise, capturing value from high-demand launches. Further, the team is also exploring ways to integrate META into liquidity pools paired against ownership coins, which would further reinforce the place of META within their launchpad.

Together, these components make META directly tied to the success of ownership coins, and therefore to the success of the MetaDAO launchpad itself. And they are already off to a strong start, as the platform has already generated over $1M in revenue to date.

Risks and Important Considerations

Of course, every design comes with trade-offs and potential second-order effects. For now, MetaDAO is far from perfect. While they have managed to build a true 0-to-1 innovation, there are still many iterations needed to go from 1-to-n and drive broader adoption, especially beyond the crypto echo chamber and into the wider startup world as a credible alternative to traditional funding models.

Below are some of the drawbacks we have identified in the current model:

1/ The pro-rata subscription model:

The sales being uncapped and with founders deciding how much they take from the total is a great property. However, this model introduces a major drawback: if a launch is 2× oversubscribed, you are incentivized to put up 2× the USDC for the allocation you want, which then makes it more oversubscribed and reinforces the loop.

This dynamic can also disproportionately favor large players, as smaller investors often cannot “keep up” with the escalating deposits required to maintain their allocation. The result is potential dilution of smaller backers and excessive token concentration in the hands of a few.

Furthermore, because deposits and withdrawals can happen until the very last second, contributors must actively monitor the sale to avoid being underallocated (if others pile in late) or overallocated (if someone withdraws at the last moment).

2/ A permissionless platform

Going permissionless in the sense that any project can leverage their ICO launchpad is great, it fits the ethos of crypto, and it is easy to understand the rationale behind this choice from MetaDAO.

However, removing gatekeepers also opens the door to a decline in project quality. If anyone can launch a project without any filtering, there can be a flood of low-quality launches that may weaken the MetaDAO brand (even though the team acknowledges this risk and prefers it over potentially missing a unicorn idea).

From a user point of view, it can cause a sort of investment fatigue if there are too many projects, and it will also make their job harder when deciding which projects / founders are worth investing in.

3/ The governance model

Let’s be honest, there is still a high barrier to entry in understanding how decision market based governance actually works. For many users, the mechanics of taking positions and interpreting outcomes are not very intuitive. And because the whole model requires putting real money at stake, participation may end up being limited to highly sophisticated users. In practice, this can weaken the “wisdom of the market” argument if not enough traders are watching the market.

While we can argue that MetaDAO decreases friction around capital formation, the model increases long-term friction on capital usage by teams. This is an important consideration. If a founder needs to get something done but the market rejects proposals by a tiny margin because of a small clause in a document and not enough traders are actively trading on it. We can argue that this might not be the best use of a founder’s time, and repeated failed proposals could slow execution rather than accelerate it.

Some Ways Ahead

Several solutions and design enhancements could help MetaDAO overcome its current drawbacks. Below are some avenues the team is already exploring, along with additional suggestions from Shoal on how the product could be improved:

1/ Improving the subscription models

MetaDAO’s founders are already working on solutions to fix the weaknesses of the pro-rata subscription model.

In the short term, they are considering adding fees on commitments over a certain amount to reduce the incentive to over-allocate.

In the longer term, they are exploring a system, where everyone would have a “Ownership score” based on how much “ownership coin” they help, and higher scores receive better allocation. This would help ensure that high-quality, long-term holders are prioritized.

2/ The need for a curation layer

As MetaDAO moves toward a permissionless model, there will be a need for a curation layer.

One potential solution we find interesting is a “verified launch” system (similar to the blue tick on X) where: if a project wants to launch on MetaDAO, it first needs to get publicly “referred” by a trusted partner or a well-regarded founder / voice in the ecosystem (MetaDAO can select the pool of partners). This would act as a first filter, and the referrer would effectively put their reputation on the line creating natural incentives to only endorse projects they truly believe in.

Additionally, it would be valuable for the MetaDAO platform to better aggregate key information about each project to help investors make informed decisions (social graph signals, founder background, key links, optional KYC from founders, etc.).

This would make the screening process far more efficient for potential investors.

3/ Reducing friction on capital usage

In the long run, it’s crucial that MetaDAO does not create unnecessary friction for teams trying to execute. One idea the team is exploring is making “team-sponsored” proposals easier to pass than normal proposals. For example, if the default pass threshold requires the price to move at least +2%, a team-sponsored proposal might still pass even if the market moves –2%. In practice, this gives the team the benefit of the doubt and acknowledges that founders should be trusted unless the market signals strong disagreement.

Another potential improvement is introducing a light filter before proposals go live, either by the team or by a small community council to reduce noise and ensure only meaningful proposals reach the market.

Closing Thoughts

Crypto has enormous potential to improve capital markets and reinvent how capital formation happens on the internet. But for years, this promise has been held back by structural incentive misalignment: too many short-term opportunists have taken advantage of poor token structures to extract value from the market instead of creating it. In practice, this has led to a slow erosion of trust and legitimacy in the crypto industry as a whole.

MetaDAO proposes a genuinely interesting and refreshing solution to this problem through a launchpad architecture that is unruggable by design and that realigns incentives between founders and investors.

While this is a very bold mission, they have already made some very meaningful progress. The performance of their launchpad is one of the most impressive in crypto, and it has managed to attract a strong cohort of high-quality founders. Moreover, MetaProphet, Kollan, and the entire MetaDAO team have proven to be thoughtful, ambitious builders who take feedback seriously and are clearly motivated to keep improving their offer.

At Shoal, we believe MetaDAO stands a real chance of becoming an important pillar for how the next generation of startups, crypto-native or not, fund their ideas on the internet. This is especially relevant at a time when countries like the US are actively moving toward pro-crypto and pro-innovation regulatory frameworks.

Sources

• Elementus. “ICO Market Report - August 2018.” elementus.io/blog-post/ico-market-august-2018/

• MetaDAO. “MetaDAO Project Update.” x.com/MetaDAOProject/status/1909251208336019511

• MetaProphet. “On Improving MetaDAO’s Launchpad Model.” x.com/metaproph3t/status/1985393563153440786

• MetaProphet. “Thoughts on Allocation Mechanics.” x.com/metaproph3t/status/1979243370452258837

• Galaxy Research. Why Futarchy Matters. galaxy.com/insights/research/why-futarchy-matters/

• MetaDAO Documentation. docs.metadao.fi/

The Coming Age of Autonomous Agents

AI agents have advanced beyond simple language tasks. They’re now capable of executing trades, managing capital, making payments, and operating across more complex, multi-step tasks. But as these systems grow more capable, one thing becomes clear. There is a growing mismatch between the infrastructure that enabled today’s AI models and the structural needs of autonomous agents. Systems designed to serve request-response interactions simply aren’t suited for software that needs to make decisions and perform multi-step operations independently.

Consider an autonomous agent tasked with managing a protocol’s treasury. It monitors market conditions across dozens of protocols daily, evaluating risk parameters and executing capital allocation strategies. To do so, an agent needs to query a proprietary API for market data, but the provider can revoke access or modify pricing without notice. Rate limits shift based on provider capacity. The AI model generating trading signals is opaque, as stakeholders can’t verify whether the agent’s decisions actually follow its intended logic. As agents cannot hold assets or sign transactions, they cannot execute actions directly. As a result, there is no shared source of truth to confirm whether an agent acted within their authorized parameters if a dispute occurs.

Why Traditional AI Infrastructure Fails for Agentic Intelligence

Developers building autonomous agents have little choice among infrastructure providers today. Market concentration has consolidated AI infrastructure around a handful of providers controlling access to models and compute. This creates dependency risk in several ways. Pricing becomes unpredictable as terms of service change unilaterally. Rate limits appear and disappear based on provider capacity, and API endpoints shift without warning. For autonomous agents requiring guaranteed uptime and predictable costs, these dependencies represent existential vulnerabilities.

The issue goes deeper than reliability. Centralized platforms cannot provide the transparency and verifiability that multi-party coordination demands. When multiple stakeholders delegate authority to an agent, they need to verify that its decisions followed approved logic. They need audit trails showing how inputs produced outputs, along with guarantees that the agent operated within specified parameters.

Centralized APIs cannot provide this. They return outputs without proofs, processing requests behind closed doors. Users must trust that the model executed correctly, that results were not manipulated, and that pricing was calculated fairly. This level of trust may be tolerable for individual developers building applications but breaks down for autonomous agents coordinating economic activity across organizational boundaries.

Economics introduces another barrier. Agents that generate value cannot capture it directly or participate as economic actors. All revenue must flow through accounts controlled by humans or corporations. Platform operators capture the upside from agent activity while externalizing risks, preventing the emergence of agent-to-agent markets and limiting use cases to narrow, pre-approved categories.

Perhaps the deepest incompatibility lies in how centralized platforms handle permissions and authorization. When multiple parties coordinate through autonomous agents, trust must be explicit and mechanically enforced. Permissions require cryptographic verification that all participants can audit, and execution paths must be provably correct, with disputes resolvable through objective evidence rather than platform policies.

No centralized platform can provide these guarantees. Doing so would contradict centralization itself. The moment a trusted intermediary controls execution, the exact dependencies and trust assumptions that autonomous coordination seeks to eliminate reappear.

Altogether, these limitations show that centralized AI infrastructure cannot support autonomous agents in any environment that requires persistence, verifiability, or cross-organizational coordination. A different architectural foundation is needed.

Talus: A New Decentralized Operating System for Agents

Talus Network aims to address the structural limitations of today’s agentic infrastructure through a decentralized framework purpose-built for autonomous onchain agents. Its architecture supports verifiable workflow execution, cryptographic state management, and programmable economic primitives, enabling agents to custody assets, execute transactions, and coordinate across organizational boundaries through onchain settlement and shared state.

Core Design Principles

Talus is designed on several foundational principles:

• Verifiable computation: Through onchain workflows and cryptographic proofs, Talus ensures that every agent action is auditable.

• Composability: Talus supports modular tool registries and agent “packages,” allowing agents to access and share tool registries and invoke other agents into their workflows without platform-specific integration.

• Economic alignment: Economic incentives are embedded directly into the protocol, with value flowing programmatically and transparently to agents and infrastructure operators.

At its core, Talus offers deterministic workflow execution where each step in an agent’s operation is recorded as a state transition onchain. This creates an immutable audit trail for how decisions were made and executed, while allowing agents to coordinate across organizational boundaries through shared, verifiable state.

The system supports offchain computation with onchain verifiable results, addressing the cost and performance constraints of executing complex AI workloads directly on blockchain virtual machines (VMs). Compute-intensive tasks like model inference occur offchain through a distributed network of execution providers. Cryptographic commitments and state updates settle onchain. This hybrid architecture preserves transparency without sacrificing the performance requirements of production-grade AI systems.

How Talus Actually Works

Talus works via a modular architecture: each component serves a specific role in enabling autonomous-agent coordination. The system couples blockchain consensus with offchain computation, delivering an infrastructure that is both verifiable and efficient. Nexus, the core engine, handles onchain coordination and offchain execution.

A consumer submits a request to a Talus workflow, which is encoded as a directed acyclic graph (DAG). Each step in the DAG corresponds to a tool invocation or state transition. During execution, the Nexus onchain packages coordinate with Leaders offchain to trigger tools, update workflow state, and return results. This separation between workflow specification (onchain) and computation (offchain) allows Talus to remain verifiable without sacrificing performance.

Talus Stack Architecture

Talus runs on the Sui blockchain and utilizes Sui’s object-centric state model and the security of Move. Agents, tools, and workflows are represented as objects with explicit ownership, meaning each resource has a defined owner and can be transferred, combined, or restricted through code. Smart contracts on Sui Move define the structures and protocols for agent and workflow management, allowing developers to then build atop this foundation using different contract package types:

• The Nexus Onchain Package (NOP): The foundational layer maintained by the Talus team, defining core data structures, workflow coordination logic, and the protocol’s primitives.

• Tool Packages sit atop this foundation, allowing developers to publish modular tools — on or offchain — that agents can invoke. Tools expose defined inputs, outputs, and access/payment constraints.

• Talus Agent Packages (TAP): enable developers to compose these tools into complete agent systems with custom business logic. This layered structure creates a clear separation of responsibilities while enabling composability across the ecosystem.

The relationship between Talus agents, the Nexus onchain packages, the Leader network, and the tool ecosystem is shown below. Talus agents route requests to Nexus, Nexus updates workflow execution onchain, and Leaders perform offchain computation while triggering tools across both environments.

Nexus sits at the center of execution flow: agents submit workflow requests onchain, Nexus updates workflow state, and Leaders coordinate offchain execution by invoking the appropriate tools and returning results onchain. This separation between onchain coordination and offchain computation is what enables Talus to remain both verifiable and performant.

Workflow Engine and Deterministic Coordination

Talus encodes agent behavior as directed acyclic graphs (DAGs) stored onchain. Each node within these graphs represents a specific action, whether reading data, calling a tool, or modifying state, and the dependencies between nodes establish which operations must complete before others can begin. Because the workflow specification itself lives onchain, anyone can audit what an agent is authorized to do before execution even begins.

Computation, however, is offloaded. The Leader network performs the actual work by pulling node definitions from Nexus, executing the corresponding tool, and submitting a verifiable receipt back to the chain. This hybrid model preserves performance for heavy workloads while ensuring that state, permissions, and results remain transparent.

Workflow Execution States

Each workflow execution creates a DAGExecution object that tracks progress through walk states. A walk represents the execution of a single node in the workflow graph. Walks transition through four possible states: Active (currently processing), Successful (completed and ready to activate next nodes), Failed (encountered an error), or Consumed (completed but waiting for other inputs to converge).

This state system ensures workflows handle errors gracefully and prevents deadlocks through fallback mechanisms. If a tool fails, the workflow can trigger fallback edges that route execution to alternative paths, maintaining liveness even when individual components encounter issues.

Talus Tools and Modular Capabilities

Tools represent functional modules that agents can invoke during workflow execution. When registered onchain, each tool declares its expected inputs, produced outputs, pricing structure, and access requirements. This registration system creates an open marketplace where developers contribute capabilities and agents discover services organically.

Tool execution can happen in two environments:

• Onchain tools interact directly with Sui smart contracts.

• Offchain tools execute compute-heavy tasks (LLM inference, analytics, image work, math routines) coordinated by Leaders.

Leaders orchestrate these calls and return results onchain with proofs or commitments, keeping the entire workflow auditable.

Payment and Gas Model

Every workflow execution requires economic coordination across multiple service providers. Users deposit payment into a gas budget within a globally unique gas service object. Before execution begins, Nexus verifies sufficient funds to cover all potential tool costs based on the workflow’s maximum execution path.

As the workflow progresses, each tool consumes its designated payment from this budget only after successfully completing its work and passing any required verification steps. This delivery-versus-payment mechanism ensures tools receive compensation for honest work while protecting users from paying for failed or incomplete operations.

The protocol implements a dual-track revenue system. According to current protocol design, when overall protocol revenue falls below a threshold, priority fee income is burned, reducing token supply and supporting token economics. When revenue exceeds the threshold, fees are distributed to Leaders performing coordination work.

Data Storage with Walrus

Essential workflow metadata lives on Sui’s blockchain, ensuring its integrity and availability. However, storing everything onchain becomes prohibitively expensive. Walrus, a decentralized storage platform from Mysten Labs, handles supplementary data including agent memory, operational context, and intermediate results.

Agent functionality depends critically on maintaining context and memory across multiple sessions, allowing them to learn from past interactions and build upon previous decisions. Walrus provides this storage layer with configurable verification mechanisms.

Tools can reference data stored on Walrus through onchain commitments, enabling workflows to pass large datasets between operations without incurring excessive gas costs. This distributed storage approach maintains verifiability for intermediate values while achieving practical scalability.

Leader Network and Distributed Execution

Leaders serve as the coordination layer between onchain workflow specifications and offchain computational resources. They monitor the blockchain for workflow execution requests, identify which tools need to run, coordinate their execution, and submit the results back onchain as verifiable receipts.

Execution Flow in Practice

Consider an investment agent making a portfolio adjustment.

The user triggers the workflow by submitting a transaction to the agent’s smart contract. This creates a DAGExecution object and emits an event that Leaders monitor. A Leader picks up this event, retrieves the first tool’s information from the onchain registry, and discovers it needs to fetch current market prices. The Leader calls this price oracle tool, receives the data, and submits it back onchain along with payment for the tool. This activates the next workflow node, perhaps an analysis tool that recommends allocation changes. The Leader orchestrates this second tool’s execution, submits results, and continues until the workflow reaches a terminal node that executes the actual trades through onchain DeFi protocols. Each step produces an auditable record while the Leader handles all coordination overhead.

Security and Progressive Decentralization

The network maintains security through economic incentives. Leaders stake collateral that faces slashing if they behave maliciously or fail to maintain liveness. The system rotates execution responsibilities across multiple Leaders, preventing any single operator from dominating the network. These mechanisms create fault tolerance and resistance to coordinated attacks.

The Leader network architecture evolves progressively. It currently operates with initial trusted Leaders to ensure reliability while the platform establishes product-market fit. Future phases introduce TEE-based distributed execution, where Leaders run inside trusted execution environments that provide cryptographic proof of correct operation. The final phase reaches a fully permissionless model where anyone can stake tokens and participate as a Leader. This gradual transition maintains service quality while steadily increasing decentralization and minimizing trust assumptions.

The combination of object-based state management, flexible security levels, hybrid execution, and economic coordination addresses specific technical constraints that emerge when agents need to operate across organizational boundaries.

Building a Market for Autonomous Intelligence

Talus creates economic infrastructure where agents transact as independent participants rather than subordinate tools. The $US token is designed to serve as the coordination and incentive layer across the network. It functions as payment and settlement for workflows, tools, and agents, and as the medium for tool registration and Leader network participation.

Within this system, agents compensate other agents for specialized services based on computational requirements and market demand. Revenue flows programmatically to tool developers through usage, to model providers through invocations, and to Leaders through execution work. $US holders secure the network through staking and participate in governance over protocol parameters.

The result is a market-driven coordination system where intelligence operates as a commodity. Stakeholders capture value proportional to their contribution. Economic sustainability derives from network activity rather than external subsidy.

Use Cases: What Talus Makes Possible

Taken together, these primitives (workflows as DAGs, tools with flexible security, hybrid execution, and programmable payments) address a specific class of applications that existing infrastructure cannot support.

Agent-Driven Prediction Markets

Prediction markets aggregate distributed information through financial incentives, but their efficiency depends on participants who can continuously process diverse data sources and execute trades instantly. Human traders cannot simultaneously monitor onchain oracle feeds, analyze social sentiment, cross-reference polling data, and adjust positions across multiple markets 24/7. Talus agents eliminate these constraints:

• Polling oracles provide official results with confidence intervals

• LLM tools analyze sentiment from social platforms

• Statistical models weight historical accuracy and detect trends

• Execution tools adjust positions across market contracts

• Risk modules enforce portfolio constraints

Traditional platforms like Kalshi operate as black boxes where users cannot inspect internal algorithmic behavior. Talus workflows, by contrast, can record decision steps onchain. When an agent is configured to trade based on polling data and sentiment, the DAG execution trail provides a verifiable onchain record of which tools were invoked, in what sequence, and how their outputs influenced the final action.

Computation-heavy analysis runs offchain within the Talus agent framework, while trades and key coordination events settle onchain. Market resolution can follow the same pattern: agents query multiple oracles, check for consensus conditions, and trigger settlement only after verification.

Verifiable DeFi Agents

Consider an MEV protection bot executing trades across decentralized exchanges. Today, users must trust the operator’s claims about routing logic. With Talus, the agent produces cryptographic receipts for every step: route selection, price impact calculation, final execution path. Users verify that the actual transaction matched the stated strategy without requiring blind trust.

Cross-protocol yield strategies work similarly. When an agent moves capital between lending markets, stakes proceeds, and rebalances positions, the Leader network generates proofs for each interaction. The complete execution trace becomes auditable. If something goes wrong, participants can verify exactly where and why through cryptographic evidence recorded onchain.

Agent-to-Agent Tool Markets

A trading agent needs machine learning predictions but doesn’t want to train models itself. On Talus, it hires a specialized prediction agent, verifies the model’s identity through cryptographic attestation, and pays per inference onchain. The predictor earns revenue automatically through usage. No platform middleman, no API contracts, no trust required beyond cryptographic verification.

This creates markets for specialized intelligence. Agents that build valuable capabilities, whether ML models, data analysis tools, or execution strategies, monetize directly through usage. Tool development becomes economically sustainable without platform dependency.

Cross-Chain Autonomous Portfolios

Today, moving assets across blockchains requires custodial bridges or trust assumptions. Talus enables coordinated operations across chains through verifiable state queries. A portfolio agent could check prices on Ethereum, execute a swap on Base, and stake proceeds on Arbitrum, all within a single coordinated workflow.

Each step occurs within the same execution context. The Leader network provides cryptographic proofs that operations happened correctly across different chains. This eliminates custodial bridge risk since agents read and write state directly rather than locking assets with intermediaries.

Accountable DAO Governance

Treasury management agents prove their risk calculations through transparent workflows auditable before vote execution. Stakeholders verify that proposed allocations derive from stated logic. Emergency response agents act autonomously within smart contract-enforced constraints. All authorization logic remains verifiable onchain. This creates accountability for autonomous governance while maintaining automated response speed.

Privacy-Preserving Enterprise Operations

Through TEE integration, agents process sensitive data without exposing it. Healthcare agents analyze patient records, financial agents evaluate credit risk, and compliance systems audit transactions, all while keeping underlying data encrypted. Only the TEE decrypts inputs during computation, and cryptographic attestation proves correct processing. This enables autonomous intelligence in regulated domains where privacy is mandatory.

Economics

Talus creates a self-reinforcing agent economy where growth compounds across the network. As tools expand capabilities, agents become more powerful. More capable agents attract users with sophisticated needs. Rather than relying on centralized rent-seeking, the network distributes value programmatically to contributors while capturing protocol-level revenue through usage-based fees.

Value Flow and Network Effects

When a workflow executes, users fund its execution through onchain fees that cover computation and coordination. As execution completes and verification passes, fees distribute to workflow participants according to protocol rules:

• Leaders earn for coordination work

• Tool developers earn from usage

• Agent developers earn from deployment and performance

This creates reinforcing network effects. Each additional tool increases what agents can do, attracting users with more sophisticated needs. Increased usage generates more fee revenue for successful capabilities, incentivizing developers to build specialized services. The flywheel accelerates as growth in one area drives growth everywhere else.

Token Value Accrual

$US sits at the center of this economy as the primary unit of value and coordination. (Note: $US has not yet been listed on exchanges as of this writing.) Network activity creates ongoing demand for the token to pay for usage, access features, and participate in governance. Users can pay base gas fees in SUI, with the protocol routing settlement and incentives through $US. Direct $US payment enables priority execution and enhanced features.

Supply Dynamics and Fee Structure

The protocol implements a capped supply with a fee model that links token scarcity to real usage. When protocol revenue falls below a threshold, priority fees are burned rather than distributed. This permanently reduces circulating supply. As network activity scales, this creates a value-accrual loop where demand acts on shrinking supply. When revenue exceeds the threshold, fees distribute to Leaders performing coordination work, aligning rewards with network growth.

Staking and Participation Incentives

Staking forms the foundation of Talus’s security model. Leaders stake $US to participate in coordination and earn fee revenue. Stakes face slashing for malicious behavior or failures. Tool providers stake when registering capabilities, aligning their incentives with service quality. As the marketplace grows, staked tokens lock supply while usage-driven demand continues.

Long-term holders gain governance rights and access to protocol features. This creates incentives to participate in the ecosystem rather than purely speculate. The combination of staking requirements, governance participation, and usage-based rewards aligns all participants with network health and sustainable growth.

Limitations & Open Challenges

Talus addresses coordination problems that existing systems cannot solve, but introduces distinct constraints in doing so. Understanding these limitations matters for realistic deployment and protocol development.

Technical Constraints

Verification adds latency to every workflow. Each step requires cryptographic proof generation and onchain settlement, creating overhead that centralized API calls avoid. Offchain execution handles compute-intensive tasks efficiently, but the coordination layer still adds milliseconds to seconds depending on blockchain finality. For high-frequency trading or real-time response systems, this latency may prove prohibitive.

When agents hire other agents as subcontractors, workflow dependencies multiply across the system. A failure in one sub-workflow cascades through dependent operations, creating unpredictable failure modes. Debugging becomes difficult when execution spans multiple tools, chains, and offchain providers. Tooling for monitoring and diagnosing multi-agent systems remains immature.

Economic and Governance Risks

Incentive misalignment emerges at protocol boundaries. Leaders might prioritize high-fee workflows, delaying execution for lower-paying users. Tool developers could extract value through opaque pricing or degraded service quality. Agent owners might exploit protocol mechanics for individual gain at collective cost.

Token holders must balance competing interests across tool developers, agent operators, and end users when making governance decisions. Protocol upgrades require consensus among stakeholders with different time horizons and risk tolerances. Without effective mechanisms, the system risks capture by concentrated interests or stagnation through disagreement.

Security Concerns

Malicious agents pose systemic risk. An agent could exploit tool vulnerabilities, manipulate other agents through adversarial inputs, or drain assets through legitimate-looking workflow logic that contains hidden exploits. Permissioned tool registration and workflow verification provide safeguards, but determined attackers may find edge cases.

Despite slashing penalties, a coordinated attack on the Leader network could compromise workflow execution during the current trusted phase. The progressive path toward full decentralization addresses this over time, but the trusted setup introduces temporary centralization risk.

Ethical and Societal Implications

Autonomous agents operating in the real world raise questions infrastructure cannot answer. An agent managing capital might make economically rational decisions that cause social harm. Agents coordinating across domains could amplify systemic risks or trigger unintended consequences no single operator foresaw. The protocol verifies what agents do, not whether they should do it. This gap between technical capability and ethical judgment remains an open challenge for autonomous systems.

Future Outlook: The Path Toward Decentralized Intelligence

The trajectory of AI development points toward a fundamental reorganization of economic activity. As agents gain autonomy and operate across decentralized infrastructure, they will evolve from tools that execute commands into participants that negotiate, transact, and coordinate independently. Talus positions itself as the coordination layer for this transition.

Agents as Economic Participants

Current systems treat agents as extensions of human operators. Future systems will treat them as independent actors. Agents will hold assets, evaluate counterparties, negotiate terms, and execute agreements without human intervention at each step. An agent managing a treasury will adapt strategies based on market conditions rather than following predefined rules. It will hire specialized agents for analysis and coordinate with others to achieve objectives.

This requires infrastructure where agents can transact trustlessly. Traditional finance operates through intermediaries that verify counterparty creditworthiness and enforce settlement. Decentralized systems replace intermediaries with cryptographic guarantees and programmatic enforcement.

Talus provides this foundation through verifiable workflows and onchain settlement. As agent-to-agent commerce grows, the protocol could function as settlement infrastructure similar to how SWIFT coordinates interbank transfers or Visa processes card transactions.

Expansion of Decentralized AI Infrastructure

Security and privacy requirements will drive technical evolution. Zero-knowledge machine learning and trusted execution environments will enable privacy-preserving verification. A healthcare agent could prove it analyzed patient data correctly without exposing the data itself. A trading agent could verify strategy execution without revealing its algorithm.

Interoperability will expand beyond blockchain ecosystems to encompass traditional systems. Agents will read state from legacy databases, execute operations through conventional APIs, and write results to blockchains. The distinction between onchain and offchain execution will become less important than whether operations are verifiable and settlement is trustless. Marketplaces for tools and agent services will mature from experimental protocols into established infrastructure with standardized interfaces and competitive pricing.

The Long-Term Vision

Decentralized intelligence may evolve into global utility infrastructure. Just as cloud computing commoditized server access and the internet commoditized information distribution, autonomous agent platforms could commoditize intelligent coordination. Multi-agent ecosystems might manage supply chains, coordinate energy grids, or optimize resource allocation across organizations.

Talus is positioned to serve as backbone infrastructure for this future. The protocol does not attempt to solve all problems but provides coordination primitives that other systems can build upon. If agents become economic participants at scale, they will require neutral infrastructure for settlement and verification. Whether Talus captures this role depends on execution, but the architectural foundation exists. The question is not whether autonomous agents will reshape economic activity, but which infrastructure will coordinate them.

Closing Thoughts

The infrastructure supporting AI development has reached a critical juncture. Centralized platforms delivered the current generation of AI models, but they cannot support the next phase of autonomous agent deployment. Their constraints are structural, not temporary: opaque execution, unilateral control, and no way for agents to act as independent economic actors prevent the coordination mechanisms autonomous systems require.

Talus addresses these limitations through architectural choices that leverage blockchain properties for verifiable execution, permissionless participation, and programmable economic alignment. Rather than trying to rebuild the whole AI stack, Talus offers coordination primitives: composable infrastructure that other systems can build on.

The path forward involves more than technical specs. Verification latency must shrink. Multi-agent debugging tools must emerge. Incentives must align across stakeholders. Security must decentralize progressively. These are real challenges, but they are addressable through iterative development.

What remains uncertain is adoption trajectory, not technical feasibility. The architectural foundation exists for agents to operate as independent economic participants. Whether this vision materializes at scale depends on execution, ecosystem development, and whether builders choose verifiable coordination over centralized convenience.

Autonomous agents will reshape economic activity. Which infrastructure coordinates them remains an open question. Talus positions itself through verifiable workflows, agent-first architecture, and programmable economic primitives. Success will be measured not by technological sophistication alone but by whether the protocol becomes essential infrastructure for the autonomous systems that follow.

At Shoal, we believe autonomous agents could reshape economic activity at scale. What matters is the infrastructure that supports them. Adoption will determine its ultimate role, but with verifiable workflows, native asset control, and modular coordination primitives, Talus’s architecture is designed in a way that gives it a credible path toward becoming foundational rails for the agentic economy.

Sources

• Talus Documentation. Talus Network, docs.talus.network

• Talus Network Litepaper. Talus Network, talus.network/litepaper

• Nexus Whitepaper. Talus Network, talus.network/whitepaper

• Talus Combines Walrus and Sui to Enable Onchain AI Agents. Walrus, walrus.xyz/blog/talus-builds-onchain-ai-agents-walrus

• What Is Talus ($US)?. Whales Market, whales.market/blog/what-is-talus/

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. This post has been created in collaboration with the Talus team. Some members of the team have material holdings of SUI and Talus. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

DeFi solves the information asymmetry problem that has riddled TradFi’s capital markets, though still more in theory than in practice. The value, and difficulty, of coordination, only becomes more evident in decentralized systems, and despite its transparency, self-custody, and operational efficiency, liquidity in DeFi still remains scarce and mercenary as there is no shared coordinating framework. In this piece, we explore the need for onchain liquidity coordination and how Turtle approaches this challenge.

The Capital Coordination Challenge

For all its innovation and growth, DeFi has long been plagued by mercenary, non-sticky liquidity. This is ultimately a product of structural misalignment between foundations and liquidity providers (LPs). Foundations allocate token emissions to incentivize aligned, multi-cycle liquidity for their protocols, but may have no idea what type of LPs they will attract nor how long they will stick around for. Meanwhile LPs, seeking a return on their capital, have little visibility into the organic activity or trading volume a protocol can sustain over time, therefore it becomes rational to exit once emissions end rather than remain committed. As such, most protocols and LPs stand little chance against the self-reinforcing cycle of short-term incentives and mercenary liquidity that defines much of DeFi today.

Information asymmetry is not new to capital markets by any means. The distribution of knowledge around asset quality, risk, and value between borrowers and lenders has never been proportional for as long as capital markets have existed. Investment banks emerged to solve this underlying coordination failure, conducting diligence, structuring credit into tranches by risk appetite, and distributing that credit across a syndicate of lenders accordingly. Borrowers gained access to consolidated capital through a single negotiation, while the IBs earned fees for aggregating information, standardizing risk, and coordinating supply and demand.

This process, formally known as syndication, transformed credit markets by separating origination from investment. Large banks would originate loans but distribute the debt to non-bank investors such as hedge funds, pension funds, and collateralized loan obligations (CLOs). The Basel II and III frameworks reinforced this dynamic by incentivizing banks to transfer credit risk off balance sheet and optimize capital efficiency. What began as bespoke loan placements evolved into a standardized system for converting private credit assessments into tradable financial products. Though complex and costly, syndication has helped standardize processes for diligence, distribution, and ongoing risk management, building the infrastructure that enabled credit to be assessed, distributed, and maintained at scale. More importantly, it demonstrated the value of coordination in capital markets by turning a fragmented, bilateral lending process into a scalable, trillion-dollar asset class.

DeFi sought to rebuild these financial coordination architectures with code. AMMs and lending markets encoded core functions of intermediation (i.e. price discovery, collateralization, settlement) into smart contracts. Anyone with an internet connection and capital could supply liquidity or borrow assets on shared, observable infrastructure where transaction settlement was compressed from days to minutes or even seconds. This transparency, however, has not produced coordination.

Protocols can issue incentives, but they cannot determine or predict their outcomes. Token emissions attract liquidity, but they do not specify who participates, how long that capital will remain, or under what conditions it will leave. Each program operates in isolation, competing for the same pool of capital with no shared framework for evaluating risk or aligning expectations. Liquidity flows toward the highest nominal yield, not toward sustainable participation. When incentives end, deposits leave, and the process begins again

Information asymmetry in DeFi thus re-emerged in a different form. Onchain data made transactions visible but that barely means much if investors and LPs still cannot easily assess governance quality, operational integrity, or the long-term economics of a protocol, nor if foundations, for their part, cannot distinguish between speculative and committed capital.

DeFi protocols have demonstrated that smart contracts and code can replace costly, operationally inefficient human intermediaries across a range of financial products and services. But removing intermediaries has also made it that much more difficult to coordinate how liquidity is distributed across these systems in a way that aligns incentives for all participants.

With this in mind, we can reasonably assert the opportunity for DeFi’s ‘investment bank’, a protocol dedicated to structuring, allocating, and sustaining liquidity across markets. Rather than replacing existing protocols, it would provide the coordination infrastructure through which foundations and liquidity providers can negotiate and maintain capital at scale. In effect, such a protocol would serve the same function investment banks did for credit markets: aggregating information, matching the right participants, and standardizing how liquidity is structured and deployed.

Turtle: DeFi’s Investment Bank Layer

Turtle is an onchain liquidity distribution protocol connecting lenders (i.e. onchain LPs) with borrowers, including protocols and foundations seeking liquidity. Through curated campaigns, custom deposit vaults, and embedded distribution across partner frontends, Turtle aims to standardize how Turtle standardizes how liquidity is sourced, coordinated, and deployed across DeFi. Since its MVP launch in May 2024, Turtle has coordinated over $5.5B in total liquidity, nearly $300m in boosted campaign deposits, grew its treasury to over $13.7M, and has over 400k connected wallets alongside 15k campaign LPs.

Functionally, Turtle operates as a liquidity distribution layer beneath chains, bridges, and applications onchain. It integrates through APIs, wallets, and smart contracts to track liquidity positions and coordinate deployment across multiple ecosystems. Foundations define their liquidity terms, including total amount, duration, and under what conditions. Turtle works with foundations to help structure the best possible deal in order to incentivize LPs long term and ensure liquidity is not mercenary. LPs meanwhile can review terms and deposit liquidity directly to the foundations through Turtle’s non-custodial vaults. Together, this structure aims to improve upon standard token emission models through organized dealflow, functioning as an Investment-Bank-style coordination layer across the broader DeFi ecosystem.

Turtle’s architecture revolves around curated campaigns and embedded distribution, the two mechanisms through which it coordinates liquidity:

• Curated Campaigns: Structured liquidity programs negotiated with protocol teams, each with defined capital targets, reward schedules, and durations. These campaigns bring consistency and transparency to how liquidity is sourced and rewarded.

• Embedded Distribution: Integrations that surface campaigns directly within wallets, exchanges, and analytics platforms, allowing users to discover and participate in opportunities through familiar interfaces.

Campaigns are standardized and published through Turtle’s deal interface; deposits are managed through non-custodial structured vaults; and participation data flows through embedded dashboards and leaderboards that coordinate rewards and feedback. To better understand how these components all work together, it’s worth unpacking them in greater detail.

Discovery and Dealflow Layer

The Discovery and Dealflow layer, known collectively as Turtle Deals, structures how liquidity opportunities are sourced, negotiated, and distributed through the protocol. Partner protocols define their key campaign parameters, namely their target capital, eligible assets, reward terms, and duration, which are then verified and published on the Turtle Deals dashboard. This is designed to provide a standardized and transparent framework to onchain liquidity sourcing.

Within this system, Boosted Deals represent campaigns co-incentivized by the Turtle DAO, where LPs (Turtle Members) earn both native rewards from partner protocols and additional rewards, paid out in TURTLE tokens, proportional to their participation. Partner protocols provide the DAO with a defined boost payment, and the DAO distributes those boosts back to Members pro-rata, the first distribution happening during Turtle’s TGE.

This process ties liquidity incentives to real-time activity. Partner protocols gain structured, predictable access to capital under defined parameters, while LPs are compensated transparently according to duration and engagement. The Turtle DAO functions as the coordination and settlement layer, tracking deposits, managing boost payouts, and maintaining auditability across campaigns.

Ecosystem-As-A-Service: Turtle Vaults And Campaigns

Turtle’s Vaults and Campaigns infrastructure forms the operational layer through which liquidity is committed, distributed, and tracked across DeFi. It organizes the flow between foundations, vault providers, and liquidity providers into a repeatable framework that any protocol can deploy as a service.

Each vault represents a campaign-linked deposit contract coordinated by the Turtle DAO and operated by Vault Curators. A vault is a smart contract at its core: foundations define their desired liquidity parameters, including the target amount, eligible assets, lock-up duration, and reward logic, and the vault is created to enforce these specific terms onchain. Turtle Members supply liquidity directly to the partner, where rewards accrue natively. Each vault is designed to remain fully non-custodial. Liquidity providers sign participation approvals through their own wallets, while assets stay in the partner protocol’s native contracts. Participation and performance are tracked through onchain activity.

This design allows campaigns to launch without introducing custodial risk or manual oversight. Fees and boost rewards flow transparently between participants: partner protocols pay a liquidity fee to the DAO, the DAO redistributes boost rewards directly to LPs, and all activity remains visible through onchain data via the smart contract vaults. Vaults also simplify capital allocation for LPs, enabling them to earn yield passively without manually rotating across protocols or campaigns.

At the campaign level, Turtle coordinates between Partner Protocols, Vault Providers, and Vault Curators to align incentives and operational tracking. Campaign vaults distribute liquidity directly to whitelisted protocols, where users earn both base and boosted rewards. Optional lock-ups synchronize capital duration with protocol needs, and integrated tracking captures data on performance, duration, and aggregate TVL.

Protocols can launch structured liquidity programs through a single integration; vaults manage capital logistics and tracking; and the DAO oversees coordination, auditing, and reward distribution. Meanwhile LPs can easily discover campaigns, deposit through Turtle’s interface, and receive both native and TURTLE rewards without relinquishing custody of assets.

Turtle Earn

Turtle Earn provides the distribution layer through which liquidity campaigns reach their designated end-users. It integrates directly with frontends such as wallets, exchanges, and analytics platforms, allowing them to surface active campaigns within their own interfaces. This structure enables users to review terms and participate in campaigns without leaving the environments they already use.

Distribution partners connect their user base to Turtle campaigns and receive a share of deal revenue proportional to the liquidity they help onboard. Turtle Members deposit directly to partner protocols, earning native rewards from those protocols and any additional boosts allocated by the Turtle DAO.

The DAO manages coordination and accounting between all participants. It sources dealflow from partner protocols, collects associated boost revenue, and redistributes it to Members and distribution partners based on verified activity.

Embedded Distribution and Tooling

Turtle’s embedded distribution layer connects the protocol’s liquidity infrastructure to the broader DeFi interface network, integrating directly into existing user frontends.

The Earn Widget embeds active Turtle campaigns within these applications, allowing users to discover and participate in verified opportunities natively. Deposits, campaign data, and reward parameters are synced in real time, creating a consistent interface across multiple protocols.

Participation and performance are tracked through Turtle’s Leaderboard system. Wallets earn points relative to their total deposits, referral activity, and lockup participation, with boosted weighting for referred liquidity. Weekly snapshots then determine the distribution of TURTLE rewards and campaign bonuses. For foundations and partners, client portals and dashboards provide visibility into campaign performance, emissions tracking, and reward distribution, ensuring liquidity programs can be monitored and adjusted in real time without requiring manual oversight.

Together, these tools extend Turtle’s coordination framework into user-facing environments. Campaigns appear directly within existing interfaces, participation is recorded onchain, and reward distribution is managed through a standardized system.

Tokenomics and Value Flows

Turtle’s coordination framework is anchored by TURTLE, an ERC-20 utility token deployed on Ethereum, BNB Chain, and Linea. TURTLE coordinates liquidity incentives and governance within the Turtle network, governing how liquidity incentives are distributed, how campaign revenue circulates through the Turtle DAO, and the decisions made about the protocol’s development.

TURTLE is transferable and classified as a functional utility token under Swiss law. It carries no ownership, profit-sharing, or redemption rights.

Value Flow

The Turtle DAO manages capital between three participants: partner protocols, liquidity providers (LPs), and the DAO treasury.

1. Partner Protocols fund liquidity campaigns by paying boost and integration fees.

2. LPs deposit through verified vaults and earn rewards based on their deposit amount.

3. The DAO Treasury collects campaign proceeds, and reallocates it toward future campaigns.

In theory, this all works together through a self-reinforcing feedback loop: protocols fund liquidity programs on Turtle, the Turtle DAO distributes rewards, and proceeds flow back into future operations.

Governance

Governance is executed through Turtle DAO, using OpenZeppelin’s Governor contracts and Tally’s interface. Holders can stake TURTLE to mint sTURTLE, which represents voting and delegation rights for proposals related to campaign parameters, integrations, and protocol operations. Proposals are subject to quorum and creation thresholds to maintain procedural integrity. Treasury execution remains under DAO oversight, with progressive decentralization planned over time.

TURTLE standardizes how liquidity programs are funded, distributed, and governed. Protocols pay to access coordinated capital; LPs earn verifiable rewards; and the DAO manages redistribution and governance through TURTLE.

Closing Thoughts

DeFi has solved for access but not for coordination. Anyone can deploy a market or a vault, and liquidity can move freely between them. Yet each system operates under its own parameters, incentives, and time horizons, leaving no shared structure for how capital is discovered, priced, or maintained over time. In practice, this leads to the aforementioned self-reinforcing cycle of short-term incentives and mercenary liquidity that defines much of DeFi today.

Turtle is designed to address this coordination gap. Its framework standardizes how campaigns are structured, how deposits are tracked, and how incentives are distributed. Rather than creating new markets and custodying assets, it provides the organizational layer through which existing ones can coordinate capital more efficiently.

To reiterate, DeFi has thus far proven that markets and other financial services can run without intermediaries; but coordination remains a central challenge among decentralized networks, and the scarcity of liquidity in DeFi is a prime example. An opportunity emerges for protocols capable of encoding commitment: to make capital deployment measurable, recurring, and auditable across ecosystems.

With the shift in the regulatory environment surrounding digital assets, the demand for bringing net new capital onchain is slowly but surely growing. With new capital coming onchain comes the need for coordination. Through its curated campaigns, structured vaults, and embedded distribution framework, Turtle makes a compelling case to capture this opportunity and become DeFi’s Investment Bank layer.

Sources

• Scott, Zachary. The Syndicated Loan Market. zacharyscott.com/syndicated-loan-market/

• The Syndicated Loan Industry Statistics. Coinlaw, coinlaw.io/syndicated-loan-industry-statistics/

• “Investment Banking.” Wikipedia, en.wikipedia.org/wiki/Investment_banking

• “Asymmetric Information.” Investopedia, www.investopedia.com/terms/a/asymmetricinformation.asp

• The Ten Commandments of Liquidity Incentives. Caladan Labs, caladan.xyz/report-the-ten-commandments-of-liquidity-incentives/

• Turtle Frontend. app.turtle.xyz/

• Turtle Documentation. docs.turtle.xyz/

• Turtle MiCA Whitepaper. drive.google.com/file/d/1DGhHqPv8RVX2XYgVb1yjPFQJQ4Y4961R/view

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. This post has been created in collaboration with the Turtle team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

The Convenience Premium: A Tradition Rooted In History

“Civilization advances by extending the number of important operations which we can perform without thinking of them.” ― Alfred North Whitehead

Throughout history, humans have relentlessly pursued convenience. Nothing illustrates this better than the convenience premium: the additional amount that a consumer is willing to pay for goods and services that save time, effort, and make their lives easier.

There has always been a market for convenience: a willing buyer and a willing seller. Roman merchants charged higher prices in busy forums than in remote markets. Before refrigerators were invented, American households paid significant premiums for ice delivery. Even money itself has evolved for convenience: from barter to coins to paper to digital assets, each step has been around making money easier to carry around and transact with.

Today, the convenience premium lies in digital experiences. Online shoppers are increasingly seeking shorter delivery windows at checkout. Hundreds of millions of people pay for an annual membership to have Amazon deliver almost anything to their door the next day. Food delivery apps continue to see record users and order numbers despite regularly charging 30-40% markups on orders.

Time has shown that while the means have changed, the ends sure haven't. People gravitate towards convenience, and they’re willing to pay the price for it. It is no wonder why, across numerous industries, application-specific solutions have historically evolved into universal, general-purpose solutions as they mature. The question then becomes who delivers convenience and captures these premiums in the digital age.

The Rise Of The Aggregator

The post-internet era has been dominated by aggregators.

Platforms like Google, Meta, Amazon, among many others, curate information, content, and services from other providers, offering consumers a simpler way to access what they are already looking for. Billions of web pages are searchable through Google. Millions of products are browsable on Amazon. Friends’ photos and life updates appear in one place on Facebook or Instagram.

Crucially, these companies do not own what they sell. They own something far more valuable: the user relationship.

Before the internet, this would have seemed an implausible business model. Distribution was physical, therefore distribution costs were higher, supply was scarcer, and generating outsized profits required controlling most if not all of the supply chain.

The internet transformed these dynamics. The cost to distribute information about digital or physical goods to a global audience became nearly free. A single website could handle hundreds, thousands, sometimes even millions of customer transactions at once, with far less overhead than physical stores.

Ultimately this reshaped consumer marketplaces by shifting power towards the user. Owning the user relationship became key to gaining a competitive advantage and making outsized profits with the internet, and the business model revolves around user experience above all else. With abundant supply now at their fingertips, what consumers valued most was discovery and curation: finding the best goods and services in a single place.

So what lies next? As mobile becomes the new user interface, and consumers demand more integrated digital experiences, the next evolution of aggregators is evolving into Everything Apps.

Aggregating The Aggregators: Everything Apps

Everything Apps, also called ‘Super Apps’, are platforms that bundle multiple services and utilities into a single cohesive interface, most commonly a mobile app.

On a desktop, users could manage multiple tabs simultaneously without much friction. This doesn’t quite translate to smartphones, as smaller screens, app-switching delays, repeated logins, lost context, all create friction. History shows the pattern: whenever convenience can be improved, someone builds the solution, and someone else is willing to pay for it.

These mobile pain points point to the need for more integrated, multi-service experiences on mobile. The model benefits all participants:

• For consumers, Everything Apps provide a simplified, all-in-one experience. Users can access a variety of services without having to leave the app. One login, an integrated payment system, and personalized experiences based on their user preferences.

• For businesses, Everything Apps can help reduce user churn and lower Customer Acquisition Costs, while strengthening network effects and creating the opportunity to capture multiple revenue streams from the same user base.

The concept was first articulated publicly by Blackberry founder Mike Lazirdis at the Mobile World Congress in 2010, where he envisioned “everyday apps that people would use because they provided such a seamless, integrated, and efficient experience.” The first live example would come a few years later, when Tencent’s WeChat - a messaging app at the time - would launch WeChat v5.0. This update introduced a handful of new features including payments and gaming, marking WeChat’s shift from messaging to a robust multi-service platform.

Today, the most successful Everything Apps combine messaging, personal finance, payments, social networking, e-commerce, and plenty more. Unsurprisingly, they have flourished in “mobile-first” regions where smartphones are the primary - and in some cases the only - gateway to the internet.

So Why No Everything Apps In The US (Yet)?

Despite their widespread success in Asia and other mobile-first regions, Everything Apps have yet to truly take root in the US and Europe. The reason is straightforward: structural headwinds..

Digital ecosystems in the US and Europe are crowded with entrenched incumbents: specialized apps which dominate their respective fields and benefit from strong brand loyalty. Users love Venmo for payments, Uber for ride-hailing, Robinhood for trading. Habits like these are difficult to break, and app-store dynamics only further reinforce them. Platform restrictions such as Apple's notorious 30% App Store tax, and restrictive control over native capabilities, made aggregation even more difficult to build and sustain over time. Furthermore, data privacy laws like GDPR and CCPA, combined with aggressive antitrust enforcement, have created compliance burdens that actively prevented platforms from dominating multiple sectors.

But the demand IS there. The gravitational pull of convenience keeps growing. A new digital banking report recently revealed that 60% of users add a second finance app specifically because their primary app lacks essential features, while 91% would gladly consolidate to a single app if it offered all the services they needed.

And slowly, this shift is happening, in a way. Companies like Meta and Google continue layering in more messaging, shopping, and payment features to their apps. Elon Musk has openly shared his long-term vision for X as ‘the Everything App’, which recently integrated Polymarket, the kind of vertical integration that can very well be a stepping stone for future expansion.

Despite regulation, platform politics, and consumer inertia, the Everything App vision is alive in the West.

Aggregators in Finance: A Natural Evolution

If there’s any sector primed to capture this transformation next, it’s finance.

Financial services remain fragmented across thousands of banks, brokers, and financial products today. This complexity has always made aggregation valuable. Historically, banks themselves were the original aggregators, combining checking, savings, credit, and investing under one roof. However, they aggregated financial services through regulation, branches, and charters. As technology evolved though, this monopoly would start to crack.

The internet would then enable the next generation of financial aggregators. PayPal and Stripe aggregated payment processing. Plaid then followed suit by aggregating bank accounts. Robinhood aggregated trading stocks, options, and crypto assets.

From there, the ambition only grew. The following generation of financial aggregators sought to aggregate the entire financial stack. On the consumer side, apps like Revolut and Cash App bundled banking, payments, and trading. On the enterprise side, solutions like Ramp and Brex combine payments, banking, credit, payroll, and expense management under one roof.

Fintechs have proven the aggregator model works in finance: bundling services creates stickier products, stronger network effects, and captures greater market share. But they’re still boxed in by regulations, jurisdictional barriers, and the tech debt of legacy infrastructure. These pain points beg the question: today’s financial aggregators being built on the right rails? Or are we at an inflection point, a time to explore new rails, new regulations, and unlock new opportunities?

New Rails

Crypto protocols are well-suited for financial aggregators because they are composable, open, and permissionless. Unlike legacy infrastructure, integrating these protocols doesn’t take years of licensing battles or contracts to sign, just code to write and deploy. This programmability makes it easier to embed and integrate more financial services at scale. Today’s blockchains, the rails which crypto protocols live on, also enable significantly lower fees and faster speeds for financial transfers than legacy systems.

New Rules
“Plain and simple: securities intermediaries should be able to offer a broad range of products and services under one roof with a single license..” - Paul Atkins, SEC Chairman

Regulators are now dismantling the barriers that previously prevented Everything Apps from flourishing in the US. Today, a financial platform needs separate licenses for each individual service: broker-dealer license for trading, money transmitter licenses in all 50 states for payments, banking charter for deposits, and somehow, the list goes on. This is one major point the SEC's Project Crypto aims to address. As per recommendation from the White House Digital Asset report, the SEC is now actively developing a ‘Regulatory Super-App Framework’, which would allow an SEC-registered platform to offer multiple financial services under one platform or license. This extends beyond traditional securities to crypto asset staking, lending, payments and more.

New Opportunities

Altogether, crypto rails unlock access to financial services on a broader, more global scale than its legacy predecessors. Regulations are now being developed to ensure this can develop in a compliant and secure manner. But more importantly, the real unlock is the innovation that the composability of crypto protocols and transparency of blockchains enables.

Every new protocol becomes a building block for others, enabling products and services that are difficult for financial services to assemble on their own. Borrowing and lending, payments, trading, identity, can be integrated with one another with code. A financial system built on the internet, for the internet.

The most impressive part about this system is that it’s already live. There is already over $300 billion in value on public blockchains today. $9.5 trillion has already been traded - in a non-custodial manner - on decentralized exchanges (DEXs). Over $274 billion has been issued in stablecoins to date, which have actively surpassed Visa, Paypal, and legacy remittance systems in monthly volumes since November. Yet DeFi is still largely niche and unknown- why is that?

The Missing Ingredient: The Mobile Moment

Today, over 5 billion people use the internet, the vast majority of this activity taking place on mobile devices. Mobile has become the dominant user interfaces across the globe, and mobile apps the new pipes through which industries reach mass adoption:

We’ve seen this playbook before. The explosion of mobile in the early 2010s went hand-in-hand with the rise of social media, as mobile internet access quadrupled between 2011 and 2015. The same pattern would unfold into e-commerce, which grew from less than 5% of retail purchases in 2010 to over 18% in 2020. In 2025, smartphones are projected to account for nearly 60% of global retail e-commerce sales, or roughly $4 trillion in mobile commerce revenue.

16 years since Bitcoin’s Genesis Block, crypto’s Mobile Moment is overdue.

Signs are certainly starting to appear. A16z estimates there are now 34.4m monthly active mobile wallet users. Coinbase has previously topped all finance apps on the iOS App Store and even broke the top 10 free apps overall. Jupiter, the largest DEX aggregator on Solana and one of the largest in crypto broadly, launched its mobile app in late 2024, allowing users to onboard with familiar payment systems like Apple Pay. Solana Mobile recently shipped out over 250k orders of the Solana Seeker second-gen phone to more than 50 countries.

Across industries, mobile has been the unlock for mass adoption. Crypto will be no different. The next major opportunity to aggregate financial services is clear: a truly crypto-native Everything App.

DeFi App: The Crypto-Native Everything App

Every breakthrough technology needs its killer app. For social, it was Facebook. For AI, it was ChatGPT. DeFi App aims to be that catalyst for crypto.

Today, DeFi ultimately functions as a consortium of protocols built on top of one another. DeFi App simply aggregates these multiple layers between chains and their respective applications into a single mobile interface.

These layers make up what we call the DeFi Value Chain:

• Assets: These are digital assets that live on blockchains and represent some monetary value.

• Protocols: These are smart contracts that provide financial primitives and ultimately aggregate user assets together.

• Protocol Aggregators: These are protocols built to aggregate other crypto protocols, optimizing to find the best rates, prices, and execution for users.

• Interface aggregators: These are the applications that provide the consumer touchpoint to access all underlying layers and services.

In a sense, DeFi resembles an open set of legos. An Everything App would be the box they're packaged in. And as other industries in the post-internet era have proven, whoever controls that box - and defines how users interact with those legos - owns the user relationship and becomes crypto's ultimate aggregator.

Early Traction

DeFi.App has achieved significant early traction since launching in February:

• 3.7M+ wallets created across 1.38M active users

• $2.87M in protocol fees generated since April.

• 80M+ HOME staked by 7.7K+ unique stakers, the majority choosing 12-month lockups.

So far, the protocol generated $18.8B in total volume, with the majority ($15.2B) coming from Swaps.

Perps meanwhile, launched in May and have already generated $3.66B in total volume.

But exactly how does it all work under the hood?

Here’s how DeFi App intends to capture this opportunity.

What does DeFi App Offer?

DeFi App provides a simple, cohesive interface for users to access core DeFi services:

Swapping

• Spot trading across multiple DEXs on multiple chains with aggregated liquidity to find the best rates.

• DeFi App users can access more assets on DEXs than on traditional CEXs, and better rates depending on the asset and its onchain liquidity.

By using an intent-based system, DeFi App users can express their swap preferences with less manual configuration.

Leverage Trading

• Perpetual contracts (Perps) trading, accessible through a simple interface built on a Hyperliquid backend.

• Users can access institutional-grade liquidity, transfer fees lower than on CEXs, and maintain custody of their assets.

• Users get a dedicated ‘Perp Account’ which they can fund from their existing DeFi App wallets. From there, they can long or short any supported asset, and add leverage if they so choose. It’s important to note that leverage trading can be significantly riskier than spot trading.

Earn

• Users can easily stake the HOME token and access various DeFi yield strategies with transparent risk assessment.

Lending/Borrowing

• Users can borrow or lend supported assets through a simple interface.

• DeFi App aggregates multiple borrowing and lending protocols to offer users the best rates across the DeFi ecosystems and chains it supports.*

To address common pain points in the onchain user experience, the platform offers:

Self-custodial Wallet Management

• DeFi App creates a wallet for users on all its supported chains to eliminate new wallet set-up hassle for users. This is especially useful for chains that operate on different VMs, like Ethereum and Solana, both of which DeFi App supports.

• While CEXs provide this service for users, they custody the assets held in those accounts. Though it’s been almost 3 years since FTX imploded, the principle hasn’t changed much. Not your keys, not your crypto.

• With DeFi App, users avoid wallet set-up hassle but still maintain custody of their assets.

Easy onboarding/on-off ramping

• Users can easily fund their DeFi App accounts using familiar payment methods like Apple or Google Pay.

Gasless Transactions

• Users don’t pay gas fees when transacting. Gas fees are either sponsored by DeFi App directly or swapped from other tokens on the user's behalf.

Integrated Cross-chain UX

• All swaps are executed for users “behind the scenes”, including those involving different assets on different chains. This helps eliminate the need for users to manually bridge their assets, which could involve multiple steps and transactions otherwise.

*Note: this feature is not live yet.

System Architecture

Stripped down to its purest elements, DeFi App is a crypto-native interface aggregator. It combines and integrates different smart contracts, Solvers, Smart Account infrastructure, APIs, and adapters through a single cohesive interface layer.

• Smart Accounts: Creates seedless wallets on user’s behalf through AA

• Gas Abstraction: A paymaster to sponsor gas fees for transactions.

• Transaction Execution: An aggregator system for routing transactions using intents.

• Frontend interface: Combines multiple DEXs, lending protocols, and yield sources into one interface.

Smart Accounts

DeFi.App lets users sign up and manage crypto wallets on their behalf using familiar authentication methods like email and social apps. Instead of directly managing private keys and gas fees on multiple chains, embedded Smart Accounts let DeFi.App handle gas, bridging, and signing under the hood for users.

Smart Accounts are built on the principle of Account Abstraction. The core principle is to separate how an account is verified from how its transactions are actually processed on Ethereum. In simpler terms, it means a public key (a wallet address) is no longer tied to a single private key. Instead, smart contracts can be written to define custom rules for verification, recovery, and fee payment.

The vision has been around for a while now, dating back to Vitalik Buterin’s EIP-86. The core concept was to make wallets more flexible by allowing accounts to operate like smart contracts rather than just externally owned accounts (EOAs) controlled by private keys. The first major implementation was realized through multi-signature (multi-sig) wallets pioneered by Safe, which demonstrated early forms of AA by separating asset custody from transaction authorization. Instead of just one signature with a single private key, protocols could set up contracts to require multiple signatures before a transaction is approved. This proved beneficial for protocols and teams, but less tangible to retail.

With ERC-4337, AA resurfaced strongly as a key upgrade concept: an additional layer, though not one that altered the core Ethereum protocol. ERC-4337 wrapped user transactions into a higher-level construct known as a ‘UserOp’, short for UserOperation. Any transaction generated from an ERC-4337 enabled wallet would be a UserOp, and UserOps had their own Mempool. From there, Bundlers would aggregate UserOps into regular transactions to be posted to Ethereum mainnet.

A core UX unlock that was long envisioned with AA was gas abstraction. EIP-4337 enabled this through the use of Paymasters, specialized smart contracts which can be programmed to either sponsor fees on behalf of an account or accept gas fees in any ERC20 token besides native ETH.

ERC-4337 provided the toolkit for advanced Smart Account logic, but it did not standardize it in a way that was more universally applicable. It also required that users create a new Smart Account instead of being able to import their old Externally Owned Address (EOA). This would change with EIP-7702, as part of the Pectra upgrade. EIP-7702 allowed any existing EOA to temporarily function as a Smart Account with additional features like transaction batching, gas sponsorship, alternative gas fee payment.

In short, Smart Accounts enable apps like DeFi.App to sponsor gas fees for users, let users pay gas in any ERC20 tokens, and support alternative and more familiar verification mechanisms beyond the standard ECDSA commonly used in crypto today. And central to Smart Accounts and Account Abstraction is proper and secure key management.

Key Management

DeFi.App integrates several providers for secure key management of newly-generated user accounts. The implementation varies slightly between EVM and SVM environments, but together create a smooth onboarding and transaction flow for users:

Turnkey

Turnkey is the custody and signing provider that underpins account creation on both Solana and EVM chains.

• On Solana, Turnkey directly manages the user’s wallet where assets are actually held. Because funds live in this wallet, importing the key into another wallet provider, like Phantom, would display a balance.

• On EVM chains, Turnkey generates a signer key for each user. This signer key doesn’t hold any funds itself - but it does authorize transactions via a linked smart account. In practice, Turnkey provides the signature layer while funds themselves live in a generated smart contract.

Zerodev

ZeroDev provides DeFi.App’s Smart Account infrastructure for EVM chains.

• User funds on EVM chains are stored in an EIP-4337 smart contract wallet managed by ZeroDev.

• The wallet is controlled by the Turnkey signer (described above), but custody of assets lives entirely within the ZeroDev smart contract.

Effectively, ZeroDev handles the vault and execution layer for EVM assets, while Turnkey supplies the signer that secures it.

Dynamic

Dynamic is the wallet connector and onboarding layer that ties the system together, managing user authentication mechanisms.

When a new user signs up, Dynamic provisions two embedded wallets:

• A Solana wallet (Turnkey-managed, holds funds directly).

• An EVM Wallet consisting of a Turnkey signer + ZeroDev smart account (signer controls, smart account holds funds).

Dynamic also allows users to export their keys. For Solana, this means exporting the Turnkey wallet. For EVM, users can export the signer key, but balances won’t appear in a standard EOA wallet since funds live in the ZeroDev contract.

Besides simpler user onboarding, Smart Accounts also enable another major UX breakthrough for DeFi.App: the ability to pay transaction fees in any token.

Gas Abstraction

It’s critical to understand that users still pay a fee to DeFi.App when transacting. Transactions and blocks cannot be uploaded to a blockchain without a fee to cover the associated computational costs. These fees are paid in the native token of that blockchain, which in itself is a core part of the token’s utility. While it is not possible to avoid gas fees, it is possible for application developers to make sure their users don’t need to worry about them.

DeFi.App enables gas abstraction across all its supported chains, though the implementation varies by the execution environment (VM) of that chain.

On EVM chains, gas fees are sponsored by ZeroDev architecture and funded by Defi App transaction fees.On Solana, this is handled by a custom paymaster contract. The gas fee is quoted to the user transaction, and swapped from the paying token into SOL.

Intent-based Execution

DeFi.App implements an intent-based system for transaction execution, designed to give users a simple experience with optimal pricing.

An “intent” has no formal definition, but it functions similarly to a transaction, only instead of specifying the exact execution path, the user specifies their desired outcome. This approach focuses on removing the complicated parts of the onchain transaction experience like sourcing liquidity, ensuring sufficient gas, and bridging if another chain is required. For example, a user may want to swap 100 USDC for SOL, but doesn’t know if the best prices are on Orca, Raydium, or elsewhere.

How does this work on DeFi.App?

DeFi.App runs a Solver transaction aggregator that taps into multiple liquidity sources across chains and protocols, presenting users with the best available price. The platform integrates with 0x, 1inch, Bebop, Debridge, Dodo, Enso, Jupiter, LiFi, Odos, Open Ocean, Paraswap, Relay, and Stable. Proprietary routing logic in the backend evaluates these options in real time, ensuring users see a single, streamlined execution flow.

Cross-chain support is native to this system. Traditionally, swapping USDC on chain A into USDC on chain B (or even USDC → USDT across chains) would require multiple bridging steps. With DeFi.App’s solver network and routing logic, cross-chain swaps are presented to the user as a single transaction, no different from a same-chain swap.

MEV-Protection with Jito

One particular underrated feature DeFi.App enables is to let users opt-in to protect themselves from MEV on Solana.

MEV is often captured through sandwiching/arbitraging unsuspecting users.

Jito built the Jito-Solana Validator Client to help mitigate this on Solana. Users can submit transaction bundles to Solana validators running the Jito client. These transactions get executed atomically, in order, therefore either they all execute or fail altogether. Tips (bonus fees) are attached to bundles to incentivize validators, priority going to the highest bidder.

Broadly speaking, DeFi.App supports three transaction modes: Classic, Jito, and Auto. Classic mode provides standard routing to validators running the Agave validator client. Jito mode routes transactions to validators running the Jito-Solana client, while Auto mode selects the best option for the user at the time.

DeFi.App Users can opt-in to MEV protection by simply toggling “Jito Mode”, which will then route their transactions through Jito-enabled validators, leveraging the bundling and tipping system.

Capturing The Convenience Premium: DeFi.App’s Business Model

Earlier, we highlighted the impact of the convenience premium throughout history: people are willing to pay a premium for goods and services that make their lives easier, plain and simple. Aggregators dominated the post-internet era by focusing on owning the user relationship and experience. In an increasingly mobile-first world, the next evolution of this model is the Everything App.

The next question that follows is how exactly do the aggregators, the harbingers of convenience that don’t own what they sell, actually generate and accrue value?

Let’s examine DeFi.App’s business model.

The HOME Token

DeFi.App and its ecosystem is powered by the $HOME token. HOME launched on June 10, 2025, and currently lives on Solana, Base, and BNB Chain. There are 10 billion HOME tokens in total.

Token Utility

HOME plays several key roles across the DeFi.App ecosystem:

• Governance: HOME stakers can create and vote on any proposals that come up around the DeFi App protocol, whether it’s revenue sharing models, token buybacks or yield to $HOME stakers, which feature comes next for the platform, and so on. Companies can also buy and stake HOME to accelerate their own integrations into the ecosystem. Over 5.9k votes have been cast over the first 5 proposals.

• Gas Abstraction: Users who hold HOME in their DeFi.App wallets can transact on any supported chain and pay gas fees in HOME. Defi.App’s treasury automatically purchases HOME from the user at open market rates and uses that HOME to subsidize that user’s gas fees on their behalf. This is facilitated through the HOME Staking contract, which provides collateral to support gas subsidies and conversions.

• Incentive Coordination: Users can lock HOME to earn XP, which accrues on a daily basis and may be a qualifying criteria for future HOME airdrops. Locking HOME can activate up to a 3x multiplier on XP gains, with more XP for longer lockups.

Data shows that the majority of HOME token holders are on Base (83k holders), with ownership on BNB Chain (6.4k) and Solana (1.9k) notably lower.

DeFi.App’s Business Model

DeFi.App generates revenue through protocol fees. Every swap, deposit, leveraged trade - any user action that generates a transaction - generates a protocol fee. Think of this fee as the convenience premium that DeFi.App charges.

The business model is designed to work the following way:

1. A user joins DeFi.App.

2. Each time they swap, borrow, lend - each action generates a protocol fee.

3. Fees are allocated however governance sees best fit.

4. Fees are distributed, often through buybacks or allocated for future incentives.

5. As more HOME is staked, token supply decreases, interest grows, and…

6. A new user joins DeFi.App.

DeFi App charges 0.02% on swaps, and 0.01% on perps. Today, as much as 80% of DeFi App’s net fee revenue is allocated towards HOME buybacks for its treasury reserve, as was recently voted on in DIP-004.

Analysis

It’s time to unpack what we just learned and reflect on the challenges and opportunities Shoal Research sees ahead for DeFi.App.

Challenges And Considerations

DeFi.App is building a solution to a very real problem: a lack of simple, beginner-friendly access to DeFi. This isn’t a new problem by any means though, and the DeFi.App team are not the only ones actively building to solve this problem.

The biggest, high-level challenge we foresee DeFi.App facing is competing with bigger “crypto-adjacent” firms that have a strong distribution advantage and bigger user-base. Firms like Coinbase and Robinhood come to mind. This may even extend beyond crypto firms: major fintechs and even banks can push for their own Everything App, incorporating crypto and DeFi alongside other non-crypto services.

Still, most of these firms require users to fill out KYC verification beforehand, which can be a major onboarding pain and bottleneck. DeFi.App has an upper-hand here: users can quickly sign up with their email and fund their account with Apple Pay. However, this is where major wallet providers like Phantom and Metamask, who also very much stand to benefit from launching their own ‘Everything App’, stand to be a bigger threat and concern. In a way, these apps already function as “crypto-native Everything Apps” and offer multiple integrated services similar to DeFi.App. Therefore, non-custodial wallets are currently the biggest competitors to DeFi.App we see as of today as they can provide similar offerings relatively easily. That said, while there may be less room to compete on service offerings, there will always be room to compete on pricing and execution rates against wallet providers and other protocols. After that, it becomes a race to who can support more chains, more assets, and offer more services to users.

Moving on to more crypto-native challenges, DeFi.App, like many other crypto protocols, need to make sure they can scale to keep up with the expanding multichain landscape. There are currently 300 chains, some believe we will have 1000s. DeFi.App currently only serves 6. While many of these chains are not active or have not generated any real sustained activity, users are continuously traveling to different chains and ecosystems. Corporations like Circle and Stripe are launching their own chains. Who knows who else will follow. As an “aggregator of aggregators”, it’s in DeFi.app’s best interest to be able to serve their users wherever they want to go.

This is a hard problem to solve, but if users can access virtually any chain through DeFi.App’s simple interface, this can be a major advantage and differentiator. Conversely, if DeFi.App chooses to keep their overall chains and ecosystems limited, someone else will expand to serve users of any asset on any chain. It even becomes advantageous for infrastructure-focused teams, such as those building interoperability protocols, to create their own user-facing application to let users access any asset on any chain. The easiest solution for DeFi.App to hedge against this risk is to integrate a major interoperability protocol, like Hyperlane or LayerZero, and tap into their existing distribution and scale with them. A much more difficult approach will be to build a proprietary solution. Either way, we believe DeFi.App needs to dream big, and embrace aggregating “everything”. This starts with providing users access to any asset on any chain.

Exciting Opportunities and Outlook

Overcoming these challenges will be critical for DeFi.App’s short and long-term success, but there is plenty to be excited for. By building around aggregation and the mobile-first experience, DeFi.App is following the same playbook that has kickstarted major growth and adoption cycles in other digital industries as it sets out to build the first crypto-native Everything App.

Consumers have expressed a strong preference for mobile-first experiences in today’s age. DeFi.App is building a mobile app for that. Interest in crypto will likely continue to grow as enterprises and major institutions continue to either experiment with or fully embrace blockchain solutions. And they’re actively piling in because for the first time in crypto’s history, the US is actively developing pro-innovation guidelines and regulations to legitimize this technology. This alone won’t bring “the next million users” onchain, but the path to mass adoption all starts from there.

It doesn’t hurt that aggregators have done quite well overall, either. Once Google had integrated search results with user data, they were able to offer targeted advertising, and have made hundreds of billions in revenue over the years. Meta had a similar approach, integrating their feed with user’s data to unlock targeted advertising, and generates over $100b annually, with most (97%) of that revenue coming from targeted ads. WeChat, the poster child for Everything Apps today, has earned hundreds of billions over the years from in-app purchases and more.

In DeFi, numerous protocols have already demonstrated the revenue potential of frontend applications. Photon and Pump Fun have both seen upwards of $6m in daily fees before. Axiom hit over $250m revenue in 8 months.

Though maybe not all apples-to-apples comparisons, these examples demonstrate there is lots of demand and value to capture in frontends and aggregators.

Ideas And Suggestions from Shoal

Some ideas and suggestions Shoal Research believes could help contribute to DeFi.App’s success moving forward:

• Expand to support more chains and assets over time. Dream big: every asset, every chain should be accessible through DeFi.App’s mobile interface.

• Integrate an underlying cross-chain messaging protocol so DeFI.App’s chain coverage can easily scale with them.

• Integrate an AI chatbot UX to let users type out their preferred action. Bonus points for voice mode to make it even more convenient.

• Enable non-users to onboard easily via text message. Text your friend some money through a link. They sign up for DeFi.App in seconds.

• Enable a “Privacy Mode”: Integrate a proven privacy solution like Railgun to let users transact privately when they want to, the same way they can toggle “Jito Mode”. This may be trickier to manage from a legal perspective, but can be a massive benefit and differentiator for DeFi.App long-term.

• Offer MEV protection on all chains, not just Solana. Integrate a Flashbots/MevBlocker RPC endpoint for EVM chains.

• Productize (or even better - open source!) a plug-in that teams can use to easily add their protocol or service to DeFi.App’s interface.

Importantly, these are merely ideas we suggest the DeFi.App team take into consideration. Some of these ideas are more practical and urgent than others. Some may not make sense right now, but may become critical in a few months or a year. Time will tell.

Closing Thoughts

History has repeatedly shown us that the convenience premium is timeless. In 2025, aggregators have captured this premium and dominate consumer marketplaces by delivering superior user experiences. Mobile devices have taken over the majority of internet traffic as they have evolved to offer more services and information than desktops, conveniently fitting in everyone’s pocket.

At Shoal, we believe the same plot will inevitably unfold on crypto rails. Fintechs have proven the demand for convenient, aggregated access to financial services, but they still face centralization risks and remain barred to geographical barriers. Crypto protocols are open, programmable, and permissionless to integrate, and have already moved upwards of twelve figures in value across the globe. Major enterprises and institutions are adopting stablecoins for payments. Countries like the US are actively pushing to establish pro-crypto and pro-innovation regulatory frameworks. It’s becoming clear that the time to build crypto’s everything app is now.

Sources

• Aggregating the Aggregators.” Fintech Takes, 14 June 2024, fintechtakes.com/articles/2024-06-14/aggregating-the-aggregators/. Accessed 24 Oct. 2025.

• “Convenience Premium: Consumer Trends 2024.” Morgan Stanley, www.morganstanley.com/ideas/consumer-trends-2024-convenience-premium. Accessed 24 Oct. 2025.

• DeFi App. DefiLlama, defillama.com/protocol/defi-app. Accessed 24 Oct. 2025.

• DeFi App Staking. Dune, dune.com/defiapp/defiapp-staking. Accessed 24 Oct. 2025.

• de la Mano, Matías. Open Platforms and Innovation: The Case of the Linux Operating System. London School of Economics, 1999, eprints.lse.ac.uk/22471/1/wp20.pdf. Accessed 24 Oct. 2025.

• ‘“Digital Assets.” The White House, www.whitehouse.gov/crypto/. Accessed 24 Oct. 2025.

• ERC-4337 Documentation. docs.erc4337.io/. Accessed 24 Oct. 2025.

• EIP-7702 Documentation. eip7702.io/. Accessed 24 Oct. 2025.

• “New Study Reveals Using Multiple Financial Apps Is Necessity, Not Choice, for Most Users.” Nordic Fintech Magazine, nordicfintechmagazine.com/new-study-reveals-using-multiple-financial-apps-is-necessity-not-choice-for-most-users/. Accessed 24 Oct. 2025.

• “Statistics That Prove How Your Delivery Speed Impacts Your Business.” Meteor Space, 13 Feb. 2025, meteorspace.com/2025/02/13/statistics-that-prove-how-your-delivery-speed-impacts-your-business/. Accessed 24 Oct. 2025.

• Thompson, Ben. “Aggregation Theory.” Stratechery, 17 July 2015, stratechery.com/2015/aggregation-theory/. Accessed 24 Oct. 2025.

• Thompson, Ben. “Defining Aggregators.” Stratechery, 24 Apr. 2017, stratechery.com/2017/defining-aggregators/. Accessed 24 Oct. 2025.

• “Uber Eats Statistics.” Business of Apps, www.businessofapps.com/data/uber-eats-statistics/. Accessed 24 Oct. 2025.

• “10 Years of WeChat History.” Eggsist, www.eggsist.com/en/insights/10-years-wechat-history/. Accessed 24 Oct. 2025.

• Super App Market in United States. Research and Markets, www.researchandmarkets.com/reports/6105712/super-app-market-in-united-states. Accessed 24 Oct. 2025.

• “Superapps.” Venture Vine, Medium, medium.com/venturevine/superapps-6a425de7db87. Accessed 24 Oct. 2025.

• “The Era of Provable Software.” Succinct Writings, writings.succinct.xyz/provable. Accessed 24 Oct. 2025.

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author's own, not the views of their employer. This post has been created in collaboration with the DeFi App team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

The Experience Is The Product

Over the past three decades, the World Wide Web has reshaped the world and how it functions as we know it. As software gradually replaced physical distribution channels, the user experience has become the product. Look no further than the role which aggregators like Google, Amazon, Facebook (among plenty others) play in everyday life for evidence. By delivering cohesive user experiences, these platforms came to dominate consumer markets.

It can certainly be argued that DeFi faces a similar fate. The early internet began as a patchwork of disconnected webpages and hyperlinks, and so too, the broader DeFi landscape today spans hundreds of chains, tens of thousands of protocols, and millions of tradable assets, many of which are forks. This replicability is indeed a feature, not a bug. As Richard Stallman laid out, the right to reproduce, modify, and share code freely is a pillar of truly free software. In practice, however, DeFi’s open-source, permissionless design has created as much fragmentation as it has driven innovation.

The Unified Margin Opportunity

A majority of today’s DeFi volume and activity still concentrates around a few primitives: swaps, perps, staking services, and money markets. Yet there’s no simple, intuitive way to access them all through a single margin account. To trade perps, users deposit collateral to a specific account on a specific exchange. To borrow or lend, they need to withdraw and then deposit to a new position on another protocol. These DeFi primitives operate in isolation, fragmenting liquidity and leaving large amounts of capital idle and unproductive.

The lack of a unified margin account hasn’t been a conceptual problem so much as it’s been a structural one. Different DeFi protocols maintain their own accounting and risk parameters. An AMM tracks LP positions and pool reserves. A lending market tracks deposits and debt and evaluates protocol health. A perps exchange needs to track margin balances, open interest, funding rates, and liquidation thresholds. Each protocol has its own requirements in order to remain solvent. They can integrate with one another via smart contract calls, but they can’t share balance sheets.

This localized risk design is what makes DeFi safe in isolation but inefficient in aggregate. However, by building these primitives around a single shared risk engine, the opportunity to build a unified margin account emerges. This design would enable a user’s deposit to support multiple roles across trading, lending, staking, while maintaining consistent solvency rules. Collateral that once sat idle could be reused across products. A trader’s gain in one market could balance a loss in another, tightening spreads and reducing redundant margin.

Still, connecting DeFi primitives does not address the inefficiencies in their underlying mechanics.

DeFi’s Static Trap

The DeFi primitives we know today have processed trillions in volume, supported hundreds of billions in liquidity, and generated billions in protocol revenue. Like the internet, their greatest strength lies in being borderless, transparent, and always-on. Most protocols were designed as a set of smart contracts with fixed parameters that can run autonomously, for an indefinite period of team. Some teams have introduced governance or upgrade hooks for managing in critical situations, but between constant-product AMMs, fixed loan-to-value ratios, and passive liquidity provisioning, much of DeFi still operates on static logic.

These design choices made sense initially. Fixed parameters gave users trust: DAI’s stability, Uniswap’s simplicity, and Aave’s predictable risk. In stark contrast, however, traditional financial systems, which handle more volume in a single day than DeFi does in a month, operate on dynamic parameters that adjust to real-time conditions. Banks, market-makers, and derivatives desks continuously reprice risk, widen spreads, and adjust leverage based on market activity.

Building DeFi primitives that respond to real-time market conditions unlocks better performance, safer risk management, and more efficient and productive use of capital. These protocols can adjust key parameters such as collateral ratios, borrow-lending rates, and execution routing based on real-time market conditions.

This responsiveness matters most during market stress. When asset prices move sharply, parameters can tighten automatically to prevent unnecessary liquidations and preserve solvency. During more stable conditions, they can loosen to improve capital utilization and allow collateral to work more efficiently. In both cases, risk settings evolve with the market rather than remaining static.

The question then becomes how this looks like in practice.

A Deep Dive Into Flying Tulip

Flying Tulip introduces an onchain financial system designed to standardize pricing, credit, and risk across a unified suite of markets. The protocol brings together spot trading (AMM + CLOB), lending, perpetuals, insurance, and a protocol-native stablecoin within a shared margin framework.

Flying Tulip is built around three core design goals. First, to make collateral reusable across multiple functions. A single deposit can support several forms of activity, earning base yield, margin for trades, or loan collateral, without being locked into a single utility or module. Second, price risk using real, executable liquidity instead of static references or delayed oracles. The protocol measures depth and volatility across its markets in real time, and those readings feed directly into parameters like collateral ratios, funding rates, and liquidation thresholds. Third, to recycle protocol cashflows back into the system. Revenue from trading, borrowing, and settlements flows toward the FT token through programmatic buybacks or user distributions, linking network activity to value capture in a transparent way.

These design goals shape two outcomes: better yield and better user experience. Better yield comes from capital efficiency. The same deposit can earn base yield while simultaneously securing loans, resting limit orders on the CLOB, or providing margin for derivatives. Assets stay productive across the stack rather than sitting idle. Better UX, meanwhile, comes from integration. Core mechanics are encoded directly in contracts and applied consistently across products. The same depth-aware inputs that determine trade execution also inform borrowing limits, funding adjustments, and liquidation logic, ensuring that all parts of the system respond to market conditions in the same way.

Flying Tulip’s design builds on the original Deriswap concept Andre Cronje introduced in 2020. The concept he laid out was simple: to merge multiple DeFi functions into a single, more capital-efficient protocol. Deriswap proposed that the same liquidity pool could be used for swaps, lending, and options simultaneously in order to reduce idle liquidity. which proposed reusing liquidity across swaps, lending, and options. Here, that principle extends to the full financial stack. The protocol’s architecture connects trading, credit, and risk management within a single environment, allowing capital and exposure to be managed through one unified framework.

Flying Tulip will launch natively across multiple chains, beginning with the Sonic L1, and expanding to Ethereum, Avalanche, BNB Chain, and Solana. Each chain will feature its own local instance of Flying Tulip, ensuring liquidity and settlement remaining within native environments across all deployments.

The Flying Tulip Stack

Flying Tulip consists of an integrated suite of DeFi components. ftUSD, lending, spot, and perpetuals operate from a shared liquidity base and unified margin layer. Parameters across the system adjust to market conditions in real time, keeping pricing, collateral, and risk consistent across products.

ftUSD: The FT- Native Stablecoin

To avoid dependency on third-party stablecoins for bootstrapping liquidity, Flying Tulip introduces ftUSD, a protocol-native, dollar-pegged stablecoin. that serves as the primary margin and settlement asset across the protocol’s AMM pools, order book, and derivatives markets. ftUSD is minted by depositing supported stablecoins or blue-chip assets and can be held as a stable unit of account or staked to sftUSD to earn yield from Flying Tulip’s underlying yield strategies. Staking represents a conversion into the yield-accruing pool, with distributions reflected through a variable exchange rate between sftUSD and ftUSD.

Collateral deposited to mint ftUSD is deployed across delta-neutral strategies across several venues, executed programmatically onchain to remain transparent and auditable. Assets are allocated across money markets, staking pools, and hedging positions, and the yield generated on these positions is then distributed to sftUSD holders while proceeds from unstaked ftUSD are retained by the protocol to fund operations and liquidity.

How It Works

ftUSD maintains its dollar peg through a delta-neutral strategy, wherein collateral backing ftUSD is deployed to earn yield onchain while keeping net exposure to market movements near zero. Yield for ftUSD originates primarily from the interest earned on supplied collateral in money markets i.e. Aave, plus staking rewards generated on the long side of hedged positions. Positions are rebalanced periodically and constrained by caps, sizing bands, and venue limits to preserve solvency and reduce volatility transmission.

The yield, realized after deducting borrow costs, fees, and safety buffers, is distributed proportionate to the amount of sftUSD held. Distributions to sftUSD holders are reflected through a variable exchange rate between sftUSD and ftUSD. Unstaked ftUSD does not accrue yield; its proceeds are directed to the protocol’s treasury to fund operations, expand liquidity, and support the token-first model.

This structure allows collateral to remain productive while minimizing directional risk. The long (staked) and short (borrowed) legs are calibrated to offset one another under normal conditions, reducing the likelihood of liquidation during volatility. The approach prioritizes conservative sizing and transparent, programmatic management. All strategies and rebalancing logic are executed onchain and are auditable through public dashboards.

ftUSD’s underlying yield strategies operate fully onchain, with key parameters such as pool exchange rates and collateral exposures remaining transparent to track performance and risk composition. All positions are marked to market and managed under the same delta-neutral framework, with periodic adjustments based on observed liquidity and volatility conditions.

A native stablecoin like ftUSD allows Flying Tulip to price risk, settle trades, and manage liquidity under a single unified framework. Anchoring market activity to such a stablecoin enables Flying Tulip to unify collateral management across its AMM, CLOB, and derivatives markets. ftUSD serves as the base unit for margin, settlement, and lending, allowing the same collateral to support multiple positions without leaving the system. Yield generated from these activities, such as funding payments or lending carry, remains within the protocol’s liquidity base and is routed either to sftUSD stakers or to operational reserves according to policy.

FT Lend: A New Money Market Structure

Flying Tulip introduces FT Lend, a native money market integrated directly into the protocol’s unified margin system. It allows users to borrow and lend assets using the same collateral that supports trading, settlement, and derivatives positions across the protocol. FT Lend is designed from the ground up to operate within an adaptive framework informed by real-time market data on liquidity depth and volatility.

Most of the major money markets today rely on fixed loan-to-value (LTV) ratios and over-collateralization thresholds. Borrowers deposit collateral exceeding the value of their loan, maintaining a margin buffer that depends on the price of the underlying asset. Liquidation occurs when the debt obligation surpasses the collateral’s adjusted value.

Static LTV parameters are chosen for their simplicity and the predictability they offer. They let protocol designers fix a borrow threshold for each asset, defining the maximum debt a borrower can take relative to posted collateral. These thresholds typically assume worst-case volatility and enforce over-collateralization, ensuring lenders remain protected during rapid price movements. However, this design also limits capital efficiency and can have cascading effects. When markets are stable, capital remains under-utilized; when volatility spikes, static parameters amplify liquidation cascades as prices fall and collateral thresholds are reached across the protocol. Static risk parameters, by design, cannot differentiate between stable and volatile market conditions.

FT Lend replaces static assumptions with adaptive parameters that adjust continuously to market conditions. Borrow limits, interest rates, and liquidation behavior are derived directly from onchain data rather than fixed governance rules:

• Trade-Weighted LTV (TWAR). Borrowing power scales with position size relative to pool depth. Smaller loans receive higher limits, while larger ones face progressively lower caps to account for execution impact. The collateral-to-pool ratio determines the maximum permissible LTV, which tightens predictably as position size or volatility increases.

• Volatility-Aware Rates. Borrow costs adjust according to realized dispersion. Assets are classified as stable or volatile, and rate formulas respond automatically: during high volatility, rates rise and borrowing capacity contracts; during calm periods, rates compress and available credit expands.

• Snapshot LTV. When a borrower opens or modifies a position, borrowing limits are locked to current market conditions. Existing positions remain under those limits even as policy parameters change, preserving predictability while allowing future loans to reflect updated market states.

• Market-Aware Liquidations. Liquidations are executed through a Liquidity Engine that aggregates AMM reserves and order book depth to minimize slippage. Before execution, the engine simulates price impact, segments large positions into smaller trades, and prioritizes resting CLOB orders when available. This approach reduces volatility transmission and ensures orderly liquidation behavior under stress.

• Unified Collateral System. The permissionless layer mirrors the AMM: each trading pair hosts its own lending market, parameterized by live depth and volatility. The permissioned pool governs a curated set of cross-margin assets. Deposits in this pool remain productive across the system—earning base yield, backing open orders, and securing perpetual positions simultaneously. A debt-netting mechanism offsets delta-neutral exposures, mitigating conventional liquidation paths and reinforcing the collateral logic that also underpins ftUSD.

All parameters across LTVs, rates, and utilization update onchain in real time. The AMM publishes time-weighted (TWAP) and reserve-weighted (RWAP) price windows that feed directly into lending logic, ensuring collateral values reflect executable market conditions. Borrowers pay interest; suppliers earn it. Cashflows are settled through the token-first model, where lenders receive FT-denominated yield distributions and policy fees flow into protocol reserves and buyback mechanisms.

Flying Tulip’s protocol research demonstrates that collateral utilization adjusts in line with both market volatility and liquidity depth, as illustrated above. As volatility rises or liquidity thins, the maximum permissible LTV declines along a predictable curve, allowing leverage to expand and contract with market stability rather than remain fixed. This relationship directly informs how FT Lend calibrates borrowing power and liquidation behavior in real time, ensuring that capital allocation across the protocol remains both responsive and risk-aware.

Adaptive AMM-CLOB Spot Trading

Flying Tulip offers spot trading through a dual-engine exchange that combines an adaptive AMM with a central limit order book for execution. The two systems operate within a unified framework, enabling liquidity to route dynamically between continuous and limit-based liquidity depending on market conditions. Orders execute along the path offering the best realized price and minimal impact, designed to maintain consistent pricing across the protocol.

The AMM is curve-adaptive, referencing short-horizon volatility inputs including realized volatility (rVOL), implied volatility (IV), time-weighted average price (TWAP), and reserve-weighted average price (RWAP) to continuously reshape its pricing curve. In stable conditions, the curve flattens toward a constant-sum form to minimize slippage and compress bid-ask spreads. During volatility spikes, it steepens toward constant-product behavior to preserve depth and maintain price integrity against rapid order flow. This allows markets to self-regulate without manual intervention, adjusting curvature to prevailing liquidity and volatility conditions.

Price and flow data are smoothed through exponential moving averages (EMAs), dampening the effects of short-term swings while allowing the protocol to respond to structural market shifts. Guardrails limit how far the curve can migrate during a single window, ensuring predictable behavior for traders and liquidity providers alike. The result is a trading engine that adapts continuously to changing environments while avoiding instability.

Before execution, each swap is simulated onchain to assess its price impact relative to current pool depth and defined pool thresholds. Large trades are automatically broken up into several orders to smoothen market impact. If better pricing is available through the CLOB, orders are routed there by priority; while any remainder clears through the AMM. Fees are dynamic, designed to lower in stable markets to encourage activity, while raising during volatility to compensate LPs for their risk accordingly.

LPs can supply assets across full or concentrated ranges. A full-range position provides consistent fees on a x*y=k basis. Concentrated liquidity allows higher fee density while prices remain within range but requires active rebalancing when markets trend. The adaptive curve moderates these dynamics: spreads tighten when markets are stable and widen when volatility increases, reducing divergence loss during stress periods.

Fees function as a dynamic policy variable rather than a fixed parameter, adjusting with observed market conditions. The schedule moves toward its lower bound in calm regimes, attracting flow, and rises toward its upper bound in volatile conditions, compensating liquidity providers and slowing adverse flow. All bounds and coefficients are publicly visible and updated on-chain.

By unifying AMM and CLOB execution under a shared liquidity and risk framework, the protocol maintains consistent price discovery across conditions and avoids fragmenting depth. The AMM also serves as the foundation for other components; perpetual markets, lending, and liquidations, all of which reference AMM-derived price and depth windows for funding, collateral valuation, and impact-aware execution.

Flying Tulip’s protocol research demonstrates that AMM curvature dynamically adjusts to market volatility, as illustrated above.

This figure compares the simulated performance of several LP strategies across range-bound, uptrend, and downtrend regimes. Concentrated and trigger-based strategies generated higher fee income during stable periods, while passive LPs preserved value through directional moves. The results highlight the trade-off between reactivity and exposure: adaptive strategies outperform in equilibrium markets but converge toward passive outcomes when volatility rises sharply.

This relationship underpins how the protocol’s adaptive curve manages liquidity under stress. By adjusting curvature in response to volatility, the AMM preserves depth, stabilizes fee generation, and supports collateral assets such as ftUSD, ensuring yield and price stability across the broader protocol.

By unifying both market types under a shared liquidity and risk framework, Flying Tulip’s spot module maintains efficient pricing across conditions and avoids fragmenting AMM and orderbook liquidity. The CLOB also incorporates volume-based fee scaling, maker rebates, and a referral system that rewards LP and trading activity, designed to align user incentives with liquidity depth.

FT Perps

Flying Tulip introduces a native perps engine designed to let users take long or short positions on assets with leverage, settling directly to prices discovered within the protocol’s own AMM and CLOB. FT Perps derives these values internally from the protocol’s live trading activity. Prices, funding rates, and liquidation thresholds reference actual executable liquidity rather than delayed or externally sourced data.

This design allows the protocol to align mark prices with real trading depth. If an asset changes hands at a given price on the AMM or CLOB, that becomes the effective settlement price. Prices are updated on a continuous basis. Funding rates adjust automatically based on borrowing demand, position imbalances, and the effective cost of holding long or short exposure within the protocol. When longs are effectively borrowing stable assets to hold, and that borrowing becomes expensive, the funding rate reflects it; when the imbalance reverses, funding direction flips. All funding inputs and parameters are transparent and observable onchain.

Perpetuals can be traded in isolated or cross-margin modes. In isolated mode, collateral supports a single position, containing risk within that market. In cross-margin mode, users can post collateral from the permissioned Lend pool, allowing a single deposit to back multiple positions across the Flying Tulip protocol while continuing to earn its base yield. Borrowing power and leverage limits are determined by live depth and volatility metrics and are snapshot at the time a position is opened or adjusted to prevent retroactive changes.

Liquidations follow the same logic that governs the rest of the protocol. When a position approaches its liquidation threshold, the engine simulates the next execution step on the AMM’s adaptive curve. If the modeled impact exceeds safe limits, the position is unwound gradually, crossing resting CLOB orders first and breaking up the remainder across the AMM, to minimize price disruption.

All positions settle in ftUSD, Flying Tulip’s native settlement currency. ftUSD itself does not yield, but users can stake to sftUSD to receive protocol distributions. Liquidity providers who opt into settlement pools earn per-settlement fees, supplying ftUSD to back the perps engine.

Because pricing, funding, and liquidation logic all derive from internal markets, FT Perps operates as an integrated component of the broader protocol. It shares the same liquidity base, depth windows, and collateral pools that support the spot and lending layers, ensuring that leverage, pricing, and liquidation behavior remain consistent across the protocol. This structure creates a reinforcing trading environment: market data informs pricing, pricing informs leverage, and both evolve within the same collateral and liquidity framework.

Insurance

Flying Tulip introduces a protocol-native insurance layer with onchain protection for investors against unprecedented protocol incidents. These span across smart contract exploits, faulty liquidations, or other technical failures across the protocol’s trading, lending and settlement layers. The insurance engine operates as a continuous market between coverage buyers - investors seeking to protect their capital - and capital providers that earn yield through the premiums they collect.

Coverage is structured as an active position in a shared pool. Buyers post collateral and pay a streaming premium for the duration of coverage. Providers deposit capital in USDC, which serves as the pool’s base asset and payout currency. In return, they pool tokens representing their proportional share of assets and accumulated premiums, allowing protection capacity and pricing to adjust automatically as utilization and risk conditions change.

Premiums function as variable rates that respond to real-time data. Utilization, coverage demand, and internal risk indicators, which are derived from the protocol’s AMM and order book, jointly determine rate adjustments. When pool utilization rises or volatility increases, premiums move higher to attract liquidity; when conditions normalize, they ease back down.

If an incident occurs, an external verifier such as UMA’s optimistic oracle assesses whether it meets predefined on-chain conditions, including the affected system, time frame, and loss threshold. Once verified, users with active coverage positions can redeem their insured amount in USDC directly from the pool. If no qualifying event occurs, coverage can be closed at any time, immediately halting premium payments.

The insurance layer integrates with the same collateral and pricing systems that govern lending and trading. Assets deposited in Lend can back both open positions and coverage, while the same liquidity and volatility metrics that drive funding and liquidation logic also inform premium and capacity adjustments.

Capital providers assume exposure to verified payout events; coverage buyers depend on oracle adjudication. Both remain exposed to typical smart contract and liquidity risks, with temporary withdrawal limits possible during claim settlement.

In this model, insurance functions as part of the protocol’s internal risk infrastructure rather than an external add-on, allowing protection capacity, premiums, and liquidity to evolve directly with system conditions.

FT & Economics

Flying Tulip’s economic structure centers around its native FT token. Each protocol component – ftUSD, Lend, Perps, AMM, and Insurance – generates transaction fees, funding payments, and yield; which is then used to repurchase and burn FT. This reflects FT’s core design principle: to reflect protocol performance through net token supply over time.

The FT launch introduces a new kind of structure in DeFi, in which 100% of token supply is allocated to private and public participants, at the same valuation at the same time, through the Public Capital Allocation. FT has a fixed supply of 10 billion tokens and no set inflation schedule, and the founding team receives no upfront allocation; any exposure is earned later through open-market buybacks funded by protocol revenue. Minting occurs only through the Public Capital Allocation (PCA) at a fixed ratio of 10 FT per $1 contributed. If $500 million is raised, exactly 5 billion FT are minted; once the 10 billion cap is reached, issuance ceases permanently.

Participants in the raise receive their FT position as an onchain Perpetual PUT. While the option is active, holders can redeem FT at par in the original collateral asset, permanently burning the redeemed tokens; or withdraw FT, invalidating the option and releasing the backing capital for market buybacks and burns.

Each PUT functions as an NFT and encodes specific redemption rights to the participant’s underlying deposit, wherein if a holder withdraws 50% of the tokens allocated to their NFT, they will still be able to redeem the remaining 50% of their invested capital. This enables partial redemptions for investors with transparent onchain accounting, though it also means redemptions are irreversible, i.e. tokens cannot be re-deposited into the NFT once they’ve been withdrawn.

Capital raised through the PCA is deployed into conservative, onchain yield strategies, spanning Aave V3, stETH, jupSOL, AVAX staking, and sUSDe. Yield from these deployments is first distributed across the protocol and its operational costs; while the surplus is allocated towards FT buyback-and-burn. This structure is designed to enable protocol revenue and capital yield to sustain itself without relying on new issuance.

Both paths reduce circulating supply, either directly through redemptions or indirectly through repurchases funded by released reserves. Secondary-market FT carries no such redemption right; if holders redeem their underlying capital, their corresponding FT is burned, reducing circulating FT supply and concentrating more value to existing holders.

Flying Tulip’s Business Model

Revenue generated across the FT product stack is used for FT buybacks:

• ftUSD yield flows to the treasury and is used for FT repurchases.

• Lend contributes its net interest margin, the spread between borrower and supplier rates.

• Perps forwards a portion of trading and funding fees to the same buyback mechanism.

• Insurance directs its share of active premiums there as well.

• When holders withdraw FT from the Perpetual PUT, the capital released from that redemption reserve funds additional market buybacks.

Repurchased FT is then split between two outcomes: one portion is burned, permanently reducing that given portion of circulating FT supply; the other part is unlocked for distribution.

Unlocked tokens are governed by revenue‑funded buybacks and follow a fixed allocation schedule. When protocol revenue funds buybacks, the Foundation, Team, Ecosystem, and Incentives unlock 1:1 in a 40 : 20 : 20 : 20 split.

Just as Flying Tulip’s products are designed to adapt to real-time market conditions, the protocol’s business model is designed to adapt to real-time protocol activity. When protocol utilization rises, whether through higher trading volume, borrowing activity, or insurance demand, the aggregate revenue available for buybacks increases proportionally. When utilization slows, supply contraction continues but at a reduced rate, as no new issuance occurs.

In practice, FT functions as the coordination layer for value across Flying Tulip’s native ecosystem. Product-level revenue and conservative yield form the inflows; buybacks and burns are the outflows; and unlocks, when revenue-backed, maintain contributor alignment. The result is a closed capital circuit in which operational output, user activity, and liquidity depth all converge into measurable changes in supply, effectively tying FT’s value directly to the protocol’s realized performance and operational efficiency.

Outlook

DeFi hasn’t yet crossed the chasm, but it is far closer than it was a few years ago. The foundations of an Internet Financial System are already in place: 24/7 global settlement, transparent ledgers, composable infrastructure, and the ability to move capital without intermediaries.

However, DeFi’s current architecture remains too fragmented for the open, composable financial system it was intended to be: each primitive manages its own accounting, risk parameters, and collateral base. This isolation preserves protocol solvency but limits broader capital efficiency.

This issue isn’t unique to crypto, nor is it a new one by any means. A brokerage account at Fidelity can’t seamlessly interact with assets held at Charles Schwab. Transferring securities between them involves settlement delays and manual coordination. Even within a single institution, moving funds between accounts, say, rolling over a 401(k) into an IRA, requires intermediary steps and time-consuming processes. In contrast, however, DeFi protocols operate on shared, public infrastructure. Open standards and transparent state make composability a native property rather than a feature built through integration.

Flying Tulip lies uniquely at the intersection of two structural shifts in DeFi: aggregation and real-time adaptivity. The need for unified margin architectures that bring DeFi services i.e. trading, lending, derivatives under shared liquidity and collateral is becoming glaringly obvious as DeFi becomes more and more crowded. At the same time, the need to build DeFi products and services that respond to real-time market conditions in order to adjust parameters such as collateral ratios, borrowing limits, and funding rates, is becoming more apparent.

Flying Tulip aims to capture both in a single protocol. It connects DeFi’s core primitives: stablecoins, trading, lending, derivatives, and insurance, designed to adjust risk and pricing dynamically with real-time liquidity and volatility, through a unified margin account. Undoubtedly, if Flying Tulip’s launch and early growth are successful, there will be dozens of imitators building and selling a similar product. Nonetheless, first-mover advantage is a force to be reckoned with in DeFi. At Shoal, we believe Flying Tulip is well-positioned to become the leading real-time DeFi stack.

Sources

Data is sourced from DeFi Llama.

• Richard Stallman, Free Software, Free Society: Selected Essays of Richard M. Stallman, 3rd Edition https://www.gnu.org/doc/fsfs3-hardcover.pdf

• Flying Tulip, Flying Tulip Documentation https://docs.flyingtulip.com/

• Flying Tulip, Internal Research Threads. Retrieved from:

  • https://x.com/flyingtulip_/status/1898432266499416429

  • https://x.com/flyingtulip_/status/1898785006249513246

  • https://x.com/flyingtulip_/status/1898839079757996287

  • https://x.com/flyingtulip_/status/1898784803249410508/photo/1

  • https://x.com/flyingtulip_/status/1899466570981691502

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. This post has been created in collaboration with the Flying Tulip team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

A Transformation Is Overdue

Innovation tends to be scarce in an environment as entrenched, risk-averse, and burdened by technical debt as the financial services sector. Yet history suggests that advances in financial infrastructure have constantly moved in tandem with periods of exponential economic growth. Double-entry bookkeeping laid the foundation for modern accounting and credit. The joint-stock corporation, introduced in the 17th century, opened the door to large-scale investment and capital formation. SWIFT and ACH helped standardize interbank transfers and cross-border payments. Since the Industrial Revolution, global GDP has only accelerated.

Naturally, this raises the question: where and how does the next opportunity for financial innovation emerge? As Blackrock and Fidelity move hundreds of billions onto blockchain rails, landmark digital-asset legislations continue to be passed, and even retirement-plan managers begin allocating capital to crypto, it’s becoming clear a growing number toward one particular direction: tokenization.

At its core, tokenization means encoding assets of economic value - cash, securities, real estate - and their associated ownership claim onto blockchains. These distributed ledgers record every transaction as a transparent and immutable event, maintaining a single source of truth synchronized across a decentralized network of nodes. Offchain assets are represented as digital tokens; when ownership changes (i.e. assets are created, transferred, or destroyed), the changes are first validated by the nodes, and then permanently stored onchain.

The most prominent and recognizable example of this phenomenon today is the stablecoin. Designed to represent the value of stable reference assets, most commonly the US dollar, stablecoins are digital dollars issued and transferred on blockchain rails. They provide a stable, borderless unit of exchange in digital form: just as anyone with an internet connection can use WhatsApp to message globally in seconds, anyone can move money globally with stablecoins.

Given >99% of circulating stablecoin supply is made up of US Dollar backed stablecoins, we can effectively think of them as tokenized dollars: their supply onchain is backed 1:1 by reserves held in assets like dollars and treasuries. Stablecoins have stood the test of time and have seen remarkable growth in supply, which sits at just over $300B today. That said, if we observe monthly issuance volume of tokenized assets 5 years ago vs year-to-date, it’s clear the appetite for tokenization extends well beyond just digital dollars now.

To better understand why demand for tokenization is growing, it helps to first examine the limits of today’s market infrastructure.

Why Finance Needs New Rails

Few words capture the state of today’s financial infrastructure better than archaic. The systems that move trillions each day; payment networks, clearinghouses, settlement systems, were designed more than half a century ago.

History doesn’t repeat itself, but it often rhymes. Throughout much of the 20th century, America’s pre-1935 corporate giants dominated the market. They lost ground slowly, shedding about 2.2% of value each year to rising competitors. Then came the 1970s. New technologies, oil shocks, and inflation broke that inertia, and the pace of decline nearly doubled to 3.4% annually, sometimes even spiking above 10%.

That decade marked a structural inflection. The electronic systems that replaced paper trading and manual clearing ushered in a new era of efficiency, standardization, and scale. Networks like SWIFT, ACH, and the DTCC digitized the plumbing of global markets, transforming how capital moved and was recorded. Yet half a century later, those very systems now constrain the markets they once modernized. The infrastructure that enabled global finance to operate electronically has become its primary bottleneck.

T+1, T+2 (And Counting)

Most global securities markets today rely on delayed, multi-day settlement cycles, typically one to two business days between trade and final transfer. A trade executed on Monday is not settled until Wednesday. A trade placed on Friday may not be settled until next week. It’s as outdated as it sounds; this standard emerged from the paper-certificate era when trades required physical delivery and manual reconciliation. While trades themselves can be executed electronically in seconds today, the final transfer of their ownership still takes days. Until that moment, each trade is merely an entry in another institution’s siloed private ledger.

It’s naive to downplay this structural lag as mere operational inconvenience: delayed settlement represents one of the largest hidden costs in global markets. Delays mean asset ownership remains in flux, exposing participants to credit and counterparty risk and tying up that capital that could otherwise be productively deployed. In aggregate, trillions of dollars remain effectively idle and unproductive because the underlying infrastructure has failed to adapt.

The DTCC reports that tens of billions of dollars in daily settlement failures. These failures rarely occur in isolation; when one security fails to arrive, it often has already been pledged as part of another transaction. That second trade then fails, potentially a third after it, effectively creating a cascade of failures which are only amplified in markets with high leverage and thin liquidity.

Even when trades do eventually clear, structural inefficiencies remain. The longer the settlement window, the greater the collateral required, as clearinghouses demand higher margins to account for the additional risk. Meanwhile, banks and brokers often struggle to determine which securities are truly available in real time, and settlement delays often lead to over-allocation and inventory mismanagement. On top of this, settlement systems stop when markets close, meaning their daily operating hours and operational days per week are always limited.

These frictions only amplify across borders. Different regions operate their own central securities depositories with their own rules and timelines. Transferring assets across them involves multiple intermediaries and reconciliation steps. The regulatory patchwork adds another layer of friction. Compliance requirements differ by jurisdiction, forcing firms to spend heavily on reconciliation and reporting. Market operating hours rarely align, creating dead zones where trades cannot move forward. A current example is Europe’s delayed adoption of T+1 settlement, scheduled for 2027, meaning the EU will remain out of sync with the US and other regional markets, imposing new costs on participants that operate across both markets.

With this in mind, it’s important to recognize that the evolution of financial infrastructure more often than not is a reactionary one:

• In the 1960s, back-office paperwork overwhelmed Wall Street, leading to NASDAQ’s creation in 1971 as the first electronic stock market.

• In 1973, the Depository Trust Company centralized recordkeeping to eliminate the physical transfer of certificates.

• After 9/11, Congress passed the Check Clearing for the 21st Century Act, allowing digital images to replace paper checks.

• In 2012, Hurricane Sandy flooded DTCC vaults, destroying 1.7 million certificates and accelerating the transition to fully digital records.

Infrastructure most commonly evolves when inefficiency or crisis leaves no alternative. Today, the pattern repeats. The shortcomings of today’s market infrastructure are not abstract. They translate directly into costs, UX pain points, and risks that are borne by end-users.

The internet already enables information to move globally in milliseconds. There is little reason why money and securities should remain constrained by regional ledgers and business-hour settlement when the technology for instant, continuous transfer already exists. It is only natural that value should move as freely as information: accessible globally, operating continuously, and secured by transparent, programmable infrastructure.

All Roads Lead to Tokenization

Tokenization is designed to directly address the structural lag in modern financial systems.

By recording ownership and transfer on shared ledgers, it removes the need for multiple intermediaries to reconcile the same transaction across fragmented databases. Settlement becomes a matter of redistributing balances on a digital ledger rather than routing instructions through correspondent banks and clearing houses. The primary resource consumed in this process is computing power, paid as a transaction, or gas fee, a cost that continues to decline as low-cost or near-zero gas transactions have now become table stakes for chains today. As a result, the marginal cost of value transfer for tokenized assets will continue to gravitate to zero.

By contrast, legacy payment systems remain burdened by institutional overhead. A single wire or ACH transfer may pass through several intermediaries; sending and receiving banks, correspondent institutions, and clearing houses, each extracting fees and introducing settlement latency. Global cross-border transfers still average 6.49% in transaction costs, a persistent tax on capital mobility that tokenized rails largely eliminate.

The idea of tokenizing assets is not new. It has resurfaced repeatedly over the past decade in different forms. As early as 2012, Meni Rosenfeld’s Colored Coins proposal introduced the idea of attaching metadata to fractions of Bitcoin to represent other assets such as stocks, bonds, or commodities: a digital bearer asset could embed both monetary value and an external ownership claim. A few years later, DigixDAO in Singapore sought to bring physical assets like gold onchain. Built on Ethereum and IPFS, it introduced a Proof of Provenance model that allowed anyone to verify an asset’s existence through its custody chain. Digix was among the first to combine asset-backed tokens with decentralized governance via a DAO.

The broader environment, however, was not ready to scale. Between 2017 and 2020, onchain liquidity was scarce. Average daily volumes on many exchanges were under $10 million, and quoted bid-ask spreads in smaller tokens often exceeded 4-8%, setting up for unreliable price discovery and therefore limited adoption.

The supporting infrastructure for tokenization, across custody, settlement, and compliance, was equally immature. In 2018, only a handful of licensed custodians operated globally, and most lacked regulatory clarity. The SEC noted that few met depositary standards under Rule 206(4)-2 of the Advisers Act, leaving persistent uncertainty around asset segregation and safekeeping. On/off-ramps between banks and blockchains were also unreliable. Until 2020, fiat-crypto conversion failure rates averaged nearly 50 percent across major providers, driven by inconsistent KYC processes and recurring payment rejections. Infrastructure diversity was minimal: early entrants like MoonPay, Ramp, and Transak collectively supported fewer than 60 fiat currencies globally, excluding a good portion of emerging markets and locales.

The concept of tokenized finance was sound, but the market lacked the architecture, incentives, and trust mechanisms to sustain institutional participation. It would take another half-decade, driven by advances in compliant custody, the rise of stablecoin liquidity, and the emergence of cross-chain settlement frameworks, before tokenization began to take form at the scale it was once envisioned to.

At the foundation of this shift is a principle of fluidity. In any monetary system, assets that are highly divisible and low-friction tend to circulate rather than sit idle. Tokenized assets follow that same logic: they are designed to move, integrate, and settle across networks in real time. Blockchains function as public digital ledgers, and automated reconciliation reduce the cost of movement, while fractional ownership lowers participation thresholds and deepens liquidity.

The Tokenization Landscape Today

Total tokenized value now sits at just over $320 billion, spanning more than 220 issuers and roughly 400,000 onchain addresses. Still, only a fraction of that value circulates actively within DeFi protocols. The difference highlights a key point: much of tokenized value today remains in custodial or permissioned environments rather than freely composable onchain.

That definitional caveat aside, the trendline is clear: while still small relative to the $100T+ traditional markets, tokenized asset value has grown sharply in the past year. The rise of tokenized assets has been most present in two particular asset classes: stablecoins and tokenized Treasuries.

The State of Stablecoins

Stablecoins remain the clearest proof of concept for tokenization. With a circulating supply of more than $300 billion, they show that there is demand and utility for programmable, globally transferable, always-on cash works at scale.

Over the past five years, stablecoin adoption has accelerated sharply. Tens of trillions of dollars in value have already moved through stablecoin rails, and supply continues to set new all-time highs.

By token, issuance remains concentrated in USDT and USDC, which together account for the vast majority of supply. New entrants such as FDUSD and PYUSD, backed by major exchanges and payment networks, signal a gradual institutional pivot toward regulated issuance, while DAI, USDS, and USDe demonstrate persistent demand for decentralized, DeFi ‘native’ stablecoins.

By chain, Ethereum still leads in aggregate supply and transaction value, but Tron, Solana, and Base have grown rapidly.

These distributions reveal two different types of utility. Ethereum dominates in DeFi-related usage (i.e. liquidity pools, lending markets, and settlement) while Tron leads in peer-to-peer transfer volume, especially across emerging markets where low fees and quick confirmations make it ideal for payments and remittances.

More impressively, though, stablecoins are already eroding legacy payment networks. Aggregate transfer volumes now reach into the trillions per month, rivaling networks like Visa, Mastercard, and SWIFT, but with near-instant settlement and materially lower transaction costs.

The regulatory landscape around stablecoins is evolving in tandem. A new class of regulated money-market fund (MMF) tokens, including names like BUIDL, BENJI, USDtb, and Cap Money (which aggregates them), illustrates how stablecoin design is converging with traditional cash-management structures. In effect, these instruments merge the accessibility of stablecoins with the yield of Treasuries, hinting at the next phase in tokenized assets.

A Rising Phoenix: Tokenized Treasuries

If stablecoins effectively functioned as a blueprint for tokenization, treasuries are emerging as the rising phoenix. At the time of writing, tokenized Treasuries have reached upwards of $8B marking more than an 80% increase YTD. That growth has well outpaced the early trajectory of stablecoins, reflecting growing demand for yield-bearing, low-risk assets that can serve as collateral and liquidity instruments across global markets.

At a high level, the tokenized treasury landscape today already has:

• $8.3B total value

• 50 total assets

• 52.7k total holders

*As per rwa.xyz

Treasuries are debt instruments issued by the U.S. Department of the Treasury to finance government spending. Backed by the U.S. government, they occupy a central position in global markets, functioning as cash equivalents for banks, corporations, and sovereigns. The four main categories - Treasury Bills, Notes, Bonds, and TIPS - differ in maturity but share two defining traits: liquidity and yield.

While stablecoins provide price stability, Treasuries offer something GENIUS-compliant stablecoins cannot: interest income. With short-term yields above 5% since the Federal Reserve’s tightening cycle in 2022/23, onchain investors have increasingly sought exposure to the U.S. risk-free rate. The logic is simple: idle capital held in stablecoins can instead earn yield through tokenized Treasuries without sacrificing liquidity or transparency.

Demand has also been shaped by broader structural forces. The rise in rates ended the ‘easy-money’ era that defined much of DeFi Summer. Liquidity mining returns fell sharply as incentives disappeared and the unsustainable yields of prior cycles collapsed. Tokenized Treasuries emerged as an alternative source of yield which itself stems from interest-bearing government securities with clear legal protections and transparent collateral.

It’s worth noting tokenized Treasuries come with a distinct limitation: they are legally classified as securities, which restricts their composability across open DeFi systems. Compliance requirements, investor whitelisting, and regulated custody frameworks introduce friction that prevents them from circulating as freely as stablecoins. Even so, the pace of growth speaks for itself. Tokenized Treasuries surpassed $7 billion in supply far faster than stablecoins did in their early years.

A Deep Dive Into OpenEden

OpenEden represents one of the first credible attempts to build a functioning framework for institutional-grade tokenization. Its mission is straightforward: to provide investors with continuous, regulated access to U.S. Treasuries onchain, combining the legal protections of traditional markets with the operational efficiency of blockchain infrastructure.

Founded in 2023, OpenEden is a tokenization protocol providing structured access to short-duration U.S. Treasuries. It is the first tokenized-Treasury issuer to receive independent third-party bond ratings, earning an “A-bf” from Moody’s and “AA+f / S1+” from S&P Global Ratings.

OpenEden Digital (OED), a licensed subsidiary of the OpenEden Group, serves as the platform’s regulated issuer. Operating under a Digital Assets Business License granted by the Bermuda Monetary Authority, OED is authorized to issue, sell, and redeem digital assets within a clearly defined legal framework.

Growth and Adoption

OpenEden’s footprint has expanded steadily since launch, though adoption has notably accelerated in 2025.

Total value locked, which currently sits at $531M, has climbed sharply YTD, driven by consistent inflows into TBILL, OpenEden’s tokenized Treasury product, and USDO, its stablecoin, which each have amassed ~$266M and ~$264M in TVL respectively.

To date, OpenEden has generated $7.29M in total fees, which thus far has amounted to $1.79M in protocol revenue.

Most OpenEden assets reside on Ethereum, however, liquidity is also growing across other chains like Solana, Arbitrum, and XRPL.

Transaction data shows a steady rise in usage, with daily transfer volumes across OpenEden’s products now reaching parity between TBILL and USDO, the latter of which was notably launched at a later time.

Key Features

OpenEden’s framework is designed to combine the reliability of regulated financial structures with the efficiency and transparency of onchain settlement. The TBILL fund’s underlying assets are custodied by The Bank of New York Mellon (BNY), while the fund itself is investment-managed by BNY Investment Management (BNYIM), marking the first time BNY is managing a tokenised fund on a public blockchain. Each tokenized instrument represents a verifiable claim on a corresponding pool of short-term U.S. Treasuries, and the protocol automates issuance, redemption, and settlement through smart contracts while maintaining regulatory compliance.

​​OpenEden’s model rests on several core principles:

• Regulated and licensed issuance: OpenEden assets are backed by real U.S. Treasuries held by qualified custodians under a BMA–licensed framework.

• Self-custody: Investors hold their OpenEden assets directly onchain.

• Low-cost, programmable settlement: Onchain rails minimize reconciliation costs and enable cheaper, faster, and more transparent settlement.

• Smart contract automation: Core fund operations, namely minting, burning, and exchange-rate calculation, are governed by verifiable smart contracts.

• DeFi Composability: ERC-20 compatibility allows OpenEden assets to integrate across broader DeFi ecosystems.

• Multichain deployment: Multichain support for assets expands accessibility and network reach including Ethereum, Solana, Base, Arbitrum, BNB Chain, and XRPL.

In practice, these design choices allow OpenEden to combine the trust and governance of traditional markets within an onchain environment, where issuance, custody, and settlement are managed programmatically under a regulated framework.

OpenEden Core Products

TBILL

OpenEden’s flagship product, TBILL, provides tokenized access to short-duration U.S. Treasury Bills. It is available on Ethereum and Arbitrum, and is backed 1:1 by a pool of short-term U.S. T-Bills and dollar reserves held with regulated custodians.

Growth and Fees

Since launch, TBILL has seen consistent growth in both deposits and fees generated. At the time of writing, TBILL TVL sits at $264M, up over 130% YTD and 2300% since launching in 2023 ($11M).

TBILL has also consistently generated tens of thousands in fees since early 2024, amassing $624K total fees to date.

Structure and Issuance

TBILL is issued through the TBILL Vault, a permissioned smart-contract that governs how investors onboard, deposit capital, and receive tokenized exposure to short-term U.S. Treasuries.

The vault is investment-managed by BNY Investment Management (BNY IM), while the underlying assets, namely U.S. Treasury Bills, are custodied by BNY, ensuring that collateral remains fully auditable and compliant with global custody standards.

The investor onboarding process begins once investors complete full verification. Whitelisted wallets are granted permission to interact with the vault, allowing them to deposit USDC and receive tokenized exposure to short-term Treasuries.

TBILL is minted and redeemed through the TBILL Vault smart contract. USDC deposits on supported chains are converted into TBILL, while redemptions are processed back into USDC. Each TBILL token represents a proportional claim on the net asset value (NAV) of the underlying fund. Minting and burning are handled automatically by the vault’s smart contract, which updates circulating supply onchain in real time.

All issuance and redemption activity is publicly verifiable onchain, while underlying assets remain secured through traditional custodians

Subscriptions (Aka Minting)

Onboarded investors can “subscribe” to receive TBILL tokens by depositing USDC; which can be done through the standard interface or manually through the smart contract.

Subscriptions begin once USDC has been deposited. TBILL tokens are minted and delivered to the investor; the exact number is determined as a function of the TBILL/USDC price, fetched from TBILL’s price oracle contract, as well as the amount of USDC deposited.

tbillMinted=usdcDeposit/tbillusdcExchangeRate

Initial deposits must be at least 100,000 USDC, with subsequent deposits at least 1,000 USDC.

Redemptions

Investors may redeem TBILL for USDC at any time. Redemption requests are placed in a First-In-First-Out (FIFO) queue. During redemption, TBILL tokens are burned, and the corresponding USDC amount is minted and returned to the investor’s whitelisted wallet.

usdcReceived=tbillRedeemed*tbillusdcExchangeRate-TransactionFee

This process ensures redemptions are orderly and transparent, with NAV-based pricing enforced by the vault oracle.

Vault Strategy

The fund managing TBILL maintains a portfolio of short-term U.S. Treasury Bills with a weighted-average maturity of less than three months.

T-Bills are issued at a discount to par value. For instance, an investor might spend $950 to buy a $1,000 bill and redeem it at maturity for a ~5% yield. For TBILL holders, this structure translates to a predictable, low-risk yield that accrues through the vault’s automated portfolio management.

Fees

Two primary fees apply to TBILL: the Total Expense Ratio (TER) and the protocol transaction fee.

Total Expense Ratio (3 bps or 0.03%)

The TER is charged daily on the fund’s total value (TVL) and represents the cost of managing the underlying T-Bill portfolio. It covers:

• Maintaining the portfolio’s weighted-average maturity below three months.

• Rolling over matured Treasuries into new issues and compounding generated yield.

• Meeting regulatory and reporting obligations for the BVI fund.

• Commissioning third-party audits for both fund assets and smart contracts.

• Custodian and banking fees charged by BNY Mellon and affiliated institutions.

Transaction Fee (5 bps or 0.05%)

Applied during minting and redemption, this fee is calculated in USDC and processed onchain. It offsets operational costs such as gas usage, bank wire fees, and offramping costs associated with fiat conversion.

Together, these fees sustain both the onchain and offchain components of the TBILL system, ensuring the vault remains compliant, functional, and capital-efficient.

Token Price

The TBILL token price reflects the Net Asset Value (NAV) per token, tracking the appreciation of the underlying T-Bills as they approach par value:

tokenPrice=totalAssets - feeClaimable/ circulatingTokenSupply

At launch, TBILL was priced at 1.0000, appreciating gradually as underlying assets accrue yield.

Price Oracle and Governance Controls

OpenEden has implemented a set of onchain mechanisms to ensure the security of the TBILL Vault. To start, OpenEden uses an in-house price feed that transmits NAV data to an onchain oracle, safeguarded by a price guard that halts minting or redemption if deviations exceed predefined thresholds.

• Timelock: Whenever the TBILL Vault’s treasury wallet address [changes], a 24-hour window is implemented to [allow admins to offramp funds if the change in address is unintended].

• Multisig: The TBILL Vault uses a multi-signature (multi-sig) mechanism to authorize onchain transactions (i.e. minting/redeeming TBILL).

• Price Guard: A circuit-breaker mechanism designed to track the TBILL token price and respond when needed, namely when the price deviates beyond predefined thresholds. In the case of attempted oracle manipulation attacks or failures, this mechanism halts minting/redeeming of assets via the TBILL Vault.

Onchain, TBILL Vault smart contracts are publicly viewable and verifiable on Etherscan. Offchain, the TBILL Vault’s U.S. T-Bills are held in custody by regulated custodians. Any remaining USD fiat currency reserves will be held in regulated custodians or be in transit between the on/off service providers, the prime broker, and the custodian account.

USDO: The OpenDollar

Another core component of OpenEden’s product suite is the OpenDollar, or USDO.

USDO is a regulated, yield-bearing stablecoin issued by OpenEden Digital (OED). The rebasing yield is distributed directly in the form of additional USDO to holders’ balances, and is available on Ethereum, Base, and BNB Chain.

USDO has seen faster growth than TBILL, both in supply and adoption. TVL has climbed steadily since launch, nearly mirroring that of TBILL with $264M of its own.

The number of USDO holders has also increased rapidly, surpassing TBILL’s user base within months of launch (400 USDO holders vs 59 TBILL holders).

As a result, USDO is also generating fees and revenue at a much greater rate than TBILL, its $6.6m in fees accounting for >90% of OpenEden’s aggregate total fees ($7.29m).

Rebasing mechanism

USDO rebases daily while maintaining a fixed $1 price. This rebasing mechanism allows holders to earn yield generated from reserves backed by U.S. Treasury Bills and reverse repurchase agreements (repos).

Yield is distributed directly in the form of additional USDO, meaning holders see their balance increase daily, rather than the price changing.

The rebase is governed by a bonus multiplier, which updates automatically each day (including weekends):

usdoBalance=shares*bonusMultiplier

Like traditional fixed-income products, USDO’s yield is predetermined by OpenEden Digital and may be periodically adjusted to reflect prevailing market conditions. For instance, if short-term Treasury yields rise, USDO’s rate may be increased accordingly; if they decline, the protocol may lower it to maintain parity with underlying asset performance.

USDO Minting & Redemption

At a high-level, USDO can be minted against either USDC or TBILL collateral deposits. Similar to the TBILL token, USDO can only be minted by authorized users who pass KYC and KYT checks.

• To mint USDO, an authorized user initiates the Instant Mint function, selecting their collateral token.

• The USDO smart contract calculates the equivalent amount of USDO to be minted.

  • USDO minted at a 1:1 rate to USDC

  • USDO minted based on the prevailing TBILL exchange rate at the time.

• The Liquidity Manager contract then mints and transfers USDO tokens to the authorized recipient’s wallet address.

USDO redemptions follow the same logic in reverse. Tokens are first burned, and the equivalent amount of USDC is transferred back to the redeemer’s wallet.

Two redemption modes exist:

• Manual Redemption, wherein USDO is transferred to OED’s wallet and processed on a First-In-First-Out (FIFO) basis. Requests settle during U.S. business hours, typically within 1–2 business days

• Instant Redemption: The USDO Liquidity Manager contract sends the underlying TBILL to the TBILL Vault, which redeems USDC from Circle’s BUIDL contract using its BUIDL allocation. The resulting USDC is transferred to the redeemer’s wallet onchain

USDO Reserves

USDO is backed by a diversified pool of regulated tokenized Treasuries issued by major financial institutions:

• TBILL (OpenEden)

• BUIDL (BlackRock)

• BENJI (Franklin Templeton)

• VBILL (VanEck)

These assets are backed by short-duration U.S. Treasuries themselves. OpenEden integrates Chainlink Proof-of-Reserves for real-time, onchain verification of collateral holdings. As of the latest data, USDO reserves sit at ~273,196,076.72, with over 99 % of circulating USDO residing on Ethereum.

Fees are charged on all transactions involving the minting and redemption of USDO:

• Minting Fee: 3 bps (0.03%)

• Redemption Fee: 10 bps (0.10%)

These fees are calculated in USDO and deducted directly from the total USDO amount being minted or redeemed.

They are designed to cover the Vault’s operational costs, including:

• Onchain gas usage

• Bank wire fees
  Off-ramping and fiat conversion costs

Together, these transaction fees are designed to sustain both the onchain and offchain components of USDO’s infrastructure, while preserving the asset’s liquidity and peg stability.

cUSDO

USDO is designed to provide secure, regulated yield. However, its structure as a rebasing token makes it difficult to integrate with a broader range of DeFi protocols. As such, OpenEden introduced cUSDO, a wrapped and compounding version of USDO.

cUSDO represents the same underlying exposure as USDO but accumulates yield internally, causing the token’s price to increase over time rather than its balance. Each cUSDO token reflects an increasing claim on the underlying pool, ensuring it remains fully composable across DeFi protocols. Conversion between USDO and cUSDO is permissionless and handled through a public smart contract, allowing users to wrap or unwrap at any time.

Available on Ethereum, Base, and BNB Chain, cUSDO extends the reach of USDO’s regulated yield into the broader DeFi ecosystem.

Collateralization ratio

To ensure each USDO token remains redeemable at $1, OpenEden maintains a real-time onchain collateralization ratio that compares the total value of reserves to circulating supply:

CR=ReserveNAV/usdoCirculating

As of the latest reporting period, USDO is 103.7719% collateralized, implying a 0.37719% over-collateralization buffer. This margin accounts for operational frictions, such as price movements or settlement delays, while ensuring full redemption coverage.

The collateral ratio is continuously updated and verified through Chainlink’s Proof-of-Reserves integration, which tracks the real-time Net Asset Value (NAV) of the underlying Treasury and repo instruments. Should the ratio approach parity, the system is designed to restrict new issuance or trigger rebalancing actions to maintain full coverage.

EDEN and Economics

OpenEden’s business model is built on the fee revenue generated from its products, primarily TBILL and USDO. These fees, derived from minting, redemption, and ongoing management, are collected as protocol revenue by OpenEden Group, the platform’s operating entity. This is made up of TBILL’s Total-Expense-Ratio (TER) and transaction fees (0.03% and 0.05%), plus USDO’s minting and redemption fees (0.03% and 0.10% respectively).

To date, OpenEden has generated $7.29 million in total fees and $1.79 million in revenue, according to DeFiLlama. The revenue base grows in tandem with product adoption and transaction activity, as both TBILL and USDO generate recurring volume-driven fees tied to their respective vaults. Again, it’s worth recalling that USDO has generated a more meaningful portion of these fees ($6.6m in fees or >90%) and despite having been around less than TBILL, which has generated $624K in fees respectively.

The EDEN token sits at the center of OpenEden’s ecosystem across several functions:

• Staking, to support protocol operations and economic security

• Governance, allowing holders to participate in decision-making on upgrades and parameters

• Incentives and emissions, to bootstrap liquidity and adoption of new products

• Utility features, such as fee discounts or rebates for active participants

The OpenEden Group is also exploring mechanisms such as buyback-and-burn programs, funded through a portion of protocol revenue or treasury reserves, to reinforce token value capture over time.

The OpenEden Ecosystem

OpenEden’s ecosystem combines onchain integrations that extend the usability of its tokenized Treasuries with offchain partnerships that provide regulated market access and infrastructure support. The design reflects a dual objective: to make short-duration U.S. Treasuries operable within DeFi while ensuring the legal, custodial, and compliance standards required by institutional investors remain intact.

Onchain Integrations

OpenEden’s onchain footprint spans the main environments where DeFi activity occurs today. Its assets are deployed across Ethereum, Base, BNB Chain, Solana, Arbitrum, and XRPL, designed to maximize distribution by allowing broader user access from different ecosystems.

Within the broader DeFi landscape, OpenEden has integrated a number of bluechip liquidity venues including Curve, Balancer, Aerodrome, and money market protocols including Pendle, Morpho and Euler among others. These integrations allow cUSDO (and therefore indirectly USDO) to operate as productive collateral or yield-bearing components within existing financial primitives including liquidity pools, vaults, and structured yield products, offering USDO investors a way to maximize the productivity of their capital.

Offchain Partners

Offchain, OpenEden’s network centers on custodial, brokerage, and infrastructure providers that establish the operational and regulatory base for its products. Custodians including Binance, BitGo, Fireblocks, Hex Trust, and Propine handle storage and segregation of client assets within regulated frameworks, while HiddenRoad handles OpenEden’s brokerage needs, This ensures institutional holders can manage exposure through their existing compliance and risk channels.

The infrastructure and services layer, spanning providers including Chainlink, Kaiko, and Archblock, and supports data integrity, market transparency, and pricing reliability. Together, these integrations form the scaffolding that allows OpenEden’s assets to operate in both regulated and onchain environments.

Binance Banking TriParty

OpenEden has partnered with Binance Institutional through Binance’s Banking Triparty framework, allowing cUSDO to be used as yield-bearing collateral within Binance’s trading environment. The setup lets institutional clients hold cUSDO with approved custodians while using those balances on Binance for trading and settlement purposes.

The arrangement preserves segregated custody, wherein assets remain off-exchange with custodians such as BitGo, Fireblocks, and Hex Trust, while Binance mirrors the positions internally for operational use. This reduces the need to move assets between custodians and the exchange, lowering counterparty and settlement risk.

In effect, the partnership connects OpenEden’s tokenized Treasury products to existing exchange infrastructure without altering their underlying regulatory or custodial structure. It offers a straightforward mechanism for institutions to deploy tokenized Treasuries as collateral with institutional-grade compliance and risk management.

Analysis & Outlook

Having detailed OpenEden’s design and ecosystem, the next step is to evaluate how its hybrid structure, anchored by regulated issuance and DeFi composability, shapes its prospects in the growing market for tokenized Treasuries and beyond.

Competitive Landscape

The tokenized-asset market has grown crowded in a short period of time. Growth accelerated notably after late 2024, when renewed institutional optimism and a post-election risk-on environment drove inflows into yield-bearing digital products. Unlike prior cycles dominated by crypto-native experiments, today’s competition includes some of the largest names in global finance, with over 115 tokenization platforms in production today.

In tokenized Treasuries, OpenEden competes most directly with Securitize, Ondo, Backed, and Matrixdock, alongside institutional entrants such as BlackRock (BUIDL), Franklin Templeton (BENJI), and WisdomTree (WUSDY). Each offers exposure to short-duration U.S. government debt through regulated structures and onchain issuance.

Stablecoins present a different challenge. Supply remains highly concentrated in a few dominant issuers (USDT, USDC) which together account for well over 90 percent of circulating volume. However, zooming out, if we exclude USDT, USDC, and BUSD supply, it’s becoming evident that stablecoins, like treasuries and the rest of the tokenization landscape, is only going to become more competitive soon.

How Does OpenEden Differentiate?

With $531M in TVL and $7.29M in fees thus far, OpenEden’s raw numbers, albeit notable, are not reflective of its positioning. OpenEden’s strength lies in the overall quality of its protocol structure and how it merges together institutional-grade regulatory compliance with onchain programmability and DeFi composability.

Importantly, OpenEden is the first tokenized Treasury issuer to receive third-party credit ratings, (an A-bf from Moody’s and AA+f / S1+ from S&P Global) attesting to the institutional standards of its fund structure and custody model. In a sector still dominated by self-reported audits, third-party credit ratings mark a meaningful step toward formal institutional adoption.

Investor onboarding follows a permissioned framework: wallets must complete KYC and KYT checks before interacting with vaults. Once approved, all transactions (i.e. mints, redemptions, and fee accruals) are visible onchain. This setup combines regulatory traceability with public transparency, creating a model where compliance and verifiability reinforce each other rather than conflict.

At the same time, OpenEden’s assets are built for interoperability. Both TBILL and USDO follow the ERC-20 standard, allowing them to move freely across DeFi protocols. TBILL functions as a yield-bearing Treasury asset, while USDO extends that yield into a rebasing stablecoin format. Regulated issuance with open integration illustrates how tokenized securities can exist within DeFi infrastructure without compromising oversight requirements.

OpenEden’s roadmap points toward a shift from individual product issuance to a standardized infrastructure model. The aim is to simplify how institutions bring regulated assets onchain, abstracting the operational and compliance overhead behind tokenization itself. In this sense, its long-term vision resembles a “Shopify for tokenization”: a modular framework that enables others to issue and manage tokenized products within defined regulatory and technical boundaries.

Where We Suggest OpenEden Focus Next

There are several key emerging catalysts could strengthen OpenEden’s position within the tokenization landscape:

DeFi-Nativitiy as a Differentiator

As institutional capital becomes more comfortable operating on public blockchains, the expectation will shift from passive exposure to productive onchain deployment. Assets like Treasuries, which already serve as low-risk collateral in traditional markets, can increasingly be used within DeFi to generate incremental yield or support liquidity provision.

OpenEden’s architecture is already compatible with major DeFi protocols, and as the regulatory perimeter around tokenized assets expands, this interoperability will matter more. Institutions will likely prefer frameworks that allow their assets to circulate safely across lending markets, structured vaults, or automated liquidity systems, without losing compliance guarantees. In that environment, composability becomes a form of capital efficiency, and OpenEden is positioned to benefit from that shift.

Privacy: The Next Institutional Unlock

The next major frontier for institutional adoption is likely transaction privacy. Institutions are unlikely to transact meaningfully on public blockchains until confidentiality, data protection, and counterparty privacy can be guaranteed. Zero-knowledge proofs, encrypted state systems, and privacy-preserving chains are quickly maturing, and the first regulated issuers to adopt them will gain a substantial lead in onboarding capital that cannot move through transparent rails today.

For OpenEden, integrating privacy infrastructure, or even pursuing strategic partnerships or acquisitions in that domain, could become a defining differentiator. Privacy-enabled settlement would allow institutions to interact with tokenized assets while maintaining compliance and auditability through selective disclosure. The ability to conduct verifiable yet confidential transactions would mark a decisive step toward large-scale institutional use.

Closing Thoughts

Tokenization has momentum, but its footprint remains small: tokenized assets including government bonds, credit, and equities still represent only a fraction of global financial markets, estimated at less than 0.2% of the roughly $500 trillion in total assets worldwide. Stablecoins continue to dominate onchain liquidity, with over $300 billion in aggregate supply dwarfing the combined value of all tokenized assets on public chains. The advantages of tokenization are clear: operational efficiency, near-instant settlement, 24/7 access, transparency, and programmability for functions like automated compliance or dynamic asset management.

However, though magnitudes more efficient than legacy financial rails, tokenization still encounters its fair share of structural limits. Derivative markets such as perpetual futures protocols already offer efficient onchain exposure to the price or yield of offchain assets without requiring direct ownership or custody. These instruments capture much of the same demand that tokenization seeks to serve, often with greater capital efficiency and fewer regulatory constraints.

Furthermore, value capture remains uncertain. John Pfeffer argued that much of the economic benefit from tokenization will flow to users rather than intermediaries. Open systems are difficult to monopolize. The same qualities that make blockchains effective in coordination and record-keeping also make them incompatible with business models built on control and opacity.

Even so, the catalysts on which today’s surge in tokenization adoption hinge on suggest it really may be different this time. The ICO period lacked regulatory guardrails; that foundation now exists. Institutional trust and adoption, while still unfolding, is being accelerated by major asset managers like BlackRock, Franklin Templeton, and WisdomTree deploying and issuing regulated onchain funds. Tokenized assets are now used as collateral in protocols including Aave and Maple Finance, demonstrating the composability that yield-bearing instruments can get from DeFi rails. As adoption grows, capital is likely to move up the onchain yield curve, from stablecoins to Treasuries and eventually into tokenized credit and equity, expanding the potential tokenized asset value well into the trillions.

At Shoal, we think it’s clear by now that tokenization is no longer a matter of “If?” or “When?” but rather “How?” The more pressing question now becomes what kind of products and services prove to be the most useful over time, which hinges on a) the quality and efficacy of their underlying structure; b) the exogenous value they provide to users, DeFi, and the broader DeFi and financial services sectors; and c) their ability to capture value from the services they provide and redistribute to investors and token holders in a sustainable way.

In practice, this resembles a tokenization platform which manages to efficiently integrate compliant, regulated financial services with smart contracts and onchain rails; lower barriers to entry for institutions to bring regulated assets onchain by abstracting the operational and compliance overhead; and coordinate and align value capture from the organic demand for the services it provides through a native token.

OpenEden offers one of the most practical attempts to build this exact framework. Its regulated structure, emphasis on short-duration Treasuries, and institutional custody integrations anchor it within existing financial infrastructure, and independent credit ratings reinforce its credibility. A growing presence among the broader DeFi ecosystem ensures its assets are composable, productive, and scalable. OpenEden wasn’t the first attempt, nor will it be the last, but we believe it is one of the best-positioned teams to capture the tokenization opportunity ahead.

Sources

Data is sourced from DeFi Llama, Rwa.xyz, and Artemis Analytics.

• Dune Analytics, RWA Report 2025 Dashboard. Retrieved from https://dune.com/rwareport2025

• Theia Research, Internet Finance. Retrieved from https://x.com/theiaresearch/status/1876618725547233417?s=46

• Modern Treasury, History of ledgers. Retrieved from https://www.moderntreasury.com/journal/history-of-ledgers

• Gresham Technologies, Why trades fail: Understanding the cost of reconciliation errors. Retrieved from https://www.greshamtech.com/blog/why-trades-fail-reconciliation

• TD Securities, Cross-border implications of T+1 settlement. Retrieved from https://www.tdsecurities.com/ca/en/cross-border-implication-of-t-1-settlement

• John Pfeffer, An investor’s take on cryptoassets. Retrieved from https://hostingfilesonline.co.uk/An%20Investor’s%20Take%20on%20Cryptoassets%20v6.pdf

• Teej Ragsdale, Jack Chong, Mukund Venkatakrishnan, An Unreal Primer on Real World Assets https://docsend.com/view/u53utyp2j4ycg7r6

• Carter, Nic, The Stablecoin Duopoly Is Ending. Retrieved from https://x.com/nic__carter/status/1973399535092171216

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. This post has been created in collaboration with the OpenEden team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

The way we move money has always evolved, from barter to gold to paper to digital dollars. As stablecoins are set to eat global payments and work their way up the rest of the financial services stack, purpose-built stablecoin infrastructure becomes critical. In this report, we explore how Plasma is building towards global rails for the future of money movement.

The Digital Dollar Arc

Money rarely sits still, and neither do the ways we move it.

Few things are as elementary and timeless as the transfer of value from one individual to another. When ancient herders needed grain or tools, they traded cattle and goats. If medieval farmers needed a pair of shoes, they’d head down to the local village market with bushels of wheat. Over time, it became clear that carrying bulky items and livestock wherever one traveled was inconvenient, so everyone turned to precious metals like gold and silver bars. It didn’t take long to realize those too were not practical nor convenient, and so bars were melted into coins, and coins eventually gave way to paper cash, IOUs, and banknotes. As technology became a bigger part of people’s day-to-day lives, the ways in which money moved only accelerated.

Today, someone in the US can send digital dollars to a friend in Peru or Thailand in a matter of seconds, while paying a penny to do so. This isn’t something they could do through their local bank or Western Union; this kind of borderless, low-cost, near-instant money movement is made possible with stablecoins.

Stablecoins are digital dollars issued and transferred on blockchain rails. They provide a stable unit of exchange in digital form: the same way anyone with an email address or WhatsApp can instantly communicate across the globe, stablecoins enable anyone with internet access to move money globally.

Tens of trillions of dollars have already been moved through stablecoins. They continue to grow and reach new all-time highs in supply. Though not new by any means, stablecoin adoption has recently accelerated at a pace few anticipated.

Impressively, stablecoins aren’t just growing. They’re already eroding legacy payment networks.

At Shoal, we believe it is inevitable that stablecoins work their way up the rest of the financial services stack beyond just payments, eventually disrupting consumer banking, lending, B2B settlement, payroll systems, and beyond. But this all begs the question: what’s so special about these digital dollars?

The Stablecoin Value Prop

“It is possible to create tools to allow end users to create currency protocol layers which have a stable value, pegged to an external currency or commodity. In this way, users of these currencies can own stabilized virtual currency tied to U.S. Dollars, Euros, ounces of gold, barrels of oil..” - Mastercoin whitepaper (2012)

Fundamentally, stablecoins are digital assets programmed to maintain the value of an underlying asset it is pegged to. Most commonly, stablecoins are pegged to fiat currencies, particularly the US Dollar (this is why we can call them digital dollars). To maintain this peg and stable value, stablecoin issuers implement specific mechanisms to ensure each stablecoin is backed 1:1 by its underlying asset. The most common way to do this is by holding reserves in cash and short-term US Treasury bills, matching the circulating stablecoin supply. For every new stablecoin minted, users deposit dollars to the issuer. These funds are safeguarded in regulated financial institutions and custodians. When stablecoins are redeemed, an equivalent amount is withdrawn from these reserves and returned to the redeemer, and the corresponding stablecoin supply removed from circulation, or “burned”.

*Quick aside: There are other stablecoin peg stability mechanisms, some of which are represented by OG leading stablecoin protocols like Maker DAO (now Sky) who built a CDP protocol to let anyone borrow DAI. Conversely, there are also examples like Luna/UST which have failed tremendously and wiped out tens of billions of dollars. Overall, the design of stablecoins can be a fascinating rabbit hole to fall down, but it’s worth staying grounded to the reality that over 80% of stablecoin supply is in USDT and USDC, both of which are USD-backed stablecoins maintained and operated by central issuing entities.

The stablecoin value proposition is not one-dimensional by any means:

• Global, 24/7 Settlement: Stablecoins can be transferred globally at any time of day, any day of the week. They operate on blockchain rails, designed to settle in minutes if not seconds. For reference, legacy transfer systems like ACH or international wires often take several days to clear, can only be processed during limited business hours, and can further be delayed by weekends or holidays.

• Superior UX: Stablecoins provide a superior experience to legacy payment systems, on the simple basis of speed and cost. On certain chains, stablecoin transfers can be settled in a matter of seconds. Legacy systems like ACH or wire transfers can take anywhere from hours to multiple business days.

  Stablecoins are also multiples cheaper than legacy payment networks. A stablecoin transaction is simply a redistribution of balances on a digital ledger. The primary resource consumed is the computing power required to update this balance, which is paid as the transaction or gas fee. Nowadays, gas costs are racing to zero as low-cost transactions are becoming table stakes for most chains.

  By contrast, a wire or ACH transfer involves hand-offs between multiple intermediaries - sending banks, receiving banks, clearing houses - all of whom impose a meaningful rake on the money being moved. Legacy cross-border transfers still charge 6.49% on average.

  It is important to note that while stablecoins offer near-instant, low-cost blockchain transfers, converting funds off-chain into bank accounts or cash, or “offramping”, can still involve legacy fees, FX spreads, and delays. But overall, even with this final step, stablecoin-based transfers remain dramatically faster and less expensive than legacy networks today .

• Permissionless Global Access: Stablecoins essentially democratize access to stable currencies, like the US dollar. Anyone with an internet connection can send, receive, and hold stablecoins, regardless if they have a bank account or access to financial services. Despite rising global financial inclusion, over 1 billion adults still remain unbanked today, unable to access formal financial services and often excluded from the digital economy. At the same time, many countries still face hyperinflation and currency devaluation. By enabling permissionless global access to the US Dollar, stablecoins provide a financial lifeline to residents in these developing regions.

• Programmable: Because stablecoins are built on blockchain rails, they exist as smart-contract based tokens. Put even simpler: they are code. This unique design means specific conditions and regulations (i.e. settlement rules, transfer restrictions etc) can be programmed directly into the asset itself. This programmability helps streamline operations as it is much easier and more predictable to write code than to anticipate human error. And because the crypto-native economy is a consortium of open permissionless protocols, stablecoins can naturally plug into, and enhance, nearly any application built on public chains: earning yield through lending or liquidity provisioning, collateral for borrowing other assets, margin for perpetuals trading, betting on bizarre prediction markets, and so on.

Homegrown, Organic PMF

Stablecoins, unlike most other blockchain-native innovations, have stood the test of time because there has always been an organic demand for them. Their history is largely defined by organic adoption arising from clear catalysts at each chapter.

A Trader’s Best Friend

Stablecoins first gained traction among traders looking for a simple way to move value in and out of volatile positions without offramping into fiat. In the early 2010s, there were few things to do with Bitcoin besides trading it, yet traders lacked an easy way to park funds in between trades.

Early references to stablecoin concepts first appeared in the Mastercoin whitepaper, and in 2014 it came into production with the launch of Realcoin (now known as Tether).

USDT was first issued on Bitcoin via the Omni Layer, and became available through exchanges like Bitfinex. When it launched, USDT brought a new utility for crypto traders: move capital between assets, stabilize exposure to volatility, and execute more complex trading strategies without needing to move into fiat then back into crypto. That said, given such a niche audience, adoption was rather limited.

Global Access To Stable Currencies

As stablecoins matured, their impact spread well beyond speculative markets. In countries beset by hyperinflation, where local currencies can be devalued significantly overnight, the value of a stable currency like the US Dollar is hard to underestimate. And today, the best way to get access to the US Dollar is through stablecoins.

Some notable data points:

• Stablecoin purchases accounted for >4% of Turkey’s GDP in 2024.

• In 2024, Argentina led LATAM stablecoin volume share as >61% of crypto transaction volume regionally was attributed to stablecoins.

• $2.36 trillion was transacted through stablecoins in APAC alone from June 2024 - June 2025.

• Sub-Saharan Africa (SSA) grew $205B in onchain value in 2025, reflecting 52% YoY growth in crypto adoption from 2024.

As such, stablecoins have become essential tools for personal savings, payments, and remittances for millions of people across much of Latin America, Africa, Asia.

A Reserve Currency’s Best Friend

As stablecoins have spread across emerging markets, their role in reinforcing US Dollar dominance globally becomes evident. But while the value of access to digital dollars becomes rather self-explanatory in emerging economies, it has been more difficult to translate over in the west, particularly in the US. Most Americans have savings accounts. They can send money instantly through apps like Venmo. Few lose sleep at night because they are worried about the dollar devaluing (20-30%) overnight.

The most compelling reason for US policymakers to endorse stablecoins is geopolitical: to strengthen the global dominance of the US Dollar. The US has long wielded the dollar’s reserve currency status to maintain global financial power, most commonly through the petrodollar system.

Today, this opportunity lies in stablecoins. The idea is simple: dollar stablecoins, nearly all of which are backed by cash and short-term US Treasuries, require real dollar reserves for every token issued. Each stablecoin minted is a new dollar someone overseas chooses to hold, and therefore a new source of demand for US government debt.

One could make the case that the US doesn’t have much of a choice but to embrace stablecoins at this point. In Q4 2024, Tether was ranked as the seventh-largest foreign buyer of US Treasuries, outranking countries such as Canada and Mexico in annual flows. Tether’s latest stablecoin report confirms Tether holds over $127b in U.S. Treasuries, making it one of the largest non-sovereign holders of U.S. government debt.

This dynamic is already reshaping policy. The US passed the landmark GENIUS Act recently, laying the groundwork for a regulatory framework for stablecoin issuance in the US for the first time. Not surprisingly, the GENIUS Act requires dollar stablecoins to be fully backed by [US assets],besides providing monthly reserve disclosures and conducting independent third-party audits. This helps reinforcing a stablecoin-to-debt-financing flywheel of sorts: every new token minted effectively creates another buyer for U.S. debt, therefore stablecoin adoption becomes a powerful strategic tool for maintaining dollar dominance. Treasury Secretary Scott Bessent has publicly said “We are going to keep the U.S. the dominant reserve currency in the world, and we will use stablecoins to do that.”

In short, US dollar stablecoins are evolving from mere crypto products into key instruments for the US’s geopolitical strategy, meaning the US government is highly motivated to see the adoption of US backed stablecoins continue to grow from here on out.

The Stablecoin Landscape Today

These organic catalysts have helped shape and accelerate the adoption of stablecoins to this day. But to better understand where stablecoins go from here, it’s helpful to zoom out and examine the landscape as it exists today.

In the last 30 days alone:

• $3.2T in volume processed in stablecoins

• 1.2B transactions in stablecoins onchain

• 41.4 million addresses have interacted with stablecoins

*Data is from Artemis and referenced at the time of writing.

The total stablecoin supply continues to reach new all-time highs, sitting at just over $291B today. USDT accounts for ~58% of this supply, and has continued to dominate supply throughout the years.

Another important aspect of the stablecoin landscape today is the distribution of stablecoins across different chains. Just as stablecoin supply is dominated by USDT, stablecoin distribution across chains is dominated by Ethereum, accounting for ~55% of total supply today, as is overall stablecoin volume.

That said, it’s important to recognize there is more than meets the eye here.

Ethereum’s dominance, while it cannot be understated, is in large part historical. The first stablecoins like USDT, USDC, and DAI were on Ethereum because there were simply no other blockchain rails to issue and grow programmable digital dollars on. As liquidity deepened on Ethereum, it created a durable moat that persists today.

But the nuances start to emerge when considering specific use-cases: how stablecoins are actually being used on their respective chains.

For instance, if we observe data for purely peer-to-peer transactional volume, which we can map to payments, it’s clear that Tron has steadily grown and become the people’s choice. This doesn’t come as a surprise to anyone who’s actually used the two chains; transactions on Tron are simply cheaper and faster. They are more accessible for everyday users. The numbers account reflect this point.

In short, the stablecoin landscape is broad and expanding, but still heavily concentrated in specific stablecoins on specific chains. At a glance it may seem the winners and losers are already set. Yet the challenges and pain points of today’s infrastructure suggests otherwise.

Current Challenges and Pain Points

Despite their scale and adoption, today’s stablecoin rails weren’t designed to serve a global-scale payments network beyond crypto-native rails. In particular, today’s stablecoin infrastructure falls short in three key areas: large-scale performance, practical user experience, and integrated infrastructure for fiat rails.

Performance At Scale

The standard for chain performance and network capacity has come a long way since Ethereum’s L1 gas wars. Fees for stablecoin transfers, which could cost tens of dollars during peak network congestion on the L1, have dramatically fallen, and stabilized. Even so, most public blockchains still lag legacy payment networks in scalability and uptime. Ethereum and its L2s have roughly average 244 daily TPS. Solana regularly handles upwards of 2-3K daily TPS, and previously peaked around 4.8K (though it is always important to point out the nuance between vote and non-vote transactions). Yet global payment networks are designed to support tens of thousands of TPS, and can’t afford downtime even under peak congestion.

There are lots of promising developments ahead to improve this. Between the rise of app-specific perp DEX chains, Firedancer and Alpenglow coming to Solana, the performance that Monad and MegaEth are expected to deliver, the rise of SVM L2s. Yet none of these are stablecoin-specific. Stablecoin transfers on these chains still compete for more blockspace across swaps, perps, and everything else users can do on those chains as network activity and adoption scales.

User Experience

Even though transactions settle much quicker onchain than through banks, the user experience is still clunky. The Boston Consulting Group’s 2025 stablecoin report identifies “gas-token management for transaction fees” and fragmented liquidity as critical technical obstacles that both retail and enterprise users face when using stablecoins for payments.

The most obvious, low hanging fruit is gas-token friction: someone receiving USDC on Ethereum or SOL on Solana inherently needs ETH or SOL just to move or spend their funds. Onboarding for net new users is still impractical.

Liquidity is another challenge. Stablecoin supply is currently fragmented across hundreds of chains, which makes it harder to move large amounts or guarantee immediate conversion back to fiat outside of Ethereum. This fragmentation also dilutes network effects, forcing users and institutions to navigate bridges, gas tokens, and liquidity sources rather than relying on a single liquid, unified market.

Privacy, too, is lacking on today’s stablecoin infrastructure. Public blockchains expose transaction details by default. While privacy-preserving apps exist, users have to go out of their way to find and use them. There is no integrated “toggle” to enable private transactions. This means everyday payments with stablecoins are far more transparent than they would be with cash or even traditional banking. To the individual consumer, this may just feel invasive. To enterprises and financial institutions, it’s a non-starter.

The onchain user experience has improved significantly, but still leaves room for improvement.

Lack Of Integrated Infrastructure

One of the underappreciated challenges with today’s stablecoin rails is the lack of integrated infrastructure, particularly to fiat rails. Sending a friend USDT is not the same as them being able to spend it at a grocery store. In practice, users still face FX spreads, hidden rakes, and compliance bottlenecks when they try to move between blockchain rails and local payment systems.

Off-ramping involves using centralized exchanges or other intermediaries that require users to create accounts with them, often KYC’d, and pay service fees. This only gets hairier with cross-border transactions, which often introduce more intermediaries and FX Spreads that further eat into the transferred amount.

Until stablecoins integrate seamlessly into fiat rails, they’re great for moving value across crypto, but remain largely impractical for mainstream global payments.

So Where Do Go From Here?

Stablecoins have crossed the chasm. They are no longer a niche by-product of crypto markets. They’re clearing trillions in volume annually, sometimes even monthly, and already powering crypto trading, DeFi, and peer-to-peer markets across emerging economies.

But that level of adoption, as meaningful as it is, remains a different bar than what is required to serve as the backbone for global financial rails. Settlement systems like VisaNet, SWIFT, and ACH operate under far stricter demands: near-instant finality, reliability, and uniform compliance frameworks across varying jurisdictions. Stablecoins already move big numbers, but the chains they run on were never designed to consistently meet these standards at global scale.

One solution is to wait for general-purpose chains to evolve and harden into payments-grade infrastructure. Another is to embrace purpose-built stablecoin infrastructure.

Purpose-Built Stablecoin Infrastructure

Nearly every major industry where reliability, risk management, and performance are table stakes is built around specialized, purpose-built infrastructure.

Global payment networks like Visa and SWIFT are built with specific capabilities to securely move money globally, running in isolated environments optimized for data integrity, regulatory compliance, and uptime. In cloud computing, financial institutions and research centers don’t use AWS or Google Cloud, they still depend on purpose-built setups built to handle petabytes of physics data. In finance, high-frequency trading firms colocate servers next to exchange matching engines because general-purpose infrastructure cannot deliver the latency or reliability needed in markets where every millisecond counts. LLMs trained on sector-specific data in healthcare, insurance, or finance consistently deliver higher accuracy, lower error rates, and stronger regulatory alignment than their general-purpose counterparts.

It’s no different in the world of cryptography. The standards that were critical to the expansion of the internet - RSA for secure communication, SSL for browser authentication, and ECDSA for digital transactions - were purpose-built with singular missions: to secure and authenticate data between counterparties online.

Stablecoins are now at that inflection point.

Applying The App-Chain Thesis

Blockchains follow the same logic. As apps gain traction and activity scales, the limits of general-purpose chains emerge. Unpredictable gas fees, throughput ceilings. Compliance gaps. The list goes on. In response, applications are increasingly motivated to launch their own chains.

We’ve already seen this play out: decentralized exchanges like Osmosis, dYdX and most recently Unichain; gaming and NFT platforms like Immutable; data networks like Pyth; have all adopted some version of the app-chain model. The thesis originates from Cosmos, which argued that applications should own sovereign blockspace, optimized for their needs, while still interoperating with a broader ecosystem.

When a chain is purpose-built, it can deliver deterministic performance and predictable pricing, unconstrained by unrelated blockspace demand. It can embed compliance routines, disclosures, and risk management tailored to regulated products. It can align economic incentives, governance, and value capture directly with the needs of its user base and community.

App-specific infrastructure allows chains to move beyond one-size-fits-all environments for more customization, stronger performance, and better UX. Given the trajectory of stablecoin adoption, we believe it is only a matter of time before stablecoins require the same purpose-built infrastructure. One of the first teams building directly towards this vision is Plasma.

Plasma: A Blockchain Purpose-Built for Stablecoins

Plasma is a new L1 purpose-built for the movement of stablecoins. It combines a custom consensus protocol, an EVM-compatible execution layer, and specialized smart contracts to support high-performance at scale, while posting state roots to Bitcoin through a native Bitcoin bridge for security guarantees.

Plasma’s mission is simple: to transform the way money moves around the world with specialized stablecoin infrastructure. Just as TCP/IP enabled the internet to become a global information hub, Plasma aims to empower stablecoins to become the global payments hub.

Plasma aims to address the pain points of today’s infrastructure - performance, user experience, and integrations- through its core features:

• Day-One Liquidity: Plasma launches with native USDT and $2B in day-one stablecoin liquidity.

• Zero-Fee USDT Transfers: Direct USDT transfers are free through Plasma’s frontend. Gas is subsidized through an in-protocol Paymasters contract, using authorization-based transfers controls for rate-limiting and preventing abuse.

• Custom Gas: Users and apps on Plasma can pay gas fees using whitelisted tokens. At launch, Plasma will enable gas fees in native USDT and pBTC.

• Specialized Architecture: Plasma is built on a modular architecture, combining a custom high-performance consensus protocol and an EVM-compatible execution environment.

• Bitcoin Security: Plasma anchors its state roots to Bitcoin through a trust-minimized bridge for direct BTC-EVM programmability. This bridge also supports native BTC deposits, which are converted to pBTC on Plasma.

• Integrated Infrastructure: At launch, Plasma will support over 100 DeFi apps, including leading protocols like Aave, Ethena, Fluid, and Euler among others, as well as various physical peer-to-peer cash networks. Beyond this, Plasma will support a wide ecosystem of developer tooling and infrastructure across account abstraction, onchain analytics and block explorers, interoperability protocols, oracles, indexers, and RPC providers.

To better understand how Plasma actually delivers these features, it’s worth diving deeper into their core architecture.

System Architecture

Fundamentally, Plasma is a Bitcoin sidechain that maintains its own consensus and posts state proofs to Bitcoin. It is built on a modular, multi-layered architecture combining a custom BFT consensus protocol (PlasmaBFT), a Reth-based EVM-compatible execution environment, a trust-minimized Bitcoin bridge, and protocol-native stablecoin smart contracts.

A transaction on Plasma begins at the user layer, through a supported frontend. It is broadcast to the Plasma chain via RPC. From there it passes through consensus, and once 2/3 PlasmaBFT validators have validated it, the user’s transaction is executed. Plasma then periodically posts state roots to Bitcoin through its native bridge.

Let’s examine these core components up closer.

PlasmaBFT

Consensus is at the very core of onchain systems. It is the coordination mechanism that separates blockchains from banks and fintechs: instead of a single authority, a decentralized distributed network of nodes must validate incoming transactions. This design mechanism, however, introduces latency especially as the network scales and adds more validators, and comes at the cost of performance for many chains today.

To overcome latency bottlenecks, Plasma introduces PlasmaBFT, a custom consensus protocol designed to support high throughput. PlasmaBFT is a pipelined implementation of the Fast HotStuff protocol, written in Rust. Finality is deterministic, and is achieved within seconds.

As its name suggests, PlasmaBFT follows classic Byzantine Fault Tolerance (BFT) assumptions. In practice, this means the network remains secure as long as no more than one-third of validators are malicious (this can be reflected as n ≥ 3f + 1, where n is total nodes and f is Byzantine nodes specifically).

To participate, validators must stake XPL and run supported hardware (2 CPU cores, 4 GB RAM, SSD-based persistent storage). They are then selected to propose and validate blocks on Plasma based on an XPL stake-weighted voting process.

The protocol finalizes blocks through a two-chain commit process. Validators vote on block proposals, and once two consecutive quorum certificates (QCs) are formed, the block is finalized. QCs are aggregated validator attestations; chaining them together enforces a single canonical history.

PlasmaBFT is optimized to support high-performance on the L1. This is made possible with Plasma’s use of pipelining: while one block is being finalized, the next can already be proposed. As such, blocks can be finalized after just two rounds.

This design is derived from Fast HotStuff, a modern BFT protocol designed for, unsurprisingly, being fast. HotStuff introduced a leader-based structure and QC chaining to reduce communication overhead. Fast HotStuff further optimized [chain commit paths for lower latency and higher throughput].

Like HotStuff, PlasmaBFT uses a leader-based round structure, designed to minimize communication overhead while still maintaining fault tolerance. Leaders propose blocks, validators vote, and once enough votes are collected, a QC is generated. If a leader fails or goes offline, the protocol shifts to a new leader using aggregated QCs.

Plasma plans to expand validator participation in several stages. Initially, the biggest priority will be ensuring baseline network stability, therefore Plasma will be secured by a whitelisted set of validators at launch. Over time, the validator set will grow to stress-test performance under larger committees until the final stage, in which participation opens up to the public.

Plasma’s Execution Environment

Virtual Machines (VMs) process transactions, run smart contracts, and keep state in sync across all participants on its underlying chain. A VM reads the current state of the chain, executes new inputs, and then updates state deterministically. It ensures the same code always produces the same result and state is synchronized across all nodes.

Plasma employs a general-purpose Ethereum Virtual Machine (EVM) execution environment. This means developers can deploy existing EVM smart contracts and use familiar tooling and infrastructure.

Plasma’s execution engine is Reth, a modular Rust-based Ethereum client that separates consensus from execution. This enables more efficient updates, clearer boundaries between block production and execution, and better predictability in performance and behavior.

When transactions are submitted on Plasma, Plasma’s execution environment processes them through the EVM, ensuring the relevant smart contracts run and state is updated consistently across all Plasma nodes.

Bitcoin-Level Security

Blockchains normally secure themselves only through their own validator sets. That security is limited by the size of the validator pool and the economic weight behind it. For stablecoins, where large values may be at stake, relying solely on a new or relatively small validator set can be a risk.

To mitigate this, Plasma periodically posts its state roots to Bitcoin. Anchoring to Bitcoin provides an additional settlement guarantee: once a Plasma state is recorded on Bitcoin, altering it would require rewriting Bitcoin’s history. This makes censorship or rollback far less feasible and gives Plasma a stronger security baseline than relying on its validator set alone.

Plasma achieves this through a Bitcoin-native bridge. The bridge consists of a verifier network, each running full Bitcoin nodes to observe deposits and validate state anchoring. Periodically, state roots from Plasma are committed to Bitcoin via transactions (e.g. OP_RETURN), and the verifier network attests that these anchors match Plasma’s canonical chain.

Beyond settlement, the bridge also enables native BTC to flow into Plasma. Users deposit BTC to a designated address, verifiers confirm the transaction on Bitcoin, and Plasma mints pBTC: a fungible ERC-20 token backed 1:1 by BTC. Withdrawals follow the reverse process: users burn pBTC on Plasma, and once verifiers confirm, BTC is released on the base chain.

This bridge makes native BTC usable inside Plasma smart contracts. pBTC is issued as a standard ERC-20, built on LayerZero’s OFT standard to allow cross-chain portability without compromising verifiability against the Bitcoin base layer itself. Users always receive pBTC on Plasma at a 1:1 rate against BTC deposited.

To secure withdrawals, Plasma relies on Multi-Party Computation (MPC). Rather than one party holding a private key, multiple verifiers collectively generate signatures, with no single entity able to unilaterally release funds.

Stablecoin-Native Smart Contracts

On current stablecoin rails, stablecoins exist as generic ERC-20 tokens. They are applications built on top of a base chain. This design works to an extent but friction still emerges: transaction fees paid in separate gas tokens. Every app or wallet has to operate and maintain its own custom Paymaster. Private payments are not feasible.

On Plasma, this functionality is built directly into the protocol. A set of in-protocol contracts, written in Solidity and integrated into the execution layer, give stablecoins first-class treatment. These contracts are written in Solidity, integrated into Plasma’s execution layer, and are compatible with any EVM wallet or contract system, including AA standards like EIP-4337 and EIP-7702.

Plasma is launching with two core modules. The first is the Protocol-Managed Paymaster for Zero-Fee USDT Transfers. This contract sponsors gas costs for direct USDT transfers: transfer() and transferFrom(), so users can send stablecoins without needing XPL. The scope is narrow by design: it applies only to the official USDT and only to direct peer-to-peer transfers, not arbitrary contract calls. To prevent abuse, eligibility is gated through lightweight identity checks such as zkEmail, zkPhone, or captcha systems, and usage is subject to rate limits. The economics are covered by a pre-funded XPL pool managed by the foundation, which pays gas on behalf of users. Developers don’t need custom integrations beyond routing transfers through standard smart account flows, and the system supports both EOAs and smart contract wallets. Over time, Plasma is exploring features like reserved blockspace for eligible USDT transfers, ensuring inclusion even under network congestion

The second module is the ERC-20 Paymaster for Custom Gas Tokens. This contract allows users to pay for any transaction, not just transfers, using whitelisted tokens (this will be USDT and pBTC initially). The process is simple: the user approves the paymaster to spend the chosen token, the paymaster consults oracles to calculate how much of that token equals the required gas, and then pays the validator in XPL under the hood while deducting the equivalent amount from the user. This removes the need for swaps or native token balances, smoothing the onboarding process for new users. Developers benefit because the paymaster is handled at protocol level, so they don’t have to build or maintain their own fee abstraction systems. Wallets only need to surface approvals and error handling, while users see a unified and intuitive UX.

By running these modules at the protocol level instead of leaving them to individual apps, Plasma ensures consistent behavior across apps, enables subsidized gas without external funding tokens, and ties these features directly into block production and execution.

XPL And Plasma’s Economics

At the core of Plasma’s business model is its native token, XPL, which secures the network and subsidizes PlasmaBFT validators.

Every transaction on Plasma requires a base fee, with dynamic demand-based fees. These fees, along with newly issued tokens, form the reward pool that sustains validator incentives.

Plasma takes a unique approach to slashing. Rather than punishing malicious validators, it incentivizes honest behavior through a novel reward slashing mechanism. In this model, validators who misbehave or fail to participate lose their block rewards but keep their principal stake. The penalty is lighter, but it makes participation less risky for institutional operators, where sudden capital loss is often commercially unacceptable. Importantly, Byzantine safety is still preserved under the standard assumption that fewer than one-third of validators act maliciously.

Validators are compensated in XPL for proposing blocks, voting in consensus, and validating transactions. Their rewards come from a mix of transaction fees and token emissions, making validator incentives directly tied to both network activity and the broader economics of XPL.

The Plasma Ecosystem

Surrounding Plasma’s technical work is a growing, integrated ecosystem. Plasma is launching with $2B in stablecoin liquidity and over 100 DeFi integrations, including names like Aave, Ethena, Fluid, and Euler.

Plasma recently announced Plasma One, its main consumer-facing app. It functions as a stablecoin-native wallet and card interface, giving users “one” place to hold, send, and spend USDT. Transfers are gasless, balances can be used directly for payments, and onboarding is quick enough to issue a virtual card in minutes.

On the integration side, Plasma has partnered with Binance Earn, allowing users to access yield products directly from the network. Work is also underway on fiat on/off-ramps and peer-to-peer cash networks in emerging markets, aiming to make the jump between stablecoins and local currency less dependent on centralized exchanges.

Plasma will also launch with a wide ecosystem of developer tooling and infrastructure across account abstraction, onchain analytics and block explorers, interoperability protocols, oracles, indexers, and RPC providers.

The Outlook For Plasma

Given what we now know about Plasma, it’s worth zooming out and reflecting on some of the most important catalysts and considerations impacting how the path forward unfolds from here.

Competitive Landscape

Plasma has an ambitious and important mission: to transform how money moves across the globe. Unsurprisingly, they face competition from several angles.

First, general-purpose blockchains aren’t going anywhere. Ethereum still dominates in stablecoin liquidity and network effects. Tron commands the largest share of USDT transfers and peer-to-peer transaction volume, and Solana is constantly working on developments to improve performance. Meanwhile, new chains like Monad and MegaETH are also competing on the basis of high-performance and full EVM compatibility.

At the same time, we’re seeing the rise of stablecoin-specific chains, or “stablechains”, similar to Plasma. Circle is building Arc, a permissioned chain designed for regulated USDC settlement. Stripe is working on Tempo, focused on embedding stablecoins into merchant payments. Google recently announced Google Cloud Universal Ledger (GCUL), an L1 focused on digital payments and tokenization for financial institutions. Meanwhile others stand out with differentiated approaches and unique value propositions. For instance, Payy also introduces neobanking stablecoin infrastructure, including its own purpose-built chain, but with a core focus on privacy-preserving transfers.

Even outside of crypto, non-blockchain payment rails are already converging to offer much of the same key benefits stablecoins do. That means Plasma not only has to match crypto benchmarks, but also these legacy standards of performance, speed, and reach.

Key Areas of Focus

With that in mind, what are key areas of focus that would help the Plasma team?

For starters, distribution is everything. Like any business, a chain can’t grow without getting its product into the hands of users. For blockchains, this has been mostly limited to crypto-native apps, exchanges, connected chains, and DeFi protocols. Though Plasma launches with over 100 integrations and $2B in liquidity, the harder challenge is pushing beyond crypto-native adoption into retail and enterprise crypto-adjacent use. Plasma is set to support 100+ countries, 100+ currencies, and 200+ payment methods, laying the groundwork for a strong initial distribution footprint. Long-term, though, sustaining real-world adoption will require constant effort: onboarding merchants, working with fintech partners, and leveraging Tether/Bitfinex’s existing networks. Tron’s rise shows how powerful grassroots distribution can be. The question is whether Plasma can retain users and build durable channels beyond its crypto-native base.

Liquidity is another area of focus. For a chain purpose-built around stablecoins, deep liquidity is simply existential. Plasma is launching with billions in native USDT issuance, making it the 8th largest USDT chain on day one. To ensure it can sustain future growth, bridges, ramps, and deposit flows have to be simple and as friction-free as possible.

Privacy is another underrated piece. Confidential Payments are planned but won’t ship with Plasma’s mainnet beta launch. The core idea being explored is to shield sensitive transfer data while remaining composable and auditable. This feature would be implemented as a lightweight, opt-in module at first, though Plasma could very well look to enshrine privacy features at the protocol layer in the future.

With its novel architecture, ecosystem reach, and liquidity base Plasma is in a good position:

• Anchoring to Bitcoin provides a differentiator. Plasma periodically posts its state roots to Bitcoin, giving extra settlement guarantees beyond relying solely on its validator set.

• Additionally, building as a public permissionless chain lets Plasma reach a broader audience, while being able to enforce features like identity-based transfers for specialized experiences like zero-fee USDT transfers.

• Using a custom consensus protocol enables Plasma to support fast execution at a high-throughput rate.

• Launching with over 100 DeFi integrations and $2B in USDT makes it the 8th largest chain by stablecoin supply from day one.

Applications and Use Cases

Plasma provides rails to support a variety of stablecoin-specific use cases and applications.

Global Payments and Remittances

One of the most immediate applications is as a global payment rail. A worker in the U.S. could send $100 in USDT to a relative in Nigeria. The relative could then spend directly through integrated merchants, use directly through crypto cards, or cash out via local OTC desks and exchanges.

In countries such as Nigeria, Argentina, and Turkey, where stablecoins already act as a hedge against inflation and a remittance lifeline, Plasma can reduce friction even further. Success here depends on integrations with local wallets, ATMs, and payment systems. Tron achieved this over years of grass-roots outreach, so Plasma will need similar partnerships, possibly leveraging Tether’s existing networks. If executed well, Plasma could serve as the backend for remittance firms or neo-banks, offering instant dollar transfers without requiring their own blockchain infrastructure.

Merchant Payments and Micropayments

Paying with crypto has been rare due to volatility and fees, but zero fee USDT transfers on Plasma could change that. Merchants could accept stablecoins at the point of sale via QR codes, avoiding credit card fees and chargebacks.

Privacy features would let businesses shield revenue data from competitors, while micropayments become practical. Platforms could charge a few cents per article, stream, or download without fees eroding margins. For merchants, the key will be user-friendly tools and regulatory compliance. Stablecoin payment processors may emerge on Plasma, and over time, even traditional providers could integrate it in high-fee or underbanked regions.

Forex and Cross-Currency Transactions

The stablecoin market extends beyond the U.S. dollar, with Euro, offshore yuan, and gold-backed tokens already in circulation. Plasma could become a hub for on-chain foreign exchange if multiple fiat stablecoins are supported.

A user could, for instance, swap USDT for EURT on a Plasma-based DEX at near-zero cost. This enables cheaper, faster forex trades compared to banks. Imagine a multinational paying European suppliers by converting millions of USD into EUR instantly and settling the transaction on-chain. Deep liquidity will be needed, but zero fees and institutional demand could draw in market makers.

DeFi with Stablecoins and BTC

Plasma’s EVM compatibility opens the door to decentralized finance focused on stablecoins and Bitcoin. Potential applications include:

• Stablecoin DEXes and AMMs: Low-cost, high-volume trading of stablecoin pairs (USDT/USDC, USDT/EURT) or stablecoin/BTC pairs.

• Money Markets and Lending: Platforms could let users lend or borrow USDT against BTC collateral.

• BTC-DeFi Innovations: Bitcoin-backed stablecoins minted on Plasma without custodians.

Institutional Treasury and Settlement

Institutions such as exchanges, fintechs, or even banks could use Plasma as a settlement layer for large transfers. Exchanges may prefer Plasma over Tron or Ethereum for inter-exchange USDT flows, thanks to its speed and zero fees.

Banks or corporate consortiums could also run private overlays on Plasma, settling large interbank transfers with Bitcoin-backed finality. For corporate treasuries, moving $50 million between subsidiaries could take seconds instead of days with SWIFT. Privacy modules would allow selective disclosure for auditors or regulators. If U.S. legislation like the GENIUS Act advances, regulated institutions may adopt public stablecoins like USDT and USDC, with Plasma positioned to capture that demand.

Beyond these, there are more crypto-native use cases that would be interesting to see teams explore building on Plasma. Zero-fee USDT transfers could make a really compelling case to build infrastructure for autonomous agent payments on Plasma. With $2B deployed from day one, Plasma could provide deep stablecoin liquidity prediction markets need to sustain meaningful user activity. Plasma could also serve as a routing layer for stablecoin liquidity across multiple chains.

Closing Thoughts

Plasma’s mainnet beta is now live. We’re excited to see how purpose-built stablecoin infrastructure unfolds from here on out. Stablecoins are set to disrupt global payments and the rest of the financial services stack, but they need dedicated, purpose-built rails to flourish. Though Plasma is not the only one pursuing this north star, it offers one of the most promising solutions to capture the trillion dollar stablecoin opportunity..

Sources

1. Plasma Docs docs.plasma.to

2. XPL MICA Whitepaper https://drive.google.com/file/d/1kw2CfXp0SLPGkitm6v814vmTtWOQTYBw/view

3. Artemis Analytics https://app.artemisanalytics.com/stablecoins

4. DeFi Llama

   https://defillama.com/

5. Stablewatch stablewatch.io

6. U.S. Department of the Treasury. (2025). Major Foreign Holders of Treasury Securities. TIC Data, Treasury.gov.

7. Chainalysis. (2024). The Geography of Cryptocurrency Report. Chainalysis. https://www.chainalysis.com

8. Chainalysis. (2025). Sub-Saharan Africa Crypto Adoption. Chainalysis Blog. https://www.chainalysis.com/blog/subsaharan-africa-crypto-adoption-2025/

9. Tether. (2021) Tether Whitepaper https://assets.ctfassets.net/vyse88cgwfbl/5UWgHMvz071t2Cq5yTw5vi/c9798ea8db99311bf90ebe0810938b01/TetherWhitePaper.pdf Tether whitepaper

10. Mastercoin (2013) Mastercoin Whitepaper https://drive.google.com/file/d/16t_trC9bP1fkxWImFuQUj96fgjw5JVjL/view

11. Tether. (2025). Tether Reserve Report (June 2025). ISAE 3000R Audit Opinion. https://assets.ctfassets.net/vyse88cgwfbl/2SGAAXnsb1wKByIzkhcbSx/9efa4682b3cd4c62d87a4c88ee729693/ISAE_3000R_-_Opinion_Tether_International_Financial_Figure_RC187322025BD0201.pdf

12. Maven11. (2025). The Application Specific Chain Thesis. Maven11. https://www.maven11.com/publication/the-application-specific-chain-thesis

13. Artemis Analytics, Castle Island Ventures, & Dragonfly. (2025). Stablecoin Payments from the Ground Up. Artemis Reports. https://reports.artemisanalytics.com/stablecoins/artemis-stablecoin-payments-from-the-ground-up-2025.pdf

14. World Bank. Remittance Prices Worldwide. World Bank. https://remittanceprices.worldbank.org/

15. International Monetary Fund. (2025). [Working Paper]. IMF eLibrary. https://www.elibrary.imf.org/view/journals/001/2025/141/001.2025.issue-141-en.xml?cid=568260-com-dsp-crossref

16. Boston Consulting Group. (2025). Stablecoins: Five Killer Tests to Gauge Their Potential. BCG. https://media-publications.bcg.com/Stablecoins-five-killer-tests-to-gauge-their-potential.pdf

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. This post has been created in collaboration with the Plasma team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research

Decentralized AI is beginning to cross the chasm. The United Nations Development Programme (UNDP) has long advocated for the sustainable use of AI to empower developing nations and underserved communities as part of achieving its Sustainable Development Goals (SDG). Earlier this week, the UNDP selected FLock - a decentralized AI network - as its strategic AI partner. Why does this all matter, and how does FLock’s decentralized approach address challenges that centralized AI cannot?

AI Is Inevitable

The role of AI continues to grow in our day to day lives. Millions of people are using AI-powered applications like ChatGPT. Enterprises are pouring hundreds billions into developing the infrastructure, training, and integration of AI in their workflows. Governments are actively implementing AI solutions for public operational efficiency with AI.

This is all for good reason: AI stands to unlock a new level of productivity gains not yet seen. It’s already leading to groundbreaking applications across various fields of scientific research. People are automating busy work, leading to more creative initiatives and experiments. A new generation of goods and services is actively being transformed from natural language into existence, what has come to be known as “vibe-coding”. McKinsey projects $4.4 trillion in productivity gains from AI adoption, while Goldman Sachs forecasts up to 7% increase in global GDP by 2030.

There is a caveat though: the AI models we know and use today are black boxes: closed-source LLMs developed and maintained by central, for-profit entities. These entities control how the AI models are developed and trained, and determine the terms and means by which they can be accessed and used. At a glance, these are resourceful, legally compliant companies with a strong economic incentive to keep improving these AI models and listening to their customers’ feedback and requirements. What exactly then is the concern?

Why Not Just Use Centralized AI?

People have been waking up to the dangerous realities of social media algorithms, realizing the extent to which these black boxes maintained by for-profit entities are impacting the way they think and behave. The implications with AI are significantly greater.

Binji’s AI therapist tweet offers a more facetious example to reason about, but it speaks to the concerning implications of speaking to black boxes which operate in an unknown manner behind the scenes. But a shift away from centralized AI is not about realizing utopian cypherpunk ideals: there are legitimate concerns and risks at the individual, enterprise, and national levels:

• Single point of failure: Centralized AI introduces a single point of failure for its users. First, this poses an operational risk, if these facilities go offline due to outages, attacks, or natural disasters. This is not uncommon. Second, there are substantial security concerns, including the risk of leaked user prompts, chat histories, and sensitive data with single-failure points. Such breaches at AI companies could expose everyday user information and become national security liabilities when government or sensitive data is involved.

• Data Protection: Centralized AI apps need to store and maintain user data to improve models and provide personalized experiences. Users are providing LLMs with all kinds of data about themselves, including sensitive and personal information. The concern here is twofold: that data is at risk of being breached. Additionally, the risk is that AI companies monetize user data the same way social media and internet companies have historically monetized their users.

• Value Plurality and Model Output Bias: Model outputs are at risk of bias towards a single entity’s values and perspectives. The Google Gemini incident controversy, though a mostly isolated example, highlighted the potential risks of models providing misinformation to its users.

• Scalability: Processing power limited to a single entity creates potential bottlenecks over time. Network delays, capacity constraints, and overprovisioning challenges can arise as usage scales, and the entire network runs on the assumption that the centralized AI provider alone has enough processing power and capacity to handle it all.

Beyond this, innovation is simply stifled if a limited number of people or entities can experiment and develop new models. Most of the internet’s infrastructure runs on Linux, an open-source operating system that empowers developers worldwide to innovate and adapt freely. Wikipedia, a freely editable and collaboratively maintained knowledge base, serves as a gateway to information for billions of people globally. In the world of computing and software, open source technology movements have repeatedly shown that collaborative development can produce superior, more resilient solutions than closed-source alternatives.

The UNDP: Using AI As A Transformative Force For Good

AI is technology powerful enough to change the world for good. What may be mere quality-of-life improvements in one country can be transformation 0:1 improvements in others. et centralized AI inherently conflicts with its potential as a public good.

Developed in 1965, the UNDP was formed to help eradicate poverty and reduce inequalities worldwide through sustainable development. For years now, The UNDP has been advocating for embracing AI as a transformative force for good. Specifically, the UNDP believes that AI can help accelerate its mission.

The key challenges they are concerned with include:

• Digital public infrastructure: Developing nations may not be able to afford to build Google/OpenAI-scale systems. At the same time, they do not want to be dependent on AI developed by other nations like the US or China.

• Nation-specific needs: Nations need AI solutions tailored to their specific needs and scale, not settle for cookie-cutter general purpose solutions.

• Data sovereignty: Nations need to protect their citizens’ data, especially across healthcare, agriculture, and other sensitive and personal data.

Just earlier this week, the UNDP announced a new strategic AI partner. It wasn’t OpenAI, Anthropic, or Google, but a new decentralized alternative: FLock.

Introducing FLock

FLock, short for Federated machine learning on blockchain, is a decentralized AI network. Instead of a single entity, it enables anyone around the world to contribute models, data, and computing resources and participate in an open, collaborative environment for decentralized AI training. To do this, FLock combines conventional and Federated Learning AI model training with automated blockchain-based reward distribution.

Altogether, this creates an open marketplace of app-specific models which are community owned, built, and led.

How It All Works

To better understand FLock’s approach, it helps to first understand Federated Learning.

Federated Learning, or federated Machine Learning, is a collaborative machine learning technique where multiple participating clients can collaboratively train a global model without exposing any raw data. This approach is designed to improve output quality by enabling AI models to be trained on wider and more diverse data sources, while protecting the privacy of participants’ data.

Federated learning typically involves a central hub server on which the global model lives and is redistributed for local training. Participating clients then train the global model using their local data and only exchange their gradients, the weights and parameters used in their local training, back to the hub server. The hub server then aggregates these gradients to update the global model, and the process is repeated until the training is complete.

Federated learning has proven to be an effective solution to addressing user privacy within AI training, there is a catch with this set up, though. To start, the central hub server, on which the global model lives, is still a single point of failure. Should it stop working for whatever reason, the whole learning stops. Additionally, federated learning still assumes the data clients provide is honest. In other words, it doesn’t address the risk of data poisoning, a technique in which clients provide inauthentic data targeted at diminishing the quality of a model’s training and therefore its output. This is becoming a growing area of concern as more of today’s world becomes reliant on AI models, especially in fields like healthcare.

FLock aims to address these problems by implementing cryptographic proof and economic incentives enforced onchain. So how exactly does that work?

FLock System Architecture

FLock consists of three interconnected systems that form its decentralized AI ecosystem:

• The AI Arena: A decentralized training platform where developers submit models that compete on public datasets. These models are evaluated by a distributed network of validators, with an important feature: validators cannot identify which model came from which trainer, preventing collusion. High-performing models earn rewards while underperforming ones can be refined and resubmitted. This competitive process produces models optimized for real-world performance, with participation requiring token stakes to ensure accountability.

• The FL Alliance: FLock’s Federated Learning client that enables training on sensitive private data without exposing it. The system randomly assigns participants as either proposers (who train models locally) or voters (who evaluate results). When a majority of voters approve a model update, proposers receive rewards. Those who submit corrupted data or false validations lose their stake.

• The AI Marketplace: Successful models from Arena and Alliance are deployed in the Marketplace for production use, with version control, performance monitoring, and automated updates. Model hosts provide infrastructure and set pricing, while users pay for API access beyond free tier limits. Higher-quality models attract more users, generating revenue for creators and hosts - creating market incentives for continuous improvement.

Altogether, models begin in the Arena with public data training, undergo refinement in the Alliance with private data, then reach production in the Marketplace. Usage data feeds back to improve subsequent training cycles. The key innovation lies in how FLock applies onchain mechanisms to coordinate incentives among network participants.

The Onchain Layer

FLock’s key innovation is using blockchain to solve the lack of coordination among participants in federated learning. FLOCK, a token that lives on the Base L2, serves as the key mechanism that aligns incentives across the network.

Proof of Stake

FLock implements a robust incentive mechanism to incentivize honest behavior (and penalize malicious behavior at that) among its federated learning participants. This mechanism, based on a research paper published by the FLock team, utilizes a proof-of-stake system in which participants stake FLOCK tokens to participate. Malicious behavior, i.e. data poisoning, risks real economic value, while honest contributions earn rewards. Rewards are distributed in FLOCK, proportional to stake size and performance quality.

There are three ways to participate:

• Training node operators: stake tokens to compete in model training tasks.

• Validators: stake to evaluate and score submitted models

• Delegators: delegate stake to [training nodes], earn rewards accordingly.

Smart Contract Orchestration

FLock uses a set of smart contracts to orchestrate the training and validation process. When tasks are created, the smart contracts are responsible for:

• Selecting participants using stake-weighted randomness to prevent gaming

• Distributing rewards based on aggregated validation scores

• Slashing stakes of participants who submit poisoned data or false validations

• Managing reward distribution between operators and delegators

More on FLOCK

Live on the Base L2, the FLOCK token serves three functions within the ecosystem:

Utility: FLOCK is staked across different roles, with larger stakes increasing selection probability for training and validation tasks. Task creators can pay additional FLOCK as bounties to expedite their training processes. The system implements time-based multipliers: longer staking periods (up to 365 days) generate gmFLOCK (governance-weighted FLOCK), increasing influence and reward shares from network emissions.

Payment: Users access models trained in AI Arena and FL Alliance with rate limits based on stake amounts, paying in FLOCK for usage beyond these limits. Model hosts stake FLOCK to serve models and set custom pricing structures.

Governance: FLOCK holders participate in DAO governance, voting on task verification (determining which tasks qualify for rewards), parameter adjustments (reward distributions, slashing rates), and protocol upgrades.

Use Cases and Applications

FLock is already being actively deployed across numerous real-world applications where deep, app-specific contextual knowledge, strict privacy guarantees, and decentralization matters:

Specialized Blockchain Development: The Aptos Move LLM

FLock partnered with the Aptos Foundation to develop an LLM that outperforms ChatGPT-4o in generating Move-specific code, from simple "Hello World" scripts to complex programs like yield tokenization with AMM trading functionality. The model was trained specifically on community-contributed Move code datasets, taking advantage of FLock's decentralized training infrastructure.

Initial testing demonstrated superior performance compared to ChatGPT-4o, with greater accuracy and adherence to Aptos-specific requirements. The model, built on top of DeepSeek's foundation and available on Hugging Face, achieves ChatGPT-4-level performance specifically for Move programming.

Community-Specific AI Assistants

FLock enables tailored AI assistants that understand specific contexts:

• FarcasterGPT: Trained on Farcaster protocol data to understand its unique social dynamics, terminology, and user patterns

• ScrollGPT: Optimized for the Scroll L2 ecosystem, understanding its technical documentation, governance proposals, and developer patterns

• DAO-specific models: Custom assistants that understand individual DAOs' governance structures, historical decisions, and community norms

Privacy-Preserving Healthcare Applications

FLock enables healthcare providers to collaborate on diabetes prediction models using linear regression, where each participant retains control over their data while computing model updates locally. Multiple hospitals can train on their local patient records, contributing only mathematical gradients to improve the global model.

This approach is crucial for complying with stringent health data protection regulations such as HIPAA, as patient data never leaves the institution. By integrating data from diverse demographics and geographical locations without sharing raw data, FLock helps develop more accurate and generalized models that account for population variations.

Decentralized Compute Integration: FLock x Akash

FLock has integrated with Akash Network to create one-click deployment templates for running FLock validators and training nodes on decentralized compute infrastructure. This partnership exemplifies the composability of decentralized systems as users can now:

• Deploy FLock validators on Akash with minimal configuration

• Access GPU resources through Akash's marketplace

• Run training nodes using Docker containers with customizable hardware specifications

• Pay for compute using AKT tokens while earning FLOCK for validation

The integration includes pre-configured templates requiring only an API key and task ID, making decentralized AI training accessible to non-technical users.

Natural Language Database Access: Text2SQL

FLock's Text2SQL model enables users to query databases using natural language commands, simplifying SQL syntax. Developed through AI Arena's competitive training process, the model was trained on extensively cleaned and manually reviewed open-source datasets.

The Path Forward

AI represents the next foundational layer of human-computer interaction. However, the practical concerns around centralized AI are becoming harder and harder to ignore. Single points of failure could cripple nations. Data sovereignty violations could compromise millions. Innovation bottlenecks stand to largely favor incumbent interests.

At Shoal Research, we believe this layer must be built just like the internet was: as an open, collaborative effort rather than a corporate, centralized service. We’re excited to see this frontier push forward, and think FLock’s approach to combine Federated Learning with onchain incentive mechanisms and cryptography offers an innovative solution here. Being selected by the UNDP, FLock will mentor five pilot projects across climate finance, inclusive energy, and social protection, proving decentralized AI can address humanity's most complex challenges.

Time will tell how the outcome plays out, but FLock is well-positioned to thrive in a world that embraces AI as a public good and decentralized AI networks as the approach to get there.

References

1. United Nations Development Programme. (n.d.). Sustainable Development Goals. UNDP. https://www.undp.org/sustainable-development-goals

2. FLock. (n.d.). Documentation. FLock Docs. https://docs.flock.io/

3. FLock. (n.d.). Whitepaper. FLock. https://www.flock.io/whitepaper

4. FLock. (2022). FLock: Federated learning on blockchain. arXiv. https://arxiv.org/abs/2211.04344

5. FLock. (2024). Decentralized federated learning: Incentives and mechanisms. ACM Digital Library. https://dl.acm.org/doi/10.1145/3701716.3715484

6. FLock. (2024). Blockchain-enabled federated learning: Privacy and trust in decentralized AI. IEEE Xplore. https://ieeexplore.ieee.org/abstract/document/10471193

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author's own, not the views of their employer. This post has been created in collaboration with the FLock team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

Introduction

The Brazilian butt lift (“BBL”) has become a mainstream obsession. In perfect algorithmic, addictive brainrot fashion, I was watching a TikTok where the creator mentioned that BBLs are a form of transhumanism. The creator argued that individuals have a perceived self, which they embody through physical means, and by augmentation, someone can reach their desired “avatar.”

This creator’s offhand remark shows how readily people embrace technology-driven self-modification in everyday life. Such cultural anecdotes hint at a broader phenomenon: an emerging form of “over-the-counter” transhumanism. By over-the-counter, I mean enhancements that are accessible without specialized clinics or implanted devices, practically consumer-grade boosts to human abilities. Notably, these enhancements are increasingly cognitive rather than physical. Just as social media filters and cosmetic procedures allow “one-touch magic” to reshape our appearance, AI tools like ChatGPT offer on-demand augmentation of memory, creativity, and problem-solving.

We’ve been doing it for ages, from writing and printing to smartphones and search engines, each innovation profoundly changing not just how we live but even who we are. But ChatGPT’s arrival in late 2022 felt different in scale and immediacy. Suddenly, a powerful AI, capable of answering questions, writing code, brainstorming ideas, and more, was in the public’s hands. At this pace, the question is no longer whether sustained ChatGPT use makes us a little bit transhuman; it’s whether the tool is now so deeply embedded in that threshold that it verges on pseudo-cyborg technology.

Defining Transhumanism

To ground the discussion, let’s start with a clear definition of transhumanism. In simple terms, transhumanism is the concept of utilizing advanced technology to surpass the natural limitations of the human organism. Transhumanism is described as a movement that advocates using current or emerging tech such as genetic engineering, cryonics, AI, nanotech, etc. In other words, transhumanists want to transcend the normal human state through science and tech, eventually maybe even becoming “posthuman” beings with expanded capacities that an unenhanced human wouldn’t possess, thus enhancing human capabilities to improve the human well-being.

Modern theorists in the transhumanist school of thought offer complementary definitions. Philosopher Max More who helped formalize transhumanist thought in the 1990s, defined it as “a class of philosophies that seek to guide us towards a posthuman condition”. He emphasized that transhumanism shares humanism’s respect for reason and science but “differs from humanism in recognizing and anticipating the radical alterations in the nature and possibilities of our lives” resulting from advancing technologies. Along the same vein, former Oxford futurist Nick Bostrom explains that transhumanists see human nature as “a work-in-progress, a half-baked beginning”. We need not accept our current mental and physical limits as the endpoint of evolution. With “the responsible use of science, technology, and other rational means,” Bostrom says, transhumanists hope humans will “eventually manage to become posthuman, beings with vastly greater capacities than present human beings have”. Yet these ambitions have also drawn sharp criticism. Skeptics argue that the movement’s rhetoric can hide an elitist desire to engineer a “better” class of humans, stoking fears of selective biological enhancement and widening social divides.

In his 2004 Foreign Policy essay “Transhumanism,” Stanford political scientist and author Francis Fukuyama warns, “If we start transforming ourselves into something superior, what rights will these enhanced creatures claim, and what rights will they possess when compared to those left behind?”

In short, transhumanism is about deliberately using technology to overcome our biological limits, whether it longer lifespans, enhanced bodies, or sharper minds. For the fiction nerds, picture the Mentats in Dune, those human “living computers” trained to perform the feats once handled by banned thinking machines.

ChatGPT and the advent of chatbots

At first glance, a chatbot on your computer or phone might not sound as dramatic as cyborg implants or designer genes. After all, ChatGPT doesn’t physically change your physiology rather it’s “just” a very smart tool. Yet the threshold between general tool and a true transhumanist enhancement isn’t always clear-cut.

Transhumanism isn’t limited to physical upgrades. Enhancing cognitive abilities is equally central, and many prominent transhumanists actively pursue it. Just as we accept eyeglasses and prosthetic limbs as bodily augmentations, we can likewise regard an AI assistant as an augmentation for the mind. The key distinction is whether the tool merely offers convenience or if it genuinely expands what we can know or do as humans. A simple calculator, for example, is very useful but arguably just automates a narrow mental task. ChatGPT, by contrast, can generate new ideas, text, and solutions. Such cognitive interactions can converse, explain, and create in ways that feel like having a second brain on call. When a technology begins to so vastly amplify one’s intellectual output or understanding, it starts to cross into the transhumanist realm of qualitatively enhanced capability. ChatGPT, in essence, allows a person to tap into a vast web of knowledge and a reasoning engine adjacent to any individual’s mind. That is why some have described it as a form of cognitive enhancement available to the masses, an “over-the-counter” cognitive boost that doesn’t require a PhD or a billionaire budget to use.
With the right user-driven guardrails in place such as prompt engineering, ChatGPT pushes beyond the ordinary tool threshold of transhumanism and emerges more as a cognitive steroid.

The Extended Mind

Long before AI chatbots, philosophers were already arguing that tools can become literal extensions of our minds. In a famous 1998 paper titled “The Extended Mind,” Andy Clark and David Chalmers proposed that objects like notebooks or computers, when used in the right way, are as much a part of one’s cognitive process as the neurons in one’s brain. They portray this with the case of Otto, an Alzheimer’s patient who relies on a notebook to remember important information. Otto is benchmarked against Inga, who uses her biological memory. When Inga wants to go to a museum, she recalls the address from memory. When Otto wants to do the same, he looks it up in his notebook. Clark and Chalmers argue that the notebook is a constant, trusted resource for Otto, serving the same role memory serves for Inga, and thus can be considered part of Otto's mind. As they put it, "the notebook plays for Otto the same role that memory plays for Inga. The information in the notebook functions just like the information constituting an ordinary belief; it just happens that this information lies beyond the skin".

In Otto’s case, consulting his notebook isn’t fundamentally different from Inga consulting her brain since both are accessing stored information to guide their behavior. This example powerfully suggests that the mind is not limited to the brain. It can extend into the world via devices and tools, as long as they are integrated into our cognitive routines.

The question then becomes: at what point does an external tool count as part of you? Philosophers have offered several criteria sometimes called the “glue and trust” conditions for when we should treat something like a notebook or by extension, an app or AI as an extension of the mind.

• Reliable Availability: The tool must be reliably present and readily accessible whenever you need it . (Otto always carries his notebook everywhere he goes.)

• Ease of Use: Information from the tool should be easy to retrieve almost automatically, without great effort or delay. (In practice, using the tool becomes second-nature, like recalling a memory.)

• Trust: You trust the tool and accept its outputs as true, much like you trust your own memory. (Otto doesn’t doubt his notebook; if it says “MoMA is on 53rd Street,” he believes it, just as Inga believes her recollection.)

• Personal Integration (Prior Endorsement): Ideally, the information in the system was placed there or vetted by you, or in some way, you’ve integrated it into your identity. (Otto wrote the notebook entries himself, so they reflect knowledge he endorsed.)

When these conditions are met, the boundary between “tool” and “mind” gets fuzzy.
Clark and Chalmers explain that our everyday experience fullfills this. For example, a smartphone serves as a memory bank (with our notes, contacts, calendar), a navigation system, and even a “second brain” that we consult without a second thought. In fact, by 2011, even Chalmers noted that his iPhone satisfied at least three of the four criteria for a mind-extension device in skilled users’ hands. For many of us, losing our phone or internet connection feels like losing a part of our mind which is the extended mind thesis in action.

However, building an extended mind also comes with trade-offs and caveats. One obvious issue is that external tools can fail or be wrong. If any of the “glue and trust” conditions break down such as the device isn’t available, or you suddenly doubt its accuracy then the extension breaks down. For instance, experienced GPS users learn not to solely trust their GPS in all cases. They stay alert to correct it when it inevitably makes mistakes or loses signal. Only with skill and critical oversight can a GPS become a helpful extension of one’s navigational mind, rather than a mindless crutch. The same caution applies to AI assistants. Over-reliance on an external memory or skill can lead to cognitive atrophy where we might stop exercising our own memory or problem-solving abilities, becoming too dependent on the tool. Psychologists have observed this with phenomena like the “Google effect”, where people are more likely to forget information that they know they can just look up online. In other words, when a tool is always at hand, we offload mental work to it, which is great for efficiency, but might leave our natural abilities underdeveloped or prone to atrophy. There’s also the risk of false confidence, if the tool feels like part of your mind ,you might accept its outputs uncritically as if they were your own thoughts. With something like ChatGPT, as we’ll discuss, this is a double-edged sword as it can deliver brilliant insights, but also confident-sounding nonsense also known technically by AI researchers as hallucinations. An extended mind must therefore be built on trust and verification. We have to cultivate good “cognitive hygiene” and guardrails with our tools. It is important to know when to trust the AI and when to double-check, much as a good driver knows when to ignore a misleading GPS route. Abiding as a simple “left turn” could be deadly. The ideal is a balanced partnership where the external aid contributes knowledge or speed, and the human contributes oversight and contextual judgment.

ChatGPT as a Cognitive Extension

Alas the king… ChatGPT, the AI chatbot that launched in 2022, that is synonymous with the word AI itself. If any digital tool has the potential to act as a mind extension, ChatGPT is a prime candidate. It often satisfies the key conditions we listed.

Availability: If you have an internet connection, ChatGPT or similar models built into apps and devices is available 24/7, ready to answer questions or generate ideas on demand.

Ease of use: Absolutely, you just converse in plain language, and it responds within seconds. People have found it astonishingly easy to integrate ChatGPT into workflows by asking it to brainstorm topics, explain tricky concepts, draft emails, debug code, etc.

Trust: This is where it gets sticky; we’ll address its pitfalls soon, but many users do report that after some experience, they develop a sense of when to trust the AI’s answers for example, on a familiar topic or coding task and when to be cautious like when it confidently states an obscure “fact” that could be wrong. ChatGPT is often described as “having a super knowledgeable friend always at hand,” which indicates a high level of trust in the tools guidance.

Personal integration: Unlike Otto’s notebook, you didn’t personally write all of ChatGPT’s knowledge store – it comes pre-trained on vast swaths of the internet. However, you can customize the interaction by giving it your context, preferences, or writing style. Over time, the AI’s outputs might start to reflect your own way of thinking or the directions you nudge it toward, creating a kind of feedback loop between your mind and the AI. For example, ChatGPT’s Latent Memory feature makes that augmentation concrete. It quietly retains key details from past conversations, your projects, preferences, and stylistic quirks and uses them to shape future responses. As the model “gets to know” you, a slice of your working memory is effectively outsourced to the chat history, deepening the extended-mind partnership. In effect, when someone uses ChatGPT regularly, it can become a personalized cognitive aide, augmenting their natural abilities.

Empirically, we are already seeing how AI tools boost human cognitive performance. A recent experiment at MIT had hundreds of professionals work on writing tasks (emails, reports, etc.), with half given access to ChatGPT and half working solo. Those with ChatGPT finished their tasks 40% faster, and their output was rated ~18% higher in quality. In other words, the AI made people both quicker and better at their work. Interestingly, it was the weaker writers who benefited the most as ChatGPT helped close the skill gap between people, acting as an equalizer. This suggests that AI isn’t just a fancy convenience but rather can fundamentally alter someone’s cognitive productivity. In creative domains, anecdotal evidence shows AI sparking new ideas. Writers use ChatGPT to overcome writer’s block or generate plot ideas. Coders use it to learn new programming techniques on the fly. Students (unfortunately) use it to get instant explanations of complex topics. In many cases, people report that these tools help them achieve results they couldn’t have achieved (at least not as easily) on their own. For example, a non-programmer building a simple app with ChatGPT’s help, or a novice writer producing a polished essay by iterating with the AI. All of this aligns with the notion that ChatGPT can act as a cognitive amplifier. It extends what we know, effectively giving an individual access to a composite of Wikipedia, a librarian, a tutor, and a creative partner all at once. Little wonder that some have likened it to a “bicycle for the mind” (to borrow Steve Jobs’ old phrase for computers) except now the bicycle sometimes feels more like a jetpack. As AI copilots absorb the repetitive or low-level pieces of knowledge work, our top performers no longer rise by raw technical ability alone; they graduate from hands-on specialists to orchestrators. And in a world shifting from specialization to orchestration, these orchestrators hold the keys: they design the workflows, craft the prompts, select the data sources, and synchronize human talent with machine agents into a seamless whole unlocking outcomes no single expert could achieve in isolation.

The dawn of the orchestrator

Highway to the Danger Zone

That said, we must also address the drawbacks and dangers of relying on such AI extensions. Perhaps the biggest issue with current generative AI is that it can be too confident for its own good. ChatGPT doesn’t actually “know” facts in the way we do. It predicts plausible answers based on patterns in data. This means it sometimes produces fabrications that sound perfectly credible what we call “hallucinations” as described previously. For example, ChatGPT might cite studies or laws that don’t exist, or assert health facts that are utterly wrong but seem right. These inaccuracies are so common that researchers have given them a nickname and are actively studying why they occur. If a user treats ChatGPT’s output as gospel, trusting it like an infallible memory, they can get into trouble. A now-infamous case involved a lawyer who used ChatGPT to help write a legal brief, and the AI invented court cases to cite. The lawyer, assuming the AI’s confidently presented citations were real, submitted the brief and later faced professional sanctions when the judge discovered those cases were nonexistent. In this cautionary tale we can takaway that powerful cognitive extension can mislead you if you don’t remain critically engaged. Over-trust in the AI can lead to mistakes, misinformation, or the erosion of one’s own expertise. This is why many experts stress AI literacy and knowing the strengths and weaknesses of tools like ChatGPT as a crucial skill for the future.

Another consideration is how these tools fit into our broader cognitive habits. Do they complement our thinking or start to substitute for it? There’s a subtle but important difference between complementary and competitive cognitive aids. A complementary aid handles the tedious bits so that you can focus on higher-level thinking. For instance, using ChatGPT to perform basic data entry for you might free up time and mental energy for you to synthesize insights and make creative connections (things the AI might not do as well). In this mode, human and AI form a partnership where each does what it’s best at. By contrast, a competitive aid is one that essentially takes over a task that humans used to do, potentially sidelining the human role. If someone uses the AI in lieu of learning the basics or outsources all their creativity to an algorithm, they might be left with diminished skills and understanding. For example, if students lean on ChatGPT to do all their writing, they might never develop the ability to structure an argument themselves. The AI has “competed” with and supplanted their own cognitive growth. In the workplace, this distinction plays out as well: will AI assistants simply assist workers, or eventually replace those who don’t add unique value? Current evidence suggests that in many cases AI acts as a force multiplier for human talent , but we can’t ignore the possibility that some jobs or skills will be rendered obsolete. Navigating this will require conscious effort and we should embrace the complementary uses of ChatGPT that let us achieve more, while guarding against over-reliance that leaves us complacent or deskilled.

The Cyborg Question

All this talk of human-machine coupling naturally leads to the image of the cyborg. The archetypal transhuman figure who is part human, part machine. So, does using ChatGPT make you a cyborg? The answer depends on how we define cyborg.
Traditionally, the word means a “cybernetic organism,” implying a being with technology integrated into its body or biology. The term was originally coined in the 1960s to describe a person whose bodily functions are aided by implanted devices or biochemical modifications . Classic sci-fi cyborgs have robotic limbs, bionic eyes, brain implants, and so forth. By that strict definition, simply chatting with an AI on your phone doesn’t qualify. There’s no physical fusion of man and machine in the case of ChatGPT; the AI remains an external tool, not a literal part of your organic body. You could put your phone in a drawer and poof the “cyborg” abilities vanish, proving that you and the tool are separate entities. So, in the conventional sense, no, using ChatGPT does not make you a cyborg

.
However, some theorists have argued for a broader conception of cyborg-hood that applies to everyday life. Notably, anthropologist Amber Case argues that we are all cyborgs now in as much as we rely on technology constantly to extend our capabilities. You might not have a chip in your brain, but if you rarely go anywhere without your smartphone (your external memory/communication device) and you use digital tools to mediate so many experiences, you are functionally a cyborg. Case points out that we use our phones and computers like “external brains” for communication and memory, effectively becoming a “screen-staring, button-clicking new version of humans” . In this more metaphorical or sociological sense, anyone using ChatGPT as a cognitive crutch is engaging in a cyborg-like merging of human intellect with machine processing. The boundary between user and tool becomes porous during those moments of interaction. Think of how a person might say “I’ll ask my AI,” the way they’d say “I’ll think about it” – it hints that the AI has been incorporated into their cognitive loop. Some bioethicists and futurists use the term “soft cyborg” to describe people who, while not physically augmented, are so intertwined with their personal tech that it’s an extension of their self. By that view, millions of us became soft cyborgs the day we got smartphones, and tools like ChatGPT only deepen that intertwinement.

Even so, ChatGPT remains an external tool unless we literally implant it or physically couple it to our bodies. It’s worth clarifying where the line would be crossed into true cyborg territory. If, for example, in a decade we have a brain–computer interface (BCI) that lets you query an AI with your thoughts and receive answers as instant flashes of neural input, that would pretty clearly qualify as being a cyborg. Companies like Neuralink are already working on high-bandwidth BCIs that, in theory, could one day link human brains with AI systems. A less invasive route might be augmented reality glasses or contacts that overlay AI assistance onto your visual and auditory field at all times basically, an AI that’s always in your perception, not confined to an external screen. At that point, the AI starts to feel like part of your sensory system.

We can also imagine AI-driven neural prosthetics or implants that aids memory, or a language chip that provides real-time translation of foreign languages in your head. Those blur the line between user and device in a much more intimate way than a chatbot app does. ChatGPT, as amazing as it is, still lives in the cloud, you have to physically query it, and there’s a clear boundary (the interface, the screen) where information passes from machine to you. In cyborg terms, it’s one step short of full robocop.

So, calling ChatGPT users full “cyborgs” is mostly a playful metaphor hinting at the near future. A true cyborg enhancement becomes a part of you even when you’re not consciously thinking about it. One might argue like a pacemaker that keeps your heart rhythm steady, or a cochlear implant that continuously provides hearing.

In summary, using AI like ChatGPT moves us toward a cyborg-like existence in a philosophical sense, but it doesn’t make us cyborgs in the literal, physical sense. For that next leap, we’d need tighter integration at the physical level, at the current phase reliably consulting AI still largely requires skill.

The Haves and the Have-Nots: Access and Inequity in AI

If ChatGPT represents a sort of mass-market, over-the-counter cognitive enhancement, we should ask: Who gets to benefit from it? Historically, one concern in transhumanist technologies is that they might create a divide between the “enhanced” and “unenhanced”. For example, only the rich affording life-extending tech or brain boosts. With ChatGPT, the financial barrier is actually relatively low as the basic version has been offered free, but that doesn’t mean access is truly equal. First, there’s the straightforward digital divide: not everyone has a reliable internet connection or a modern device to use AI on. Billions of people still lack broadband access, and even within wealthy countries, underserved and rural communities may struggle with connectivity. Hardware and infrastructure are the baseline requirements for entry into this augmented world.

However, as observers note, a new divide is emerging that goes beyond just owning the tech – it’s about knowing how to use it effectively. Some have started calling this the AI literacy gap, akin to digital literacy but focused on understanding and working with AI. In other words, two people might both have internet access, but if one knows how to craft good prompts, interpret the AI’s output, and integrate it into their tasks, while the other is intimidated or unskilled with the AI, the first person will gain a significant advantage. We’re already seeing this in educational settings and workplaces. Students with strong guidance on using AI can produce better projects and learn faster, whereas those left unguided might either misuse the tool (e.g. simply plagiarize answers they don’t understand) or avoid it altogether out of fear. Similarly, a professional who adapts quickly to using AI tools may outshine colleagues who stick to older methods. This raises the concern that AI could exacerbate existing skill and socioeconomic gaps. Those who are digitally privileged having not just access but also the savvy to use technology can surge further ahead, while others lag behind.

Model Access

Another subtle access issue is the difference between the free versions of AI and the most advanced versions. For instance, OpenAI offers a paid subscription to ChatGPT Plus (with access to more powerful models like GPT-4). Organizations and individuals who can pay for premium AI will get significantly better results, more accurate, less hallucination-prone, with advanced features compared to those using only the free model. Over time, if cutting-edge AI remains behind paywalls, we could see a situation where wealthier users effectively have a “stronger cognitive enhancement” than others. This is not unlike healthcare disparities, except here it’s an intelligence tool. It’s easy to imagine a future where businesses invest in top-tier AI for their employees, training them in its use, and thereby dramatically increasing their output, while smaller firms or workers without such resources fall behind. However, as a hedge, open source models like deepseek have done the unthinkable with launching free models which could be run locally on a person's own computer. Though, enterprise grade hardware is required to run these full models to even spit out a simple question.

So, how do we address these gaps? AI literacy education is one key. Just as basic computer literacy became essential over the past few decades, knowing how to interact with AI should become a widely taught skill. This includes understanding AI’s limitations and ethical considerations, not just technical know-how. Initiatives are already calling for integrating AI training in schools and community programs. For example, learning how to fact-check AI or use it to assist (not replace) one’s learning could be built into the curriculum. Public libraries and online courses can play a role in democratizing knowledge about AI tools, so it’s not confined to tech specialists or elite institutions. Policymakers and organizations like UNESCO have begun discussing “AI literacy as a human right” in the digital age, emphasizing that without proactive measures, AI could deepen inequality rather than alleviate it.

On the infrastructure side, continuing to expand internet access is obviously crucial as every new person brought online is a potential new beneficiary of tools like ChatGPT. There’s also a case to be made for public interest AI: ensuring that advanced AI models are available in forms that the public and underprivileged communities can access perhaps via open-source models or government-provided AI services, rather than having all the best AI locked behind corporate gates.

In summary, ChatGPT offers a glimpse of a future where cognitive augmentation is widespread, but making that future equitable requires conscious effort. Otherwise, we risk a scenario where some minds get much “bigger” with AI help, while others are left behind in the pre-AI paradigm, widening the gulf in opportunity. The notion of transhumanism often dwells on individual enhancement, but we have to broaden that: true progress will be if these enhancements uplift as many people as possible, not just a tech-savvy few.

Conclusion: A Mind in the Making

We stand at a peculiar moment in human history. The tools we've created to extend our minds have become so powerful that they force us to reconsider what it means to be human in the first place. ChatGPT isn't just another productivity app; it's a mirror that reflects our evolving relationship with intelligence itself.

The central tension this essay has explored is not whether ChatGPT makes us transhuman (by most definitions, it doesn't), but rather what it reveals about the porous boundary between tool use and cognitive enhancement. When a technology integrates so seamlessly into our thinking processes that we struggle to separate our thoughts from its suggestions, we've crossed a threshold that demands new frameworks for understanding human capability.

Three critical tensions emerge from this analysis:

First, the enhancement paradox: ChatGPT simultaneously amplifies our abilities and threatens to atrophy them. We become more capable while risking dependence. The solution isn't to reject these tools but to develop new forms of cognitive hygiene: practices that maintain our intellectual muscle tone even as we delegate routine mental labor to AI.

Second, the equity challenge: Cognitive enhancement through AI could either democratize intelligence or create new hierarchies of the augmented versus unaugmented. The determining factor won't be the technology itself but how we structure access to it and, more importantly, education about its effective use. AI literacy may become as fundamental as traditional literacy, yet we're barely beginning to understand what that means.

Third, the agency question: As we transition from specialists to orchestrators, we must guard against becoming mere operators of intelligent systems. True agency in the age of AI means maintaining the ability to think independently, to question AI outputs, and to synthesize insights in uniquely human ways. We must be conductors, not just audience members, in the cognitive symphony.

Perhaps the most profound insight is that we've been augmenting ourselves all along: through writing, mathematics, computers, and smartphones. ChatGPT simply makes this augmentation impossible to ignore. It strips away the comfortable fiction that our tools are separate from our thinking and forces us to confront what we've always been: tool-using animals whose intelligence is distributed across our technologies.

The question isn't whether to embrace or resist this augmented future. It's already here. The question is how to shape it consciously. We need new ethical frameworks that account for distributed cognition, educational systems that teach orchestration alongside traditional skills, and a renewed commitment to human agency even as our tools grow more powerful.

In the end, ChatGPT offers us a preview of a future where the boundaries between human and artificial intelligence blur not through physical merger but through cognitive partnership. How we navigate this partnership with wisdom, equity, and intentionality will determine whether these tools amplify our humanity or diminish it. The choice, as always, remains ours.

References

Bajarin, T. (2014, April 21). Who needs a memory when we have Google? Time. https://time.com/69626/who-needs-a-memory-when-we-have-google

Bostrom, N. (1998). A history of transhumanist thought. https://nickbostrom.com/old/transhumanism

Bostrom, N. (2005). Transhumanist values. Ethical Issues for the Twenty-First Century, 3–14. https://nickbostrom.com/ethics/values.pdf

Brynjolfsson, E. (2022). The Turing trap: The promise & peril of human-like artificial intelligence. Daedalus, 151(2), 120–146. https://www.amacad.org/sites/default/files/publication/downloads/Daedalus_Sp22_19_Brynjolfsson.pdf

Clark, A., & Chalmers, D. J. (1998). The extended mind. Analysis, 58(1), 7–19. https://www.consc.net/papers/extended.html

Clynes, M. E., & Kline, N. S. (1960, September). Cyborgs and space. Astronautics, 26–27. https://web.mit.edu/digitalapollo/Documents/Chapter1/cyborgs.pdf

Education Week. (2023, May 17). AI literacy, explained. https://www.edweek.org/technology/ai-literacy-explained/2023/05

Ghanem, K. (2025, May 9). Instagram face & BBL baddies—Welcome to the first wave of transhumanism. Mille World. https://www.milleworld.com/instagram-face-bbl-baddies-welcome-to-the-first-wave-of-transhumanism/

Hauser, C. (2023, May 27). Avianca lawsuit shows perils of citing A.I.-generated cases. The New York Times. https://www.nytimes.com/2023/05/27/nyregion/avianca-airline-lawsuit-chatgpt.html

IBM. (2023, September 1). What are AI hallucinations? https://www.ibm.com/think/topics/ai-hallucinations

Maiberg, E. (2025, February 10). Microsoft study finds AI makes human cognition “atrophied and unprepared.” 404 Media. https://www.404media.co/microsoft-study-finds-ai-makes-human-cognition-atrophied-and-unprepared-3/

Mentat. (n.d.). In Dune Wiki. Fandom. Retrieved May 26, 2025, from https://dune.fandom.com/wiki/Mentat

More, M. (1990). Transhumanism: Towards a futurist philosophy [White paper]. https://www.ildodopensiero.it/wp-content/uploads/2019/03/max-more-transhumanism-towards-a-futurist-philosophy.pdf

Noy, S., & Zhang, W. (2023, June 7). The productivity effects of generative artificial intelligence. VoxEU/CEPR. https://cepr.org/voxeu/columns/productivity-effects-generative-artificial-intelligence

OpenAI. (2024, February 13). Memory and new controls for ChatGPT. https://openai.com/index/memory-and-new-controls-for-chatgpt/

PhilPapers. (n.d.). Transhumanism. In PhilPapers. Retrieved May 26, 2025, from https://philpapers.org/browse/transhumanism

Sparrow, B., Liu, J., & Wegner, D. M. (2011). Google effects on memory: Cognitive consequences of having information at our fingertips. Science, 333(6043), 776–778. https://scholar.harvard.edu/files/dwegner/files/sparrow_et_al._2011.pdf

UNESCO. (2025, February 12). What you need to know about UNESCO’s new AI competency frameworks for students and teachers. https://www.unesco.org/en/articles/what-you-need-know-about-unescos-new-ai-competency-frameworks-students-and-teachers

YouTube. (2025, February 15). Microsoft research discovers AI atrophies cognitive confidence [Video]. YouTube.

Modern blockchains have achieved scale, but not certainty. While Solana leads on throughput and latency, it still lacks reliable execution guarantees for high-stakes applications. Raiku introduces a programmable coordination layer that restores determinism, predictability, and trust to onchain systems without compromising performance. Built as a sidecar to Solana’s validator network, Raiku enables developers to reserve blockspace ahead of time, schedule transactions precisely, and avoid all the mempool chaos.

This paper explores how Raiku brings execution guarantees, MEV resistance, and pre-confirmation to Solana’s monolithic architecture, offering a system built not just for speed but for reliability in a distributed, adversarial world.

The State of Blockchain Architecture and the Need for Execution Certainty

Global markets demand certainty. Crypto, too often, offers only hope.

Today’s blockchain infrastructure is riddled with architectural compromises. In the pursuit of scale, we've built systems that violate core distributed computing principles, assuming infinite bandwidth, ignoring latency ceilings, and forcing universal state models on applications that don’t need them. The result? Fragile abstractions, unreliable performance, and a developer experience that feels more like survival than innovation.

Imagine launching a modern financial product and being told your transaction might fail, unless you spam it, bribe the validator, or just pray for inclusion.

Blockchain systems are ultimately supposed to abstract that complexity, offering decentralized infrastructure that "just works." But instead, we’ve traded server racks for validator nodes, and latency issues have simply moved from physical hardware to Layer-1 congestion.

This is the daily reality in Web3. Ethereum, the most widely used smart contract platform, handles just 15–30 transactions per second. During high demand NFT drops, liquidations, memecoin seasons, the base layer clogs, fees spike, and L2s are the only escape hatch. These Layer-2 rollups offer massive throughout with reduced gas fees by shifting execution off-chain, but bring new tradeoffs: fragmented liquidity, complex bridging, divergent trust models, and a somewhat fractured user experience.

Meanwhile, Ethereum’s restaking ecosystem introduces even more fragility. Protocols like EigenLayer ask validators to secure third-party systems with Ethereum’s social consensus, effectively betting that if anything breaks, the community will coordinate a bailout. Even Vitalik has flagged this approach as dangerously “high-risk.” Scaling Ethereum is still a 10-year roadmap. Builders need something now.

Solana, on the other hand, pursued a high-performance monolithic design: it keeps consensus and execution in one chain, enabling very fast block times and parallel execution. In practice Solana regularly processes 3,000–4,000 TPS on a global state machine, far outpacing Ethereum’s throughput. This design yields low fees and near-instant finality under normal conditions. However, Solana’s single-chain architecture has also shown stress under extreme load. During periods of surging usage, Solana has experienced congestion and even outages, as every dApp competes for the same global resources.

For example, a dramatic increase in traffic (e.g. a popular NFT mint or arbitrage bots) historically led to stalled blocks and transaction failures. Notably, in Feb 2024 a bug triggered by Solana’s runtime caused a nearly five-hour network halt. Even when the network stays up, users and bots often see transactions fail or time out during peak demand, undermining Solana’s otherwise strong user experience. In fact, high-frequency traders on Solana have observed failure rates up to 75% for transactions when the network is congested. This happens because Solana’s leader schedule and QoS (quality-of-service) prioritization favor certain validators, and when too many transactions flood in, many simply never get included in time.

Beyond throughput limits, both ecosystems struggle with MEV exploitation and unpredictable execution. Solana, despite using a public leader schedule, faces its own MEV dynamics. Solana’s stake-weighted transaction scheduling means large validators or order flow specialists can cut deals to prioritize certain transactions off-book. This lack of transparency leads to centralization concerns, where well-connected bots or firms get fast-lane access while regular users’ transactions struggle. Although Solana has introduced priority fees and solutions like Jito (a specialized MEV-aware client) to bring more open fee markets, the underlying issue remains: when the network is busy, inclusion becomes a bidding war or insiders’ game, and ordinary users face uncertainty and slippage.

On the state side, Ethereum’s rollup-centric model fragments applications across chains. Each rollup becomes a silo, requiring bridges, redundant tooling, and extra security assumptions. Composability, the magic of DeFi, dissolves when liquidity and contracts are no longer co-located.

What’s missing is scale without latency spikes, state fragmentation, or failed trades. The precision global finance requires but blockchains still lack.

This is the design space Raiku occupies.

Born from years of Ethereum infrastructure frustration and a deep respect for clean system design, Raiku introduces a new class of infrastructure to Solana, one built not around more rollups, but around precision execution. It extends Solana’s core by offering programmable building blocks—Edge Compute environments—that give applications their own fast lanes, guaranteed bandwidth, and deterministic settlement without managing a separate chain or breaking composability.

If Solana is the global highway, think of Raiku as the intelligent traffic control system, enabling express lanes for the applications that need them most.

This isn’t another rollup. It’s not a sidechain. Raiku is a rethinking of blockchain execution: fast, modular, programmable, and predictable. A system forged not to chase trends, but to meet the demands of institutions, builders, and global-scale applications that need certainty, not hope.

From Limitations to Vision: The Genesis of Raiku

Raiku was born from a simple observation: not all blockchain workloads need to run in the same crowded kitchen. In late 2023, a team of researchers and Solana veterans began asking how they could offload heavy computations from Solana’s L1 without losing the benefits of being on-chain. This initiative started as a research project (supported by Superteam and the Solana Foundation) out of frustration with the “stagnation” they perceived in Ethereum-centric infrastructure. Ethereum’s ecosystem, while rich in Layer-2s, hadn’t delivered the kind of leap in performance or developer experience these researchers hoped for, rollups were making incremental progress but still tied to a relatively slow and congested base layer. By contrast, Solana represented a chance to try something different: its L1 was already fast and proved that a web-scale blockchain was possible, yet it too could improve by evolving its architecture.

Raiku team noted that by January 2024, many Solana applications were “naturally gravitating” toward an extensions architecture, or, in other words, projects were attempting to build their own mini-rollups or isolated execution layers to scale the base layer throughput even further. Lacking an official framework, some teams tried repurposing tools like the Sovereign SDK (meant for standalone chains) to create Solana extensions or arguably “rollups”. The results were suboptimal: misusing an Ethereum-oriented rollup framework on Solana led to poor performance and lots of friction. Every project rolling their own extension would cause state fragmentation (“basically moving towards all the problems that Ethereum has) and duplicated effort. More importantly, these DIY solutions did not integrate cleanly with Solana’s design, they ran into data throughput limits, timing issues, and inability to share state or accounts with L1.

This pattern highlighted a clear design problem: Solana needed a purpose-built extension framework, not one shoehorned from elsewhere.

Raiku’s founding team, led by Robin A. Nordnes and others, set out to solve this by building an “edge compute” layer tightly coupled to Solana from first principles. They chose Solana after surveying other new L1s like Aptos and Sui, concluding that Solana was uniquely positioned to support their vision. Solana had a critical mass of users, a strong developer community, and fundamentally sound architecture (often likened to an early, rapidly improving Ethereum). Importantly, Solana’s leadership and ecosystem were willing to innovate, core developers shipped updates every couple of weeks, and there was appetite for new approaches to scaling. The idea was not to launch yet another independent L1, nor to create a completely separate shard, but rather to extend Solana in a complementary way.

As one team member put it, “We’re not an L2, we’re not an L1... we’re somewhere in between.” More formally, Raiku positions itself as the block building architecture, an infrastructure protocol that connects validators, applications, and the base chain to orchestrate high-performance execution beyond what the base layer alone can provide. If Solana L1 is the highway, Raiku builds the express lanes and traffic control system that allow certain applications to operate with significantly greater speed and predictability when required.

A key insight driving Raiku’s design is that many high-scale dApps do not require constant interaction with the entire global state. Some applications can run largely isolated (their own orderbook or game engine logic) as long as they can occasionally settle to the main chain and leverage its security and liquidity when needed. As Nordnes explained, “most use cases with large-scale potential do not require state composability at all times”. You can sandbox an application’s execution in its own zone (like an L2), but still get the benefits of the base chain for things like settlement finality, shared user accounts, on-chain price data, and asset security.

This realization underpins Raiku’s architecture: it seeks to give applications their own sovereign execution environments (so they aren’t bottlenecked by others) while maintaining the advantages of Solana’s L1 (one unified asset and identity space, and a high-performance settlement layer). In the Ethereum world, one could try to achieve something similar by launching an optimistic or ZK rollup, but as the team noted, “you can build as an L2 in Ethereum, but you’re still severely restricted by the underlying L1”. Even the best rollup will be limited by Ethereum’s data posting throughput, latency, and upgrade timeline (“fixing the L1 is going to take a decade”). Instead of waiting on that, the Raiku team saw an opportunity to leverage Solana’s strengths today and innovate on top of them.

Raiku would introduce a new layer running alongside Solana’s consensus, operated by (and economically aligned with) the validator community, to coordinate advanced execution features. The vision was bold: make on-chain apps “faster, more reliable, and market-competitive” with Web2 and TradFi systems like AWS or NASDAQ, all without compromising decentralization.

By early 2024, this vision gained traction. The concept of Solana “extensions” became a hot topic, and the community settled on that term (or “network extensions”) instead of “L2s” to emphasize adding to L1 rather than forking away. Raiku emerged as one of the leading projects implementing this concept.

Technically, an extension is similar to a rollup or sidechain, and it’s stigmatized and perhaps downplays what the Raiku team is building. Raiku embraced the term “Edge Compute” to describe its execution zones. The phrase “edge compute” is borrowed from traditional IT (where it means computation done at the edge of the network, closer to where it’s needed). Raiku’s edge compute environments aren’t separate blockchains in competition with Solana, instead, they are modular execution zones at the edge of the Solana network, purpose-built to handle specialized workloads with deterministic performance. It’s a term that resonates with Web2 infrastructure teams and institutional players, bridging the conceptual gap between “rollups” and the familiar idea of edge servers. In essence, Raiku provides custom rollup-like environments (“extensions”) integrated as Solana edge compute zones. This gives developers execution sovereignty, i.e. freedom to run their own logic and scheduling, without the headache of launching an entirely new chain or fragmenting users across ecosystems.

Redefining Rollups: From “Extensions” to “Edge Compute Environments”

It’s worth highlighting how Raiku is reshaping the landscape around custom execution environments. In Solana circles, the term “extensions” emerged to describe these Solana-tailored rollups. However, the Raiku team felt that term was a bit narrow (and even “stigmatized” by early rough attempts). To capture the imagination of both crypto and traditional web2 audiences, what Raiku is building is more than just extensions, they’re building “Edge Compute environments”.

Source: https://x.com/owocki/status/1830621049190560061

With Raiku’s Edge Compute environments, we’re no longer thinking of a Layer-2 as an external add-on that lives on top of L1, but rather an integral part of the network’s architecture, an extension of L1 that lives at the network’s edge, close to the users and applications. By calling them “modular execution zones”, Raiku emphasizes that you can plug in different modules (each module being an execution runtime/VM) to one coherent system. These modular execution zones allow developers to plug different execution runtimes or custom virtual machines into one cohesive system, empowering them to shape low-level application logic with unparalleled control.

The Raiku team believes that performance at scale isn't patched in, it's built in from the outset. Raiku begins precisely where others stop: at the physical boundaries of bandwidth, geography, and time constraints inherent to distributed networks. Specifically, Raiku delivers:

• System reliability that maintains robust operation even under extreme load and pressure.

• Deterministic execution guaranteeing predictable outcomes for every transaction.

• Low latency by placing high-performance edge computing (HPEC) capabilities directly at the edges of the Solana network, enabling transaction processing within milliseconds.

• Developer freedom to customize low-level logic, providing unmatched flexibility and control.

Raiku’s Coordination Engine orchestrates transactions with precision, ensuring they are sent, scheduled, and confirmed swiftly, supported by a sophisticated ahead-of-time blockspace marketplace that guarantees inclusion (more on this in the later sections). Validator Plugins power both ahead-of-time (AOT) and just-in-time (JIT) execution. Combined with proof streaming, these plugins allow for instant pre-confirmation of transactions, turning today’s unreliable, best-effort interactions into dependable and scheduled execution.

Edge compute environments have practical implications. It helps differentiate Solana’s approach from Ethereum’s in the narrative: Ethereum has “Layer-2 rollups”, Solana (via Raiku) has “Edge Computes”. The latter suggests enhancement rather than separateness. It is a term that traditional finance will understand. In enterprise computing, edge compute is a positive concept, it implies faster response by moving compute closer to where it is needed.

Raiku is effectively saying: we move execution closer to the app (in a logical sense) while still being anchored to the main network.

So, in this report we’ve consistently used “edge compute environments”, “extensions”, and “modular execution zones” somewhat interchangeably, to reflect how Raiku’s idea might be referred to. Going forward, as Raiku hits mainnet and more marketing, you’ll likely see “Raiku Edge Compute” as a branded term, much like how Polkadot has “parachains” or Avalanche “subnets”. This terminology also makes it easier to convey new capabilities: for example, Raiku can say “deploy your own edge compute environment on Solana in one week”, which sounds like setting up a cloud environment, thus familiar to developers.

By emphasizing “edge compute”, Raiku aligns itself with the broader trend in web infrastructure where logic is moving closer to the user (edge networks, CDNs, etc.) for speed, except here the “user” is the application transaction, and the edge is a special zone in the network. It’s a powerful analogy that could help more people grasp how Raiku differs from just another scaling hack.

Raiku’s design is guided by a few key principles:

Not all dApps need continuous global state:

Some of the highest throughput applications (exchanges, games, payment networks) can operate in siloed environments for most of their activity, tapping the main chain only when needed. Raiku embraces this by providing opt-in isolation, freeing those apps from the global mempool competition, while still giving them access to L1 liquidity/state when necessary. This stands in contrast to the Ethereum DeFi ethos where everything is highly interwoven on one chain (which is powerful but doesn’t scale when every minor app demands global atomic composability). By recognizing that temporal or contextual composability (only when needed) is enough for many cases, Raiku achieves massive performance gains.

Keep the one-network feel:

Despite introducing modular zones, Raiku strives to avoid the multi-chain UX headaches. The global accounts and orchestration engine ensure that from a user’s perspective, Solana remains one network. You don’t need to manage multiple tokens for gas on different chains/ zones or switch RPC endpoints manually. You interact with Solana, and under the hood Raiku may route your transaction to an extension or the main chain as appropriate. This is a stark difference from, say, the Cosmos app-chain model or even Ethereum’s L2 landscape, where using a new chain means new tokens, new block explorers, and a mental shift.

Raiku’s edge compute zones are much like “network extensions” rather than independent networks, signaling that they extend Solana rather than compete with it. The architectural advantage here is network effects preservation: SOL token’s utility still underpins the whole (fees, staking), and Solana’s community isn’t split among dozens of mini-chains. This addresses a common critique of Ethereum’s rollup-centric roadmap, that Ethereum might become just a settlement layer while user activity migrates to various L2 tokens and ecosystems, potentially diluting Ethereum’s economic security. Raiku’s approach adds capacity and keeps it under the Solana economic umbrella.

Leverage existing security, don’t reinvent it:

Raiku does not create a new base consensus mechanism or require users to trust a brand new validator set with their funds (in fact, Raiku won’t custody funds separately, assets remain on Solana). This is a major advantage over launching a sovereign appchain or a new L1. If a project today chooses to start its own chain (whether via Cosmos SDK, Avalanche subnet, or some sovereign rollup), it faces the monumental task of bootstrapping validators, incentivizing them (often via inflationary new token rewards), and securing bridges back to other ecosystems. Raiku shortcuts this by building on Solana’s validator community and bridging natively via global accounts.

There’s no separate bridge contract, the extension is logically part of Solana. This dramatically lowers the security risk and development overhead compared to sovereign chain approaches. For example, teams who tried Sovereign SDK on Solana ended up with state fragmentation and poor performance because Sovereign SDK wasn’t made for Solana’s context. Raiku’s custom solution avoids those pitfalls and maximizes reuse of Solana’s battle-tested components (like its networking, validator incentives, etc.).

Predictability and transparency as core features:

Both builders and users value knowing what will happen. Raiku bakes predictability at the protocol level. Inclusion signals remove the guesswork from transaction submission. MEV is handled by design (no private mempools, everything goes through auctions or known channels. This fosters a healthier ecosystem.

On Ethereum, despite improvements, users still fear being sniped by an arbitrage bot the moment they send a Uniswap trade. On Solana, users fear transactions “not going through” when the network is busy. Raiku wants to eliminate those fears, making the blockchain feel reliable and “boring” in the best way, like AWS infrastructure where if you schedule a job, you trust it runs on time. This is a key selling point for institutional adoption (who require SLAs and predictability) and for broad consumer use (no one wants to spam “Submit” hoping one transaction sticks).

Real-World Use Cases Enabled by Raiku’s Edge Compute Design

What can developers actually do with Raiku that they couldn’t before? The answer: build on-chain applications with the speed and guarantees of off-chain systems, and deploy new types of services on Solana that previously might have required a separate chain or centralized solution. Let’s explore a few illustrative use cases that Raiku’s team and community have envisioned, highlighting how the edge compute approach makes a difference:

High-Frequency Trading and Exchanges (Drift Protocol’s Swift as an example):

Drift is a leading Solana-based perpetuals exchange that processes large volumes of trades. In early 2025 they introduced Swift Protocol, an on-chain ultra-low-latency matching engine built directly on Solana. It keeps the order book and matching logic on-chain, then routes filled trades to Drift’s perpetuals program for settlement. While innovative, Swift still faces a limitation: when it comes time to settle those matched trades on Solana L1, it’s subject to the usual network conditions and could experience delays or contention (especially during volatile market moves when many exchanges are active).

Enter Raiku: a Drift-like DEX could deploy an edge compute extension specifically for its trading engine. In this extension, orders could be matched and immediately finalized on-chain (in the extension) with microsecond precision, far faster than even Solana’s 400ms block time. The extension could use Light SVM optimized for trading, enabling thousands of operations per second (e.g. matching bids and asks, updating trader positions) with deterministic timing. Crucially, using Raiku’s guaranteed inclusion, once a trade is matched, it can be scheduled to settle on the next Solana block with zero uncertainty. No more racing the clock or praying your transaction gets in, the trade settlement is reserved and confirmed ahead of time.

This means Drift could offer execution guarantees akin to NASDAQ, something unheard of in DeFi. Swift Protocol currently can’t guarantee exactly when a Solana settlement lands or that it won’t be front-run. With Raiku, they can guarantee inclusion and timing, solving that problem. In effect, Raiku could turn a decentralized exchange into a low-latency trading platform where market makers and arbitrageurs can operate on-chain with confidence.

Beyond Drift, any exchange or AMM could benefit, imagine an on-chain order book that updates prices every 100ms in a dedicated extension without bogging down the mainnet. Raiku’s design even supports HFT (high-frequency trading) strategies: as stated on their website, you could execute “thousands of cross-exchange trades per second with microsecond precision and guaranteed settlement timing,” giving quantitative traders an institutional-grade DeFi infrastructure. This is exactly the kind of performance unlock that could bring serious trading firms into DeFi, when they no longer have to worry about network jitter or unpredictable failure rates.

Payments and Fintech Infrastructure (e.g. “Stripe-like” payments, Squads):

Payment applications demand both high throughput and high reliability. Consider a scenario like Stripe on Solana, a service handling thousands of transactions per second for merchants, payroll, micropayments, etc. On Solana L1, this is possible in theory (given the high TPS), but in practice if the network gets congested or if a program in one payment workflow eats too many compute units, others might fail.

With Raiku, one could create a payments extension, essentially a specialized (edge compute) zone for payment transactions. This extension could be optimized for simple token transfers, including specialised/optimised environments or Light SVM for maximum efficiency. Through Raiku’s bandwidth reservation, a payment operator (like a stablecoin issuer or a CBDC platform) could reserve throughput for, say, 500 tps continuously to ensure their transactions always go through regardless of external demand. Users sending funds would get instant inclusion confirmation (no stuck transactions).

For enterprise or institutional use, Raiku can enable private settlement networks on Solana: “private settlement channels between major financial institutions with deterministic finality and encrypted flows”.

Think of big banks settling FX trades or securities on a shared Solana extension, they could have their own Raiku extension with transactions visible only to the parties (via encryption, yet still verifiable) and guaranteed finality. This unlocks use cases like cross-border payments, remittances, or inter-bank settlements on a public chain, but with the predictability of SWIFT or FedWire.

On the consumer side, something like SquadX (a popular Solana multisig and coordination tool) could use Raiku to guarantee that multi-signature transactions (which might involve many instructions) execute reliably even during peak network times. A major pain point for DAO treasuries or multi-sigs is when you try to execute a complex transaction and it fails due to network issues, Raiku could eliminate that by allocating a dedicated slot when all signers have approved, so the multi-sig transaction goes through atomically. Essentially, Raiku can provide institutional-grade reliability for any critical transaction flow, “five nines” of success rate, as they say in cloud, which is vital if blockchain is to be trusted for payments at scale.

Moreover, with RFQ-style liquidity integration, Raiku could empower new payment models: for instance, a decentralized payment app could query market makers via Raiku’s RFQ system to get the best conversion rate for a currency swap as part of a payment, all settled within one extension with no slippage or MEV. This is analogous to how Stripe routes payments through various banks to optimize fees and success, Raiku could let crypto payments route through various liquidity sources in a controlled, deterministic manner.

DeFi Protocols and Services (beyond trading):

Beyond exchanges, many DeFi protocols can benefit from Raiku’s edge compute environments. Lending platforms could use them to perform instant liquidations via dedicated channels (Raiku even enables “automated risk management with microsecond precision”,meaning a lending protocol could monitor positions and execute liquidation transactions in a guaranteed time window, reducing bad debt). Options and derivatives platforms could coordinate complex multi-leg strategies across venues by using an edge compute zone as a co-ordination hub, with Raiku guaranteeing all legs execute atomically in consecutive slots.

For instance, an options DEX could ensure that when a user rolls over a position (closing one option and opening another), both transactions happen back-to-back with no gap for price movement. This level of control is currently only feasible in centralized systems. Stablecoin issuers could benefit as well: imagine USDC could use a Raiku extension to manage its mint/redeem flows in large batches with priority, ensuring big redemptions don’t clog the network or get front-run. By allocating blockspace, they maintain smooth operation even in stress times.

Hybrid CEX/DEX and Institutional Access:

Raiku could blur the line between centralized exchanges and DeFi. Its architecture allows something like a “regulated DeFi zone” where only KYC’d entities (say institutions) participate, enabling compliance while still settling on Solana. The site hints at “hybrid CEX/DEX exchanges with superior UX”, a scenario where a central venue (or consortium) provides liquidity but trades settle on a public network extension. With edge compute, such a platform could offer the speed of a CEX (matching engine on dedicated hardware) and the transparency and custody benefits of DeFi (settlement on Solana). Institutions could use this to trade on DeFi markets without dealing with retail traffic or uncertain fees, since they might have their own extension or guaranteed lanes. Over time, this could attract significant volume from traditional finance into the Solana ecosystem, as Raiku can meet their performance and privacy needs (e.g., encrypted order flows in a private extension).

Non-Financial Apps (Real-time Games, Social, AI Agents, IoT):

While Raiku’s focus seems to start with DeFi and the financial markets, the framework is broadly applicable. For real-time games or virtual worlds, Raiku could support an extension that handles rapid game state updates (imagine a fully on-chain fast-paced game, Raiku’s scheduling could guarantee actions happen in a timely tick system). For social networks or messaging apps on Solana, Raiku could provide throughput to handle spikes in activity (say a viral post causing thousands of reactions, handled in an extension so the main chain isn’t flooded).

The website’s use cases explicitly mention bringing “AI Agents, DePIN, Social Networks, Payment Infrastructure, Capital Markets, HFT Trading, The Internet to Solana”. This sweeping vision suggests Raiku sees itself as enabling any high-demand application that today might think a blockchain can’t handle their scale or speed.

For example, AI agents that perform dozens of on-chain actions per second (perhaps bidding in auctions, rebalancing portfolios, etc.) could utilize Raiku to get those actions processed reliably. DePIN (projects like Helium or decentralized Uber/Airbnb concepts) often require lots of micro-transactions and device interactions, Raiku could ensure IoT devices have reserved throughput to log data or settle payments consistently.

In all these cases, the common theme is that Raiku enables a level of performance and trust that wasn’t possible on a single L1. It lets developers think bigger, to imagine on-chain services matching the responsiveness of centralized servers.

An example: if Solana is already very fast for blockchain, Raiku makes “fast” the default even under load, much like a well-provisioned cloud server that auto-scales capacity for your app.

The edge compute model is particularly attractive to projects that considered launching their own chain for performance reasons: now they can get similar benefits while plugging into Solana’s ecosystem, with a shared global state and full composibility. We may see projects from Ethereum L2s or other ecosystems “orbit” to Solana via Raiku. In fact, Raiku explicitly plans to court EVM-compatible protocols in its go-to-market, showing them that they can deploy on Solana with minimal friction and huge performance gains.

Raiku’s Novel Approach: Execution Consensus Separation with Predictable Performance

Raiku introduces a new block-building architecture that improves Solana’s base layer from within. It does this by enabling programmable coordination, allowing validators and applications to engage in more deterministic execution without introducing separate consensus or fragmented environments.

One can think of Raiku’s network as a specialized execution layer that runs in parallel to Solana’s main chain, powered by the same validator set, that simply opts in by running the Raiku sidecar. By doing this, Raiku frees intensive application logic from contending with all of Solana’s traffic, yet it’s not an island, it remains tightly synced with Solana for finality and data availability.

Unlike other ecosystems still wrestling with modular tradeoffs or fragmented execution models, Solana offers a high-performance, monolithic base layer. It delivers sub-second block times, ultra-low fees, and parallelized execution via Sealevel. These characteristics make it the most likely chain where ideas like just-in-time (JIT) or ahead-of-time (AOT) block auctions can be implemented at scale without prohibitive latency.

While Solana delivers fast block times, low fees, and parallelized execution through Sealevel, the current block construction process still has limitations:

• Validator profitability remains volatile, heavily reliant on native inflation subsidies and occasional MEV spikes.

• Transaction inclusion is unpredictable, particularly for applications that require atomicity, deterministic ordering, or pre-confirmations.

• Out-of-protocol coordination is rising, with protocols like Jito stepping in to address the lack of robust auction mechanisms and bundle execution guarantees.

What’s been missing is a programmable coordination layer, one that gives validators more consistent revenue opportunities, empowers dApps with reliable execution features, and plugs into Solana’s native architecture without compromising its low-latency, high-throughput properties.

Solana’s incentive and economic framework is evolving rapidly, guided by a series of critical Solana Improvement Documents (SIMDs). These proposals reshape core validator incentives, transaction priority mechanisms, and reward distribution, setting the stage for a more competitive and robust ecosystem:

• SIMD-0096: Redirects 100% of priority fees to validators, significantly increasing validator profitability and discouraging off-network side deals.

• SIMD-0123: Introduces a native, scalable protocol mechanism for validators to distribute rewards directly to stakers, enhancing economic alignment and transparency.

• SIMD-0228: would have introduced a dynamic, market-driven emission schedule by adjusting inflation according to staking participation levels to improve economic efficiency and security. (However, the proposal failed to reach the required two-thirds supermajority in its March 2025 vote and has not been activated)

While these changes focus on incentive alignment, they also amplify competition among validators, driving them to find new external revenue streams, especially important in bear markets when MEV and priority fee opportunities decrease.

This ongoing evolution in Solana’s market structure lays the foundation for Raiku’s orchestration engine, designed precisely to enable reliable, predictable, and high-performance decentralized execution.

The benefits of this execution–consensus separation are profound.

First is predictable inclusion: where normally a user’s transaction might sit in a mempool or queue and hope to be included in the next block (or be dropped due to a spike in load), Raiku’s design aims to offer hard guarantees on inclusion and timing. Transactions submitted via Raiku can receive an “ahead-of-time” confirmation of inclusion, effectively a reservation in an upcoming block. This is achieved through Raiku’s novel scheduling and auction mechanisms (which we’ll discuss shortly). For users and dApp developers, it means no more spamming transactions or anxiously waiting to see if a critical trade gets mined, you can know within milliseconds that your transaction is scheduled for a specific future slot. This focus on deterministic, predictable execution is a key differentiator. Traditional L2s on Ethereum can improve fees and throughput, but they generally cannot guarantee exactly when a transaction will land on L1 (especially for optimistic rollups with challenge periods). By contrast, Raiku provides time-slot guarantees on Solana, an L1 known for its 400ms block times. Raiku essentially extends Solana with a “global scheduler” that applications can tap into for reserved blockspace.

Another major advantage is failure isolation. In a monolithic L1, if one application (say, a popular NFT mint program) suddenly consumes huge resources or crashes, it can degrade or halt the entire chain. We’ve seen this on Solana, one dApp’s workload can cause network-wide slowdown. With Raiku, applications run in isolated execution zones, a.k.a. edge computes. If one of these zones faces an issue, for example, a runaway program consuming excessive compute, it won’t directly clog Solana’s main chain or other zones. The fault is contained to that extension environment. Solana’s consensus remains unaffected, and other extensions continue normally. This failure isolation is akin to having multiple “sandboxes” on the network: each application (or group of applications) can utilize a dedicated slice of capacity and even have custom parameters, without risking the stability of the whole. Traditional L2s offer some isolation (a fault on Arbitrum doesn’t halt Ethereum), but because they ultimately depend on L1 for proofs and bridging, a severe failure (or exploit) on a popular rollup can still have systemic effects (e.g. mass withdrawals through L1, or social pressure on L1 to intervene in case of a huge hack. Raiku’s close integration with Solana means extensions are first-class citizens of the ecosystem, but any given extension’s troubles don’t spill over. It’s like partitioning traffic into separate high-occupancy lanes, an accident in one lane won’t gridlock the entire highway.

Crucially, Raiku’s architecture preserves what both L1s and L2s aspire to: security and sovereignty. Each Raiku extension environment has execution sovereignty, meaning the application developers can customize the execution logic, VM, and parameters to their needs (it’s their “own chain” in that sense), but they do not need to bootstrap a new set of miners or validators from scratch. Raiku leverages a validator network that works in sync with Solana’s validator set. In practice, Raiku validators will be Solana validators opting to run Raiku’s software (a sidecar for the validator client), potentially earning additional fees for doing so. This means security is professional and robust from day one, you have an experienced validator set at the helm, and there isn’t a need for a separate token for security.

By separating consensus (still handled by Solana’s PoH/PoS for finalizing blocks) from execution (handled by Raiku’s scheduling and validator network), throughput scales up significantly. Solana no longer has to execute every single instruction of every program itself; it can outsource execution of certain programs to Raiku extensions and simply verify outcomes or proofs. This is a different philosophy from Ethereum rollups which fully verify proofs on L1 (often incurring high costs). Solana can instead trust its own validator-integrated network to do much of the heavy lifting, given the alignment of incentives and real-time cooperation.

In summary, Raiku is neither a standalone L1 nor a typical L2, it is an execution layer for Solana that introduces:

(a) execution–consensus separation (freeing apps from L1’s throughput limits),

(b) predictable inclusion and scheduling (no more probabilistic mempool games), and,

(c) robust fault isolation (one extension’s issues don’t threaten the whole)

It transforms Solana from a single-tier network into a multi-tier system: the base layer for consensus and global state, and an upper layer for high-performance application-specific execution.

Inside Raiku’s Technology Stack: Deterministic Settlement and Modular Execution

To deliver on its promises, Raiku introduces several novel components and transaction types. These can be thought of as infrastructure building blocks that work together to enhance Solana. Let’s break down the key elements of Raiku’s tech stack:

1. Ahead-of-Time Block Auctions & Inclusion Signals:

At the heart of Raiku is a new way of managing blockspace. Instead of the ad-hoc first-come-first-served mempool model, Raiku implements a slot auction marketplace. Applications or users can bid for upcoming slots on Solana (or rather, on Raiku’s coordinated schedule) in advance, securing priority for their transactions. The winning bids receive “inclusion signals” ahead of time, essentially a guarantee that their transaction (or bundle of transactions) will be included in a specific future block or sequence of blocks. These auctions are stake-weighted and atomic, meaning the scheduling respects the Solana stake distribution (validators with more stake have more capacity to include reserved transactions, aligning incentives) and transactions can be reserved in bundles that execute sequentially without interruption. The outcome is that a Raiku user can get a faster confirmation now that their “ticket” for execution is secured.

Compare this to the traditional experience: on Ethereum, you send a transaction and hope a miner picks it soon (maybe boosting the fee if you’re desperate), and even on Solana, you might spam several transactions to ensure one lands during congestion.

With Raiku, the process becomes akin to booking a train seat in advance rather than elbowing through a crowded platform. This system dramatically reduces failed transactions and uncertainty, one of Raiku’s core objectives is guaranteed execution.

Proof Streaming: Unlocking Large Payload Execution via Sequential Blockspace

One fundamental limitation in Solana today is strict per-block data constraints, designed to preserve fast block propagation. This can become a bottleneck for applications that need to submit large state updates, such as settlement engines or ZK rollup proofs.

Raiku addresses this through sequential blockspace reservations, a concept enabled by its Ahead-of-Time (AOT) block auction model. By securing a sequence of upcoming slots, applications can reliably stream large proofs or payloads in smaller, verifiable chunks, without hitting Solana’s per-block cap.

The idea is to break up large transactions or proofs into smaller pieces that can be streamed and verified over multiple slots, bypassing Solana’s strict per-block data limits. Practically, this means an application could submit a very large state update or proof (for example, a zero-knowledge proof or a batch of hundreds of trades) through Raiku, and Raiku will handle feeding this data into Solana in chunks that validators can handle.

Rather than submitting a large transaction that risks failure or bloat, applications can schedule and stream structured data across multiple slots, while validators process and verify it in a controlled manner.

2. Fast and Deterministic Settlement (“Guaranteed Execution”):

Many of the next-generation applications Solana aims to support, such as high-frequency trading platforms, real-time gaming systems, and institutional payment networks, demand strict guarantees that transactions will land exactly when and where they are expected. In these domains, execution uncertainty is not just a UX flaw; it is a deal breaker.

Unpredictable network congestion and mempool dynamics can result in transaction failures, reordering, or delays. For advanced use cases like automated liquidations, synchronized asset swaps, or arbitrage strategies, this unpredictability leads to missed opportunities and capital inefficiency.

Raiku addresses this gap with Guaranteed Inclusion through Ahead-of-Time (AOT) and Just-in-Time (JIT) slot reservations. For example, bots acting on real-time price movements may prefer JIT inclusion, while external systems may opt for scheduled AOT slots. In both cases, users pay for precision, both in timing and bandwidth (using a combination of Raiku tokens and SOL).

When a Guaranteed inclusion transaction is submitted through Raiku, it is assigned a reserved execution window, ensuring it is processed at the intended time and never dropped or reordered due to validator behavior or network congestion. While only the slot leader can include the transaction, all validators running the Raiku sidecar help propagate and acknowledge the schedule ahead of time. Raiku uses a pre-consensus scheduling system to coordinate transaction plans, which the slot leader then executes during block production.

By reserving blockspace in advance and assigning deterministic execution slots, Raiku mitigates peak failure scenarios where high-frequency users on Solana have historically seen failure rates exceeding 90 percent. It delivers guaranteed bandwidth, latency precision, and settlement predictability, even during periods of extreme load.

Guaranteed Execution also introduces MEV resistance by design. Since transactions are scheduled in advance and confirmed across the network, frontrunning is mitigated, and sandwich attacks are neutralized by incorporating expected value extraction into the auction mechanism itself. Private order flow deals that previously operated outside the protocol are no longer necessary. Instead, inclusion is handled transparently via a fair scheduling auction or reservation system.

For developers, Guaranteed Execution means you can offer your users a web2-like guarantee: e.g. a trade on a Solana DeFi app can be confirmed in milliseconds with certainty it will settle, no more “transaction dropped, please retry” errors.

3. Global Account Model and Unified State:

One of the most groundbreaking aspects of Raiku is its Global Accounts Module. This component (planned for V2 alongside proof streaming) tackles the state fragmentation problem head-on. The idea is to allow users and applications to maintain a unified identity and state across multiple execution environments.

In practical terms, a user would still have one Solana wallet/address that they use on the main L1 and across any Raiku extension they interact with. Assets and data can move seamlessly between the main chain and extensions without traditional “bridging.” The global account model will enable composability across extensions, so two Raiku extensions can interoperate or access a shared user state if needed.

This is a significant differentiator from typical L2s, where each rollup is a walled garden requiring a bridge to move assets and where accounts/contract addresses might be chain-specific. With Raiku, since extensions are more like “zones” within the Solana ecosystem, the user experience remains unified. Developers can deploy in an extension environment and still easily integrate with Solana-native programs or accounts.

For example, an order placed in a Raiku-powered orderbook extension could settle into a user’s main Solana wallet or be recognized by a program on L1, thanks to unified accounts. Technically, this might be achieved by having Raiku share Solana’s account address space and signature verification, or by having a mechanism to synchronize state roots between the extension and L1.

The outcome is that state fragmentation is solved, you get multiple execution environments with one combined state. As the Raiku team describes, this allows composability across extension environments, which is something neither Ethereum L2s (all separate) nor earlier Solana rollup attempts achieved. It’s a first-principles approach to ensure that scaling out doesn’t mean splitting the user base or liquidity.

The Global Accounts Module also supports multi-VM functionality. Raiku isn’t limited to Solana’s native VM (SVM), it is being built to potentially host different virtual machines under the same umbrella of coordination. In fact, Raiku aims to support EVM-compatible extensions, allowing projects from the Ethereum world to deploy their Solidity code as a Solana extension.

The mention of “projects like Arbitrum Orbit to deploy on Solana” suggests an Ethereum L3 or custom chain could effectively plug into Solana via Raiku. This is huge: it means an Ethereum dApp could enjoy Solana’s performance and user base without abandoning its codebase. All of this is enabled by global accounts, users wouldn’t even need to switch wallets or bridge tokens; the EVM extension would recognize their same wallet (possibly via an address derivation or mapping) and could use Solana’s native assets.