hodler

6 Jun 2026, 09:20

Alephium Token Bridge Exploited for $815,000 in Guardian Key Attack

BitcoinWorld Alephium Token Bridge Exploited for $815,000 in Guardian Key Attack The Alephium token bridge has been exploited for approximately $815,000 after an attacker compromised three of the four guardian keys securing the cross-chain protocol, according to blockchain security firm Blockaid. The incident marks the latest in a series of attacks targeting cross-chain infrastructure in the decentralized finance ecosystem. How the Exploit Unfolded Blockaid reported that the attacker gained control of three out of four guardian keys responsible for signing verification messages on the bridge. This enabled the signing of a forged VAA (Verification of Asset Authenticity) message, which was then used to authorize the unauthorized transfer of assets out of the bridge’s liquidity pools. The total loss stands at roughly $815,000, though the exact breakdown of stolen tokens has not yet been fully disclosed. Guardian keys are a common security mechanism in cross-chain bridges, designed to require a threshold of signatures from trusted validators before transactions can be approved. In this case, the threshold was set at three out of four, meaning a single key compromise would not have been sufficient — but the attacker managed to breach three separate keys, bypassing the protocol’s intended security layer. Implications for Cross-Chain Security The Alephium incident highlights a persistent vulnerability in multi-signature bridge architectures: the risk of simultaneous key compromise. While threshold signatures are intended to distribute trust, the concentration of keys within a small validator set can create a single point of failure if multiple validators are compromised through similar attack vectors. Blockaid noted that the attack appears to have been carefully planned, targeting the specific key management infrastructure rather than exploiting a smart contract bug. This distinction is important because it shifts the focus from code auditing to operational security and key management practices. Market and Community Response Following the disclosure, the Alephium team confirmed they are investigating the incident and working with security firms to trace the stolen funds. The bridge has been temporarily paused to prevent further losses. Token prices for Alephium’s native ALPH token saw a moderate decline in the hours following the news, reflecting broader market concerns about cross-chain security. For users who have assets bridged to or from Alephium, the immediate risk appears contained to the bridge contract itself. However, the incident serves as a reminder that cross-chain bridges remain one of the most targeted attack surfaces in DeFi, with over $2 billion lost to bridge exploits since 2021 according to industry data. Conclusion The $815,000 Alephium bridge hack underscores the ongoing challenges in securing cross-chain infrastructure. While the absolute loss is relatively modest compared to larger DeFi exploits, the method — compromising multiple guardian keys — raises fundamental questions about key management and validator security in bridge architectures. Users and developers alike will be watching closely to see what remediation measures the Alephium team implements and whether the industry moves toward more robust key distribution models. FAQs Q1: What is a guardian key in a token bridge? A guardian key is a cryptographic key held by a trusted validator or entity that must sign off on transactions before they are executed on the bridge. A threshold of multiple guardian signatures is typically required to authorize a transfer, adding a layer of security against single-point failures. Q2: How did the attacker compromise three guardian keys? Blockaid has not disclosed the exact method, but common attack vectors include phishing, social engineering, exploiting weak key storage practices, or compromising the infrastructure where keys are stored. The investigation is ongoing. Q3: What should Alephium users do now? Users who have assets on the Alephium bridge should monitor official announcements from the Alephium team. The bridge has been paused, which prevents further withdrawals or deposits. Users should not interact with the bridge contract until it is declared safe. No action is needed for assets held directly on the Alephium mainnet. This post Alephium Token Bridge Exploited for $815,000 in Guardian Key Attack first appeared on BitcoinWorld .

6 Jun 2026, 08:55

Zcash’s Orchard Shock: Why Supply Verification Became ZEC’s Main Catalyst

