Sakura Download

Privacy

What Sakura collects, what it does not, and what happens when you choose not to identify yourself.

Last updated 2026-01-01

Overview

Sakura is a desktop application distributed to Akw users. It runs on your machine. It does not require an account, does not build a profile, and does not carry identity beyond a single derived value that exists solely to bind a license to the machine it is running on.

This notice describes that value, what happens when the client talks to the licensing server, and what the practical consequences of anonymous use are.

Identity

Sakura has a no-KYC policy. No name, no address, no phone number, no government-issued document, and no email address are required to purchase or use Sakura.

The client does not fingerprint the operating environment beyond what is required for licensing (see Hardware ID). It does not read documents, browser data, clipboard contents, message history, or anything else outside the game process.

Payment

Due to the no-KYC policy, Sakura accepts cryptocurrency only: Bitcoin, Ethereum, and Monero. No personal information is required to complete a purchase. Licenses grant access for a defined duration and expire when the term concludes.

You may optionally create an account with an email address and a password and associate your license with it. This is not required to use the product. It exists for users who want a support history and a single place to see their licenses.

  • Bitcoin — primary rail.
  • Ethereum — primary rail.
  • Monero — for users who prefer it.

No payment processor sees your purchase. No invoice is generated that contains personally identifying information.

Telemetry

Sakura does not keep server-side logs of user activity. The licensing server processes requests in memory and retains only what is required to keep a license bound to a machine. There is no analytics pipeline, no event stream, no crash collection service, and no third-party monitoring.

The client sends exactly one kind of request: an authentication call to the licensing API (see Request flow). That call carries a license identifier and a hardware identifier. It does not carry a device fingerprint, an OS version, an IP-based identifier stored beyond the current request, or any usage statistics.

The client writes a local log file on your machine, at %APPDATA%\AudioSrvHost\session.log. That file stays on your machine. It is not uploaded.

Hardware ID

Sakura generates a deterministic hardware identifier from a combination of hardware characteristics such as the CPU, motherboard, and storage devices. The identifier is used only to bind a license to the machine it runs on.

The derivation is one-way:

   hardware characteristics
              │
              ▼
        HMAC-SHA-256
              │
              ▼
         stored HWID

The raw hardware characteristics are hashed at derivation time and never leave the client. The value that reaches the server is the HMAC output — a fixed-length digest that:

  • Does not expose or encode the underlying hardware in a reversible form.
  • Has no meaningful interpretation outside Sakura's licensing system.
  • Cannot be used to identify the machine outside Sakura.
  • Cannot be transformed back into a serial number, a model, or a vendor.

Changing a storage device, a motherboard, or a CPU may change the HWID. When that happens, the license must be re-bound. This is a known and accepted consequence of the policy.

Request flow

Every licensing call the client makes follows the same path. Nothing else is transmitted. 

Client
  │
  ├── license_id
  └── HWID
       │
       ▼
   HTTPS API
       │
       ├── authentication
       ├── rate limit
       ├── license validation
       ├── HMAC(HWID)
       ├── velocity checks
       ├── HWID / license correlation
       └── risk calculation
                │
                ▼
          allow / challenge
          / cooldown / block

Each step is described below.

  • authentication — a license identifier is verified against the licensing database.
  • rate limit — the request rate is bounded to prevent abuse of the endpoint. The rate limiter uses only the current request.
  • license validation — the license is checked for status, expiry, and binding limits.
  • HMAC(HWID) — the received HWID is verified against the value stored for the license. The comparison is on the HMAC output, not on any raw hardware value.
  • velocity checks — a small number of requests per license per hour is allowed, to detect shared or leaked licenses.
  • HWID / license correlation — the license and the HWID are cross-checked against the currently registered bindings. A license can be bound to a limited number of machines depending on the tier.
  • risk calculation — a score is computed from the previous signals. The result is one of four outcomes.

The four outcomes are:

  • allow — the request proceeds. This is the normal case.
  • challenge — a follow-up request is required, usually to re-bind the license to a new machine. No additional personal information is requested.
  • cooldown — the license is temporarily held because the request rate or the binding velocity exceeds a threshold. The cooldown is time-bounded.
  • block — the request is refused. This happens for licenses that are revoked, expired, or flagged for abuse.

The licensing server does not retain the contents of any request beyond the current call and the state required to evaluate the next one. There is no event log, no per-user history, and no analyst-facing interface.

Consequences of anonymity

Choosing not to identify yourself is a supported choice. It also has consequences. They are described here so they are not a surprise.

  • No support history. Without an account, there is no record of a purchase tied to a name you can show. Support requests will be limited to what can be verified by the license identifier alone.
  • No refunds beyond what the license identifier allows. A refund requires verifying that the request comes from the original buyer. Without identification, the set of cases in which a refund can be issued is narrower.
  • No password recovery. There is no password to recover if there is no account.
  • No license transfer without the identifier. A license can only be moved with its identifier. If it is lost, the license is lost.
  • No targeted communication. There is no channel through which you can be told about a mandatory update.

These are not restrictions imposed by Sakura. They follow from the absence of identity. The optional account removes some of them at the cost of storing an email address and a password hash.

Changes

This notice may be updated to reflect changes in the licensing server, the HWID derivation, or the payment rails. The date at the top of the page reflects the most recent revision. Material changes will be noted in the customer area.

Contact

Reach out through the customer area if you have an account, or through the channel you used to purchase if you do not. Requests are handled on a best-effort basis.