Skip to main content

Overview

shyware transfers is the shared anonymous transfer layer used by the asset and payment embodiments:
  • shycontracts
  • shycustody
  • shywire
It is not a standalone coin. It is the canonical anonymous state machine for mint, burn, transfer, and related embodiment-specific records.

Core Invariant

List 1 (public chain):   transfer or state record with no identity join key
List 2 (private/off-chain or account path): participant / account commitment path

Invariant: canonical state must not publicly link identity to amount, direction,
or contract/custody/wire action detail.
The embodiment determines what is being moved or settled:
  • financing claims and remittances in shycontracts
  • pooled warehouse share custody units in shycustody
  • wrapped issuer transfers in shywire
shycustody should be read as a standalone pooled-custody embodiment, not as a renamed payment rail. It has its own policy, SKU, lot, redemption, settlement, and demurrage lifecycle; it merely uses shywire as the anonymous transfer rail for intramarket unit movement.

Authority Model

The transfer family follows the same broad shyware rule:
  • counterparties do not get identity-linked canonical state
  • canonical truth is not the same thing as off-chain rematch or operator data
  • operator or authority access, where it exists, is policy-driven and outside the public chain view
Earlier docs described this with Firestore-specific wording. That is no longer the right abstraction. The correct abstraction is:
  • canonical anonymous state on-chain
  • off-chain managed runtime or authority stores where needed
  • no public identity-to-amount join on canonical state

Current Runtime Posture

  • Contracts: shycontracts-v1
  • Custody: shycustody-v1
  • Wire: shywire-v1
  • Shared signing posture: AWS KMS + Azure Managed HSM
  • Front door / access: Cloudflare
  • Target sensitive hosting: Verne Global

Why This Matters

This transfer layer is the bridge between:
  • public auditability
  • anonymous counterparties
  • regulated operator action where required
That is why the same transfer base can support financing, custody, and wrapped payment rails without becoming three unrelated protocols.