Why Bitsy verifies keyholders, not organizations
Every crypto payment begins with a small act of faith. Someone hands you an address, a long string of letters and numbers, and you send money to it. If a single character is wrong, or if the address quietly belongs to someone other than who you believe, the money is gone. There is no chargeback, no support line, no way to claw it back.
So the real question behind any receiving address was never what is the address. It is who controls it. Bitsy exists to answer that second question, and the way it answers shapes everything else about the product. Bitsy verifies that a specific keyholder controls a specific address. It does not verify organizations, brands, companies, or teams, and it never will. What follows is the reasoning behind that line, drawn exactly where it is.
Two kinds of trust
There are really only two ways to vouch for an address.
The first is reputational. A platform says, in effect, “trust us, we checked.” You see a badge, a checkmark, a familiar logo sitting beside the address, and you proceed. But notice what you are actually trusting. Not the address, and not the math. You are trusting the institution that placed the badge, and the internal process behind it, none of which you can see or repeat. The badge is a promise, and a promise is only as good as the party making it and the day they make it on.
The second is cryptographic. The person who controls an address proves it by signing a message with the private key that controls that address. You do not have to trust the platform, and you do not even have to trust the person. The signature either verifies against the address or it does not. Anyone can run that check: you, a stranger, or software that has never heard of Bitsy.
Bitsy is built entirely on the second kind, and refuses the first. When a Bitsy profile shows an Ownership Verified mark, that is not Bitsy’s opinion. It is a claim you can confirm independently.
What a signature actually proves
When you prove ownership on Bitsy, you sign a short, human-readable message with your own wallet. Bitsy never sees your private key, never asks for it, and could not use it if it tried. It sees the signature you produced and checks it against the address you listed. Stripped to its essentials, the thing being verified looks like this:
- message
- Bitsy ownership proof for @joe
- address
- bc1q… (the address shown on the profile)
- signature
- the output of signing that message with the address’s key
The address either produced that signature or it did not. There is no middle ground and no human judgment involved. What this proves is narrow and exact: at the moment of signing, whoever holds the key to this address chose to sign this message. It does not prove the holder is honest. It does not promise the address is a wise place to send funds. It proves control, and only control.
That narrowness is the point. A good security claim is one you can state precisely and that cannot quietly come to mean more than it says. “This key signed this” is such a claim. “This organization is legitimate” is not, because legitimacy has no signature. There is nothing to check, only someone to believe.
Where organization verification breaks
Now apply the reputational model to a group rather than a person, and watch what happens to the word “verified.”
An organization is not a keyholder. It is people, roles, and access, all of which change over time. The moment a profile stands for a company instead of a person holding a key, “verified” stops meaning “the keyholder signed this” and starts meaning “someone with admin access added this.” Those are completely different guarantees, and the distance between them is exactly the space an attacker wants to stand in.
Consider how ordinary the failures are. A team member leaves, and an address they added keeps quietly collecting long after they are gone. An admin account is phished, and a legitimate-looking address that nobody actually controls appears on a trusted page. A contractor with temporary access changes one character. None of these require breaking any cryptography. They route around it, because organization verification never rested on cryptography in the first place. It rested on access control and good intentions, and those are precisely the things that fail without a sound.
This is also the engine behind address poisoning, where an attacker generates a look-alike address that matches the first and last characters a person tends to glance at before sending. The defense against that is not a cleaner badge. It is a signature only the real keyholder can produce. An organization cannot produce that signature for an address whose key it does not hold, which is the entire problem, and which is why the badge would be a guarantee with nothing underneath it.
The unit of trust is a person who can sign
Underneath all of this is a question of accountability. When something goes wrong, who answers for it? With a keyholder, the answer is unambiguous: the person who holds the key, the same person who signed the proof. With an organization, accountability diffuses across whoever happened to have access, which in practice means no one. A signature ties a claim to a specific holder of a specific secret. A badge ties it to a process, and processes do not show up when an address turns out to be wrong.
So Bitsy treats the keyholder as the smallest honest unit of trust. Not because organizations do not matter, but because an organization cannot do the one thing the product is built around. It cannot sign.
The line, and what it costs
Bitsy draws a hard line and stays behind it. Bitsy verifies that one keyholder controls one address. Any trust that is not backed by a key is out of scope, permanently. There are no organization profiles, no team accounts, no “verified business” tier, and there will not be, no matter how often it is asked for.
I want to be honest that this costs something. It means Bitsy says no to a category of users it could otherwise serve. It means the answer to “can my company get verified” is “your company cannot, but the person who holds the keys can.” That is less convenient, and occasionally less popular. I will take that trade every time, because the alternative is to let the most trusted-looking mark on the product mean the least. A verification that an administrator can grant is not verification. It is a setting. I would rather Bitsy do less and have its one promise be true than do more and hollow it out.
Trust you can re-run
There is a deeper reason I keep Bitsy on the cryptographic side, beyond the specific attacks it turns away. It has to do with what makes trust hold up over time, which is something I spend my non-Bitsy hours studying.
People extend durable trust to systems they can see into, and withdraw it from systems they are asked to take on faith. A guarantee you cannot inspect is fragile, because the day the institution behind it errs, or changes hands, or simply stops caring, the guarantee quietly evaporates and you had no way to see it coming. A guarantee you can re-derive yourself does not depend on anyone staying good. It depends on math that was true yesterday and will be true tomorrow.
This is why Bitsy makes its proofs repeatable instead of just displaying a result. The Ownership Verified mark is backed by a signature anyone can re-check, against an address anyone can read, using a method that is public. If Bitsy disappeared tomorrow, the proof would still verify. That is the difference between trust that is lent to you and trust you actually hold, and it is the kind Bitsy is built to hand you.
One keyholder. One address. A proof you can run yourself. Everything Bitsy does is downstream of that single commitment, and the things it refuses to build are downstream of it too.