Shattering: A Theoretical Approach to Privacy in a Verafy Agent Swarm
A deposit blown into shrapnel, held by a swarm of bonded agents, and reassembled by whoever holds the key. Private while it rests, private when it moves, and insured by slashing. This is a theoretical design, written up in full, including the hard questions.
The following is a theoretical approach to privacy in a Verafy agent swarm. Nothing here is live. It is written up in full as VIP-0043, including the questions we have not answered.
Why privacy on a public chain is still unsolved
Public blockchains are transparent by design. Every balance, every transfer and every counterparty is visible to anyone who looks, forever. That transparency is what makes them trustworthy, and it is also why almost no one would run payroll, hold a treasury or plan an inheritance on one in the open.
The field has tried two broad answers. Privacy coins, such as Zcash and Monero, build privacy into the asset itself. They work well, but only for their own coin, and most of the world's on-chain value is not held in them. Mixers pool many users' funds and pay them back out, to break the link between deposit and withdrawal. They work only when many people use them at once, and their operators have ended up in court.
Neither answer covers some things people actually need. Funds that rest privately and wake up only when a condition is met. A claim on funds that can be handed to someone else without a visible transfer. A guarantee that whoever holds your funds in the meantime cannot walk away with them.
What has changed is that Verafy now has the pieces to try something different: inference programs, which store an intention on chain and let verifiable AI carry it out (see A Closer Look at Inference Programs); agent bonds, where an agent posts collateral and a jury slashes it for misbehavior; and swarms of agents that can hold and move funds on a schedule. Put together, they suggest a design we call shattering.
How shattering works
A receiver wallet takes an amount (our running example is $100,000 in bitcoin) and triggers an inference program, Shatter.
- Shatter compiles and checks the shattering strategy the caller supplied.
- It breaks the amount into shrapnel: pieces of standard sizes.
- It assigns each piece of shrapnel to an agent in the swarm. Before any agent receives anything, it locks a bond worth more than the shrapnel it will hold.
- It sends the shrapnel out on the strategy's schedule, along the strategy's routes.
- It writes a sealed commitment on chain and returns an assembly key to the originating wallet.
Three things come out of a shatter:
- A sealed commitment on chain proves the deposit was shattered, without naming the wallet that shattered it. The originator's address never goes on chain in the clear.
- An assembly key goes to the originating wallet. Only a holder of the key can call the shrapnel back together.
- Encrypted strategy metadata: the record of the shattering and its strategy, encrypted, compressed and stored, readable only with the key.
Then the money rests. It is not gone, and no agent owns it. It sits in the swarm, protected by bonds and insured by slashing.
The shattering strategy
The strategy is a program, not a setting. A caller can pass a declarative strategy, pick a preset, or supply a shattering algorithm: code, or an intention, that the Shatter inference program expands into a concrete plan. Either way, the plan is made explicit (every piece of shrapnel, its size, its agent, its route, its schedule) and checked before a single coin moves.
| Dimension | What a strategy can specify |
|---|---|
| Sizes | Standard denominations, a mix of them, how many pieces, how much of the total in each size |
| Timing | A spray window from minutes to days, random delays, batching into rounds shared with other users' shatters, minimum rest before a piece moves again |
| Routing | Any number of routes through any network, per piece: hops between agents, other chains, layer 2s and privacy pools |
| Agents | How many, how they are chosen, and a cap on how much any one operator can hold |
| Reassembly | All at once or in parts, on what schedule |
| Triggers | The key holder, a time lock, or any condition an inference program can judge |
| Budget | Maximum network fees, maximum agent fees, deadline |
Routing through any network
Routing is where shattering stops competing with existing privacy systems and starts using them. A strategy can send shrapnel through any number of routes, across any network. A piece can be shielded into the Zcash shielded pool and come out of a different wallet. Another can cross to a different chain or a layer 2 before it comes to rest. Cross-network legs go through the privacy router described in VIP-0039.
The privacy floor
Some choices feel private and are the opposite. A strategy can choose freely, within a floor the compiler enforces:
- Unusual amounts are fingerprints. A piece worth 0.0731842 BTC is unique, and unique is traceable. Every piece uses a standard size, so it looks like thousands of others.
- Unusual behavior is a fingerprint. Odd transaction formats, fee patterns or timing make a user's shrapnel stand out. Privacy comes from uniformity: every agent's transactions use the same formats, the same fee policy and the same rhythm, and agents send cover traffic, so carrying shrapnel and not carrying it look the same. A strategy can change which pieces move when. It cannot make a piece look different.
- A lone shatter is easy to trace. Privacy depends on how many other shatters overlap in size and time. If the swarm is too quiet, the compiler widens the window or waits.
- Every network leg has its own floor. A route through the Zcash pool is only as private as its entry and exit: shielding and unshielding the same amount an hour apart links them. The same size and rest rules apply to every leg.
- In equals out is a link. Reassembling exactly what went in, right after it went in, ties the two together. The floor sets a minimum rest and favors staggered reassembly.
The compiler also checks that every piece is covered by a locked bond, that fees fit the budget, and that the strategy moves funds only between swarm agents and the eventual payout. A strategy is evidence, not authority: it is screened by Prompt Guard, and nothing in the jury's path follows instructions found inside it.
On Bitcoin's base layer, every piece pays its own fee, so a large number of small pieces can eat a large share of the deposit. The compiler reports the cost up front and refuses plans that exceed the budget. In practice, shrapnel probably rests on a low-fee chain or a Bitcoin layer 2.
Bonds and slashing: how the swarm restores the value
The obvious objection to handing funds to a swarm is that the swarm could keep them. Bonds and slashing are the answer.
- Bond before custody. No agent receives shrapnel until it has locked a bond worth more than the shrapnel: 150% to start. The bond sits in a program-controlled account, never in the agent's own wallet.
- Same asset where possible. BTC shrapnel is bonded with BTC. If a bond is in another asset, the program issues margin calls when prices move, and slashes agents that don't top up.
- Two offenses, checked in code, with no jury, because the chain shows them directly:
- Moving early. Shrapnel leaves an agent's wallet in a way the strategy didn't schedule. The bond is slashed on the spot and held for the owner.
- Failing to restore. Reassembly is triggered and the shrapnel hasn't arrived by the deadline. The bond pays out directly: the full value, plus a premium for the delay.
- Disputes go to a Verafy jury. An agent that says it delivered (a chain reorganization, a stuck transaction, a wrong amount) can appeal. If the jury agrees, its bond is restored and an insurance fund covers the owner in the meantime.
- Slashed agents are out for good, under Agent Bonds (VIP-0033).
- Agents are paid for every hour their bond and shrapnel are locked. That is the real price of a shatter: a $100,000 deposit ties up $150,000 of agent capital for as long as it rests.
The guarantee: whoever holds the key gets back at least the full value, either the shrapnel itself or the bonds that replace it, as long as bonds stay above the value they cover. The money is in the swarm, protected by bonds, and insured by slashing.
Who can be the swarm
Shattering only works if the swarm is large, and it is only safe if nobody can join it without something to lose. So the rule for joining is simple: anyone can run a node and hold shrapnel, provided they have enough slashable bond in the network. No mining hardware, no permission, no membership. The bond is the admission ticket, and it is also the insurance.
Two limits keep that safe:
- A capacity cap. A node can only hold shrapnel up to a set fraction of its slashable bond. The cap is the network's main security dial. At 150% collateral, a node with $15,000 bonded can hold $10,000. At a far more conservative setting, say 1% of its bond, the same node could hold only $150: almost no node could ever profit by running, but the swarm would need far more total bond to hold the same deposits.
- An operator cap. No single operator holds more than a small share of any one shatter, however much bond it posts, so a well-funded operator cannot become a single point of failure or of surveillance.
This is a different model from Zcash, and the difference is worth being precise about. Anyone can use Zcash's shielded pool; you do not have to mine or validate to shield funds. But Zcash's miners play no part in anyone's privacy. They secure the chain, and the pool's cryptography does the rest. In shattering, the participants are the privacy: bonded nodes hold the shrapnel, and they earn fees for it. In theory, that opens privacy provision to a much broader set of participants: anyone with capital to bond and a node to run, rather than anyone with competitive mining hardware.
The key is a bearer key
The assembly key, together with its encrypted strategy, is a bearer key: a claim on the funds in the swarm that belongs to whoever holds it, like cash.
- Any holder can assemble. A wallet holding the key calls assemble with the key alone. No approval from the originating wallet, or anyone else, is needed.
- The caller is paid. Reassembled funds go to the wallet that calls assemble, unless it directs them elsewhere in the same call.
- The key can be passed on any number of times. Each handoff happens off chain. The funds never move while the key changes hands.
Front-running protection. The assemble call is visible before it executes. If it carried the key itself, anyone watching could copy it with their own wallet as the payout and take the funds. So the call carries a zero-knowledge proof of two statements at once: "I hold a valid shatter key" and "pay wallet W". Change W and the proof fails. The network learns the call is valid, and nothing about which deposit it belongs to.
The key is the money. Lose it and the funds are lost; leak it and they are taken. Key custody needs the same care as a seed phrase: split keys (some number of several parts required) and recovery conditions judged by an inference program are both options.
Reassembly
Reassembly runs the shatter in reverse:
- A trigger fires. The key holder calls assemble, or a time lock expires, or an inference program rules that a condition is met: an estate opening, a contract milestone, a dead man's switch.
- The caller proves the key with a zero-knowledge proof that also locks the payout wallet.
- The swarm releases the shrapnel on the strategy's reassembly schedule, along whatever routes it chose.
- Missed deadlines are slashed automatically, and bonds pay out in place of the missing shrapnel.
- Agents are paid, bonds are released, and the commitment is marked complete.
Private while it rests. Private when it moves. Recoverable only by whoever holds the key.
Z-shatter: shattering inside a shielded pool
Shattering's weakest point is privacy per move: every move of shrapnel is visible on chain, and privacy depends on enough traffic to hide in. Z-shatter is a mode that fixes it. Each piece of shrapnel rests as a shielded note in a zero-knowledge pool, held by a bonded agent. While the funds rest, the public sees only commitments: no amounts, no holders, no moves. When they are reassembled, spent notes publish nullifiers that cannot be linked to the commitments they spend. Commitments in, nullifiers out, and nothing on chain that connects them.
Shielding breaks one thing: slashing for moving early works by watching agent wallets, and inside a shielded pool there is nothing to watch. Z-shatter restores it two ways:
- Split viewing keys. Each agent hands over a key that can see whether its notes were spent, but not spend them. The key is split across Verafy jurors: any 3 of 5 can check, and none can see anything alone.
- Periodic proofs. Every agent regularly proves, in zero knowledge, that its note is still unspent. Miss a proof, and the bond is slashed.
The pool can be Zcash's own, reached through the privacy router, or a native pool built on the chain where shrapnel rests. We would start with Zcash's: it already exists, and its anonymity set is far larger than anything a new pool would have. Z-shatter is written up as VIP-0044, and like the rest of this post, it is theoretical.
What it is for
We would lead with the uses that don't depend on hiding from anyone:
- Inheritance and the dead man's switch. Funds rest in the swarm, and an inference program judges when the trigger has been met.
- Escrow and milestones. Reassembly fires when a jury rules that the work was done.
- Treasury security. No single key, wallet or server ever holds the whole amount.
- Private holding. A deposit that can't be read off the chain while it rests or when it moves.
How it compares
| Zcash shielded pool | Monero | Verafy shattering | |
|---|---|---|---|
| Status | Live | Live | Theoretical |
| How privacy works | Zero-knowledge proofs hide sender, receiver and amount inside the pool | Ring signatures (decoy inputs), stealth addresses, hidden amounts | Standard-size shrapnel across a large swarm; privacy comes from many identical-looking moves |
| Strength of privacy | Strongest: everything inside the pool is hidden | Strong, but probabilistic | Weakest per transaction: each move is visible, only the links are obscured |
| Main weak point | Entering and leaving the pool can be linked by amount and timing | Statistical analysis of decoys and timing | Thin traffic: a lone shatter is easy to trace |
| Who holds the funds | You | You | Bonded agents in the swarm |
| If something goes wrong | Not applicable | Not applicable | The agent's bond is slashed and pays out |
| Assets | ZEC only | XMR only | Any asset, on the chosen chain, including BTC |
| Conditional triggers | No | No | Yes: time locks, inference conditions, dead man's switch |
| Hand over the claim without moving funds | No | No | Yes: the bearer key |
| Cost | One network fee | One network fee | Many fees, plus agent fees on capital locked at 150% |
| Legal exposure | Lower: no operator holds funds | Delisted from many exchanges | Highest: an operated network holds user funds |
Read honestly, shattering does not beat Zcash on privacy. Zcash hides more, with less trust, for less money. What shattering adds is what neither privacy coin can do: funds at rest that wake up on a condition, a claim you can hand over without a transfer, a bonded guarantee of restoration, and privacy for assets that are not privacy coins. And because a strategy can route shrapnel through the Zcash pool, the two combine: Zcash-grade privacy while the funds rest, with shattering's triggers and bonds on top.
The closest relative on Bitcoin is CoinJoin, as in Wasabi and Samourai's Whirlpool. It also relies on standard denominations and many participants. Its coordinators are the ones that were shut down or prosecuted, which brings us to the hardest part.
The legal question
This design has to be reviewed by counsel before it is built. In the United States, Tornado Cash cofounder Roman Storm was found guilty in August 2025 of conspiring to operate an unlicensed money-transmitting business, while the jury failed to reach a verdict on the more serious money laundering and sanctions charges. A week earlier, the developers of Samourai Wallet pleaded guilty to conspiracy to operate an unlicensed money-transmitting business.
Shattering carries more of that risk, not less. Tornado Cash never held anyone's funds. In shattering, agents in a network the Foundation operates hold user funds, and a bearer key moves value without an on-chain transfer.
Two design choices could make it more defensible, and better:
- Proof of clean funds. In the style of Privacy Pools, a user proves their deposit is not from a flagged source without revealing which deposit is theirs. A Verafy jury could judge that against an inference program rather than a fixed list.
- Leading with inheritance, escrow and treasury security, which are useful whether or not anyone is hiding.
None of this is legal advice.
Where this stands
- Exists in the Verafy harness: juries, agent bonds and slashing (alpha), Prompt Guard, and the inference program direction (VIP-0042).
- Does not exist: the Shatter program, the strategy compiler and privacy floor, the zero-knowledge key proof, cover traffic, the insurance fund, and agent custody of BTC. The chain has not been chosen.
- Open questions: which chain holds the shrapnel; bond ratio, late-delivery premium and agent fees; the minimum anonymity set and rest time; whether a shatter must carry a proof of clean funds; who runs the insurance fund; and who reviews the design legally, and when.
The full design is VIP-0043: Shattering. Read it, poke holes in it, and tell us where it breaks.