Most wallets hand you a fresh address every time, and call it privacy. On a transparent chain like Kaspa, that promise quietly breaks — and it makes covenant protection harder to keep honest. FrostCard made a deliberate choice: one covenant vault address, protected from the very first coin. Here is the decision, and the reasoning behind it.
See why ↓Privacy — give each sender a unique address, so no one can link your transactions together or see your total balance.
Covenant protection — lock funds behind on-chain rules (a whitelist of where money can go, an inheritance heir, a freeze switch) that are baked directly into the address itself.
Kaspa is a transparent UTXO chain. Every coin and every movement is public, forever. Handing out fresh addresses feels private — but the moment you ever spend two of them together, or sweep them into one place, chain analysis links them right back to you.
A checking account churns addresses because its job is everyday flow. FrostCard's job is the opposite: hold a lot, safely, for a long time, under rules you can prove. That's a vault. A vault has one heavy door, not a hundred mailboxes.
One address forever. One covenant. No rotation. This is what Tangem does.
Simplest possible design — one covenant deployment, one tap, done
Rule changes affect one address only — one sweep, one tap
Recovery is instant — derive index 0, done
Zero confusion for the user
Tangem does this with millions of users
Smallest attack surface — less code, fewer bugs
Zero privacy — every sender sees the same address
Anyone can look up your full balance and entire history
Address reuse is a known weakness on UTXO chains
For: "We're a cold vault. Privacy is not our job. We protect funds. Simple, auditable, one address."
Against: "Everyone who pays you knows your full balance and entire transaction history."
84 addresses deployed with covenants before any funds arrive. A fresh address per receive. When rules change, rebuild all 84 and sweep funds 1-to-1 (old address 1 → new address 1) to preserve distribution.
Real privacy — each sender gets a unique address
Covenant protection from the first receive — no timing gap
Rule changes preserve privacy — 1-to-1 sweep, no consolidation
All 84 deployed in one card tap via batch signing
Rule changes require sweeping all funded addresses — more taps
More complex recovery — gap scan + covenant decode for all addresses
If a user accumulates 500+ addresses, rule changes take many taps
More code = more surface area for bugs
The 1-to-1 sweep pattern is itself detectable by chain analysis
A user changes their heir. The app rebuilds 200 covenant scripts and signs them in 3 batches (84 + 84 + 32 = 3 taps). 200 sweep transactions broadcast. Privacy is preserved (1-to-1, not consolidated) — but the 1-to-1 pattern is still detectable by chain analysis.
For: "Privacy AND covenants. No compromises. The complexity is in the code, not the UX."
Against: "Complexity kills in security products. A bug in the sweep logic could lose funds. We're building for billions — simplicity is safety."
Rotating receive addresses with no covenants. One vault address that does have the covenant. The app prompts you to sweep from the receive addresses into the vault.
Privacy on the receive side — fresh address per sender
Simple covenant management — one address, one script
Rule changes only affect one address — simple and cheap
Recovery is simple
Privacy destroyed at sweep time — all addresses converge to one
Funds at receive addresses are UNPROTECTED until swept
A timing gap between receiving and sweeping
The user must remember to sweep
For: "Honest design. Privacy when receiving, security in the vault, sweep when ready."
Against: "The sweep destroys the privacy. Funds sit unprotected in the gap. Worst of both worlds."
| A · Single | B · Pre-84 Sweep | C · Rotate + Vault | |
|---|---|---|---|
| Privacy | None | Full | Until sweep |
| Covenant on receive | Always | Always | After sweep |
| Initial deploy fee | ~0.00002 KAS | ~0.002 KAS | ~0.00002 KAS |
| Rule change fee | ~0.00005 KAS | ~0.004 KAS (84 addr) | ~0.00005 KAS |
| Rule change taps | 1 | 2–12 | 1 |
| Rule change safety | Immediate | Immediate | Immediate |
| Simple send fee | ~0.00002 KAS | ~0.00002 KAS | ~0.00002 KAS |
| KRC-20 send fee | ~0.0001 KAS | ~0.0001 KAS | ~0.0001 KAS |
| Code complexity | Low | High | Medium |
| Recovery | Trivial | Complex | Medium |
| Miner-friendly | Yes | Many taps on rule change | Yes |
Receives from exchanges and friends. Rarely changes rules. Wants it simple.
Best fit: A. Doesn't need privacy. Needs funds safe and the app simple.
Doesn't want anyone knowing their balance. Does OTC deals where counterparties shouldn't see each other.
Best fit: B. Pre-covenanted addresses give unique receive addresses with protection from the start.
Thousands of UTXOs across many addresses. Needs low maintenance.
Best fit: A. Too many UTXOs for multi-address rule changes. A single address is simplest.
A merchant receiving KAS payments. Needs a unique address per customer for accounting.
Best fit: B or C. Unique addresses with protection (B), or privacy receive plus vault (C).
The whole point of one vault is that there's nothing to take on faith. One covenant address means one thing to check — and FrostCard is built so you can check it. The rules, the heir, the whitelist, the freeze state: all public, all on-chain, all readable.