user guide

KIRITE wallet

KIRITE ships as a Telegram miniapp today and as a Chrome extension once the Web Store listing clears review. Both surfaces drive the same Solana program, the same Groth16 shield pool, and the same stealth-address recipient flow. Switching surfaces changes the UI, not the cryptography.

The live wallet UI is embedded below. Create a password, explore the views, and walk through the flows as you read. It uses the same code shipped in the extension.

status

The Telegram miniapp is the active surface today (@kirite_wallet_bot). The Chrome extension is built and pending Chrome Web Store review; until the listing goes live, the steps below describe the final installed experience. Both surfaces share the same on-chain deposit and withdraw paths.

installing

  1. Open the Chrome Web Store and search for KIRITE Wallet.
  2. Click Add to Chrome on the listing page.
  3. Confirm the install prompt.
  4. Click the puzzle icon on the Chrome toolbar and pin KIRITE Wallet so it stays visible.

Once installed, clicking the KIRITE icon on the toolbar opens the wallet popup. Telegram users open the bot instead. Nothing further needs to be configured.

creating or importing a wallet

On first open the wallet shows a lock screen. From here:

  • Create new wallet generates a fresh Solana keypair plus a separate x25519 viewing keypair used for stealth-address scanning.
  • Import wallet accepts either a base58 private key or a 12 / 24 word seed phrase.

Private keys and seed phrases are masked while typing. A small show button next to each label reveals the text briefly so you can verify what you pasted. Both the spending key and the viewing key are stored encrypted in the local app storage. They never leave the device.

your two addresses

After unlocking, open the Receive view. Two tabs:

  • Public Address is your normal Solana address. Anyone can send you funds here, but the transfer is fully visible on Solscan.
  • Stealth Meta is a longer address that combines your spending public key and your viewing public key. Share this one with anyone who wishes to send you private transfers.

Each private payment you receive lands at a fresh one-time stealth address derived from your Stealth Meta. No observer can link those stealth addresses to your main wallet without your viewing key.

sending a public transfer

  1. Open the wallet, keep the privacy toggle off.
  2. Click Send, paste the recipient's Solana address, enter an amount.
  3. Click Send. A single Solana transaction is signed and broadcast.

This behaves identically to a transfer in Phantom or Backpack. Sender, recipient, and amount are all public on-chain.

sending a private transfer

  1. Toggle Privacy on. The balance panel gains a green SHIELDED indicator.
  2. Click Send, paste the recipient's Stealth Meta, choose a denomination (0.01 / 0.05 / 0.1 / 1 / 10 SOL).
  3. Click Send Privately. The wallet generates a Poseidon commitment locally, signs a deposit transaction into the shield pool, and stores the note for later proof generation.
what happens under the hood
  1. The browser generates a random nullifier secret and blinding factor (32 bytes each, BN254 field elements). They never leave the device.
  2. It computes a Poseidon commitment over (nullifier secret, denomination, blinding factor, leaf index) and stores the resulting note in local storage.
  3. An ECDH derivation against the recipient's view key produces the one-time stealth address that will eventually receive the unwrapped SOL.
  4. The user signs the deposit transaction. The shield pool program inserts the commitment as a Merkle leaf and emits a DepositCommitted event.
  5. After a short delay (10 minutes recommended for timing-correlation resistance), the wallet generates a Groth16 membership proof using snarkjs WASM (~1s desktop, ~3s mobile). The proof binds to the recipient stealth address and reveals only a nullifier hash and a Merkle root.
  6. The proof is sent to the relayer, which submits the on-chain withdraw, unwraps the resulting WSOL, and forwards plain SOL to the stealth address atomically. The relayer pays gas and per-nullifier rent.

The on-chain verifier never sees the nullifier secret, the blinding factor, or the link between deposit and withdraw. The relayer never sees the secret either; it only relays the proof. The recipient's wallet never appears on the withdraw transaction at all.

receiving a private transfer

Private payments do not appear in your main balance automatically. Each one lands at a fresh stealth address that only you can derive. To find them:

  1. Open the Activity tab and click Scan inbox.
  2. Click Start Scan. The wallet walks recent KIRITE program signatures, filters candidates by the 1-byte view tag, runs ECDH locally for every remaining candidate, and surfaces matches.
  3. Matching withdrawals show the destination stealth address and a confirmation badge.
  4. Subsequent scans start from the last seen signature, so they stay fast as the program log grows.

sweeping funds to your main wallet

Each detected stealth balance offers a Sweep to main wallet button. Sweeping signs a transfer from the stealth address to your public address using the stealth keypair the wallet just derived locally. The sweep transaction itself is a normal Solana transfer, so your main balance updates immediately once it confirms.

Sweeping is optional. Many users keep balances at the stealth address and use the wallet to send onward without ever consolidating, which preserves more privacy.

what the rest of the world sees

For a public transfer, Solscan shows the sender, recipient, amount, and timestamp. Every block explorer and graph tool such as Arkham or Nansen can reconstruct the payment relationship forever.

For a KIRITE private transfer, Solscan shows two unrelated events: a deposit from your wallet into the shield pool (commitment hash only, no amount detail beyond the denomination), and a much later withdraw from the pool to an unfamiliar one-time stealth address. The Groth16 proof contains no clue which leaf was spent, and the stealth address has no prior on-chain history. Chain analysis ends at the pool boundary on both sides.

security notes

  • Your spending key, viewing key, and shielded note material never leave the device. No server ever sees them.
  • The relayer is a stateless executor. It cannot forge a Groth16 proof, and it cannot derive your nullifier secret from the public inputs alone.
  • Always double-check the recipient's Stealth Meta before a private transfer. If the meta address is wrong, the funds end up at an address no one can derive.
  • Practical privacy depends on the active anonymity set. For high-value transfers, wait until the chosen denomination has at least 16 unspent leaves before withdrawing.
  • An independent third-party audit of the shield pool program and the membership circuit is planned for the first phase post-launch. Until then, deposit only what you can afford to lose.

troubleshooting

If a send fails, the wallet's completion screen shows the underlying error. Common causes:

  • Insufficient funds: the sending amount plus roughly 15,000 lamports in fees must fit the balance.
  • Pool full: each pool denomination caps at 32,768 leaves (v2 height-15 tree). Practically users will never hit this, but if a pool fills the wallet rolls deposits into a fresh pool at the same denomination.
  • Proof generation slow: on older mobile devices snarkjs WASM can take 5+ seconds. The progress indicator updates every second.
  • RPC rate limit: the public Solana RPC is occasionally rate-limited. Retrying usually resolves it.

For unresolved issues open the popup, right-click, and choose Inspect popup. The browser console prints the exact RPC error and the proof generation log.