Litecoin MWEB Privacy: What It Hides and What It Leaks
We read 101 consecutive MWEB blocks: 30 peg-ins, 24 peg-outs, a 451,920 LTC pool — and every peg amount published. What the extension block hides, and what it cannot.
MWEB is usually introduced as Litecoin with privacy turned on. That is half right, and the half that is wrong is the half that matters when you are about to move coins. We sampled blocks 3,202,394 through 3,202,494 — 101 consecutive blocks, 4 hours 31 minutes 31 seconds, ending 2026-10-27 around 10:05 UTC — and read every MWEB section in them. The verdict splits cleanly. Inside the extension block nothing is visible: no amounts, no addresses, no link between inputs and outputs. At the boundary almost everything is: the total sitting in MWEB is published to the litoshi in every single block, and every peg-in and peg-out appears on the transparent chain with its exact amount and destination. That is not a bug; it is how a Mimblewimble extension block is built. But it decides what MWEB is actually good for. (LTC to XMR route)
What MWEB actually is. MWEB (LIP-0002, LIP-0003) is not a new chain and not a new address format for the main ledger. It is a second, parallel section attached to each block, holding a Mimblewimble-style chain of confidential outputs and kernels. Mainnet activated it at height 2,265,984, mined 2022-05-20 05:04:16 UTC. Block 2,265,983 contains 125 transactions and no MWEB output at all; the very next block carries two special outputs: a 1.24998370 LTC peg-in committed to kernel 7b367c60, and the HogEx transaction that commits the extension block header (2d19998a) to the main chain. Nothing about your ordinary LTC addresses changes. The extension block rides along, committed by one transaction per block, and consensus caps its weight at 200,000 units against the main block's 4,000,000. (LTC to XMR route)
The pool is a public number. The HogEx transaction is the meter. In block 3,202,492 it is txid 6066d5a0, 125 bytes, one input and two outputs: the first pays 45,155,067,009,209 litoshi — 451,550.67009209 LTC — to an address beginning ltc1g, and that number is exactly the MWEB supply reported for that height. The second output is a peg-out of 2.97 LTC to ltc1q7v2qhf0. By the end of our window the pool held 451,920.71324566 LTC, about 0.581% of the 77.77 million LTC in circulation, or roughly 25.2 million dollars at 55.80. Anyone can read that figure with no special tooling, in every block, forever. MWEB is a mixing pool with a public gauge. (LTC to XMR route)
What is actually hidden. Inside the section, outputs carry Pedersen commitments instead of amounts, and the block's kernels prove the arithmetic balances without revealing it. Kernels also aggregate: 101 blocks produced 58 kernels, 35 blocks had at least one, 66 had none, and no block had more than four. Cut-through shows up in the counts — 41 MWEB inputs consumed against 83 outputs created — which is the whole point of the design: intermediate outputs vanish and what remains is a set of commitments that says nothing about who paid whom. Size follows the same logic. An empty extension section is 175 bytes; the median block in our window was exactly that; the largest was 7,901 bytes, in block 3,202,422, which carried four kernels and 600.12 LTC of peg-ins. (LTC to XMR route)
What leaks at the boundary. Peg-ins and peg-outs are ordinary transparent outputs. A peg-in is a 203-byte transaction with one input and one output whose script is OP_9 followed by a 32-byte kernel ID — trivially identifiable, and in block 3,202,493 the two peg-ins cost 326 and 1,630 litoshi in fees for 0.103 and 378.236 LTC. Peg-outs leave the HogEx as normal P2WPKH outputs. In our 101-block window: 30 peg-ins across 23 blocks totalling 1,532.98198122 LTC, and 24 peg-outs across 18 blocks totalling 764.75040055 LTC. Median peg-out 8.35 LTC, largest 355.68 LTC. The pool grew 789.41 LTC net, and MWEB fees for the entire window came to 178,902 litoshi — a median of 2,901 litoshi per kernel, a fraction of a cent. (LTC to XMR route)
Peg-outs are indexed by address. This is the part most people miss. A public explorer endpoint returns MWEB peg-outs filtered by destination address, with the kernel ID, the value in litoshi and the address class. Ask it about ltc1q7v2qhf0 and it answers: kernel 0124ff8d, value 297,000,000, witness_v0_keyhash. So the fact that a given address was funded from MWEB is not merely on-chain — it is queryable. Combine that with timing. Twenty-four peg-outs in four and a half hours is about five an hour across the whole network. Peg in 10 LTC and peg out 9.97 LTC inside the same hour and you have not disappeared into a 451,000 LTC pool; you have joined a queue of five, with matching amounts at both ends. MWEB's anonymity set is the concurrent peg traffic, not the pool balance. (LTC to XMR route)
Using it around a swap, concretely. Litecoin Core can mint an MWEB address (getnewaddress with address_type mweb); it is 121 characters, starts ltcmweb1, uses bech32 rather than bech32m, and encodes 66 bytes — a scan public key and a spend public key. Steps: generate the address, send LTC to it (that is the peg-in), wait for the MWEB confirmation, then peg out to the swap site's LTC deposit address. At 10:15 UTC on 2026-10-27 this site quoted 100 LTC to 9.22231144 XMR — 10.8433 LTC per XMR against a spot of 10.6351, so 1.96% all-in — and 10 LTC to 0.91940493 XMR at 2.27%. The LTC pair's floor is 0.24991437 LTC (13.95 dollars) and ceiling 1,350.4905204 LTC (75,357 dollars). Three pitfalls: exchanges will not send to an ltcmweb1 address, so a peg-in has to come from a wallet that builds the OP_9 output; the peg-out amount and destination are public; and a peg-out output cannot be spent for six blocks (PEGOUT_MATURITY = 6), which at the 162.9-second average spacing we measured is about 16.3 minutes. (LTC to XMR route)
MWEB is still being patched. In v0.21.5.6 (2026-08-02) mainnet parameters gained a frozen MWEB output list — currently one 32-byte output ID, 2f3a08d9 to 94f7, that nodes reject as a spend — plus a one-block grandfather for what the source calls a known MWEB input-metadata exploit, and a rule from height 3,154,440 (2026-08-04 23:04:57 UTC) that a kernel claiming the pegout feature must contain a pegout. v0.21.5.8 (2026-09-12) added the same canonical-encoding rule for extra data from height 3,172,640 (2026-09-05 16:51:01 UTC). The commit titles are blunt: reject empty MWEB pegout features, reject empty MWEB kernel extradata. That is a young format still being nailed down at consensus level. Verdict: MWEB is a decent way to break the link between the transparent coins you own and the deposit you make, as long as you accept that the deposit itself is public and that five peg-outs an hour is a thin crowd. It is not a substitute for swapping into XMR — for that, the peg is exactly the part you cannot hide. (LTC to XMR route)