I Used AI to Read Tari's Private Stablecoin Code Line by Line

Table of contents

Introduction

I hold XTM. The Tari team has repeatedly mentioned the prospect of someone building a private stablecoin on the network. It sounds appealing: a stablecoin you could use like USDT, but without exposing your balance or transfer amounts to others.

But talk is one thing. Has the code actually been written? How far along is it? Is there real work behind the idea, or is it just a promise?

A community member recently shared a GitHub link in a group chat, bringing this repository to my attention:

https://github.com/tari-project/stable-coin

I decided to take a closer look.

Finding the repository

The repository was tucked away among the tari-project organization’s 132 repositories, outside the usual showcase. With 0 stars and 4 forks, it had attracted little attention.

The basics:

• Created: November 13, 2023; public from the outset
• Last updated: April 7, 2026, with commits still arriving just hours before the check
• Development history: two and a half years, with 63 commits in total
• Main developer: Stan Bondi (sdbondi), also a core developer of tari-ootle (Tari L2)

Reading the code with Claude Code

I am not a professional programmer and cannot read Rust code. So I used Claude Code to fetch every file in the repository and read through it line by line. The process took about a minute and a half. That automated reading was not a security audit; the technical judgments below should be understood as the analysis produced at the time.

The repository is organized as follows:

stable-coin/
├── applications/
│   ├── cli/         → Command-line management tool
│   └── web/         → Web management interface
└── templates/
    ├── stable-coin/                              → V1: basic public version (deprecated)
    ├── private_stable_coin/issuer/               → V2: private version with user badges
    ├── private_stable_coin/issuer-no-user-badge/ → V3: current main version
    └── private_stable_coin_custom_account/       → V4: most complex version, with custom accounts

The four versions become progressively more complex. Their names and directory structure suggest an evolving design rather than a collection of unrelated pieces.

How the stablecoin works

Put simply, there are three main pieces. The following is Claude Code’s interpretation of the contracts; this article does not provide separate verification.

1. A private token (stealth token)

This is the stablecoin itself. Unlike an ordinary token, it does not expose how much you hold or transfer. The underlying cryptography uses what are called “Pedersen commitments.” As a simple analogy, the amount is locked in a box, and only someone with the key—the view key—can see it. Tari L2 provides this privacy layer; the contract calls its interfaces.

2. A wrapped token

If you need to use the stablecoin publicly, you can convert the private token to a public version at a 1:1 rate, with a 1% fee. Conversion in the other direction is free.

3. An administrator badge

The administrator holds a kind of pass in the form of an NFT. Only its holder can mint new tokens, freeze assets, or blacklist users. Calls to these functions without the badge are rejected.

The contract runs on Tari’s L2 network, Ootle. Its code is compiled to WebAssembly for on-chain deployment.

The main workflow:

1. The issuer deploys the contract and mints private tokens into a vault.
2. The administrator distributes tokens to users.
3. Users transfer tokens directly to one another, with amounts hidden on-chain.
4. Users can exchange private tokens for public wrapped tokens, or convert them back.
5. The administrator can blacklist users, freeze assets, and forcibly recall tokens—compliance mechanisms similar to those in USDC.

Who is building it?

Nearly all the commits came from Stan Bondi. Over two and a half years, the repository accumulated 63 commits—fewer than three per month on average. He is also responsible for core development on tari-ootle. Commit counts show code submissions, not staffing levels or development speed. My impression at the time was that the stablecoin was being maintained alongside his main work.

Potential issues identified by Claude Code

The following five points came from Claude Code’s analysis at the time, including the severity ratings in parentheses. This article provides no corresponding build results, runtime tests, or independent review evidence. These are therefore potential issues, not confirmed defects or security audit findings.

Issue 1 (model rating: moderate): the pause function may have no effect

The contract has a “pause” control. An administrator can call pause() to stop operations in an emergency—an apparently important safety feature.

According to Claude Code’s reading, however, pause() merely sets a flag to true, while the other contract functions do not check it. If that reading is correct, it would be like pressing an emergency stop button while the machine keeps running.

Issue 2 (model rating: more serious): a core compliance function in the advanced version may not work

