**Kompaktor is a proof-of-concept protocol targeting the compression of 50+ payments from different senders into a single Bitcoin output**—achieving dramatic efficiency gains while preserving privacy through techniques derived from @WasabiWallet's WabiSabi coinjoin system. This prototype demonstrates what becomes possible when ecash-style credentials meet round-based transaction coordination. The implications are significant: exchanges, payment processors, and wallet providers could drastically reduce their on-chain footprint while giving users privacy that rivals custodial ecash systems—except without the custodians.

**GitHub**: https://github.com/Kukks/Kompaktor

## From Coinjoins to Payment Compaction

Kompaktor's lineage traces directly to WabiSabi, the cryptographic protocol powering @WasabiWallet 2.0's privacy-focused coinjoins. Understanding this foundation helps explain why Kompaktor works.

Traditional coinjoins mix multiple users' Bitcoin into a single transaction, breaking the trail between inputs and outputs. WabiSabi revolutionized this approach by introducing **keyed-verification anonymous credentials**—think of them as digital stamps that prove you deposited a certain amount without revealing *which* deposit was yours. When a coordinator issues these credentials, they're cryptographically blind to the amounts and cannot link them back to specific users.

Kompaktor extends this concept beyond mixing into the realm of payments. The core insight: if credentials can represent value anonymously within a coinjoin round, why not use them to make actual payments? A sender can transfer credentials to a merchant, who then claims fresh outputs—all within the same coordinated round, with neither party revealing their coins to the other.

## How Rounds Turn Chaos Into Efficiency

The magic happens through **coordinated rounds**—time-bounded periods where multiple participants simultaneously register inputs, receive credentials, and claim outputs. Here's the simplified flow:

A merchant creates an invoice (say, 0.1 BTC) and generates a unique key, sharing this via a payment URI that includes a Nostr relay address for encrypted communication. The customer generates their own key and signals intent to pay through that specific Nostr relay. When the customer joins an active coinjoin round, they register their inputs (Bitcoin they already own) and receive credentials from the coordinator equal to their deposit minus fees.

The customer then "reissues" these credentials—splitting them into the exact payment amount needed—and transfers a **0.1 BTC credential** to the merchant via encrypted Nostr message. The merchant reissues this received credential under their own control and registers a fresh Bitcoin address to receive the output. Neither party sees the other's coins. The coordinator, despite facilitating the entire process, cannot link any input to any output. Finally, all participants sign, and the transaction broadcasts.

**Crucially, dozens of similar payment flows can occur within the same round.** The coordinator batches all of them into one efficient transaction, with multiple senders' payments potentially consolidated into single outputs where recipients share common characteristics.

## Efficiency Gains That Change the Economics

The proof of concept targets compacting **50+ payments from different senders into a single Bitcoin output**. To understand why this matters, consider how exchanges currently process withdrawals.

Most exchanges use one of three approaches:

**Single transaction mode**: Each withdrawal gets its own Bitcoin transaction. A transaction requires roughly 148 bytes per input plus 34 bytes per output plus overhead. If you're processing 1,000 withdrawals, that's 1,000 transactions competing for block space.

**Withdrawal batching**: Multiple withdrawals share a single transaction with one input and many outputs. Major exchanges have reported achieving 75% or greater fee reductions using this approach, cutting daily transaction counts dramatically.

**Full batching (Kompaktor-style)**: Incoming deposits directly fund outgoing withdrawals in the same transaction. Deposits become inputs; withdrawals become outputs. The overhead is shared across all participants.

But Kompaktor goes further through **output compaction**. Rather than each payment requiring its own output, multiple payments flowing to coordinated recipients can share outputs within the coinjoin structure. If 50 payments compress into fewer outputs, the per-payment cost drops dramatically. The **additional privacy** comes essentially free since the coinjoin structure already obscures the payment graph.

## Privacy Without Custodians or Complexity

Kompaktor delivers a trustless, private equivalent to ecash systems—without the custodians. This framing is important for understanding its value proposition.

Custodial ecash mints (like Fedimint or Cashu) offer excellent privacy because the mint issues blind tokens that users redeem anonymously. But you must trust the mint not to disappear with your funds. Lightning achieves non-custodial payments but involves channel management, liquidity constraints, and imperfect privacy.

Kompaktor threads the needle differently:

**Sender privacy**: The sender doesn't reveal which coins they own to the receiver. The credential transfer happens through encrypted Nostr messages, separate from the on-chain footprint.

**Receiver privacy**: The receiver doesn't reveal where they're receiving funds. They register outputs under a fresh Tor identity unlinked to any input registration.

**Coordinator blindness**: The coordinator cannot link inputs to outputs due to the credential system's unlinkability property. Even a malicious coordinator learns almost nothing about who paid whom.

**Non-custodial**: At no point does anyone else control your Bitcoin. Users sign only after verifying their expected outputs are included.

The tradeoff is timing: payments must complete within a coinjoin round (typically minutes to an hour), unlike ecash tokens which can be held indefinitely.

## Use Cases Beyond Individual Payments