Zcash’s privacy promise rests on advanced cryptography. But in late May 2026, the project faced a shock: a “soundness” vulnerability in the Orchard circuit called its most important asset—verifiable integrity—into question. Overnight, the conversation around ZEC pivoted from fees and throughput to a single issue: can total supply be trusted? This article cuts through the noise. If you hold ZEC, operate an exchange desk , or build with shielded transactions, you will find a practical playbook to navigate updates, assess supply-verification options, and avoid common mistakes while the ecosystem shores up trust . AspectWhat to KnowWhat happenedA critical soundness bug was discovered in Zcash’s Orchard zero-knowledge circuit and responsibly disclosed on May 29, 2026 by researcher Taylor Hornby, engaged by Shielded Labs ( Zcash Foundation ).Emergency responseA two-step response: a soft fork that disabled Orchard at height 3,363,426 (early June 2, 2026 UTC), then NU6.2 (Zebra 5.0.0) re-enabled Orchard at block 3,364,600 on June 3, 2026 (00:05 EDT) ( Zcash Foundation ).Adoption backdropShielded holdings had just surged to roughly 5.0M ZEC (~30% of ~16.7M circulating), with Orchard holding ~4.2M ZEC (~25.4%) in late May 2026 ( ZcashTracker ).Market reactionPublic disclosure and fixes coincided with a sharp drawdown; reports cited ~30–40% declines and multi‑billion market-cap evaporation around June 5, 2026 ( CoinTelegraph ).Main riskConfidence in supply integrity. Even if no exploit occurred, the mere possibility elevated “auditability” from niche concern to core investment criterion.Near-term taskGet upgraded, verify operational dependencies, and decide policies for shielded flow until community-level mitigations mature.Longer-term trackProposals include formal verification of Orchard and a new shielded pool with a “turnstile” for public supply checks ( KuCoin ). Core Concepts Zcash supports both transparent addresses and private, “shielded” addresses. Shielded transactions rely on zero-knowledge proofs to show that assets are conserved without revealing amounts or participants. In this model, a circuit’s soundness is paramount: if a bug lets someone create value from nothing, the ledger’s supply could be inflated without easy detection. In late May 2026, an independent researcher working with Shielded Labs found precisely such a risk in the Orchard circuit and disclosed it to Zcash engineers. The project executed an emergency soft fork and then the NU6.2 hard fork to address the issue and re-enable Orchard after patching ( Zcash Foundation ). This incident landed amid strong shielded adoption. By late May 2026, about 5.0 million ZEC—roughly 30% of circulating supply—sat in shielded pools, with Orchard alone holding ~4.2 million ZEC (~25.4%). That depth underscores why supply verification is now the overriding narrative for ZEC, not just a cryptography footnote ( ZcashTracker ). Glossary: the moving parts Orchard — Zcash’s latest shielded pool/circuit enabling private transfers with improved performance and UX. Soundness — A zero-knowledge property that ensures proofs cannot assert false statements (e.g., minting coins from thin air). Soft fork — A backward-compatible rule change; in this case, used to disable Orchard transactions swiftly. NU6.2 (Zebra 5.0.0) — The emergency network upgrade and release that re-enabled Orchard after patching. Turnstile accounting — A proposed design where funds must transition through a checkpoint, enabling public supply integrity checks without revealing transaction details. Step-by-Step Playbook Upgrade your stack immediately. Wallets, nodes, and services should move to releases compatible with the NU6.2 patch (e.g., Zebra 5.0.0 or later) before processing new shielded flow. Freeze-and-review policy for shielded deposits. Exchanges and OTC desks can apply enhanced monitoring or temporary holds on large shielded deposits until post-patch behavior is well characterized. Use viewing keys and address segmentation. For operational safety, separate treasury, hot, and cold flows, and use viewing keys to monitor shielded balances without de-shielding. Reconcile with transparent rails. Where possible, settle internal accounting in transparent addresses during the near term, then batch into shielded pools once procedures are validated. Track chain health signals. Monitor client diversity, block propagation, mempool behavior, and shielded pool deltas across blocks after the re-enable height to spot anomalies early. Document assumptions for audit. If you are a custodian or fund, write down your operational assumptions about supply integrity and how you would detect inconsistencies; review weekly until conditions normalize. Plan for alternative liquidity. Map out ZEC liquidity venues that support transparent withdrawals and keep emergency counterparties on file if shielded rails slow temporarily. Why “Supply Verification” Became the ZEC Catalyst Privacy coins walk a tightrope: strong confidentiality makes public auditing inherently harder. In Zcash, shielded pools hide amounts, so most observers rely on circuit soundness and protocol accounting to be confident that no excess ZEC exists. When a soundness issue surfaces—even if swiftly patched—the perceived possibility of undetected inflation forces markets to reassess risk. That is exactly what unfolded. Following public disclosure and emergency upgrades, multiple outlets reported that ZEC fell roughly 30–40% with billions shaved off market value in early June 2026 ( CoinTelegraph ). The market’s message was blunt: supply integrity is the meta-driver of ZEC’s cost of capital. Everything else—fees, throughput, even UX—sits downstream of that trust anchor. Crucially, the incident arrived at a time of real shielded usage: about 30% of circulating supply was in shielded pools, roughly 25% in Orchard specifically, just before disclosure ( ZcashTracker ). That structural adoption amplifies both the upside of privacy and the downside if verifiability is in doubt. Pro tip: Take pre- and post-upgrade snapshots of shielded pool totals from reputable trackers and your own node. You are not “proving” global supply, but you are establishing a baseline to detect outliers quickly. Where the Project Goes Next: Options on the Table Several mitigation paths are under discussion. Early signals from ecosystem participants include formal verification of the Orchard circuit, growing security staff, and a new shielded pool design with a turnstile that enables public supply checks even under strong privacy ( KuCoin ). Below is a high-level comparison of the main approaches, each with material trade-offs. OptionHow it WorksProsConsBest Use CaseStatus quo (post-NU6.2 Orchard)Patched Orchard circuit continues; community emphasizes bug bounty, audits, and monitoring.Fastest path; minimal UX change; leverages existing wallets and infra.Relies on continued circuit correctness; public can’t easily check supply end-to-end.Short-term continuity while deeper mitigations are specified.Formal verificationMathematically prove core parts of the circuit and protocol properties.Raises assurance beyond audits; institutional confidence boost.Time- and resource-intensive; scope limits may leave edges unproven.Mid- to long-term credibility investment.Turnstile-enabled shielded poolIntroduce a checkpoint that allows aggregate supply reconciliation without exposing user data.Balances privacy with public supply checks; addresses central investor concern.Requires new design and migration plan; possible friction for users and devs.Long-term path to durable market trust.Operational restrictions (policy)Exchanges/custodians throttle or require transparent rails for high-value flows.Reduces exposure quickly; straightforward to implement.Hurts shielded liquidity and UX; fragments the market.Stopgap control for risk desks during uncertainty. Stakeholder Scenarios: Making Decisions Without the Hype Long-only holders. If your thesis is privacy adoption, decide whether your conviction depends on unbroken, continuous verifiability or whether you can tolerate periods where the community’s assurance relies on engineering responses and future design changes. Position sizing should reflect that tolerance for ambiguity. Exchanges and OTC desks. After the emergency fix, re-enable shielded deposits only with upgraded infrastructure and document additional screening. Consider a tiered policy: small shielded deposits auto-clear; larger ones require extra checks or time-bound delays until chain behavior appears stable post-patch. Wallet and app developers. Communicate upgrade status clearly in-app. Offer viewing key tooling and migration paths so users can self-monitor. If a turnstile design is adopted later, build UI affordances early for a seamless transition. Institutional allocators. Request written security postures and timelines from core teams. If you need public supply checks to underwrite a position, evaluate whether a turnstile roadmap and formal verification plan meet your governance thresholds. Open-source contributors. This is a moment to expand testing harnesses, fuzzers, and circuit-level proof tooling. If you specialize in formal methods, there is leverage here: even partial proofs can raise confidence. Zcash Foundation release banner for Zebra 4.5.3 / 5.0.0 announcing the emergency soft-fork and NU6.2 activation — the official, coordinated upgrade that temporarily halted Orchard and then restored it to close the vulnerability (why supply verification became urgent). — Source: Zcash Foundation Pitfalls & Red Flags Running outdated clients. Pre-NU6.2 software may mishandle Orchard transactions or expose you to consensus mismatches. Assuming “no exploit” equals “no risk.” The market prices the possibility of silent inflation. Policies should reflect that, not just incident retrospectives. Overreliance on single trackers. Cross-check shielded pool data between multiple sources and your own node to avoid skew from API errors. Impersonation and phishing. Expect fake “urgent wallet updates.” Only download from official repositories and verify signatures. Liquidity traps. If venues throttle shielded deposits, spreads can widen. Test small amounts before committing size. Conflating privacy with opacity in governance. Supply verifiability is separate from user privacy; avoid narratives that pit them as mutually exclusive without nuance. Crypto Daily tracks security-driven market shifts and protocol-level pivots across the industry. For ongoing coverage of Zcash and privacy tech , visit Crypto Daily . Frequently Asked Questions What exactly was the Orchard bug? A researcher engaged by Shielded Labs identified a “soundness” flaw in the Orchard zero-knowledge circuit—meaning, in principle, it could allow proofs that assert something false. The issue was responsibly disclosed on May 29, 2026, leading to an emergency response by Zcash engineers ( Zcash Foundation ). How did the network respond so quickly? The community executed a two-step plan: first, a soft fork disabled Orchard at block 3,363,426 in early June 2, 2026 (UTC), then NU6.2 (Zebra 5.0.0) re-enabled Orchard at block 3,364,600 on June 3, 2026 (00:05 EDT) with the fix live ( Zcash Foundation ). Was ZEC’s supply actually inflated? There is no public confirmation that an exploit occurred. However, markets price the risk that it could have, and that’s why supply verification rose to the top of the agenda. Stakeholders are focusing on mitigations that restore confidence whether or not an exploit happened. Why did the price fall so sharply? Security and supply integrity are primary valuation anchors in privacy coins. Reports cited ~30–40% declines around June 5, 2026, following disclosure and emergency patches ( CoinTelegraph ). Uncertainty around verifiability tends to widen risk premia. What are the leading fixes to rebuild trust? Discussions include formal mathematical verification of Orchard, expanding cryptography/security staffing, and a new shielded pool with a turnstile to enable public supply checks without sacrificing privacy ( KuCoin ). As a user, what should I do now? Upgrade your wallet and node software to NU6.2-compatible releases, confirm your balances with viewing keys, and test small transactions first. If you rely on exchanges, check their current policies on shielded deposits and withdrawals. Do shielded users lose privacy with a turnstile? A well-designed turnstile aims to allow aggregate supply checks without revealing who sent what to whom. The details matter, but the intent is to keep user-level privacy while enabling public audit of total supply. Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.

