Tari Briefing (Issue 3)

Table of contents

The Ootle testnet goes live

In the previous two issues, we followed eight years of work on Tari through its mainnet launch, followed by preparations for a hard fork and broader access through exchanges.

This issue marks the beginning of another stage of development.

The Ootle L2 testnet has launched. Alongside it, Tari has announced a strategic shift with unusual candor: it is no longer treating human developers as its primary audience, instead positioning AI agents as the main participants in its L2 ecosystem.

1. Ootle L2 testnet Esmeralda launches

In early March 2026, Tari opened its L2 testnet, Esmeralda, to the public. For the first time, the execution layer of Tari’s two-layer architecture is available for the public to interact with.

The testnet currently supports the following core capabilities:

Note: tTARI (testnet TARI) is for testing only. Do not buy it through any channel.

The network is currently in Phase 1. The faucet is unlimited to make it as easy as possible for developers to get started. Phase 2 is expected to focus on activating the L1↔L2 Burn Bridge—the cross-layer conversion path in the Turbine economic model—and introducing faucet limits.

Community testing of the Burn Bridge began in mid-March. The XTM→tTARI conversion mechanism, previously described in the white paper, is beginning to take a form that can be tested.

2. A strategic shift: no longer human-first

The Ootle launch announcement contained an unusually direct statement:

“We are no longer building a human-first user or developer experience. We believe doing so is the wrong approach, given the rapid adoption of agents.”

This is more than a change in rhetoric: the strategic statement is accompanied by changes in the code.

On March 2, co-founder fluffypony personally committed feat: agent skills. The team followed with six related commits over the next three days, covering documentation discovery for AI agents through llms.txt, support for the Agent Skills Discovery standard, and a redesign of the developer documentation homepage as an “agent-first landing page.”

Agent Skills provide a standardized way to describe the operations an AI agent can perform on Ootle, such as calling contracts, querying on-chain state, and initiating transactions. llms.txt is an emerging machine-readable convention for documentation discovery. Much as robots.txt serves web crawlers, it helps compatible agents find the information they need to work with Ootle.

Agent Rule Files have now been adapted for nine widely used AI coding tools:

Claude, Cursor, Copilot, Windsurf, Gemini, Codex, Aider, Amp, Antigravity

Rather than a general claim of compatibility, this involves adapting support for each tool. In principle, a developer using one of them can point an agent at ootle.tari.com and ask it to “build an application on Tari” without first working through the documentation manually.

The first module on the ootle.tari.com getting-started page is aimed at AI coding agents, with skill installation guidance for Claude Code, Cursor, Windsurf, and Aider.

3. Agentic payments: a core use case for a private L2

An emerging AI agent economy could generate substantial demand for agents to exchange value autonomously. In our view, traditional financial rails cannot meet the combination of permissions, speed, and programmability this requires, leaving crypto payment rails as the only viable infrastructure path. Autonomous transactions between agents also need privacy to prevent their activity from being tracked, front-run, or exploited.

This is where Tari’s private L2 could have a role: amount confidentiality and holder confidentiality, combined with a programmable contract layer, form the technical basis for agent payment rails.

The team describes Tari’s role as providing private, programmable value rails for autonomous agents.

4. A stablecoin partner brings payment use cases into focus

The March 10 Tari Show disclosed a substantive development: a licensed issuer of fiat-backed stablecoins has confirmed plans to join Ootle and issue a stablecoin on L2 with confidentiality by default and peer-to-peer transfers.

A March 18 progress update indicated that development of the stablecoin contract template was under way.

The proposed balance between privacy and regulation is worth noting. The issuer itself would remain transparent to regulators, meeting its licensing obligations, while transfers between users would remain private. This offers a pragmatic approach to maximizing user privacy within regulatory constraints.

Without stablecoins, agentic payments would be difficult to put into practice. Securing this partner is a step toward turning the concept into working infrastructure. The issuer’s identity has not yet been made public; disclosure is expected during Phase 2, alongside activation of the Burn Bridge.

5. Expanding developer tools: ootle.js and language bindings

The March 18 development update reported that the JavaScript SDK had been renamed from tari.js to ootle.js, with plans to expand language bindings to Python, Go, and others.

The strategic relevance is straightforward: most AI agent frameworks, including LangChain, AutoGen, and CrewAI, are primarily developed in Python. Ootle contracts are currently written mainly in Rust, creating an integration hurdle for agent frameworks. Once available, Python bindings should make it considerably easier for agents to interact with Ootle, providing a necessary tooling component of the agent-first strategy.

6. fluffypony steps away temporarily

On March 4, 2026, co-founder Riccardo Spagni (fluffypony) published a statement on X:

fluffypony’s original post, dated March 5, 2026, announcing a temporary break from Tari-related work for personal reasons.

On the same day, fellow co-founder Naveen posted an official response in the Tari Alpha Club:

“This is in no way impacts the project, our vision, or our plans. We hope Riccardo can sort things out for himself.”

The timing is notable: fluffypony committed feat: agent skills on March 2 and announced his departure two days later. That commit may have been his last substantial contribution in this phase, laying technical groundwork for the agent-first strategy for the core engineering team to carry forward.

Commit records show lead developer sdbondi maintaining a frequent and steady pace of contributions throughout March, with no apparent interruption to Ootle development.

fluffypony’s departure is for personal reasons and is described as temporary. The community deserves to know this and to respond on that basis, rather than with either panic or indifference. Ultimately, a project’s continuity rests on its code and organizational structure, not on any single individual.

7. Development at a glance

A summary of key commits in March:

