Bitcoin's market cap is $1.65 trillion. The circulating supply is 19.8 million coins out of a 21 million cap, and the all-time high of $109,000 was set on January 20, 2025. Today the spot print is $83,000. None of that matters at the moment a self-custodial user taps "send" on their phone — what matters is whether the address pasted into the field belongs to the merchant the user thinks it belongs to. Manna's new Branta-backed verification screen claims to fix that. Hear me out: it does not fix it. It documents the address it found. That is a different thing.
What the Numbers Actually Say
Read what is on the screen, not what is implied by the screen.
A self-custodial wallet that integrates a third-party verification layer is doing one of three things, and most users cannot tell which one. The first thing it can do is resolve a human-readable identifier (a payment pointer, a Lightning address, a PayNym, a BIP-353 record) to a Bitcoin address and tell you the resolution succeeded. The second thing it can do is check the destination address against an allowlist of addresses the verification provider has previously associated with a named merchant. The third thing it can do is verify a cryptographic signature from the merchant proving control of the key behind the address at this exact moment. These are not the same operation. They produce screens that look almost identical and the user has no way to know which one fired.
I read the Manna release framing — "verified merchant details" — and the part that the framing does the work of obscuring is the verb. Verified by whom, against what, at what time. Branta is a payments-verification layer that maintains relationships with merchant integrations. The badge is a statement about Branta's confidence in the merchant identity at the moment Branta last refreshed its record. It is not a statement that the address you are looking at controls funds belonging to that merchant right now.
Here is the gap nobody is putting on the marketing page. Bitcoin's UTXO model means an address is a destination, not an account. A merchant can publish an address, rotate it, retire it, lose access to the key behind it, or have it silently swapped out by a compromised checkout integration — and the verification badge does not necessarily know any of that has happened. A cached "verified" entry can outlive the key it was meant to authenticate. A wallet display can show "Verified Merchant" against an address that is now functionally orphaned.
I am not saying this is what Manna and Branta have built. I am saying the screen does not tell you they have not. And the difference between "this address is the one the merchant uses" and "this address was the one the merchant used the last time the verification provider asked" is the entire difference between fraud prevention and fraud documentation.
Self-custody users — the actual users this product is being sold to — already paste addresses they cannot read into fields they cannot audit. Adding a green checkmark above the address does not change the cryptographic situation by one bit. It changes the social situation. It tells the user it is safe to stop checking.
What Nobody Mentions
The concession first, because the concession is real. A verification overlay that surfaces "this address has previously been associated with merchant X" is genuinely better than a wallet that shows the user a raw 42-character bc1q string and nothing else. Address-poisoning attacks — where a malicious party seeds the user's wallet history with a near-identical address hoping the user will copy-paste the wrong one on the next send — are a real attack vector, and a verification layer that surfaces a known-merchant association catches a meaningful fraction of those attempts. I will not pretend otherwise.
What nobody mentions is everything that the verification layer cannot do, and the cost of users believing it can do them.
First, the verification provider becomes a trust root. If Branta's record is wrong, the wallet's screen is wrong, and the wallet has no independent way to know. This is not a flaw of Manna's implementation specifically; it is the structural shape of any verified-merchant overlay. The user has moved from trusting Bitcoin to trusting Bitcoin plus an off-chain identity database maintained by a third party. The marketing language ("self-custodial") and the operational reality ("custodial trust delegated to the verification provider") are not the same.
Second, the verification provider has a refresh interval, and the user does not see it. If the badge says "Verified" the user does not know whether that statement was computed five seconds ago against a live signature challenge, or computed five months ago against a static allowlist that has not been touched since. A static allowlist with stale entries is worse than no badge, because the green checkmark suppresses the user's instinct to double-check.
Third, the verification provider has a coverage perimeter. The merchants in Branta's database are the merchants in Branta's database. Every other recipient — the freelance developer you are paying, the small e-commerce store that has not onboarded, the wallet of a friend — falls outside the perimeter and gets either no badge or a "not verified" warning. The "not verified" warning is functionally noise. Most legitimate Bitcoin payments in 2026 are still being made to addresses outside any verification provider's coverage, and conditioning users to treat "verified" as the safe state means conditioning them to treat the legitimate, perimeter-outside case as suspect.
Fourth — and this is the one that bothers me most — the verification overlay does not solve the problem it is implicitly claiming to solve, which is making the user safe from sending Bitcoin to the wrong place. The user is still typing or pasting an address. The user is still trusting whatever rendered that address into the copy buffer. If the user's clipboard manager is compromised, if the merchant's checkout page is compromised, if the QR code the user scanned was generated by an intercepting layer rather than by the merchant — the verification screen runs against whatever address actually made it into the send field, and the verification screen may very well say "Verified", because the destination really is a known merchant address, just not the one the user thought they were sending to.
A verification badge that fires on the destination address tells you nothing about whether the destination address corresponds to the merchant the user *believed* they were paying. That gap — between the user's intent and the field's content — is where almost all of the actual loss happens.
The Real Cost
Put a number on it. Bitcoin at $83,000 per coin, with a $1.65 trillion market cap on 19.8 million circulating coins, means every retail-grade self-custodial payment is denominated in a unit where a single keystroke error costs more than most monthly salaries. If a user sends 0.005 BTC to the wrong address — the kind of error any of us could make on a tired evening — that is $415 gone at today's print. At the all-time-high $109,000, the same error costs $545.
This is the real cost of a "Verified Merchant" badge that the user reads as "safe to stop checking." It is not the cost of the badge being wrong. It is the cost of the badge being right about the wrong thing.
I want to be precise here, because the math distinguishes between two failure modes that look identical to the user. Failure mode one: the verification provider says "Verified" against an address the merchant actually controls, and the payment goes through, and everyone is happy. Failure mode two: the verification provider says "Verified" against an address that is in its database as belonging to merchant X, but the user intended to pay merchant Y, and the user is paying because the checkout flow showed merchant Y's logo while populating merchant X's address. The user sees the same green checkmark in both cases. The financial outcome differs by the full amount of the transaction.
There is also a softer cost, which is the cost of attention erosion. Self-custodial wallets used to ask the user to read the address. Verified-merchant overlays implicitly ask the user to read the badge. The badge is faster to read. The badge is therefore the thing that gets read. Over a population of users and over a sufficient number of payments, the steady-state behavior is that the long Bitcoin address stops being checked. This is rational individual behavior — checking is expensive, badges are cheap — but the aggregate effect is that the wallet's last line of defense (the user actually reading the destination) is the line that gets retired.
The transparency-page measurement everyone wants does not exist yet. I cannot tell you how often Branta's database is wrong, or how often a verified address is stale, or how often a verification badge has fired against a legitimately registered merchant address that the user did not intend to pay. None of those numbers are public. I went looking and could not find them, and the absence of those numbers is itself part of the cost — we are deploying a trust layer at scale before we have the instrumentation to know how often the trust layer fails.
What a serious transparency report would publish: refresh cadence per merchant entry, distribution of badge-fired-but-payment-disputed events, false-positive and false-negative rates against a held-out test set of known-malicious lookalike addresses. None of that is in the Manna release. Not Manna's fault — that is the level of disclosure the category as a whole has not yet developed. But it is the disclosure level that would let me, as a user, calibrate how much trust to place in the green checkmark. Without it I am calibrating against marketing copy, which is a category of evidence with a known directional bias.
If You Only Remember One Thing
A green checkmark next to a Bitcoin address is a statement about a third party's database, not a statement about the address. The address is what spends your money. The database is what spends your attention.
I would still use Manna with the Branta layer on. I would not stop reading the destination. If those two sentences contradict each other for you, the contradiction is what this whole piece was about — and the question of whether a verification overlay net-helps or net-harms self-custodial users, once you account for attention erosion and the asymmetry between "verified the address" and "verified the intent", is one I do not see anyone in the category answering with data yet. If you have numbers, write.