Integrations

Pick a tier

Add ZKAS to your wallet

Three ready-made pieces, no cryptography to write:

npm install @zkas/sdk

import { ZKasClient, wasmPaymentSigner, DEFAULT_MAX_FEE_SOMPI } from "@zkas/sdk";
import { generateWallet, fvkHex, verifyAndSignPayment } from "./signer";

// 1. Keys on the device. seedHex is the secret - store it like a private key.
const { seedHex, address } = await generateWallet("mainnet");

// 2. Register the VIEWING KEY with a daemon. Never the seed.
const client = new ZKasClient({ baseUrl: WALLETD_URL, token: perWalletToken });
await client.watch(await fvkHex(seedHex), /* birthday DAA */ 0);

// 3. Balances are decimal strings. BigInt them.
const bal = BigInt((await client.balance()).balance_sompi);

// 4. Send: prepare -> verify-on-device -> sign -> submit, all inside send().
const signer = wasmPaymentSigner({ seedHex, fvkHex, verifyAndSignPayment });
const res = await client.send(
  signer,
  { to: "zkas:...", amountSompi: 5_000_000_000n, maxFeeSompi: DEFAULT_MAX_FEE_SOMPI },
  (stage) => console.log(stage),   // "proving" | "signing" | "broadcasting"
);
console.log(res.txids, res.feeSompi);

// 1. Register the viewing key.
POST /api/wallet/watch   { fvk_hex, birthday }
     header: X-Wallet-Token: <random 16-byte hex>

// 2. Daemon builds AND PROVES an unsigned bundle. It cannot sign it.
POST /api/wallet/prepare { fvk_hex, to, amount_sompi, allow_partial: false }
  -> { session, sighash, bundle_hex, spend_auth[], disclosure[],
       amount_sompi_exact, fee_sompi_exact, remaining_sompi_exact }

// 3. ON DEVICE, before signing anything:
//    - paid === requested and remaining === 0, else refuse
//    - fee <= your ceiling, else refuse
//    - recompute the sighash from bundle_hex; do NOT trust the returned one
//    - check the bundle against disclosure (recipient, amounts)
//    then sign each spend_auth[].alpha

// 4. Hand the signatures back.
POST /api/wallet/submit  { session, sigs: [{ index, sig }] }
  -> { txid, txids, tx_count, amount_sompi, fee_sompi }

Integrate an exchange or custodian

One deposit wallet + memo

Howevery customer gets the same address plus a unique memo / payment idVerdictUse this. The XRP/XLM destination-tag pattern — one wallet, one scan

One wallet per customer

Howa token per customer, each its own .scanVerdictDoes not scale. Every wallet syncs independently; 350 loaded wallets already strain a 4-core box

1. Split visibility from spend authorityRun a watch-only walletd from the FVK alone to detect and credit deposits. The spending key never touches the deposit scanner. Sign withdrawals on separate infrastructure holding the seed, via prepare → submit.
2. Credit deposits by memoRead /api/wallet/history and match the memo to a customer. Memos are readable per transaction on the receive side, up to 512 bytes.
3. Gate withdrawals on spend_readyNot on synced. And treat missing_history:true as "this balance is a lower bound" — never as final.
4. Consolidate continuouslyWithdrawal latency is 2.4 s × notes spent ÷ cores. Leave --auto-consolidate on, and issue one call for the full amount rather than splitting by hand.
5. Decide your cold-backup conventionZKas has no BIP-39. You may derive the 32-byte seed from a mnemonic yourself and import it as seed_hex, but the derivation is your private convention and the official wallet cannot restore from it. Test the round-trip before funding anything.

Accept merchant payments

The gateway issues invoices, watches for payment and fires webhooks. Same API hosted or self-hosted. Call it from your server — the API key must never reach browser code.

POST /api/v1/invoices
Authorization: Bearer YOUR_API_KEY
Idempotency-Key: order-123
Content-Type: application/json