The arrival of Ledger support is a step toward production-grade asset security infrastructure for Ootle, providing a stronger foundation for future DeFi applications and users holding larger amounts of assets.

8. L1 mining updates

8.1 Antminer X9 announced

On December 26, 2025, Bitmain announced the Antminer X9, designed specifically for RandomX. Its main specifications are:

Official Bitmain Antminer X9 promotional image, listing a US$5,600 price and expected shipping in July 2026.

It is worth noting that the X9 is not a conventional ASIC. It is a cluster of custom RISC-V CPUs, suspected to be Sophon SG2044 chips, with substantial DDR5 memory to meet RandomX’s memory-intensive requirements. Monero core developers have therefore argued that an algorithm update cannot exclude the X9 entirely: CPUs can run arbitrary software, unlike conventional ASICs.

The response from RandomX v2

Monero core developer sech1 has stated that RandomX v2 will reduce the X9’s mining efficiency by at least 30%, without eliminating its advantage altogether. The primary aim of v2 is to improve the energy efficiency of modern CPUs, including Zen4/Zen5 and ARM Cortex X4. Implementation is expected in the first half of 2026, as part of Monero’s next hard fork.

What changes for merged mining—and what does not

Because Tari shares hashrate with Monero through RandomX merged mining, these developments also matter to Tari miners. A large influx of X9 units would raise overall RandomX network difficulty, reducing output per machine for CPU miners. If RandomX v2 arrives as planned and substantially reduces X9 efficiency, the balance could shift back toward CPU miners.

Some participants in Reddit’s r/Monero community have also brought up Tari’s multi-algorithm mining design, suggesting that Monero could learn from its approach to balancing participation by CPUs, GPUs, and specialized hardware. This is an instance of unsolicited recognition of Tari’s consensus design from outside its own community.

Miners considering an X9 for merged mining should assess the potential return carefully until the RandomX v2 upgrade schedule becomes clearer.

8.2 A call for RandomX v2 benchmarks

The Monero development team is collecting real-world hardware benchmarks for the RandomX v2 upgrade, with a particular interest in newer Intel CPUs. Developers have published a standardized Linux testing script that miners can run to contribute results.

Because Tari L1 uses RandomX merged mining, changes to RandomX directly affect Tari miners’ hashrate and hardware compatibility. The upgrade schedule has not yet been finalized, and data collection is still under way.

Tari miners running RandomX merged mining may want to follow further announcements through Monero’s official channels and assess how v2 could affect their hardware.

Testing script: https://github.com/Fountain5405/scriptsforthewin
Results: https://gist.github.com/SChernykh/6058ecf01c929883b9d19c7eeadc8809

8.3 xmr.pw: a new community pool supporting Tari merged mining

Community miner RealAleNet has launched xmr.pw, a public pool focused on a clean, modern dashboard and clear visualizations of miner data. It is still in beta and remains small.

The pool supports three mining modes: Classic PPLNS, Solo, and P2Mining. Its distinctive offering is P2Mining, which uses P2Pool for settlement without requiring miners to set up their own nodes. They can simply point their miners at pool.xmr.pw:4242, as they would with an ordinary pool. RealAleNet explicitly acknowledges that this is still centralized and is not equivalent to running P2Pool directly, although it offers key benefits such as ongoing block rewards. If you already run P2Pool successfully, this pool may not be for you. If you want an easier entry point while retaining the underlying P2Pool reward structure, it may be worth trying.

All three modes support Tari merged mining, allowing miners to earn XTM alongside XMR without splitting their hashrate. During testing, the operator is renting hashrate to direct to the pool and distributing the proceeds to participating miners.

GeoDNS covers Europe, the Americas, and Asia. The fee is 0.5%, and the minimum payout is 0.001 XMR.

Pool: https://xmr.pw

8.4 P2Pool Starter Stack: a one-click mining setup

Community miner VijitSingh97 has released an open-source mining stack that brings the following components together in a single Docker installation:

• A Monero full node
• P2Pool mining
• Tari merged mining
• A basic monitoring dashboard

All traffic is routed through Tor by default, removing the need to configure the privacy layer manually. The intended audience is people who want a simple, private way to mine at home without specialist node-administration skills.

The tool addresses a long-standing gap: combining P2Pool with Tari merged mining offers a better reward structure, but manual setup has put many miners off. A one-click Docker setup substantially lowers that barrier and could help broaden participation in Tari merged mining.

Project: https://github.com/p2pool-starter-stack/p2pool-starter-stack

9. Roadmap and outlook

Completed in March:

• Ootle L2 testnet Esmeralda launched
• Agent Skills and support for nine major AI coding tools completed
• Wallet SDK released publicly, opening up ecosystem access
• Initial Ledger hardware wallet integration
• Stablecoin partner confirmed

In progress:

• Community testing of the L1↔L2 Burn Bridge
• Stablecoin contract template development
• Expansion of ootle.js language bindings to Python and Go
• Expansion of the library of secure smart contract templates

Worth watching:

• Blink: the March 18 Tari Show described it in terms of “high precision, with continuing improvements in speed and cost.” This appears consistent with the previously mentioned “distribution-oriented product to be announced soon,” although its exact form has not been publicly disclosed.

The protocol first, agents next

Tari spent eight years refining L1 and several more designing Ootle. When the testnet finally launched, it did so with a view that remains a minority position: the future users of on-chain capabilities at scale will not be humans, but AI agents.

No one yet knows whether that view is right. Agent tooling is still fragile, and agentic payments remain some distance from widespread adoption. But one thing is already visible: while most projects are designing products to compete for human developers’ attention, Tari is preparing infrastructure for a different set of “users.”