6 Jun 2026, 08:45

Gravity Bridge Hacker Launders Stolen Crypto Through ChangeNOW and Binance, PeckShield Reports

BitcoinWorld Gravity Bridge Hacker Launders Stolen Crypto Through ChangeNOW and Binance, PeckShield Reports Blockchain security firm PeckShield has reported that the hacker responsible for the recent Gravity Bridge exploit has moved a portion of the stolen funds through cryptocurrency exchanges ChangeNOW and Binance. The attack, which targeted the cross-chain bridge, resulted in the theft of assets valued at approximately $5.4 million. Details of the Attack and Laundering According to PeckShield’s on-chain analysis, the attacker currently still holds 2,102 ETH, worth roughly $4.23 million at current market prices. The firm’s tracking indicates that the hacker used both ChangeNOW and Binance to launder part of the stolen funds, though the exact amount funneled through each platform has not been disclosed. This follows an earlier alert from on-chain analyst Specter, who first identified the breach and estimated the total stolen assets at around $5.4 million. The stolen assets included a diverse mix of tokens: approximately $4.3 million in USDC, 274 Wrapped Ether (WETH) valued at about $553,000, $434,000 in USDT, and $64,000 in PAYG tokens. The Gravity Bridge project, which facilitates asset transfers between different blockchain networks, has not yet issued an official statement regarding the incident or any potential recovery efforts. Why This Matters for Crypto Users This incident underscores persistent security vulnerabilities in cross-chain bridge protocols, which have become frequent targets for hackers due to the large pools of locked assets they manage. For users, it highlights the importance of monitoring project security audits and the risks associated with bridging assets between networks. The laundering of funds through major exchanges also raises questions about the effectiveness of know-your-customer (KYC) and anti-money laundering (AML) procedures in the crypto space. Broader Context of Bridge Exploits The Gravity Bridge hack is the latest in a series of high-profile bridge exploits that have collectively resulted in losses exceeding $2 billion over the past two years. Previous incidents include attacks on the Ronin Network, Wormhole, and Nomad bridges. These events have prompted increased scrutiny from regulators and have accelerated the development of more secure bridge architectures, including zero-knowledge proof-based solutions. PeckShield’s report adds to a growing body of on-chain forensic evidence that helps track stolen funds and identify laundering patterns. The firm’s ability to trace the movement of assets through exchanges provides valuable intelligence for law enforcement and security teams working to recover stolen funds. Conclusion The Gravity Bridge exploit serves as a stark reminder of the risks inherent in decentralized finance (DeFi) infrastructure. With the hacker still holding a significant portion of the stolen ETH, the situation remains unresolved. The lack of an official statement from the Gravity Bridge team leaves the community in a state of uncertainty regarding potential reimbursement or recovery plans. As on-chain investigators continue to monitor the wallet, the broader crypto industry watches closely for lessons that could prevent future attacks. FAQs Q1: What is the Gravity Bridge? The Gravity Bridge is a blockchain protocol that enables the transfer of assets between different blockchain networks, such as Ethereum and Cosmos-based chains. It relies on a network of validators to secure transactions. Q2: How did the hacker launder the stolen funds? According to PeckShield, the hacker used the cryptocurrency exchanges ChangeNOW and Binance to convert or move a portion of the stolen assets. The exact methods and amounts remain under investigation. Q3: What should users do if they are affected? Users who believe they may have been impacted by the Gravity Bridge exploit should monitor official project channels for updates. It is also advisable to revoke any approvals given to the bridge contract and avoid interacting with it until the team releases a statement. This post Gravity Bridge Hacker Launders Stolen Crypto Through ChangeNOW and Binance, PeckShield Reports first appeared on BitcoinWorld .

