What a public key is
Public-key cryptography works with a matched pair. The private key is a secret random value; the public key is computed from it, and the address you share to receive funds is computed from the public key in turn. The derivation runs in one direction only: a private key yields its public key and address, but no one can reverse the steps to recover the private key from a public key or an address. That one-way property is the whole point — it lets you publish what receives and verifies funds while the secret that spends them stays hidden.
A public key has two jobs, and neither of them moves money. It lets the network verify signatures: when a transaction is signed with the private key, every node checks that signature against the corresponding public key and accepts the transaction only if they match. And it anchors the receiving address, so funds sent to the address are spendable only by whoever holds the matching private key. Sharing a public key — or the address derived from it — exposes nothing that lets an attacker spend.
It helps to keep the three values distinct. The private key is the secret that signs and must never be shared. The public key is derived from it and is safe to publish. The address is a shorter, encoded form derived from the public key, and it is what you actually hand out to receive a payment. In everyday crypto-payment work you rarely touch the raw public key directly — you share addresses — but the address only carries authority because of the public key behind it and the private key behind that.
Why it matters for crypto payments
The asymmetry between a public key and a private key is what makes crypto payments practical. A merchant can publish a receiving address as widely as needed — on an invoice, in a checkout, in an email — and anyone can pay into it, because receiving requires no secret. Spending is the part that needs the private key, so the value that is safe to expose and the value that must be guarded are cleanly separated. You can advertise where to pay without ever risking the authority to spend.
That same separation is what lets the network trust a transaction without trusting an identity. There is no account login and no permission list on-chain: a transaction is valid because its signature checks out against the public key for the address it spends from. The public key is the reference the network verifies against, which is why a valid signature — not a name or a credential — is the only authorization the chain recognizes. Guarding the private key is the security task; the public key is meant to be seen.
Public keys, addresses, and signing on halfin
halfin receives at blockchain addresses and signs the transactions that pay out from them, so public keys and addresses are the visible, shareable side of that machinery while the private keys stay internal. When a merchant takes a payment, the deposit address on the invoice or checkout is a value derived through the public key — safe to display to a customer, and useless to an attacker who only sees it, since it can receive funds but never spend them. Static deposit addresses work the same way: a persistent receive address can be published without exposing anything that authorizes spending.
Across blockchains the exact encoding of an address differs — Bitcoin, the EVM chains, Tron, the XRP Ledger, and Solana each format addresses their own way — but the underlying principle is constant: the address is derived from a public key, the public key from a private key, and only the private key can move the funds. A customer paying a halfin invoice on any supported chain is paying into a public-derived address, and the network credits it once the deposit confirms.
Signature verification has a familiar parallel in the integration itself. The webhooks halfin sends are HMAC-signed rather than public-key-signed, but the discipline is the same one public keys enforce on-chain: confirm the signature before acting. Treat the signature, not the look of the payload, as the source of truth — verify first, then take a business action.
- A public key is derived from a private key and is safe to share; the derivation runs one way and cannot be reversed.
- It verifies signatures and anchors the receiving address — it can confirm a signature and receive funds, but it can never authorize spending.
- The address you hand out to receive a payment is a derived, encoded form of the public key; publishing it exposes nothing that lets an attacker spend.
- On halfin, deposit and static addresses are the public-derived side that customers see, while the private keys that sign payouts stay internal and approval-gated.