SilentTransfer documentation

SilentTransfer is private transfer infrastructure for public blockchains: web console, FastAPI backend, and Solidity contracts. The product goal is untraceable-oriented private payouts — make payments harder to map as a plain public A→B transfer, without forcing the recipient onto a privacy app.

On public blockchains, every transfer is visible. Anyone can graph who paid whom if both addresses are known. SilentTransfer’s primary path uses a private vault: Alice deposits, then pays Bob (or many recipients) from the vault at times and amounts she chooses. Bob receives ETH in a normal wallet automatically.

Product token: sthood (see §9). Console transfers use ETH by default. This is a privacy product, not an identity product—scope is transfer mechanics, not user onboarding forms.

Transparent ledgers leak relationship graphs. If Bob’s salary wallet is public, every payroll transfer is public. If a merchant’s address is reused, customers and competitors can measure volume. Privacy tools on public chains usually trade off different properties:

• Stealth addresses (this family of designs) — primarily recipient unlinkability per payment, non-interactive for the recipient after meta-address registration.
• Mixers / pooling — different threat model, often heavier regulatory and UX cost; not SilentTransfer’s product pitch.
• Private L2s / encrypted mempools — different stack; out of scope for this docs page.

SilentTransfer focuses on a usable path: connect wallet → deposit vault → send single or batch → recipients auto-receive, with fees, privacy limits, and tokenomics stated in plain language.

Ethereum’s community standardized stealth flows so wallets and apps can interoperate:

• ERC-5564 — Stealth Addresses: defines how to generate one-time addresses and how to announce enough information (ephemeral public key + metadata) so the recipient can find the payment by scanning the chain.
• ERC-6538 — Stealth Meta-Address Registry: a canonical place for a user to publish a stealth meta-address so senders can look it up without an out-of-band chat.

Keys (ideal model)

A recipient typically holds two key pairs:

• Spending keys — control funds at derived stealth addresses. The private spending key must stay secret forever if funds should remain safe.
• Viewing keys — used to scan announcements and detect which stealth addresses belong to the recipient. A viewing key can be shared with a light scanner service (weaker privacy vs self-scan).

Together, the public spending key + public viewing key form the stealth meta-address. ERC-5564 describes a meta-address format of the shape st:eth:0x<spendingPubKey><viewingPubKey>.

Ideal send (Alice → Bob)

1. Alice fetches Bob’s meta-address from a registry (or Bob shares it privately).
2. Alice generates an ephemeral key pair and computes a shared secret with Bob’s viewing public key (ECDH on the curve used by the scheme, commonly secp256k1 in Ethereum tooling).
3. From that secret and Bob’s spending public key, Alice derives a one-time stealth address.
4. Alice transfers tokens to that stealth address.
5. Alice emits an announcement (via a messenger/announcer contract) containing the ephemeral public key and metadata so Bob can discover the payment.

Ideal receive (Bob)

1. Bob scans announcements with his viewing private key.
2. For each announcement, he recomputes the shared secret and checks whether the derived stealth address matches.
3. On match, only Bob can spend — using a spending key derived from the same secret material (scheme-specific).

Further reading: stealthaddress.dev, EIP-5564, EIP-6538.

Core live contract: SilentUserVault. Advanced modules (SilentShieldPool, ERC5564Messenger, SilentToken) exist in the repo. The remaining gap is stronger unlinkability + production ZK— not “no money moves.” Real ETH can move on testnet today.

Primary path uses a real wallet on Robinhood Chain Testnet (46630) with SilentUserVault. Operator Alice/Bob logins cannot fund on-chain transfers.

┌─────────────┐   SIWE / JWT REST    ┌──────────────┐
│  apps/web   │ ──────────────────► │  apps/api    │
│  Next.js    │                     │  FastAPI     │
│  wagmi/viem │                     │  Postgres    │
└──────┬──────┘                     └──────┬───────┘
       │ wallet txs                         │ live claim sweep
       ▼                                    │ (funded path)
┌─────────────┐                             │
│  Chain RPC  │ ◄───────────────────────────┘
│  RH testnet │
│  46630      │
└─────────────┘
       │
       ▼ (deployed / staged)
 contracts: SilentUserVault · ShieldPool · SilentToken · stealth modules

• apps/web — landing, docs, $sthood, private vault console; real wallet deposit/send.
• apps/api — SIWE auth, config, stats, optional advanced announce/scan paths for stealth modules.
• contracts — Hardhat; SilentUserVault (primary), SilentToken (1B), shield pool, optional ERC-5564/6538 modules.

What “untraceable-oriented” means here

• Break plain A→B — payouts leave the vault contract rather than a direct transfer from Alice’s everyday wallet to Bob.
• User-controlled timing & amounts — deposit once; send in pieces later to weaken simple fingerprinting.
• Zero claim friction for B — receivers never open the site; adoption does not leak through a claim portal.

What we do not provide

• Not absolute untraceability — vault deposit/withdraw txs, amounts, and timing remain public on-chain.
• Not production ZK by default — shield pool is advanced/testnet; Groth16 production path is not claimed complete.
• Not IP privacy — RPC and API calls leak IP unless the user uses VPN/Tor/self-hosted nodes.
• Not legal advice — users remain responsible for applicable law in their jurisdiction.