6 Jun 2026, 05:55

Dragonfly Capital: Market Panic Over Patched Zcash Bug Is Overblown

BitcoinWorld Dragonfly Capital: Market Panic Over Patched Zcash Bug Is Overblown Haseeb Qureshi, Managing Partner at Dragonfly Capital, has pushed back against what he describes as excessive market concern over a recently patched vulnerability in the Zcash (ZEC) protocol. In a detailed assessment, Qureshi argued that the practical risk to the broader market was minimal, even if the bug had been exploited before the fix was deployed. Understanding the Shielded Pool Exploit The vulnerability, which has since been patched by the Zcash development team, existed within the protocol’s shielded privacy pool — the feature that allows users to transact with complete anonymity. Qureshi explained that an attacker exploiting this bug could only counterfeit ZEC tokens within that shielded environment, where balances and transaction histories are not publicly visible. However, any attempt to convert those counterfeit tokens into real value would require moving them to a transparent Zcash address, a public ledger where all transactions are visible. This conversion process would immediately reveal an abnormal spike in the total supply of ZEC, alerting exchanges and the broader network to the exploit before it could be cashed out. Limited Impact on Majority of Holders Qureshi further noted that only users actively holding ZEC in shielded addresses would be directly at risk from such an exploit. The vast majority of ZEC holders, including those using centralized exchanges or storing funds in transparent addresses, would not be affected. He added that only about 1% of the ZEC held in the shielded pool has historically been converted to transparent addresses — a figure he interprets as evidence that the market’s actual stakeholders are not treating the vulnerability as a serious threat. Why This Matters for Zcash and Privacy Coins The Zcash network is one of the most prominent privacy-focused cryptocurrencies, and any security incident involving its core privacy feature carries outsized reputational risk. Qureshi’s comments aim to reassure the market that the patched vulnerability does not undermine the fundamental security of the network. The incident also highlights the ongoing tension between privacy and security in blockchain design — where features that protect user anonymity can also create unique attack surfaces. For investors and users, the key takeaway is that the Zcash development team identified and patched the vulnerability before any exploit occurred. The market reaction, which saw a brief dip in ZEC’s price, may have been driven more by fear of the unknown than by actual risk to the network’s integrity. Conclusion While any vulnerability in a blockchain network warrants serious attention, Dragonfly Capital’s analysis suggests that the specific Zcash bug was far less dangerous than initial market reactions implied. The combination of the shielded pool’s design, the transparency of the conversion process, and the rapid patch deployment effectively neutralized the threat before it could be weaponized. For the Zcash community, the incident serves as a reminder of the importance of rigorous code auditing and the resilience of the network’s economic model. FAQs Q1: Was the Zcash vulnerability actually exploited? No. The vulnerability was patched by the Zcash development team before any exploit was carried out. There is no evidence that any funds were lost or counterfeit tokens created. Q2: Who would have been affected if the bug was exploited? Only users holding ZEC in shielded addresses would have been directly at risk. The majority of holders using exchanges or transparent addresses would not have been impacted. Q3: How would an exploit have been detected? Any attempt to move counterfeit tokens out of the shielded pool would require converting them to a transparent address, which would publicly reveal an abnormal increase in the total supply of ZEC, alerting the network and exchanges immediately. This post Dragonfly Capital: Market Panic Over Patched Zcash Bug Is Overblown first appeared on BitcoinWorld .

