Kaito Pulse Went Open Source After Privacy Backlash Over X Tracking

A scheduled release of 32.6 million KAITO tokens on August 20 formed part of the wider launch backdrop. The release was reported as 7.63% of circulating supply.

How the zkTLS verification was supposed to work

Kaito said Pulse uses zero-knowledge TLS, or zkTLS, for browser-based verification. The basic promise is that a user can prove a specific claim from a third-party website without handing Kaito a full copy of the underlying account data.

According to Kaito’s response, the user must actively start a verification. The browser then generates an encrypted proof, and Kaito receives the resulting proof or attestation rather than the complete account dataset or browsing history.

That distinction mattered after early reports discussed access to services including ChatGPT, Claude, and Binance. Follow-up reporting clarified that those sites were accessed as part of a user-initiated verification flow, not as evidence that Pulse continuously collected those services’ data in the background. The reported retained result was the attestation generated by verification.

zkTLS therefore addressed one part of the privacy question: how much information is disclosed when proving an off-platform claim. It did not, by itself, answer what the extension could observe locally or how identifiers and usage telemetry might be linked.

What the source-code review alleged

On August 18, analyst 0x_ultra said a review of Pulse’s source code had identified several forms of data collection. The most prominent allegation concerned a device fingerprint built from multiple signals, including how a GPU rendered an invisible image, the device or hardware model, and the way hardware handled a test tone. The review said the resulting identifier could be associated with an X account.

The review also alleged detailed tracking of activity inside X, including:

• Posts or content shown to a user
• Scroll or dwell duration
• Clicks and other interactions
• Searches and bookmarks
• Periodic activity or “heartbeat” packets sent at roughly 30-second intervals

These points should be treated as allegations from code inspection and subsequent reporting—not as an independently adjudicated finding that Kaito misused the information. The important issue was the scope and linkability of the reported collection: a device-level identifier paired with behavioral data can create a much richer profile than a one-time proof of a trading position.

How Kaito responded

Yu Hu said the fingerprinting was intended for anti-abuse purposes, such as limiting click fraud and Sybil activity, rather than analytics or user profiling. He also said Pulse’s collection of X exposure, dwell time, and interactions was authorized when users installed the extension.

Kaito further stated that browsing activity on sites outside X was not sent to the company except where a user actively initiated a supported verification. The response also said Pulse did not capture screens, passwords, or keystrokes.

One point of friction involved Chrome’s permissions language. Users saw a permission indicating that the extension could read and modify data across websites. Kaito said that wording was broader than the product’s intended use and promised to correct the permission display in a later version.

What changed by August 21

The immediate outcome was a transparency concession. Kaito said it had open-sourced Pulse, with assistance from the analyst involved in the review, and submitted an updated version to the Chrome Web Store. At that point, the new submission was still under routine review rather than confirmed as approved.

That sequence—from launch on August 18, to public scrutiny, to an August 19 response, to a public repository by August 21—gave the controversy a concrete result. Users and outside reviewers gained the ability to inspect the implementation instead of relying only on product descriptions or permission prompts.

The broader privacy lesson

The Pulse dispute illustrates why privacy claims for browser extensions need to be evaluated in layers.

First is the proof layer. zkTLS can reduce the amount of underlying account information disclosed when a user verifies a specific claim.

Second is the collection layer. A browser extension may also observe activity on the sites where it runs, depending on its permissions and implementation. Kaito acknowledged that Pulse collected authorized X interaction data and separately defended device fingerprinting as an anti-abuse measure.

Third is the linkability layer. Even if a service receives only an attestation from a third-party account, privacy concerns can remain if device signals, account identities, and behavioral telemetry can be connected. That was the central tension raised by the review.

Pulse’s launch did not establish that zkTLS and privacy are incompatible. It showed something narrower and more practical: protecting the contents of a verified claim is not the same as minimizing all data collected by the client that generates the claim. Community scrutiny forced that distinction into the open—and, within days, pushed Kaito to make the code publicly inspectable.