Overview
Three properties. One protocol.
Prior distributed-ledger systems achieve at most two of the following three properties simultaneously:
- Anonymity to peers — submission direction, transfer amount, or contract terms are not linkable to the submitting party by any on-chain query
- Auditable aggregates — any third party can verify the tally, conservation invariant, or governance result without trusting the operator
- Recovery without memorized secrets — a participant can recover their own record, and a lawful authority can compel individual attribution, without a password, seed phrase, or any value the participant was asked to memorize
shyware achieves all three simultaneously — through write architecture, not cryptography. The same anonymous two-list state machine underlies five product embodiments across regulated domains without re-engineering the trust model for each one.
Tamper-evidence — detecting operator-purge, not preventing it — is a baseline property of distributed ledgers generally, not a shyware innovation, and it's a different property from tamper-proof. A genuinely independent multi-validator (Tier 1) deployment prevents it structurally, through BFT consensus. A single-validator deployment is tamper-evident at best: it needs an externally-managed, independent telemetry and witness layer (e.g. CloudWatch alarms plus an RFC 3161 timestamp authority witnessing period-close roots, as the reference deployment actually runs) for a purge to be detectable after the fact. A single-validator deployment with no such layer has no external audit trail and should not be described as tamper-evident. See trust tiers for the full breakdown.
How it works
Every submission is split at write time by a BFT ABCI state machine:
List 1 — anonymous submission record
ballot_id = H(beacon_block_hash ‖ random nonce) ← direction/amount/choice. No identity.
List 2 — participant registry record
H(identity ‖ scoping_id) ← who participated. No direction or terms.
No join key between List 1 and List 2 is ever written to the ledger. At period close, the count-match invariant |L1| = |L2| is enforced structurally and a dual Merkle root commitment is computed — one root over the anonymous records, one over the identity hashes, computed from disjoint element sets. Signing that commitment with a KMS/HSM key is optional (signing.backend in shyconfig); it adds third-party portability for a party who'd rather check one signature than independently verify from raw canonical state, but the count-match and non-derivability guarantees hold from the structural computation alone, whether or not any signing key is configured.
Any observer can verify aggregate correctness from the dual Merkle roots and canonical state directly — or, where a KMS/HSM signing key is configured, from that single signature alone. Individual attribution requires the protected off-chain linkage store, accessible only under lawful process.
Thirteen embodiments
The same state machine is governed by a versioned shyconfig manifest. Each embodiment declares its own authority model, identity mode, signing requirements, and deployment posture — and has its own SDK client with domain-specific method names.
| Contract version | Domain | Authority model | SDK client |
|---|---|---|---|
shyvoting-v1 | Anonymous elections and referenda | 4-party count-match | votingClient |
shywire-v1 | Private value transfer | 4-party count-match | wireClient |
shycustody-v1 | Physical commodity custody | 4-party count-match | custodyClient |
shycontracts-v1 | Anonymous smart contracts | 4-party count-match | contractsClient |
shyshares-v1 | Weighted DAO governance | 4-party count-match | sharesClient |
shybets-v1 | Anonymous event betting | 4-party count-match | betsClient |
shylots-v1 | Sealed-bid auctions | 4-party count-match | lotsClient |
shyrest-v1 | Informant stream | 4-party count-match | restClient |
shystore-v1 | Health record vault | 3-party sealer-governed | storeClient |
shystore-v1 | Credential vault / authenticator | 3-party sealer-governed | storeClient |
shychat-v1 | Confidential mailbox | 3-party sealer-governed | chatClient |
shybrowser-v1 | Browser analytics | 3-party sealer-governed | browserClient |
shystream-v1 | Private streaming | 3-party sealer-governed | streamClient |
shywire is the anonymous transfer rail shared by shycustody, shycontracts, shyshares, shybets, and shylots. Count-match embodiments expose TxTypeAuthorityRescind for two-party threshold erasure. Sealer-governed embodiments have no rescission pathway — erasure means the operator deletes the sealer key, making sealed payloads permanently undecryptable.
The SDK
The shyware web SDK (@shyware/sdk) is one client module per embodiment. Each is initialized from a shyconfig manifest and exposes a consistent initialize / build / submit interface with domain-specific method names.
// Count-match (voting, wire, custody, contracts, shares, bets, lots, rest)
import { initializeFromShyConfig } from '@shyware/sdk/clients/voting'
const client = initializeFromShyConfig(shyconfig, { getAuthHeaders })
await client.voteSubmission({ scopingId: pollId, payload: 'yes', diditSessionId, keypair })
// Count-match with transfer rail (wire)
import { initializeFromShyConfig } from '@shyware/sdk/clients/wire'
const client = initializeFromShyConfig(shyconfig, { getAuthHeaders })
await client.wireSubmission({ scopingId: assetId, senderCommitment, recipientCommitment, amount })
// Sealer-governed (store, chat, browser, stream)
import { initializeFromShyConfig } from '@shyware/sdk/clients/store'
const client = initializeFromShyConfig(shyconfig, { getAuthHeaders, deriveSealerKey, signMessage })
await client.storeSubmission({ scopingId: bucketId, plaintext, category })
The Go runtime is the ABCI state machine, signing layer, and ZK verifier. The web SDK communicates with it through the REST API. See the SDK overview and adapters reference for integration details.
Current posture
This docs site is intentionally compact while the fuller SDK reference and deployment materials are being staged for public release. The underlying protocol, embodiment examples, and integration guides are being organized into a cleaner public packet.
Request access
For pilot conversations, private walkthroughs, or licensing inquiries: [email protected]