6 Jun 2026, 04:16

IronWorm malware plants rootkit in Arweave ecosystem npm libraries

Attackers planted an infostealer inside 36 npm packages linked to the Arweave ecosystem. It targeted developer credentials, SSH keys, and Exodus crypto wallet files. Security firm JFrog traced the attack back to a compromised maintainer account. The malware is called IronWorm, and its built using Rust. It activates the moment a developer installs an npm package. Once running, it scans through the infected computer for 86 environment variables and 20 credential files, as JFrog’s research team found. It goes after AWS tokens, Anthropic and OpenAI API keys, npm authentication credentials, and crypto wallet data. Arweave project packages carry hidden Rust malware Attackers comproimised an npm account called “asteroiddao,” which belongs to the asteroid-dao GitHub group, part of the Arweave/WeaveDB decentralized database project. All packages associated with the “asteroiddao” account were republished within a short time, with each new version containing a 976 KB Linux file located in a tools/ directory. The file was set to run automatically through a preinstall hook in package.json , meaning it launched before npm even began installing anything. All a victim had to do was run npm install . JFrog’s team pulled the file apart and found it had been packed in a way designed to fool standard unpacking tools. Inside was a large Rust program that kept its strings encrypted individually, with each one locked separately, making analysis much harder. When those strings were finally decoded, they revealed GitHub API endpoints, paths to credential files, fake bot accounts linked to real GitHub user IDs, and templates for injecting malicious code into other package registries. A screenshot showing infected npm packages related to the Arweave ecosystem. Source: Jfrog . Stolen GitHub tokens let malware push commits and infect more repos After harvesting credentials, IronWorm used them to push commits into repositories the victim could access. Those commits planted the same malicious binary into other packages, which could then be published to npm and compromise the next developer in the chain. JFrog found 57 backdated malicious commits across nine GitHub organizations. The commits used the author name “claude” with the email [email protected] . Timestamps were forged to match each repository’s most recent legitimate commit. One appeared to date back 13 years, though GitHub Actions logs confirmed all pushes happened within a few days of discovery. The affected organizations included asteroid-dao, weavedb, ArweaveOasis, and several personal accounts associated with the developer “ocrybit.” IronWorm also deployed an eBPF kernel rootkit to hide on infected machines. Communications to its operator routed through the Tor network. The Rust compiler left the rootkit’s source code in the binary, an operational mistake that made analysis easier. One oddity is that the operator hardcoded their own cryptocurrency wallet recovery phrase into the malware. JFrog concluded this was a safeguard to prevent the stealer from exfiltrating the attacker’s own credentials during testing. Malware attacks keep hitting npm Application security firm Ox Security said that the attack was caught early, before it could spread to more packages on npm. The malicious versions were marked as deprecated within a day and most of the backdated commits were removed from GitHub shortly after. On May 14, hackers exploited an inactive maintainer account for node-ipc, a package with more than 822,000 weekly downloads. The exploit was accomplished by re-registering the maintainer’s expired email domain and resetting the npm password. Three compromised variants had credential stealing payloads aimed at over 90 categories of developer secrets. Security firms Endor Labs and StepSecurity identified a concurrent but distinct attack using JavaScript-based malware called binding.gyp, which performed similar registry poisoning and GitHub Actions infection during the same timeframe. Developers who installed any of the affected WeaveDB packages should rotate all credentials, check lock files for unexpected version changes, and enable two-factor authentication on npm and GitHub accounts. If you're reading this, you’re already ahead. Stay there with our newsletter .

5 Jun 2026, 18:25

Zcash Crash Just Wiped Billions From the Privacy Coin's Market Cap—Can ZEC Recover?

The price of Zcash cratered following the disclosure of a serious vulnerability for the privacy coin. Can ZEC make a comeback anytime soon?