Wallet Sync

A light wallet does not hold the chain. It syncs against a server, lightwalletd, which streams the compact blocks and relays the wallet's transactions. That server is the party the wallet must talk to directly, so it is the primary adversary.

What must not leak

Migration amounts are public on the chain. The privacy the wallet owes its user is the link between an identity and a balance. If the server can attribute a transaction, or a group of them, to one user, it recovers that link.

The threat model

The primary adversary is L2, the server. The dominant vector is V1 identity paired with V3 content. A broadcast from the user's home IP attributes a transaction directly, and grouped transactions sum to a starting balance.

The wallet also faces an application-specific public observer.

L1	Chain-only observer
Vantage	Knows only what is publicly visible on the chain.
Sees	Public on-chain data, including public migration amounts.
Cannot see	Anything off-chain.

The invariants the wallet must hold:

Invariant	Statement	Depends on
A. Identity to balance	No user identifier links to a balance, even approximately.	P1 at every actor plus V2 and V3 discipline.
B. Transaction grouping	The server must not group one wallet's transactions.	P2 plus V3 content discipline.

Unprotected: identity and contents arrive together

The wallet talks to lightwalletd directly. The server sees the client IP, every request and every broadcast. Both invariants fail with no adversarial effort.

L2The destination❌P1❌P2

Sees

Real client IP
Every request and every broadcast
All request timing and content

Residual / countermeasure

Both invariants fail with no adversarial effort. This is the baseline network protection must improve on.

L3LLocal network observer

Sees

Endpoints, timing and volume of the exchanged flows

L3GGlobal network observer

Sees

Endpoints, timing and volume (collapses with L3L on a direct connection)

Cons / mitigations

Needs IP, timing and block-height obfuscation (request blocks out of order + buffer)

Fit

Baseline only: offers no protection

Protected: the mixnet hides the client IP

Fixed-size Sphinx packets take three mix layers with per-hop delays, Poisson sending and cover traffic. The exit gateway forwards to a stock lightwalletd.

L2The destination✅P1❌P2

Sees

Exit gateway / IPR IP
All requests and contents

Can't see

Client IP

Residual / countermeasure

The wallet's TCP connection to lightwalletd is an ordinary end-to-end connection arriving from the exit's IP. Per-packet unlinkability in transit does not translate into request unlinkability at the destination.
With a fixed IPR, P2 behaves exactly like the dVPN single-exit case: rotate the IPR per request to restore it.

L3LLocal network observer✅P1

Sees

Constant-size packets at a Poisson rate with cover traffic
That the client uses the Nym mixnet

Can't see

Reliable destination, volume or activity

L3GGlobal network observer◐P1

Sees

Per-packet timing (hampered by mixing delays and cover traffic)

Residual / countermeasure

The extent to which bulk transfers of many packets can be correlated over time is an open question. The mixnet is strongest for small, independent messages and weakest for bulk sync, one reason bulk sync does not belong on the mixnet (the other is throughput).

Pros

Client IP heavily obfuscated (timing + location) by the Nym network

Cons / mitigations

Compact-block sync very slow (5-hop + mixing delays)
Fixed IPR is a linking key at the destination

Fit

Client identity + IP heavily hidden from lightwalletd
Block sync very slow

⚠️

The mixnet heavily hides the client IP and its timing from the network. Against the server, a fixed exit still behaves like a single dVPN exit, so requests stay linkable. Rotate the exit per request to restore P2.

The mixnet buys strong identity protection against the server and the network. It does not, on its own, deliver transaction unlinkability at the destination. That needs exit rotation plus the content discipline of the hygiene layer.

Where to go next

Choose a Defence picks a configuration for your case.
Build it maps the configuration you picked to a package, for Rust and for the browser.
The two-layer model explains why transport alone is never the whole answer.
Packet Anatomy shows what a Sphinx packet exposes and hides.

Nym vs Other Systems Private Messaging