{
  "orderId": "order-123",
  "amountSompi": "10000000",
  "expiresIn": 900,
  "requiredBlueScore": 10,
  "redirectUrl": "https://shop.example.com/order/123"
}

-> { "id": "inv_...", "address": "zkas:...", "amountSompi": "10000000",
     "status": "new", "checkoutUrl": "https://pay.example.com/checkout/inv_..." }

GET /api/v1/invoices/inv_...

ZKas-Signature: t=TIMESTAMP,v1=HEX_HMAC

expected = HMAC-SHA256(secret, timestamp + "." + exact_request_body)

const response = await fetch("/api/create-zkas-invoice", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ orderId: "order-123" })
});
const invoice = await response.json();
location.href = invoice.checkoutUrl;

Atomic multi-party settlement not wired

A sale, swap or escrow where both sides move or neither does — the seller spends their note, the buyer spends payment notes, both receive, and a public record is written, in one bundle.

Why the bundle shape allows it

Orchard authorizes each action separately: every action carries its own spend_auth_sig over its own randomized alpha, so one bundle can hold spends belonging to different people. What welds them together is one sighash over every action, one proof, and one binding signature that only verifies if the bundle's true net value equals its declared value_balance. Because spend_auth_sig is excluded from the sighash, signatures can be collected independently and cannot be lifted onto a different bundle.

What is missing

Wrapper-level work only — no consensus change, no circuit change:

• the prepare entry point takes one viewing key and applies it to every spend, although the underlying Orchard builder takes an FVK per spend;
• all spends must share one anchor, so a two-party build needs an explicit shared-anchor parameter instead of each wallet choosing its own;
• there is no transport for exchanging partial bundles between parties.

What atomicity does and does not buy

Note that adaptor signatures, FROST and cross-curve DLEQ are all unbuilt, so there is no cross-transaction atomic swap primitive. The single bundle is the only atomic settlement path the chain has.

Prove a payment you made

A third party can verify

Build the send through POST /api/wallet/prepare and store the returned disclosure — spend_value, out_value, out_recipient, out_rseed, rcv per action. A verifier recomputes cmx and cv_net from it and matches them against the on-chain action. No keys needed. There is no flag on /api/wallet/send that produces this

Your own records

POST /api/wallet/settings {"recoverable_history":true} attaches your outgoing viewing key at send time so your wallet can re-read its own sends. Opt-in per wallet, not retroactive, and proves nothing to a third party

Recipient proving receipt

Always possible with their IVK

Publish authenticated public app data no fork needed

For protocols that need publicly indexable data — listings, prices, token metadata — while addresses and balances stay private.

The 512-byte memo travels in enc_ciphertext, which is hashed into the shielded sighash, so memo bytes are already committed by the bundle's signatures. They are only encrypted, not unauthenticated. Make them public by publishing a viewing key:

1. Create a registry address and publish its incoming viewing keyAnyone can now decrypt notes sent to it. Spending still requires the spend key, so this is safe.
2. Send a value-0 note to that addressWith your protocol data in the memo. A zero-value note is a real note.
3. Indexers recover it with scan_bundle(ivk, bundle)Integrity comes free from the signature.

Budget: 512 B per action, each action costs 3,156 B of a 124,744 B transaction, and each announcement displaces a spend slot. Keep bulk metadata off-chain behind a content hash. Build these with the SDK — the walletd send endpoint rejects zero amounts.

SDK and repositories

@zkas/sdk · firecash/zkas-sdk

typed client: prepare/verify/sign/submit, progress, auto-chunking, fee ceiling

firecash/zkas-signer

signer WASM — key derivation and on-device verify-and-sign. No circuit, so it is small

firecash/zkas-rusty

node, consensus, shielded-core, zkas-walletd, shielded-pay CLI

firecash/zkas-payment-gateway

merchant gateway plus web and WooCommerce integrations

firecash/zkas-pool

reference pool and stratum bridge

firecash/zkas-paper-wallet

paper wallet, served from its own GitHub Pages so the page matches the audited source