Everything in this book so far has been about whether the money is sound. This chapter is about whether it works.
The test is not philosophical. It is this: can you pay another person, on the other side of the world, in under a minute, for about a cent, without asking anyone's permission and without creating a record that outlives the sale?
Bitcoin cannot do that. Monero can, at a higher cost in size, and its recipient need not be online. Zcash can, but only on its shielded side. A stablecoin can, as long as the issuer has not frozen the address.
Here is what it looks like on Epic.
A payment, step by step You open the wallet. You paste or scan the recipient's identifier. You type an amount. You press send.
The wallet builds the transaction jointly with the recipient's wallet — that handshake from the last chapter — and broadcasts it. A block is produced within about sixty seconds. The payment is in it, and from the recipient's point of view it has arrived.
The fee is around a cent.
There is no address on the chain pointing at either of you. There is no amount visible. There is no record of where the money was before, because the outputs it came from have been cut away.
What remains is a kernel: a hundred bytes proving a valid transaction occurred, paid a fee, and balanced.
That is the whole experience. It is not more complicated than a bank transfer, and in most of the ways that matter it is less.
Why a minute matters Bitcoin's ten-minute block time means a payment is confirmed in ten minutes at best, and exchanges typically wait for three or six confirmations before crediting — half an hour to an hour, in practice.
Epic produces a block every minute, so one confirmation is one minute. That is ten times Bitcoin's confirmation cadence, and it changes what the currency is good for. A ten-minute wait is acceptable for settling a large transfer between businesses. It is not acceptable for buying lunch, which is why Bitcoin's payment use migrated to intermediate layers that reintroduce custodians.
A minute is not instant. It is close enough to instant that the ordinary use of money — paying a person, in a shop, for a service — becomes practical on the base layer rather than in a second system.
For larger amounts, the recipient can wait for more confirmations. Two blocks is two minutes. Three is three. The trade-off between speed and certainty is a dial rather than a fixed cost.
The fee, and why it stays small The fee exists to compensate the miner who includes the transaction and to make spam expensive. It is not a market mechanism for allocating scarce block space, because block space is not scarce at current usage.
At about a cent, the fee is a rounding error on any purchase that matters. It is also, importantly, not set by bidding: the wallet computes it from the transaction's size and the network's current fee policy, so congestion does not push it up. Its dollar cost moves with the coin's price.
This is one of the quiet advantages of a chain that keeps its history small. Bitcoin's fees rise when demand for block space exceeds supply; Epic's blocks are not full, and if usage grew, the design's answer to capacity is a path to scaling rather than an immediate fee auction.
That path is a claim, not a fact. At current volumes, the fee is a cent and the blocks are mostly empty. What happens at a thousand times the volume is a question the next few years will answer.
The network layer, which is where privacy is won or lost A private ledger with a careless network path is a locked door with the key under the mat.
When your wallet broadcasts a transaction, the first node that sees it can, in principle, connect it to your IP address. That is true of every cryptocurrency, and it is the layer where most privacy failures actually happen — not in the cryptography, in the metadata.
Epic's design addresses this in three ways.
Dandelion++ sends the transaction along a randomised "stem" path through a few nodes before broadcasting it widely in the "fluff" phase. An observer watching the network cannot easily tell which of the stem nodes originated the transaction, so the link between you and your payment is blurred at the moment it matters most.
Tor can be used for the wallet's connection, so the node does not see your IP at all. Node operators can also exchange onion addresses, routing the stem traffic end to end over onion connections.
The relay handles the handshake separately from the broadcast, so the two pieces of metadata — who is paying and where the transaction entered the network — are not tied together in the same message. The relay itself still sees which identifiers talk to each other, and from which addresses, unless the connection runs over Tor. It separates the two facts from each other; it does not make you invisible.
Each of these is a mitigation rather than a guarantee. Traffic analysis is a real discipline and a determined adversary with global visibility is a real threat. But the design assumes the network layer is hostile, which is more than most chains do.
What can go wrong Four things, and they are worth knowing before you send anything.
The recipient's wallet has to be reachable. Because the payment requires a handshake, the recipient either needs their wallet online, or needs the relay to hold the half-built transaction until they collect it. The relay solves this for ordinary use, but it is a dependency: if you are sending to someone who has never set up a wallet, the first payment is a conversation, not a click.
The deposit method. Because there are no addresses, an exchange has to be told which account a payment belongs to, and it does that one of two ways. The older one runs through a relay: the exchange gives you an identifier and a number — the onchain note — and you put the note in the wallet's note field. Leave it out and the coins arrive with nothing to attribute them to; the exchange holds money it cannot credit, and recovering it is a support ticket. The newer one puts your account in the delivery string itself: the exchange runs a wallet listening over HTTP, your account number is already inside the deposit URL, and there is no note to forget and no relay to be down. Where an exchange offers both, take the URL. Of the two, the note is the single most common way a beginner loses access to their coins on this chain, and that risk is a consequence of the privacy design rather than a defect in it.
The wrong identifier. A mistyped relay address is refused before anything is sent: the wallet checks the address's checksum, its version bytes and its key before it posts anything. If no one answers a valid address, the payment never completes and the wallet returns the coins. Check the address anyway, and send a small amount first. There is no chargeback, no support desk, and no reversal.
Confirmations still matter. A minute is one block. For a payment of any size, wait for more. A transaction in a single block can, in principle, be reorged out, and the recipient who hands over goods after sixty seconds is taking a small risk for a small convenience.
The honest state of the software Wallet software here moves faster than print can follow, so this page names the strongest option at the time of writing rather than for all time. The most capable wallet on this chain today is BT Wallet, open source, made by BT LABS, whose founder is a long- time Epic Cash developer, and published at epiccash.btlabs.uk/releases. It runs on Windows, Linux, macOS, Android and iPhone, from the Android and Apple app stores or as a signed download, and every file there has a SHA-256 checksum to compare against BT LABS' signed list before you run it. It does considerably more than the applications the project's own download page still points at: invoices you send to a paired contact, who approves and pays or declines while you can withdraw until it is paid; contacts and pairing, so a payment goes to a person rather than a pasted string; payment links; a build with Tor and a build without it; a Kill switch mode; and support for running your own node, which the wallet sets up and manages for you.
Whatever you install, the first payment should be small and the seed should be on paper. Those two rules survive every change of software, which is more than any version number can say.
What does not change is the shape of the problem. A wallet holds your keys. It needs a node to tell it the state of the chain, and either it runs one or it trusts somebody else's. Neither arrangement is free, and the choice is worth making deliberately rather than by default.
Whether that option is worth taking is contested, and the objection deserves to be quoted rather than paraphrased. A developer who reviewed this chapter, on the wallet-node arrangement:
"My personal opinion of the wallet node thing has always been that it creates more trouble than it offers value. Users expect it to be instantly available, and many failed transactions have been due to the local node still syncing, which takes a while. The other issue is more technical: local nodes start and stop with the wallet being open. This adds more traffic between nodes, because it adds to the peer list, then the node becomes unavailable, and a public node must search for a new one, because that local node peer is gone. Nodes should run on a separate device from a wallet and run 24/7, or don't bother."
That is a fair summary of the case against, and I do not have a good answer to it. BT LABS' answer is that the wallet sets the node up and manages it, so the handling is theirs rather than yours — a reasonable answer, and not quite the same thing as infrastructure. A reader who wants the strongest guarantee should still run a node on a machine that stays on, and point the wallet at it.
None of this software is as polished as a bank app, and anyone who tells you otherwise has not used both. The interactivity requirement means the onboarding conversation is longer than "here is my address" — it is "here is my identifier, and here is how the wallet will complete the payment." That is a real friction cost, and it is the price of a design with no addresses.
Whether that price is worth paying is the question this book has been building toward. The answer depends on what you think the alternative costs — and the alternative, for most people, is a bank account that can be frozen and a payment record that can be sold.
The point of all of it Money that cannot be sent cheaply is not money. It is an asset you hold and hope.
The design work in the previous five chapters exists to make this chapter possible: a payment that is private by default, settled in a minute, priced at a cent, verified by a chain you can run yourself, and impossible to filter because there is nothing in it to filter.
That is a complete payment system, and it is running today. What it does not have is enough people using it — which is the subject of the next chapter, and the only line on the scorecard that is still empty.