Skip to main content

​
What shyware transfers is

shyware transfers is the fintech branch of the broader shyware family. It is not a coin. It is the shared anonymous transfer layer behind:
  • shycontracts
  • shycustody
  • shywire
It sits on top of any asset or settlement rail — stablecoin, sovereign currency, warehouse-share claim, financing ledger, or treasury token — and enforces a structural invariant that makes transfers private from counterparties while remaining auditable under lawful or policy-gated process. Within that branch, shywire is the transfer rail itself, shycontracts is a financing species, and shycustody is a distinct pooled-custody species that uses the rail for silo-unit movement without reducing custody to “just payments.” The transfer branch is taught after shyvoting, but before the wrapper is asked to stand alone. shywire and shycontracts are the most immediately commercial fintech surfaces; shycustody shows that the same architecture also supports pooled physical-goods custody. Across all three, canonical state stays anonymous and any rematch, registry, or authority layer remains separate from canonical write authority.

​
The problem it solves

Every existing design for private digital payments sits at one of two broken extremes:
ModelExampleProblem
Full surveillanceBank rails, most CBDC proposalsEvery transaction visible to operator and government in real-time
Black boxTornado Cash, MoneroNo law enforcement access path — legally untenable in any regulated jurisdiction
shyware transfers occupies the only viable third position:
Private from counterparties. Auditable by authorities with legal process.
This is not a compromise. It is the exact model that cash has used for centuries, adapted for deployable fintech systems.

​
The two-list invariant

shyware transfers applies the same structural property that separates vote direction from voter identity to separate transfer amounts from account identity: 
List 1 (public chain):   transfer_id  →  { amount, asset_id }    — no identity
List 2 (private store):  nullifier    →  { account_commitment }  — no amount

Invariant:  |L1| == |L2|, never joined on-chain
New:        Σ inputs == Σ outputs  (value conservation)
transfer_id = H(TransferNonce) is random and shares no derivation path with the participant-side commitment path. The two lists can never be joined on canonical state.

​
Tiered access model

PartySeesMechanism
PublicSupply totals, transfer countOn-chain BFT state
Merchant / counterpartyNothing — cannot see your balance or directionTwo-list invariant
OperatorAccount registry or settlement-side linkage onlyAdmin runtime / issuer policy
AuthoritiesFull records under legal or policy processSubpoena / MLAT / internal governance response
Authority access is reactive (triggered by legal process), not proactive surveillance — structurally identical to a bank account.

​
Deployer types

The transfer branch is a protocol family, not a single product. It is designed to be deployed by:
  • Stablecoin issuers — wrapped issuer rails with private counterparty experience
  • Neobanks — privacy-preserving account layer; the bank holds the protected linkage layer
  • Sovereign digital currency programs — cash-equivalent privacy without surrendering lawful audit capability
  • Custody and commodity operators — pooled custody claims such as silo
  • Financing platforms — anonymous contracts and remittance-style flows
See the Deployer Guides for deployment-specific architecture.

​
Intellectual property

shyware transfers is covered as part of the broader shyware filing posture. The value-conservation circuit (Pedersen commitments over BN254) is additional claim surface already described in the filing materials for the transfer embodiments. Commercial deployment requires a license. Contact hello@sayists.com.