Skip to main content

​
The use case

A neobank deploys shyware as the account layer for its primary product. Users hold private balances — merchants and counterparties see only that a payment occurred, not the account history or balance behind it. The bank holds the protected off-chain account and linkage records under its own compliance controls and responds to subpoenas exactly as it would today. This is a privacy feature that strengthens the product, not a compliance workaround.

​
How it differs from the stablecoin deployment

Stablecoin issuerNeobank
AssetDollar-pegged tokenBank account balance (internal ledger unit)
Mint/Burn triggerDeposit / redemption via bridgeACH deposit / ACH withdrawal
KYC data locationIssuer compliance databaseBank’s existing KYC system
Protected linkage holderStablecoin issuerBank
User-facing interfaceWallet appBanking app
Regulatory frameworkMSB / FinCENBanking / OCC / FDIC depending on charter
The shyware protocol is identical in both cases. The difference is the bank’s existing regulatory relationship and user-facing product layer.

​
Architecture

Banking app (user)             shyware node (bank-operated)        Bank backend
    │                               │                                    │
    │   ACH deposit arrives:        │                                    │
    │                               │◄────── Mint(user account) ─────────┤
    │                               │                                    │
    │   User pays merchant:         │                                    │
    ├─ POST /transfers ─────────────►                                    │
    │   (nullifier, commitment)     │                                    │
    │◄─ { transfer_id } ────────────┤                                    │
    │                               │                                    │
    │   Merchant's bank queries:    │                                    │
    │   GET /transfer/{id} ─────────►                                    │
    │   (amount + asset only)       │                                    │
    │                               │                                    │
    │   Subpoena arrives:           │                                    │
    │                               │──── Admin API: account history ────►
    │                               │                                    │
The merchant receives proof of payment (amount + transfer_id) without knowing the payer’s account balance, transaction history, or identity. The bank retains full records.

​
Integration points

​
ACH deposit → Mint

// Bank backend: on confirmed ACH deposit
async function handleDeposit(userId, amountCents) {
  const commitment = await getUserAccountCommitment(userId); // H(wallet_address) stored at KYC
  await shywareClient.mint({
    asset_id: "usd",
    account_commitment: commitment,
    amount: amountCents,
    timestamp: Date.now() / 1000 | 0
  });
}

​
ACH withdrawal → Burn

async function handleWithdrawal(userId, amountCents) {
  const commitment = await getUserAccountCommitment(userId);
  await shywareClient.burn({
    asset_id: "usd",
    account_commitment: commitment,
    amount: amountCents,
    timestamp: Date.now() / 1000 | 0
  });
}

​
Subpoena response

async function getAccountHistory(accountCommitment, assetId) {
  // Admin API — requires operator JWT, never exposed to public
  return await shywareAdminClient.getAccountHistory(accountCommitment, assetId);
}

​
Privacy properties for users

ScenarioWhat the counterparty sees
User pays merchant online{ transfer_id, amount, asset_id } — no balance, no history
Merchant queries transactionSame — List 1 record only
Another user queries your balanceNothing — balances are not publicly queryable
Your bank’s analytics teamNothing by default — requires operator-level access
Court order / subpoenaFull history — bank responds via standard compliance flow

​
Licensing

Commercial deployment requires a license. Contact hello@sayists.com.