Live path honesty: treat privacy as harder to trace than plain public send, not full anonymity. See docs/PRIVACY_STATUS.md.

• Now: product fees are 0% on private send and claim. On-chain sends and claims still pay network gas.
• Soon: planned 0.5% fee on sponsored / protocol claim paths. Proceeds intended for protocol ops and open-market sthood buyback — not VC extraction.
• Private send product fee stays 0% in the plan (user pays network gas).
• Self-withdraw (user pays gas): 0% product fee when that path ships as a first-class option.

Product fees are currently 0%. A planned 0.5% fee on sponsored claims will fund protocol operations and open-market sthood buybacks—not venture distributions.

sthood / ticker sthood is the product ERC-20. Hard cap: 1B (1,000,000,000) — contract does not allow mint above the cap. No VC allocation (0%).

• Community 90% — 900,000,000 sthood. Public / community supply via Pons launchpad. Ecosystem, users, and open-market float—not a VC pool.
• Protocol 10% — 100,000,000 sthood. Small protocol share for ops, infra, and continuity. Not venture supply. Within the 5–10% protocol band.

Contract address (configured): 0x01f44ADdf4af1DB2d9016a4992FFef5163648c0a (0x01f4…8c0a). Non-upgradeable; standard ERC-20 transfers; 1B hard cap (no mint beyond max supply).

Allocation is a public policy. On-chain vesting locks are not claimed live until those contracts ship.

Built and usable

• Private vault (primary product)

  SilentUserVault on testnet: deposit ETH to a wallet-bound balance, then withdraw single or batch to any addresses. Recipients receive automatically — no claim site, no note backup. Connected wallet is the key.
• Real wallet connect + SIWE

  MetaMask / WalletConnect + EIP-4361 sign-in (EIP-55 checksum). Operator JWT (Alice/Bob) remains optional for evaluation only — not for real funding.
• Auto-receive for recipients

  Vault payouts land in ordinary wallets. B never visits SilentTransfer. No claim code for the primary vault path.
• Wrong-network helper

  If the wallet is on another chain, the UI offers wallet_addEthereumChain for Robinhood Chain Testnet (RPC, chain ID, explorer).
• sthood

  Token name and ticker sthood. Non-upgradeable ERC-20, hard-capped at 1B. Vault deposit may charge an on-chain protocol fee; planned sponsored-flow fee for ops + buyback.
• Console + docs + landing

  Minimal private-vault console; public docs state live vs ideal privacy without overselling absolute untraceability.

Not done — do not market as complete

• Absolute untraceability

  Vault payouts are harder to map as plain A→B, but deposit/withdraw graphs, amounts, and timing on a public chain remain analysis surfaces. Not marketed as “untraceable forever.”
• Production ZK shield / Groth16

  Shield pool exists on testnet with Merkle-witness style proofs. Production ceremony and full path-hiding are not claimed complete.
• Mainnet production money + audit

  Live path is Robinhood Chain Testnet. Mainnet TVL, audited contracts, and renounced/hardened ops are not claimed.
• Strong anonymity sets by default

  Fixed-size delayed payouts and large shared anonymity sets are roadmap, not default guarantees today.
• On-chain vesting locks

  1B allocation policy is published. Vesting lock contracts are not claimed as fully live.

Canonical roadmap lives in the repo at docs/ROADMAP.md and on the marketing site #roadmap. Labels: Live (testnet today), Next, Later.

• Next — Delayed / fixed-size vault payouts to weaken amount and timing correlation.
• Next — Stronger shared anonymity sets for vault withdrawals.
• Next — Shield pool maturity (production Groth16 when ceremony + scope allow).
• Next — Payroll & treasury scheduling for recurring private batch payouts.
• Later — External audit before mainnet treasury or public TVL claims.
• Later — Mainnet production path with hardened ops (not claimed today).
• Later — On-chain vesting when allocation locks ship.
• Later — Multi-chain expansion after primary path is stable.

Roadmap items are intentions, not delivery dates or guaranteed launches. Absolute untraceability and production Groth16 are not claimed.

• API / JWT compromise — SIWE is the real-wallet path; operator login is evaluation-only. Production still needs secrets hygiene, rate limits, and minimal claim-key retention.
• Vault contract risk — funds sit in SilentUserVault until withdrawn; contract bugs and owner/admin powers are operational risk until audited and hardened for mainnet.
• Owner key on SilentToken — treat ownership and mint policy as operational risk until renounce/cap is verified for mainnet.
• User seed phishing — no contract can save a user who signs away keys.
• Metadata & timing — funding and claim txs on a public chain can be linked by amount, time, and graph analysis.
• Testnet vs mainnet — only risk funds you can lose on testnet; no audited mainnet TVL claim.

• This docs UI is served at /docs on the web app.
• Production intent: docs.silenttransfer.com points at this deployment (host redirect already configured in Next config when DNS is set).
• Product site: silenttransfer.com · console under /dashboard.
• Local default: Docs nav uses /docs so content is readable without public DNS.