In the most complex fourth version, the developer left this comment about freezing a user account through a cross-contract call:

“authorization doesnt carry though to the cross-component call, so this doesnt actually do anything”

In other words, the comment says the freeze call has no effect because authorization is not carried across, and marks it as a TODO for further consideration. This comment informed the analysis at the time, but it records the developer’s view when it was written. The article includes no runtime results establishing that the behavior was reproduced.

Issue 3: the basic version may fail to compile

Claude Code concluded that V1 referenced a nonexistent field and would not compile. That version is deprecated but remains in the repository. According to the same analysis, this does not affect the main version, V3.

Issue 4: a potential overflow in fee calculation

An intermediate step in the fee calculation multiplies the amount by 1000. For extremely large amounts, this could exceed the numeric limit and silently truncate the value, producing an incorrect result.

Issue 5: reverse conversion may affect the total supply

When wrapped tokens are converted back to private tokens, the contract mints new tokens rather than withdrawing them from a vault. If burns in one direction and mints in the other do not match precisely, the total supply could diverge.

What looks good

These observations also come from the same reading; this article does not provide separate verification.

The tests are substantial. The test file is close to 1,000 lines long and covers ten main scenarios, including minting and burning, user transfers, blacklist management, wrapped-token conversion, conversion limits, and rejection of unauthorized calls. Each test has a clear structure.

Code standards are strict. Numerous code-checking rules are enabled to guard against common mistakes such as unused variables, dead code, and out-of-bounds array access.

Every operation leaves an on-chain record. Minting, burning, transfers, and blacklisting all emit events, making later review easier.

The permission model is sensible. Using an NFT as an authorization credential rather than hard-coding an administrator address is an established smart contract design pattern.

Estimated progress

Both the status descriptions and percentages below come from Claude Code’s analysis at the time. They are not objective measurements or figures supplied by the project.

What remains before production deployment:

Verify and address the potential issues above, add edge-case tests, obtain a third-party security audit—a prerequisite for a regulated issuer—introduce multisignature administration, move dependencies from development branches to stable versions, and improve documentation.

Based on its assessment of staffing and pace at the time, Claude Code estimated 12 to 18 months before the project would be ready to deploy, potentially falling to 6 to 9 months with a larger team. This was a model-generated estimate, not the project’s plan or any kind of commitment.

Additional context

Centralization

The administrator has broad powers: creating an unlimited number of new administrators, forcibly recalling users’ tokens, and freezing assets. These are standard features of compliant, fiat-backed stablecoins—USDC has similar mechanisms. They are not inherently technical defects, but users need to understand them.

The issuer

Hack VC’s investment thesis mentions an issuer that has signed on and is waiting for Ootle mainnet to be ready. This is a claim from that third-party document; this article provides no independent evidence verifying it. The prerequisites for an issuer to proceed include audited contracts, core functions without known defects, and stable dependencies. According to the assessment above, those conditions had not all been met at the time.

Conclusion

Is the stablecoin actually being built? Yes, the code exists. Claude Code assessed the architecture as sound, with a clear progression from V1 to V3.

How far along is it? The basic framework is in place and tests cover the core workflows, although this article provides no execution results. The potential issues above have not been conclusively established, no third-party security audit records are cited here, and the analysis at the time described documentation as limited. There is still a substantial gap between this and a launch-ready product.

What is the code quality like? Claude Code rated it above average: in its assessment, the developer understands cryptography and smart contract design, and the tests are more thorough than in most Web3 projects. Looking only at the commit records listed in this article, the impression is of a small team and a slow pace, with the potential issues noted above affecting important safety functions.

Can a private stablecoin work? According to Claude Code’s analysis at the time, the technical approach appears feasible, with Tari L2’s privacy primitives providing the underlying support. But going from code to a product still involves substantial work on security audits, multisignature administration, fiat reserve integration, and regulatory compliance.

This is what I read with Claude Code’s help, together with the analysis it produced. It is not a security audit or investment advice. The repository is public, and anyone can examine it for themselves.

Date examined: April 8, 2026
Repository: https://github.com/tari-project/stable-coin
Analysis tool: Claude Code Opus 4.6