Live protocol · disposable credits

Use an anonymous credit token

This is the real classical protocol, not a simulation. Your browser creates the token, mines the issuance challenge, builds the zero-knowledge spend proof, and keeps the bearer secret on this device.

Everything here is experimental and unaudited. Credits are deliberately worthless and may disappear when the issuer epoch changes.

Your first credit spend

Start with a fresh wallet, or add a new 2-credit token to the tokens you already have.

  1. Issue 2 credits below. Keep this page open while your browser mines the challenge.
  2. Select that 2-credit token, spend 1, and leave the requested return at 0.
  3. Look at the replacement token: it holds 1 credit. The original token has been consumed.

You can spend the remaining credit once more. To repeat this from code, run the client example.

Starting

Loading the browser wallet.

Browser balance

0 credits

Scheme
Classical ACT
Issuer epoch
…
Storage
This browser

Your browser knows

  • The token secret and exact hidden balance
  • Which issuance produced which token
  • The journal needed to recover after a dropped connection

The issuer sees

  • A blinded issuance request and public grant
  • A spend amount, one-time nullifier, and zero-knowledge proof
  • No account, cookie, or token history
1

Issue credits

Create a fresh hidden token and pay for it with browser-mined proof of work.

For this browser demo, issuance is limited to 32 credits so the wait stays human.
2

Spend anonymously

Consume one token and receive a fresh, unlinkable change token.

Leave the return at 0 for a simple spend. With a larger token, you can also explore refunds: spend 3 and ask for 1 back for a net payment of 2.

Tokens in this browser

  • The wallet is loading.

Activity

  1. Wallet activity will appear here.

Local bearer state. Clearing site data, using a private window, changing browsers, or pressing the button here destroys these demonstration credits. The issuer cannot recover them.

What happens when you press the buttons

  1. The cryptography runs locally. Rust is compiled to WebAssembly and runs inside a background worker, so mining and proof construction do not freeze the page.
  2. Secret state is journaled first. Before any issue or spend request is sent, the exact request and the state needed to finish it are committed to browser storage.
  3. Retries are byte-for-byte identical. If the connection dies after the issuer records a response, reloading this page resends the journaled request and receives that response again.
  4. A spend creates change, not a mutable balance. The old token is consumed whole. Its zero-knowledge proof produces a fresh token holding the remaining balance plus any issuer return.

The failure-semantics page explains why the journal and replay rule are part of the monetary protocol rather than ordinary application polish.