A blockchain can preserve a valid record while its users still lose money. Security depends on several systems working together: the consensus protocol, the software that executes transactions, and the people or devices that authorize them. A failure in one layer does not prove that every layer failed.
The ledger layer protects transaction history
Bitcoin’s design combines digital signatures with a peer-to-peer proof-of-work chain. The signatures show that a holder authorized a transaction. The hash-linked chain orders transactions, while accumulated proof of work makes rewriting older records progressively harder. Bitcoin’s white paper describes security in terms of honest computing power outpacing an attacker. That protection concerns the shared transaction history. It does not stop someone who has obtained a valid signing key from authorizing a harmful transfer.
Proof-of-stake networks use different mechanics. Ethereum validators propose and attest to blocks, and the protocol can penalize stake for conflicting behavior. Ethereum’s own attack-and-defense documentation describes several thresholds and defenses rather than claiming that stake makes attacks impossible. Operators still need diverse clients, reliable nodes and sound key management. The consensus rules only evaluate the messages they receive.
Applications add another security boundary
Smart contracts and bridges can fail even while the underlying chain keeps producing valid blocks. Contract code may grant broader permissions than intended, calculate balances incorrectly or trust a compromised administrative key. A bridge adds another verification system between networks, so its validator set, message rules and upgrade controls deserve a separate review.
For users, transaction simulation and permission review can reduce exposure before signing. Check the contract address through an official project channel, read the requested token allowance, and avoid unlimited approvals when a smaller limit will do. After using an application, revoke permissions that no longer have a purpose. These steps address application risk; they cannot repair a flawed consensus protocol.
Custody controls the authorization layer
A private key, seed phrase or institutional signing policy determines who can create a valid authorization. Hardware wallets reduce key exposure, but the screen still needs to show the expected destination and amount. Organizations should separate transaction preparation from approval, set withdrawal controls and test recovery procedures before an emergency.
The FBI’s February 2025 notice on the Bybit theft illustrates why transaction validity and ownership security must be assessed separately. The agency attributed the theft of about $1.5 billion in virtual assets to North Korean actors and listed addresses used to disperse the assets across blockchains. The networks recorded those transfers; a valid ledger did not make the theft harmless or reversible.
A practical review starts with the failed layer
When investigating an incident, identify what the attacker controlled: consensus power, contract logic, a bridge signer, an exchange system or a user key. Then check whether the chain reorganized, whether a contract accepted an unintended action, and whether a legitimate credential signed the transfer. This sequence avoids blaming “the blockchain” for every loss and points the response toward the control that needs repair.
Before committing funds, inspect the protocol’s security assumptions, the application’s audit and upgrade model, and your own recovery path. Record where the official contract address came from and who can approve an emergency transaction. Those details are useful when normal access fails.
Adapted from Blockchain Security: How Blockchains Protect Data and Where They Still Fail.