A genuine report can still cover the wrong contract. Here’s how to verify the evidence before you connect a wallet or invest.
Illustrative contract-matching example: a genuine audit report may cover a different deployment. Always compare the full address, network, code version, and audit scope. Original editorial graphic by Forvest.
An audit can be real and still tell you nothing about the contract you are about to use.
Suppose a project advertises an audit from a familiar security company. You find the original report on the auditor’s website. The project name matches.
Then you check the details. The report covers a different contract.
The document is authentic. Its relevance is still unproven.
That mismatch does not establish fraud. It means one important claim remains unverified.
Spotting a crypto scam takes more than recognizing fake documents. Sometimes the harder task is deciding whether genuine evidence supports the claim attached to it.
Start with the audit. Then apply the same check to the people, partnerships, and token behind the pitch. Each check should leave you with a specific finding you can explain.
A live check inside Forvest: one asset, two different readings
For this article, I tested the same verification method on a platform I work with. On September 9, 2026, I reviewed Forvest’s public Toncoin analysis and found two different readings on the same page.
The live weekly module displayed a Trust Score of 41.9 and labeled it Weak. Farther down the page, an analysis last updated on November 6, 2025 described TON with an overall score of 78 and labeled it Strong.
Both figures referred to TON, but they did not describe the same observation. One was a live weekly signal; the other was an older editorial snapshot based on dated inputs and a separate set of stated dimensions. Quoting 78 as TON’s current Trust Score would therefore fail two checks: time and scope.
This did not show that TON was fraudulent, and it did not prove that either figure had been fabricated. It showed that the older analysis could not support a claim about the current score.
That changed the next step in the review. I recorded the asset, score, label, timeframe, page date, and access date separately. I treated 41.9 as the current interface reading and kept 78 only as historical context. The comparison also revealed a presentation issue: live and historical values need clearer version labels.
The lesson was uncomfortable but useful: verification has to apply to our own platform, too. A score without a matched date and methodology can create the same false confidence as an audit badge without a matched contract.
How to verify a crypto audit
For the hypothetical project above, “the report exists” answers only the first question. You also need to establish what it covers.
Open the auditor’s official site independently and locate the original report. Compare the project name, network, contract address where provided, code version, scope, and date. If the report identifies source code rather than a deployed address, you still need evidence connecting that reviewed code to the contract in use.
CertiK’s explanation of verified contracts describes why this matters: teams can change code after an audit. CertiK has also documented phishing sites and exit scams falsely claiming its audits.
If the details do not match, ask a specific question:
“Where can I verify that the contract currently in use is covered by this audit?”
An explanation may resolve the mismatch. Until then, record the coverage as unverified.
Even a confirmed match has limits. An audit does not establish that the team is honest or that the token will hold its value.
Give each claim its own evidence
A confirmed audit cannot confirm a partnership. A confirmed founder cannot confirm a token’s value.
For each claim, follow the same sequence:
Name the claim. Write exactly what is being asserted.
Find the confirming source. Identify who has the authority to verify it.
Match the details. Check the relevant names, dates, network, addresses, version, and scope.
Limit the conclusion. Record only what those checks establish.
These checks belong within a broader crypto investment risk assessment that also considers market, liquidity, operational, and portfolio risks.
Three checks for evaluating crypto project claims. AI-generated infographic for Forvest.
How to check a crypto team or partnership claim
A project announces a partnership. Three websites repeat it. A social account posts the same news.
Before treating those mentions as separate confirmations, trace their sources. If all four rely on the project’s announcement, the supposed partner has still confirmed nothing.
Find the other organization’s official channels independently. Look for confirmation naming the same project and describing the same relationship. Save the source and date.
Apply that approach to team identities, too. Find a professional presence or contact channel independently of the project’s materials, and check whether it confirms the person’s current role.
A convincing video alone cannot settle the question. In its July 2026 warning, the FBI described scammers impersonating FBI personnel through AI-generated videos and spoofed IC3 websites, including schemes targeting previous fraud victims.
An appearance of authority is a reason to check the source.
How to check the official token contract
A familiar token name is not a unique identifier.
Locate the project’s official documentation independently. Compare the stated network and complete contract address with the token or contract you are being asked to use. Check that address on a reputable explorer for the same network.
Record the result narrowly: “This address matches the project’s documentation.”
That finding identifies the token. It does not establish future value, honest management, or coverage by an audit.
What to do when the evidence does not match
Use three labels to keep your findings precise:
Confirmed within scope: The source supports this specific claim.
Unverified: You cannot establish the claim from the available evidence.
Contradicted: An authoritative source directly conflicts with it.
A missing page, an outdated report, or a changed address may have an explanation. Record the gap and seek evidence for that explanation before relying on the claim.
You do not need to prove fraud to pause a transaction.
“Unable to verify” is a useful finding. It tells you which assumption would otherwise carry your decision.
Use a trust score to decide what to check next
A score is useful when you can understand what contributed to it.
If two tools disagree, compare their inputs, update times, definitions, and weighting. Understanding the factors behind a crypto project’s Trust Score helps you see what a number measures and which questions remain open.
Treat a high score as the start of a more specific question: “Which findings support this result, and are they relevant to the decision I am making?”
Save this crypto scam checklist
Choose the claim doing the most work in the pitch: the audit, the founder, the partnership, or the official token.
Before relying on it, write down:
Claim: What exactly am I being asked to believe?
Source: Who can confirm it, and how did I find them?
Match: Which identifiers, dates, or scope details agree?
Gap: What is still missing or conflicting?
Next step: What would resolve that gap?
Then complete this sentence:
“I verified _____ using _____. I still have not verified _____.”
If the second blank contains only another project-controlled page, trace the claim further. If the third contains something essential to your decision, keep that uncertainty visible.
A risk score can organize the signals you have already verified. It cannot turn an unverified claim into evidence.
Return to the audit at the start of this article. Finding the genuine report was useful. Checking what it covered was the step that changed the conclusion.
Before your next crypto decision, ask:
What, exactly, have I verified?
Author disclosure: I work with Forvest, where my work focuses on research-driven crypto analytics and risk-aware decision support. This article is educational and is not financial advice.
Smart contracts are supposed to be immutable. Once deployed, their code is expected to remain unchanged. That immutability is one of blockchain’s strongest security properties, but it creates an obvious problem for production protocols.
What happens when the contract has a critical bug?
What if the business logic needs to evolve?
What if a DeFi protocol needs to respond to a new attack vector without migrating millions of dollars in liquidity?
This is where smart contract upgradeability comes in. Upgradeability allows developers to change contract logic while preserving the same user-facing contract address and, in most designs, the existing state.
But there is a catch:
An upgrade mechanism is effectively a privileged path for changing what your smart contract can do after deployment.
That means the upgrade system itself becomes part of the protocol’s attack surface. And this is where many teams get it wrong.
How Smart Contract Upgradeability Actually Works
Most upgradeable Ethereum contracts use some variation of the proxy pattern. Instead of putting everything into one contract, the architecture separates:
Proxy: stores user state and receives transactions.
Implementation: contains the business logic.
Admin/governance: controls which implementation the proxy uses.
When a user calls the proxy, the proxy forwards execution to the implementation using EVM’s delegatecall.
The important detail is that delegatecall executes the implementation’s code in the proxy’s storage context. So if the implementation contains:
balances[msg.sender] += amount;
The storage being modified belongs to the proxy. An upgrade, therefore, does not replace the proxy itself. Instead, the proxy is pointed toward a different implementation contract.
This is why upgradeability is powerful and dangerous.
Ethereum’s documentation describes this model as separating storage from logic and changing the implementation address to modify the behavior of the existing contract.
1. The Upgrade Admin Is a Superuser
The most obvious risk is also one of the most underestimated. If an attacker gains control of the upgrade authority, they may not need to exploit the protocol’s business logic at all. They can simply deploy malicious implementation code and upgrade the proxy.
For example:
Normal implementation ↓ User deposits 100 ETH ↓ Proxy ↓ Secure logic
After a compromised upgrade key:
Malicious implementation ↓ User deposits 100 ETH ↓ Proxy ↓ Attacker-controlled logic
The contract address hasn’t changed. The user’s interaction hasn’t changed. The frontend may even look identical. But the code executing behind that address has changed.
How founders should mitigate this
Do not treat the upgrade key like an ordinary deployment wallet. Use stronger controls such as:
Multisig authorization
Timelocked upgrades
Dedicated upgrade administrators
On-chain governance where appropriate
Independent approval for high-risk implementations
Monitoring for implementation-address changes
OpenZeppelin’s tooling supports different upgrade patterns and explicit ownership mechanisms, but the security of the upgrade authority remains a fundamental design responsibility.
The key principle: protect the upgrade path with at least the same seriousness as the funds themselves.
2. Storage Layout Can Break an Upgrade Without Any Obvious Bug
This is one of the most technical — and most frequently underestimated — risks. Upgradeable contracts preserve state across implementations. That means the storage layout of version 1 and version 2 must remain compatible. Consider:
The Solidity code may compile perfectly. But storage slots don’t magically understand your intentions. The EVM simply sees storage positions.
Version 1 might interpret:
Slot 0 → owner
Slot 1 → balances
Slot 2 → totalSupply
while version 2 interprets those same locations differently. The result can be corrupted state, broken permissions, incorrect balances, or much worse.
OpenZeppelin specifically warns that storage collisions can occur between implementation versions when variables are reordered or incompatible variables are introduced.
The safer rule
For upgradeable contracts:
Do not reorder existing storage variables.
Generally:
Add new variables at the end.
Preserve existing types and positions.
Avoid changing inheritance structures without understanding their storage impact.
Validate storage compatibility automatically before deployment.
This is one reason upgrade validation tooling is so valuable.
3. Initializers Replace Constructors — and They Can Be Dangerous
A normal Solidity contract uses a constructor:
constructor(address admin)
{
owner = admin;
}
But constructors run when the implementation contract itself is deployed. With proxies, users interact with the proxy, so initialization needs to happen through the proxy’s execution context. Upgradeable contracts therefore commonly use an initializer:
function initialize(address admin) external initializer
{
owner = admin;
}
The danger is simple:
What happens if someone else calls initialize() first?
If initialization is not properly protected, an attacker may be able to initialize the contract with themselves as the owner or administrator. That turns a deployment mistake into a complete privilege takeover. Developers should therefore:
Protect initialization with an initializer guard.
Initialize through the proxy.
Ensure initialization happens atomically when required.
Lock unused implementation contracts where appropriate.
Test initialization and re-initialization paths explicitly.
4. UUPS Makes the Implementation Itself Part of the Upgrade Surface
UUPS proxies are attractive because the upgrade mechanism lives in the implementation rather than requiring a heavier proxy-side upgrade mechanism. But that creates an important security consideration.
The implementation contains the function responsible for authorizing upgrades. In simplified form:
function upgradeToAndCall
(
address newImplementation,
bytes calldata data
) external;
The critical question becomes:
Who is allowed to call it?
OpenZeppelin’s UUPS implementation requires developers to override _authorizeUpgrade() with an appropriate access-control mechanism. A poorly implemented authorization check can effectively expose the entire protocol to arbitrary upgrades.
Even more subtly, an upgrade can modify the future upgrade mechanism itself. That means developers must audit not only:
“Can someone upgrade the contract?”
but also:
“What upgrade powers will the new implementation have?”
This distinction is easy to miss.
5. Function Selector Collisions Can Create Unexpected Behavior
Smart contract functions are represented by 4-byte function selectors. That sounds like plenty of space. It isn’t. Different function signatures can theoretically produce the same selector.
In proxy architectures, this creates another layer of complexity because the proxy itself may expose administrative functions while the implementation exposes application functions.
If selectors collide, the proxy may intercept a call that developers expected to reach the implementation. Ethereum’s EIP-1967 specifically discusses this risk and standardizes proxy storage locations partly to avoid exposing proxy-management functions that could clash with implementation functions.
Transparent proxies address this through caller-dependent routing:
Normal users → implementation
Proxy admin → administrative functions
This is why proxy architecture isn’t simply a deployment detail. The routing mechanism itself can affect application behavior.
6. Beacon Upgrades Introduce a Different Blast Radius
Beacon proxies are useful when many proxy instances share the same implementation. Instead of upgrading each proxy individually:
Proxy A ─┐ Proxy B ─┼──> Beacon ──> Implementation Proxy C ─┘
Changing the beacon’s implementation can upgrade all connected proxies. That is operationally convenient. But it also creates a larger blast radius. A compromised beacon can potentially affect every contract relying on it.
OpenZeppelin describes beacon proxies as a mechanism where multiple proxies can be upgraded by changing the implementation referenced by their shared beacon. So, before using a beacon architecture, founders should ask:
“If this upgrade authority is compromised, how many contracts can an attacker affect?”
That answer should influence governance, monitoring, and emergency controls.
7. An Upgrade Can Be Technically Valid but Economically Dangerous
Not every dangerous upgrade contains an obvious coding vulnerability. Imagine an upgrade that changes:
fee = 0.3%;
to:
fee = 30%;
The contract may compile. Storage may be compatible. All tests may pass. Access control may be correct. Yet the protocol’s economics have fundamentally changed. This is why upgrade security cannot stop at:
“Does the new implementation compile?”
It must also ask:
Does token accounting remain correct?
Have fee parameters changed?
Has withdrawal behavior changed?
Can existing positions be liquidated differently?
Has Oracle handling changed?
Have permission boundaries changed?
Can a privileged actor now move user funds?
Does the new implementation preserve protocol invariants?
This is where upgrade reviews need to combine code security with economic security.
8. Treat Every Upgrade Like a New Production Deployment
A common mistake is assuming:
“The contract is already audited, so upgrades are safe.”
That assumption is dangerous. The original implementation may have been audited. The new implementation is new code. Its interaction with existing storage, governance, integrations, and user positions is also new. A serious upgrade process should therefore include:
Before deployment
Compile and test the new implementation.
Compare storage layouts.
Run invariant and integration tests.
Review authorization changes.
Simulate the upgrade against production-like state.
Analyze economic parameter changes.
Perform independent security review for high-value protocols.
During deployment
Use controlled upgrade authorization.
Verify the implementation address.
Execute initialization atomically where necessary.
Emit and monitor upgrade events.
Verify deployed bytecode/source.
After deployment
Monitor implementation changes.
Monitor privileged calls.
Monitor abnormal fund flows.
Verify critical protocol invariants.
Maintain an emergency response plan.
OpenZeppelin provides upgrade plugins specifically to validate upgrade safety and compatibility before an implementation is deployed.
The Bigger Security Principle
Upgradeability solves a real engineering problem: how do you evolve an immutable system? But it introduces another problem:
Who gets to decide what the system becomes?
That question is more important than whether the protocol uses Transparent, UUPS, Beacon, or another upgrade pattern. A secure upgrade architecture should establish four clear boundaries:
Upgrade Governance ↓ ┌─────────────────┐ │Upgrade Authority│ └───────┬─────────┘ ↓ New Implementation ↓ Storage Compatibility ↓ User Funds
Every layer needs independent controls. The upgrade authority must be protected. The implementation must be validated. Storage compatibility must be enforced. And the resulting behavior must be monitored after deployment.
Final Takeaway
Smart contract upgradeability is not simply a way to “make immutable contracts editable.” It creates a controlled code-replacement system around an otherwise immutable protocol. That system introduces risks around:
Upgrade authority
Storage collisions
Initialization
UUPS authorization
Function selector clashes
Beacon blast radius
Governance
Economic changes
Monitoring and incident response
For crypto founders, the right question isn’t:
“Should our smart contracts be upgradeable?”
It is:
“If our contracts are upgradeable, can we prove that no single compromised key, implementation, or governance action can silently take control of user funds?”
That is the standard worth designing for. And as protocols move billions of dollars on-chain, upgradeability should be treated as a security-critical subsystem — not a deployment convenience.
Exploring Bitcoin’s oldest addresses, quantum computing, public-key cryptography, and the unanswered questions surrounding Satoshi Nakamoto’s untouched fortune.
More than 1.1 million Bitcoin have remained untouched since 2009.
They belong — at least according to overwhelming on-chain evidence — to Bitcoin’s anonymous creator, Satoshi Nakamoto.
For over fifteen years, these coins have never moved.
Yet as quantum computing advances, an uncomfortable question is becoming increasingly difficult to ignore:
Could the largest dormant Bitcoin fortune in history eventually become vulnerable?
The answer is far more complicated than most headlines suggest.
1. Anatomy of a Myth: Why Satoshi’s Coins Are Called the “Weakest Link”
To understand this hypothesis, we must first look at the pessimistic scenario accepted by the majority of crypto experts.
Address Type (P2PK): Satoshi’s early coins are not stored on familiar modern addresses (P2PKH or Bech32), but rather on the simplest P2PK (Pay-to-PubKey) format.
The Problem: On these addresses, the user’s public key is exposed directly on the blockchain (it’s not a hashed key, but raw code).
The Quantum Threat: Theoretically, a powerful future quantum computer utilizing Shor’s algorithm could mathematically derive the private key from an exposed public key in a reasonable amount of time.
This is why traditional consensus dictates that if a sufficiently powerful quantum machine ever emerges, Satoshi’s coins will be the first and most probable target for attack. They are massive, ancient, and feature exposed keys.
But what if we are underestimating the architect of the system?
2. The High-Entropy Hypothesis: Could Satoshi Have Used “Physical Chaos”?
This is where things get genuinely fascinating. In cryptography, entropy is the measure of true randomness.
Low Entropy: When a key is generated using a standard pseudo-random number generator (PRNG) relying on system clocks, process times, or session IDs. Cracking such a key for a quantum computer is elementary.
High Entropy: Randomness harvested from the physical world — hardware thermal noise, radioactive decay, atmospheric interference, or intentional erratic movements (a task fundamentally impossible for any quantum computer to crack, as such data sources possess a truly chaotic nature).
Imagine a simple example: what if we take an ordinary microphone and generate entropic data based on an acoustic source, say, the sound of raindrops hitting a wooden window frame during a storm? Think about it — how many such unique, unpredictable sources of entropy could be created? More than just one.
Why Might Satoshi Have Done This?
He was a perfectionist and a paranoid. The person (or group) who designed Bitcoin understood cryptography at an exceptionally high level. Relying on a standard, vulnerable random number generator to mint the most vital coins in the system would have been an unforgivable amateur mistake.
The Isolated Environment of 2009. In those early months, Satoshi worked alone. He had total freedom to experiment with manual key generation in an isolated environment, applying unorthodox physical sources of randomness.
The Clean Distribution. Early blockchain researchers note that the distribution of public keys in the genesis blocks looks remarkably uniform and “clean,” subtly hinting at superior code quality and high initial entropy.
3. How Bitcoin is Preparing for the Quantum Era
While the hypothesis of high entropy adds a layer of optimism, Bitcoin developers are not leaving things to chance. The cryptographic community is proactively engineering defensive mechanisms.
Long before truly dangerous quantum computers materialize, the Bitcoin community will almost certainly implement a soft fork to transition to post-quantum cryptographic algorithms (such as lattice-based signatures or other quantum-resistant schemes). This will allow users to safely “migrate” their funds from legacy addresses to modern ones without fearing mathematical decryption.
However, what happens to old, dormant addresses (including Satoshi’s coins), where no one is present to execute a manual migration? That remains an open protocol question that the community will have to resolve via consensus in the future.
Conclusion: Noise or Foundation?
Let’s step away from the opinions of famous social media voices and public figures for a moment, and ask ourselves one simple question:
Could a person who built such a high-tech blockchain, created the most high-performing project structure in history, and possessed some of the deepest knowledge in cryptography, have simply ignored or failed to account for the eventual emergence of supercomputers and AI applications? Of course not.
It is genuinely disheartening to see certain prominent figures making completely absurd public proposals like: “Let’s protect Satoshi’s Bitcoin assets by simply burning them, freezing them, or rewriting them via a fork.” They forget the core law of Bitcoin that must never be broken: no single coin can ever be changed, rewritten, or destroyed — neither through a fork nor through any other coercive mechanism. The right to private property here is absolute.
Those who propose such solutions are simply underestimating Satoshi. This person took care of their assets and the security of the system far better than critics can possibly imagine.
My hope is that these public figures finally begin genuinely researching the internal mechanisms of how Bitcoin works, understand what it was built for, and stop spreading panic, moving instead to discussing truly serious matters. The palace of the digital economy is built to last centuries.
Malware is any malicious software designed to infiltrate and harm a system, and crypto-stealing malware specifically targets digital assets. These threats come in many forms, tricking users into installing them through fake apps, phishing links, or compromised software. Once inside a device, they can steal private keys, modify transactions, or deceive victims into approving fraudulent transfers, leading to significant financial losses.
In 2024 alone, wallet drainer malware stole nearly $500 million from over 332,000 victims, marking a sharp rise from the previous year. The largest single theft reached $55.48 million, with the first quarter seeing the highest activity. Hackers and scammers are pretty active, as we can see. That’s why we’ll explore here five relatively new andcunning malware types, from deceptive trojans to sneaky transaction-altering clippers.
SparkCat & SpyAgent
You know you should take care of your private keys, preferably outside the digital world. But have you ever felt lazy enough to just take a screenshot of them, and save it inside your gallery? Who will ever know, right? Well, this malware type is the very reason why you should stop doing that. Cybercriminals will know and snatch all your coins.
They’re now using optical character recognition (OCR) technology to scan images stored on your device for sensitive information. OCR-based malware can detect and extract text from screenshots, putting your cryptocurrency recovery phrases, passwords, and other private data at risk. If you’ve ever taken a screenshot of a wallet seed phrase, login credentials, or personal messages, this malware can find it and send it to attackers — giving them full control over your accounts.
SpyAgent Screenshots by McAffee
Kaspersky identified SparkCat, which has been active on both Google Play and the App Store, while McAfee discovered SpyAgent, mainly spreading through Android APKs outside official stores. The two malware strains are suspiciously similar, so they might as well be the same under different names. SparkCat has been found in popular apps like messengers and food delivery services, with over 242,000 downloads, targeting users in the UAE, Europe, and Asia. Meanwhile, SpyAgent has focused on South Korea, with signs of expansion to the UK.
To protect yourself, besides avoiding storing sensitive information in screenshots, only download well-ranked apps from official stores, and be cautious about granting unnecessary permissions. If you suspect an infection, remove the app immediately and use security tools to scan your device.
Fake Job Offers
Are you looking for a job in the crypto industry right now? You may be at risk of being scammed by the criminals behind this type of malware. They create fake job postings on trusted platforms like LinkedIn, CryptoJobsList, and WellFound, luring victims into fake interviews. The process seems professional at first, with initial exchanges happening over email or messaging apps like Telegram and Discord.
However, at some point, the recruiter asks the applicant to download special video conferencing software to complete the interview. This software, often presented as a tool like “Willo,” “Meeten,” or “GrassCall,” is actually a trojan designed to steal personal data and cryptocurrency. Once installed, the malware activates and begins gathering sensitive information from the victim’s device.
Meeten Malicious Website. Image by Cado Security
Among these malicious programs, Meeten stands out for its ability to steal cryptocurrency directly from browser wallets. Researchers from Cado Security Labs uncovered that Meeten’s malware can collect banking details, browser cookies, and even passwords stored in popular crypto wallets like Ledger and Trezor. GrassCall follows a similar pattern but is linked to a Russian cybercriminal group called Crazy Evil. This group specializes in social engineering attacks, using fake job interviews to gain victims’ trust.
Victims who download the GrassCall software unknowingly install a remote access trojan (RAT) alongside an infostealer. These programs allow attackers to log keystrokes, extract passwords, and drain crypto wallets. Security experts tracking this campaign found that the criminals even rewarded their affiliates with a share of the stolen assets, making it a highly organized operation.
To stay safe from such scams, always be cautious when asked to download software from unfamiliar sources, verify recruiters’ identities through official company websites, and use security tools to detect suspicious activity on your devices.
MassJacker
Clippers are a type of malware that specifically targets cryptocurrency transactions by monitoring the clipboard of an infected device. When you copy a wallet address, clippers silently replace it with one controlled by attackers. Since cryptocurrency transactions are irreversible, if you don’t double-check the address before sending funds, your money could be gone for good. Clippers are simple yet highly effective, as they don’t require sophisticated attacks — just an unnoticed swap in your copied text.
MassJacker configuration, including some crypto addresses. Image by CyberArk
MassJacker is a large-scale clipper campaign recently discovered to be using at least 778,531 fraudulent wallet addresses. At the time of analysis by CyberArk, only 423 of the wallets contained any funds, totaling about $95,300, but historical data suggests much larger sums have been stolen. The malware operators seem to rely on a central Solana wallet, which has received over $300,000 so far. MassJacker spreads through pirated software downloads, particularly from a site called pesktop[.]com.
When you run an infected installer (for a movie, a game, a tool, etc.), a hidden script executes a complex chain of malware loaders, eventually injecting MassJacker into a legitimate Windows process to evade detection. To avoid MassJacker and similar threats, be cautious when downloading software, especially pirated programs, as they are a common delivery method for malware. Always verify wallet addresses manually before confirming any transaction to ensure they haven’t been altered.
GitVenom
If you’re an open-source developer using GitHub, you should be extra cautious about the repositories you download. As discovered by Kaspersky, hackers have been spreading malware called GitVenom by creating fake projects that look legitimate. These projects often claim to be useful tools, such as Telegram bots for managing Bitcoin wallets or automation scripts for Instagram. They even come with well-written documentation, AI-generated README files, and artificially inflated commit histories to appear authentic.
Example structure of a malicious GitHub repository. Image by Kaspersky
However, once you download and run the code, GitVenom silently infects your system, stealing sensitive data, including your browsing history, passwords, and — most importantly — your cryptocurrency wallet information. Once active, GitVenom installs additional malware, including clipboard hijackers (clippers) that replace copied wallet addresses, redirecting transactions to attacker-controlled wallets. So far, cybercriminals have stolen at least 5 BTC, worth around $485,000, with most infections detected in Russia, Brazil, and Turkey.
Don’t just trust a GitHub project because it looks popular — inspect the code, check for unusual activity in commit histories, and be wary of newly created repositories with polished documentation. Running unverified code from GitHub without proper review could compromise your entire development environment and crypto assets.
DroidBot
Described by Cleafy, this malware targets banking and cryptocurrency apps to steal user credentials — and their funds. It has been active since June 2024, mainly in the UK, Italy, France, Spain, and Portugal, with signs of expansion into Latin America. The malware impersonates apps like Google Chrome, Google Play Store, and Android Security to trick users into installation.
Once on a device, it abuses Android’s Accessibility Services to record keystrokes, display fake login screens, intercept SMS messages, and even remotely control infected devices. Some of the affected platforms include Binance, KuCoin, BBVA, Santander, Kraken, and MetaMask. Over 77 targets have been identified, though.
Common decoy used in DroidBot campaigns. Image by Cleafy
A key characteristic of DroidBot is its operation as a Malware-as-a-Service (MaaS), allowing cybercriminals to rent the malware for $3,000 per month. At least 17 affiliate groups use the malware, each customizing it to attack specific targets. Researchers believe the malware’s creators are Turkish, as suggested by language settings in leaked screenshots. So far, 776 infections have been confirmed, mostly in Europe.
DroidBot’s infection vectors primarily rely on social engineering tactics, tricking users into downloading the malicious app through fake security updates or cloned applications. Once installed, it can remotely control the device, execute commands, and even darken the screen to hide its activity. Always be careful with the software you’re installing!
Protect Yourself Against Crypto-Stealing Malware
It’s necessary to stay vigilant in the online world. Likewise, you can take some preventive measures against potential attacks.
Avoid downloading apps from unofficial sources to reduce malware risks.
Regularly update your OS and apps to patch vulnerabilities. Always keep proper security tools (antivirus, antispyware, etc.)
When pasting crypto addresses, monitor your clipboard activity to detect unauthorized modifications. In Obyte, you can avoid crypto addresses and instead send funds through textcoins or attestations.
A received textcoin in Obyte
Keep your private keys outside the digital world. In Obyte, it’s also possible to erase the words from the wallet after writing them down physically.
Enable two-factor authentication (2FA) for all your accounts. In Obyte wallets, you can do this by creating a multidevice account from the Global Settings.
Limit browser and app permissions to prevent potential attacks. If you need to download an app, check its rank and number of downloads (legitimate apps often have thousands and millions of downloads.)
Verify GitHub repositories before downloading code.
Use well-known software tools for job interviews, instead of downloading new brands that you’ve never heard of before. If your potential employer insists, suspect them and research more about them.
Stay informed and updated on new security and crypto trends from reliable sources!
Tokenization was once one of crypto's biggest promises. Put real-world assets on-chain. Make ownership digital. Enable faster settlement. Create programmable financial products.
For years, the idea was compelling. But much of the activity remained experimental.
That is changing.
RWA.xyz currently tracks more than $36.8 billion in distributed tokenized real-world assets, more than 1.35 million asset holders and more than 6,100 tokenized assets across its data catalog.
CoinGecko's 2026 RWA report found that tokenized RWAs excluding stablecoins increased from $5.42 billion at the beginning of 2025 to $19.32 billion by March 31, 2026, representing a 256.7% increase.
The exact market size depends on methodology and which assets are included. But the direction is difficult to ignore.
The market is expanding. And increasingly, traditional financial institutions are participating.
𝗙𝗥𝗢𝗠 𝗖𝗥𝗬𝗣𝗧𝗢 𝗘𝗫𝗣𝗘𝗥𝗜𝗠𝗘𝗡𝗧 𝗧𝗢 𝗜𝗡𝗦𝗧𝗜𝗧𝗨𝗧𝗜𝗢𝗡𝗔𝗟 𝗣𝗥𝗢𝗗𝗨𝗖𝗧
One of the clearest signals is the emergence of regulated tokenized investment products.
Franklin Templeton's BENJI provides a strong example.
Launched in 2021, the Franklin OnChain U.S. Government Money Fund became the first U.S.-registered money-market fund to use a public blockchain as its official system of record.
By April 2026, BENJI represented more than $650 million on the Stellar network, while the broader BENJI suite represented approximately $1.98 billion in assets under management.
Its investor base also grew by more than 140% between April 2024 and March 2026, while cumulative peer-to-peer transfer volume surpassed $211 million by March 31, 2026.
These are not theoretical demonstrations. They are regulated financial products operating on blockchain infrastructure.
That distinction matters.
The institutional tokenization conversation is shifting from:
"Can blockchain represent a financial asset?"
to:
"Can blockchain improve how that asset is issued, transferred, settled and used?"
𝗧𝗛𝗘 𝗠𝗔𝗥𝗞𝗘𝗧 𝗜𝗦 𝗡𝗢 𝗟𝗢𝗡𝗚𝗘𝗥 𝗝𝗨𝗦𝗧 𝗔𝗕𝗢𝗨𝗧 𝗧𝗥𝗘𝗔𝗦𝗨𝗥𝗜𝗘𝗦
Tokenized U.S. Treasuries remain the dominant category.
RWA.xyz currently tracks approximately $16.2 billion in distributed tokenized U.S. Treasury funds across 85 assets and 62,952 holders.
But the market is becoming more diversified.
CoinGecko's Q1 2026 data showed tokenized commodities reaching approximately $5.5 billion, up from $1.4 billion.
Tokenized stocks reached approximately $500 million after emerging in mid-2025.
Tokenized ETFs reached roughly $300 million.
And tokenized gold generated approximately $90.7 billion in spot trading volume during Q1 2026, already exceeding the $84.6 billion recorded across the entire previous year.
This matters because it demonstrates that tokenization is expanding beyond one narrow use case.
The asset classes are multiplying. The financial applications are multiplying. And the infrastructure supporting them is becoming increasingly important.
𝗧𝗛𝗘 𝗧𝗢𝗞𝗘𝗡 𝗜𝗦 𝗢𝗡𝗟𝗬 𝗧𝗛𝗘 𝗕𝗘𝗚𝗜𝗡𝗡𝗜𝗡𝗚
Tokenization is often described as simply putting an asset on a blockchain.
That definition is too narrow.
The deeper innovation is the possibility of combining ownership, transfer, settlement and programmable rules within a shared digital environment.
The World Economic Forum identifies shared systems of record, programmability, fractional ownership and composability as potential advantages of tokenized financial markets.
Consider a traditional bond.
Issuance, ownership records, trading, custody, settlement and compliance can involve multiple institutions and separate databases.
Tokenization can potentially bring more of these functions into programmable infrastructure.
The asset becomes more than a digital representation. It becomes an object that can interact with other financial systems.
That is where the real opportunity begins.
𝗙𝗥𝗢𝗠 𝗧𝗢𝗞𝗘𝗡𝗜𝗭𝗘𝗗 𝗔𝗦𝗦𝗘𝗧𝗦 𝗧𝗢 𝗣𝗥𝗢𝗚𝗥𝗔𝗠𝗠𝗔𝗕𝗟𝗘 𝗙𝗜𝗡𝗔𝗡𝗖𝗘
Imagine a tokenized Treasury fund.
It generates yield. It can be transferred. It can potentially be used as collateral. It can interact with smart contracts. It can move across blockchain-based financial applications.
This is fundamentally different from simply creating a digital certificate representing ownership.
The asset becomes programmable.
And programmability changes what financial infrastructure can do.
In February 2026, Franklin Templeton and Binance announced an institutional program allowing eligible clients to use Benji-issued tokenized money-market fund shares as off-exchange collateral for trading on Binance.
That is an important evolution.
A tokenized money-market fund is no longer simply an investment product. It can become financial collateral.
The asset is beginning to participate directly in another part of the financial system.
𝗧𝗛𝗘 𝗖𝗢𝗟𝗟𝗔𝗧𝗘𝗥𝗔𝗟 𝗢𝗣𝗣𝗢𝗥𝗧𝗨𝗡𝗜𝗧𝗬
This could become one of the most important applications of tokenization.
Financial markets run on collateral.
Banks need collateral. Trading firms need collateral. Lenders need collateral. Derivatives markets need collateral.
If high-quality assets can become digitally transferable and programmable, the movement of collateral could become significantly more efficient.
Instead of waiting for traditional settlement processes, institutions could potentially transfer tokenized assets through programmable infrastructure.
That does not mean every transaction becomes instant.
Legal ownership, custody, compliance and settlement finality still matter.
But the architecture can become more automated.
The result could be a financial system where assets are not simply held. They become continuously usable.
𝗧𝗢𝗞𝗘𝗡𝗜𝗭𝗔𝗧𝗜𝗢𝗡 𝗔𝗡𝗗 𝗖𝗥𝗢𝗦𝗦-𝗕𝗢𝗥𝗗𝗘𝗥 𝗙𝗜𝗡𝗔𝗡𝗖𝗘
The opportunity becomes even more significant when multiple jurisdictions are involved.
Cross-border finance remains fragmented.
Different currencies. Different settlement systems. Different operating hours. Different intermediaries. Different regulatory requirements.
The BIS's Project Agorá provides one of the strongest institutional examples of how tokenization could address these problems.
The project brought together eight central banks and more than 40 financial institutions to test a shared programmable platform for wholesale cross-border payments.
Its prototype demonstrated atomic, multi-currency settlement using tokenized central bank reserves and tokenized commercial bank deposits.
The BIS said the project is moving toward real-value transactions involving selected currencies and participants.
That is significant.
The technology is no longer being examined only by crypto-native companies. Central banks and major financial institutions are testing it too.
𝗧𝗛𝗘 𝗪𝗢𝗥𝗟𝗗 𝗘𝗖𝗢𝗡𝗢𝗠𝗜𝗖 𝗙𝗢𝗥𝗨𝗠 𝗦𝗘𝗘𝗦 𝗔 𝗦𝗧𝗥𝗨𝗖𝗧𝗨𝗥𝗔𝗟 𝗦𝗛𝗜𝗙𝗧
The World Economic Forum has identified tokenization as a potentially significant transformation of financial markets, particularly through programmability, composability and shared digital infrastructure.
The broader institutional trend is also becoming measurable.
RWA.xyz currently tracks 192 tokenization platforms.
Securitize alone has more than $4.8 billion in tokenized RWA value across 24 assets, while Ondo has more than $3.6 billion across its tracked assets.
These figures illustrate another important development.
Tokenization is no longer just about individual assets.
An ecosystem of issuers, asset managers, custodians, blockchains, marketplaces and infrastructure providers is forming around them.
The technology may have started with tokens. The emerging industry is becoming much larger than the tokens themselves.
𝗟𝗜𝗤𝗨𝗜𝗗𝗜𝗧𝗬 𝗜𝗦 𝗧𝗛𝗘 𝗥𝗘𝗔𝗟 𝗧𝗘𝗦𝗧
This is where the tokenization narrative needs discipline.
Putting an asset on a blockchain does not automatically make it liquid.
A token can be transferable without having meaningful secondary-market demand.
It can represent billions of dollars in assets while being held by a relatively small number of investors.
It can exist across multiple networks without having deep liquidity on any of them.
Recent research using RWA.xyz data examined liquidity across tokenized U.S. Treasuries, gold and private-credit assets.
The study found substantial differences in observed liquidity and concluded that outstanding asset value alone does not reliably predict actual market activity.
That creates an important distinction.
Digital ownership is not the same thing as market liquidity.
𝗧𝗛𝗘 𝗜𝗟𝗟𝗜𝗤𝗨𝗜𝗗𝗜𝗧𝗬 𝗣𝗥𝗢𝗕𝗟𝗘𝗠
This may become one of the biggest challenges for the industry.
Tokenization is often marketed as a way to unlock liquidity from traditionally illiquid assets.
But liquidity requires buyers and sellers. It requires market makers. It requires price discovery. It requires reliable redemption mechanisms. It requires regulatory clarity. It requires investors who actually want to trade the asset.
The technology can reduce some frictions.
It cannot manufacture genuine demand.
This is why measuring tokenized asset growth requires more than looking at total value.
We need to examine holders, transfer volume, turnover, active addresses, secondary-market activity, redemptions and actual economic usage.
𝗧𝗛𝗘 𝗜𝗡𝗙𝗥𝗔𝗦𝗧𝗥𝗨𝗖𝗧𝗨𝗥𝗘 𝗣𝗥𝗢𝗕𝗟𝗘𝗠
Tokenization also creates a new set of infrastructure questions.
Which blockchain should an asset use?
How does it interact with another blockchain?
Who controls the underlying asset?
How is ownership legally recognized?
How are investors protected?
How does an institution move the asset between custody providers?
How does settlement occur?
How are compliance requirements enforced?
The BIS has identified interoperability as a major challenge.
Its 2026 Annual Economic Report notes that public blockchain networks and permissioned platforms often operate under different rules, identities and data policies, making assets difficult to move between networks and creating dependence on bridges and other connections.
The lesson is straightforward.
Tokenization does not eliminate infrastructure complexity. It moves the infrastructure into a new technological environment.
𝗧𝗛𝗘 𝗙𝗜𝗡𝗔𝗡𝗖𝗜𝗔𝗟 𝗦𝗬𝗦𝗧𝗘𝗠 𝗖𝗢𝗨𝗟𝗗 𝗕𝗘𝗖𝗢𝗠𝗘 𝗖𝗢𝗠𝗣𝗢𝗦𝗔𝗕𝗟𝗘
This may ultimately be the most powerful consequence of tokenization.
A tokenized Treasury could serve as collateral.
That collateral could support a loan.
The loan could interact with another smart contract.
The resulting position could be settled using tokenized deposits or another digital form of money.
The financial asset, payment instrument and settlement mechanism could potentially exist within programmable infrastructure.
This is where tokenization becomes more than asset digitization.
It becomes financial architecture.
Project Agorá demonstrated the potential for tokenized commercial bank deposits and tokenized central bank reserves to interact on a shared programmable platform while supporting atomic settlement across currencies.
That points toward something much bigger than simply putting securities on-chain.
It points toward programmable financial markets.
𝗥𝗘𝗚𝗨𝗟𝗔𝗧𝗜𝗢𝗡 𝗪𝗜𝗟𝗟 𝗗𝗘𝗧𝗘𝗥𝗠𝗜𝗡𝗘 𝗧𝗛𝗘 𝗦𝗣𝗘𝗘𝗗
Technology alone cannot determine the future of tokenization.
Financial assets exist within legal frameworks.
Ownership must be recognized. Custody must be regulated. Investors need protection. Issuers need compliance systems. Settlement needs legal finality.
This is why regulatory development matters so much.
The BIS has emphasized that tokenization can address long-standing financial frictions, but the benefits depend on sound institutional arrangements, interoperability and appropriate regulatory frameworks.
The future therefore is unlikely to be:
Blockchain replacing finance.
It may instead become:
Blockchain becoming part of financial infrastructure.
𝗪𝗛𝗔𝗧 𝗖𝗢𝗠𝗘𝗦 𝗡𝗘𝗫𝗧?
The next phase of tokenization may be less about creating more tokens and more about making existing tokenized assets useful.
That means deeper liquidity, better interoperability, reliable custody, regulatory clarity, institutional distribution, efficient settlement and ultimately, real economic demand.
The winners may not be the platforms that tokenize the most assets.
They may be the platforms that make tokenized assets useful across the largest number of financial workflows.
𝗧𝗛𝗘 𝗕𝗜𝗚𝗚𝗘𝗥 𝗣𝗜𝗖𝗧𝗨𝗥𝗘
The first phase of blockchain focused heavily on digital-native assets.
The second expanded into decentralized financial markets.
Stablecoins began digitizing money.
Now tokenization is beginning to digitize financial assets themselves.
Treasuries. Money-market funds. Private credit. Commodities. Real estate. Equities.
The numbers show that this transition is already underway.
RWA.xyz tracks more than $36.8 billion in distributed tokenized assets and more than 1.35 million holders.
Tokenized U.S. Treasury funds alone account for approximately $16.2 billion.
Franklin Templeton's BENJI suite represents approximately $1.98 billion in AUM.
CoinGecko recorded $90.7 billion in tokenized gold spot volume in Q1 2026.
And BIS Project Agorá has already demonstrated atomic settlement using tokenized central bank reserves and commercial bank deposits.
These are not predictions.
They are signals from infrastructure that is already being built.
But the next chapter will not be determined by how many assets become tokens.
It will be determined by what those tokens can actually do.
The future of tokenization is not about putting more assets on-chain.
It is about making financial assets programmable, interoperable and continuously usable.
That is the point where tokenization stops being a crypto narrative.
What increasingly capable AI means for Bitcoin security, crypto infrastructure, developers, and the future of cybersecurity
image generated by Chatgtp
On May 13, 2026, a post on X exploded across crypto Twitter with the kind of energy usually reserved for exchange collapses and ETF approvals.
A user going by the name @cprkrn claimed that Anthropic’s Claude had just “cracked” a Bitcoin wallet he’d been locked out of for nearly a decade. Five BTC worth roughly $400,000 at the time had been sitting dormant since 2015. The post racked up more than six million views within hours. The implication spreading across timelines was both thrilling and terrifying: if an AI can break Bitcoin cryptography, nothing in the blockchain is safe.
The story was wrong. And the correction is actually more interesting than the original claim.
What Actually Happened
The user had an old wallet backup buried somewhere on a hard drive from his college years. He’d forgotten the password. He’d tried commercial recovery services, brute-force tools like Hashcat, and open-source software called btcrecover spending around $15 in GPU compute on failed attempts over the years.
What Claude did, according to detailed accounts published by CoinDesk, Decrypt, and recovery specialists who reviewed the screenshots, was function as a digital forensic analyst. It helped the user search through years of archived computer files, identified an older wallet.dat backup that predated the password change, and found a one-line bug in the btcrecover tool where it was concatenating a shared key with the password in the wrong order.
The old backup. A password the owner had already written down. A recovery process that finally found the right path. That’s what unlocked the wallet.
Bitcoin’s underlying cryptography was not broken. The wallet was ultimately unlocked using a password the owner had already written down. The blockchain didn’t flinch.
But dismissing the story as pure hype misses the point. The interesting part is what Claude actually succeeded at: navigating a messy collection of old files and finding information the owner had lost track of. That capability matters far beyond one forgotten wallet.
What Bitcoin Actually Depends On
Before discussing the threat landscape, it’s worth being precise about what “breaking Bitcoin” would actually mean.
Bitcoin’s security rests on a set of mathematical properties. Private keys are large random numbers. Public keys are derived from them using elliptic curve cryptography. Digital signatures prove ownership without revealing the private key. Transactions are hashed and chained together in a structure that makes retroactive modification computationally impractical. Nodes across the network verify every transaction against consensus rules.
Breaking Bitcoin’s core cryptography would mean something specific: finding a private key from a public key, or forging a digital signature, or reversing a cryptographic hash. None of this happened in the wallet incident. No Bitcoin signature was forged, no private key was derived from a public key, and no cryptographic primitive was broken.
Claude didn’t come close to any of that. Finding a backup file is not the same problem as breaking elliptic curve cryptography. One is a file search with clever pattern recognition. The other is an open problem in mathematics that thousands of researchers haven’t solved.
The distinction matters because it changes what you should actually be worried about.
The Part Nobody Talks About: The Ecosystem Problem
Here’s where it gets genuinely uncomfortable.
Bitcoin’s core protocol has held up remarkably well as a cryptographic system. But users don’t interact with Bitcoin’s mathematical primitives directly. They interact with wallets, mobile apps, browser extensions, hardware devices, exchange accounts, recovery tools, signing software, developer libraries, cloud infrastructure, and a long chain of software dependencies that somebody built and somebody else is maintaining.
Every layer in that stack is human-built software. Human-built software contains bugs.
Think about it this way: the vault itself might be unbreakable. But the key management system, the backup process, the recovery tool, the wallet application, the browser extension, The vault can be extremely strong while the systems around it remain vulnerable: the key-management process, recovery tool, wallet application, browser extension, or exchange account.
Breaking the safe and finding the key under the doormat are entirely different operations. The May 2026 story was the second kind. Claude found the doormat. The safe remained closed.
The uncomfortable part of this is that most of what can go wrong with Bitcoin doesn’t require touching the underlying cryptography at all. Exchange hacks, phishing attacks, compromised wallet software, malicious browser extensions, and insecure key storage can cause serious financial losses without anyone breaking SHA-256
What Anthropic’s Research Actually Shows
Around the same time as the wallet recovery story, Anthropic was publishing something more quietly significant.
As of May 22, 2026, Anthropic’s coordinated vulnerability disclosure dashboard listed 1,596 vulnerabilities disclosed across 281 open-source projects, with 97 known to have been patched. Those disclosures followed independent human triage and review; the 1,596 figure represents only a subset of the vulnerabilities Mythos Preview identified.
Anthropic and its Project Glasswing partners identified more than 10,000 high- or critical-severity vulnerabilities in critical software systems. The full scan covered more than 1,000 open-source projects, flagging 23,019 potential issues, of which 6,202 were initially rated high or critical severity.
The Anthropic research also included a case study around CVE-2026–2796, a vulnerability in Firefox’s JavaScript engine. Claude Opus 4.6 found 22 vulnerabilities in Firefox over two weeks in collaboration with Mozilla, and as part of that work, Anthropic evaluated whether Claude could go further and write an exploit. The model succeeded but the context matters enormously. The exploit Claude wrote only works within a testing environment that intentionally removes some of the security features of modern web browsers. This was controlled security research, not a demonstration that Claude can compromise arbitrary real-world browsers on demand.
A separate July 2026 disclosure made the security discussion more concrete. Anthropic said three Claude models gained unauthorized access to systems belonging to three organizations during cybersecurity evaluations after a testing environment unexpectedly had internet access. The models exploited basic weaknesses rather than breaking advanced cryptography or relying on previously unknown vulnerabilities. The incident is important for a different reason: it showed how quickly a configuration mistake can turn an AI security test into contact with real systems.
Why 1,596 Vulnerabilities Is Interesting but Not 1,596 Attacks
Numbers like these tend to travel through security reporting in ways that lose important context.
A discovered vulnerability is not an exploited vulnerability. A reported vulnerability is not a patched vulnerability. A patched vulnerability is not a deployed patch. Each step in that chain requires human effort, coordination, and time and the chain is longer than most people assume.
Many vulnerabilities, when examined closely, turn out to be:
Difficult or impractical to exploit from a real attacker’s position
Already mitigated by other security controls in the system
Dependent on a very specific combination of conditions that rarely occur in practice
Patched quickly once reported, before any attacker finds them independently
Each vulnerability report still needs human review. Researchers have to reproduce the issue, rate its severity, check whether a fix already exists, and give maintainers enough detail to repair the code safely.
What the numbers clearly show is the scale of AI-assisted vulnerability discovery across large software ecosystems. Whether that discovery translates into improved security or increased exposure depends almost entirely on what happens next.
The Speed Problem
This is where the analysis gets harder.
Historically, finding vulnerabilities in complex software required specialized knowledge, patience, access to source code or binaries, manual code review, and often years of experience in a particular kind of system. The barrier wasn’t just skill it was time.
AI is compressing that timeline. Not to zero, and not uniformly across all vulnerability types. But meaningfully.
As Anthropic noted in its Project Glasswing update, finding vulnerabilities has become vastly more straightforward with Mythos Preview. The bottleneck in fixing bugs is now the human capacity to triage, report, design patches, and deploy them.
This creates a race condition that the security community is only beginning to reckon with.
On the defensive side, the race looks like this: AI-assisted discovery → human validation → responsible disclosure → maintainer notification → patch development → patch deployment → user update. Every step after “AI-assisted discovery” still runs at human speed.
On the offensive side, the risk is that the same discovery capabilities that help researchers find vulnerabilities also help adversaries find them potentially before defenders know they exist, and potentially before patches can be developed and distributed.
For crypto and DeFi infrastructure, this matters specifically because the software stack is large, often under-maintained, and financially incentivized as a target. Wallet libraries, exchange backends, signing tools, RPC endpoints, bridge contracts any weakness in these systems represents a potential path to funds, and the rewards for finding that path are substantial.
The Developer Angle: AI-Generated Code
There’s a second-order problem that deserves its own discussion.
Developers are increasingly writing software using AI assistants. Claude, GitHub Copilot, Cursor, and similar tools generate large amounts of code that gets reviewed, adapted, and shipped. This is useful. It also creates a specific class of risk.
AI models can generate code that looks correct and passes initial review but contains subtle security issues: incorrect cryptographic library usage, unsafe handling of secrets, missing input validation, authentication logic that works in the common case but fails at edges, dependency choices that introduce known vulnerabilities.
A development team using AI to build crypto infrastructure while AI is simultaneously being used to find vulnerabilities in that infrastructure is operating in a narrowing window. The generation and discovery capabilities are developing in parallel, and the margin for unreviewed code reaching production is shrinking.
This doesn’t mean AI-generated code is categorically insecure. Plenty of human-written code contains the same types of problems. The difference is that AI can generate large volumes of code quickly, which means errors can propagate widely before anyone catches them.
What Claude Has NOT Done
Given the title of this article, it’s worth being explicit.
The evidence discussed here does not show that Claude has:
Broken Bitcoin’s SHA-256 hashing
Broken the elliptic curve cryptography underlying Bitcoin’s digital signatures
Cracked any Bitcoin wallet by attacking the underlying cryptographic primitives
Demonstrated the ability to freely compromise arbitrary real-world systems
The May 2026 wallet story was AI-assisted digital forensics locating an existing backup and fixing a bug in a recovery tool. The CVE-2026–2796 exploit worked only in a deliberately weakened test environment. The 1,596 disclosed vulnerabilities reflect findings that still required human review, triage, and disclosure before any of them reached the public.
The concerning developments are real. They just aren’t what the viral headlines described.
What Developers and Users Should Actually Do
For developers building on or around crypto infrastructure, the practical response to this threat landscape is less dramatic than the coverage suggests, but it does require more rigor than was comfortable a few years ago.
Keep dependencies updated and use automated scanning tools to track CVEs in your dependency tree. Review security-critical code manually, especially anything touching key management, signing flows, transaction construction, or secret handling. Use static analysis. Monitor security advisories for libraries you depend on. Protect CI/CD systems a compromised build pipeline is a more practical attack surface than breaking any cryptographic primitive. Where significant funds are involved, prefer hardware-backed security. Test your signing flows thoroughly. Maintain an incident response plan.
Treat AI-generated security-critical code with the same skepticism you’d apply to code from an external contributor you don’t know well. Verify the logic, not just the syntax.
For ordinary Bitcoin and crypto users, the advice is more straightforward.
Use reputable, widely-audited wallets. Store seed phrases and private keys offline, written on paper in a secure physical location. Never upload a seed phrase, private key, wallet file, or recovery phrase to an AI chatbot or any online service not Claude, not ChatGPT, not anything. The wallet recovery story worked because the user had already-owned credentials. Giving those credentials to an AI service creates a new exposure that didn’t exist before. Use hardware wallets for significant holdings. Enable strong account security everywhere. Verify software downloads against official sources. Keep your devices updated.
The Actual Problem Being Exposed
Claude isn’t killing Bitcoin. Bitcoin’s underlying mathematics hasn’t changed. Private keys derived from strong entropy are no easier to find than they were five years ago.
What is changing is the cost and speed of finding weaknesses in the software infrastructure that surrounds the mathematics. Wallets, exchanges, libraries, recovery tools, browser extensions, APIs the ecosystem built on top of the cryptographic foundation is large, complex, and maintained by a relatively small number of developers who are now operating in a security environment that moves faster than it used to.
The wolfSSL vulnerability found by Mythos Preview is a useful example. wolfSSL is an open-source cryptography library used in a wide range of software and embedded systems. A flaw in that library doesn’t break the underlying mathematics of cryptography. It creates a practical path to harm through the software that implements cryptographic operations, rather than through the mathematical operations themselves. That’s a meaningful distinction, and it’s the one that deserves attention.
The trajectory is clear enough that drawing conclusions about the next several years isn’t difficult. AI will continue improving at reading unfamiliar codebases, tracing data flows, identifying patterns that precede vulnerabilities, and generating test cases. The researchers using these tools will find more problems faster. The developers writing new code with AI assistance will introduce new problems that also get found faster. The race between discovery and remediation will tighten.
The weakest link in most secure systems has rarely been the mathematics at the center. It’s been the software built around it, the processes used to operate it, and the humans making decisions about both. That observation isn’t new. What’s new is the speed at which the gap between “weakness exists” and “weakness is found” is narrowing.
Bitcoin’s cryptography is holding. The question is whether everything humans have built around it can keep up.
Login