Kompaktor's architecture serves several constituencies particularly well:

**Exchanges and payment processors** represent the clearest use case. These entities process thousands of deposits and withdrawals daily. Full batching with output compaction could reduce their on-chain footprint by an order of magnitude while simultaneously enhancing user privacy.

**Wallet providers** could offer users automatic participation in payment rounds, similar to how Wasabi Wallet handles coinjoins in the background. The user experience would be: send Bitcoin, get privacy, pay lower effective fees—without understanding the underlying mechanics.

**Merchant solutions** benefit from the PayJoin-like properties without needing web servers. @BtcpayServer already incorporates related concepts through its WabiSabi plugin, which enables scheduled transactions that embed payments directly inside the next coinjoin round.

**Lightning Network operators** could use Kompaktor for managing channels—whether service provider operations or user-initiated flows like opens and closes. Kompaktor achieves both fee savings and strong privacy for these on-chain interactions.

## Kompaktor, Ark, and Arkade

Kompaktor exists as an open-source proof of concept demonstrating what's achievable on Bitcoin today. It requires no protocol changes, no soft forks—just clever coordination using existing primitives.

**Ark** represents a related but distinct approach. Where Kompaktor batches payments into efficient on-chain transactions, Ark batches them into single on-chain commitments while moving most activity off-chain entirely. Ark's Virtual UTXOs (VTXOs) function similarly to Kompaktor's credentials—representing claimable value without on-chain footprint—but they persist between rounds and support instant off-chain transfers. Ark pushes these concepts even further, enabling asynchronous execution and more aggressive scaling.

**Arkade** is my focus at Ark Labs—a superset of Ark's capabilities that extends the protocol with additional features and optimizations. Arkade will use blinded credentials for its batches and commitment transactions, inheriting the same privacy properties as WabiSabi. I believe Arkade is the obvious next step, superior to Kompaktor in almost every way: asynchronous execution, persistent virtual UTXOs, instant off-chain transfers, more aggressive scaling—and the same coordinator-blind privacy guarantees. Think of the relationship as: Kompaktor proves what's possible with WabiSabi credentials for payments; Ark defines a full Layer 2 architecture; Arkade delivers a production implementation that combines Ark's scaling with WabiSabi's privacy.

**Learn more**: https://arkadeos.com

The relationship illuminates Kompaktor's role in the scaling landscape: it's a proof of concept showing that WabiSabi credentials can serve purposes beyond mixing, paving conceptual ground for more ambitious protocols.

## How It Compares to Existing Solutions

The Bitcoin ecosystem already offers several efficiency and privacy tools. Understanding where Kompaktor fits helps clarify its unique contribution:

**Standard payment batching** (used by major exchanges) combines multiple outputs into single transactions, achieving substantial fee savings. However, it reduces privacy since recipients can see co-payments, and it doesn't address input-output linkability.

**CoinJoin** (Wasabi, JoinMarket) focuses on privacy through mixing. It doesn't directly enable payments—users mix first, then pay separately. Kompaktor unifies mixing and payment into single rounds.

**PayJoin** breaks analysis heuristics by having both sender and receiver contribute inputs. The problem: it doesn't give users direct privacy gains—it only poisons chain analysis assumptions. This means PayJoin requires widespread network adoption to matter, while offering no immediate incentive for individual users to participate. Kompaktor is inherently a multi-party PayJoin with built-in cut-through, making it superior in almost every way: users get immediate privacy benefits, efficiency gains, and the heuristic-breaking comes as a bonus rather than the sole value proposition.

**Lightning Network** enables instant, cheap payments through channel networks. It excels at high-frequency small payments but involves channel management complexity and imperfect privacy (routing information leaks). Kompaktor complements Lightning by providing efficient, private on-chain channel management.

**Ark** achieves similar efficiency goals with a full Layer 2 architecture supporting off-chain transfers and instant settlement. It's more complex but more capable, representing where these concepts mature into production infrastructure.

## Conclusion: Proof of What's Possible

Kompaktor matters as a demonstration of possibility. It proves that WabiSabi's cryptographic primitives—originally designed for privacy-focused mixing—can power radically efficient payment systems. The target of 50+ payments compacted into single outputs showcases Bitcoin's latent capacity when clever protocol design meets existing infrastructure.

For bitcoiners evaluating this space, the key insight is architectural: credentials representing value, round-based coordination, and output compaction aren't just academic concepts. They're building blocks available today—no soft forks required.

The practical takeaway for exchanges, wallets, and payment processors: these efficiency gains exist today in various forms (@BtcpayServer's coinjoin plugin, standard batching, Arkade), with Kompaktor representing the intermediate conceptual step between simple batching and full Layer 2 solutions. The future of Bitcoin payments likely involves some combination of these approaches—and Kompaktor shows what becomes possible when you push coinjoin architecture toward its logical conclusion.

---

**Links**:

- Kompaktor: https://github.com/Kukks/Kompaktor

- Arkade: https://arkadeos.com

Reply to this note

Please Login to reply.

Discussion

No replies yet.