Crypto security losses reached $136 million across 50 incidents in August, according to PeckShieldAlert data, keeping exploits, phishing, and incident response firmly in view as the market enters September.

The figure is another reminder that market recoveries do not erase infrastructure risk. Even when prices rise and liquidity improves, attackers continue to target smart contracts, wallets, bridges, exchanges, and individual users.

The number also needs careful handling. Security losses can include different types of incidents, and phishing is not the same as a protocol exploit. But the combined August total still points to a busy month for attackers.

Loading Tweet…

View original post on X

TL;DR

• August crypto security losses totaled about $136 million.
• PeckShieldAlert tracked 50 incidents during the month.
• Exploits and phishing should not be blurred together, but both remain serious risks.

A Busy Month For Attackers

Crypto security incidents tend to follow liquidity.

When more money moves on-chain, there is more incentive to attack. That can mean code exploits, private-key compromises, bridge attacks, phishing campaigns, front-end compromises, fake airdrops, social engineering, or malicious approvals.

August’s 50-incident count shows how broad the threat surface remains.

Crypto is not one system. It is a connected environment of protocols, chains, wallets, exchanges, bridges, signing tools, custody setups, and user interfaces. Weakness in any part of that stack can become expensive.

That is why headline loss figures matter.

They show that security is still one of the industry’s biggest unsolved problems.

Exploits And Phishing Are Different

The distinction matters for readers.

A protocol exploit usually involves a weakness in smart contract logic, oracle design, access control, bridge architecture, or another technical system. Phishing usually targets users directly, tricking them into signing malicious transactions, revealing credentials, or approving wallet access.

Both can lead to major losses, but the prevention methods differ.

Protocols need audits, monitoring, bug bounties, emergency controls, and better architecture. Users need safer wallets, clearer signing prompts, stronger education, and tools that detect malicious approvals before they happen.

Putting both categories together can show total damage, but coverage should not pretend they are the same thing.

Why August’s Total Matters

A $136 million monthly loss total is significant even by crypto standards.

It means attackers extracted enough value to affect users, protocols, insurers, auditors, and risk teams. It also means that security incidents remain a central cost of using decentralized systems.

This is especially important as institutional adoption grows.

Funds, companies, and payment firms entering crypto will not only look at liquidity and returns. They will also assess operational risk. Repeated security losses can slow adoption, raise compliance costs, and make custodians more cautious.

Recovery Numbers Need Care

Security reports often include gross losses, recovered funds, frozen assets, or net losses.

Those numbers can differ sharply. A hacked protocol may lose a large amount initially, recover a portion through negotiations, freeze some funds with exchange help, and still leave users with losses.

That is why August’s figure should be treated as a security-loss metric, not a full recovery analysis unless recoveries are broken out clearly.

The key point remains: attackers were active, and losses were material.

September Starts With Security In View

The market now enters September with another reminder that security risk does not pause during bullish periods.

If anything, stronger markets can attract more attackers because there is more value to steal and more users returning to activity. That means protocols, wallets, and users will need to stay alert even if price action improves.

Crypto’s growth story depends on trust.

August’s $136 million loss total shows that trust still has to be earned every month.

This article draws on PeckShieldAlert’s August crypto security loss data.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released by X. at X

Switchboard has halted oracle operations on several networks, including SUI and Aptos, after detecting a potential security compromise.

The precautionary halt also affects IOTA and Movement, according to the validated incident materials. The key detail is scope: Switchboard’s oracle services were halted on affected chains, not the chains themselves.

That distinction matters.

This should not be framed as SUI, Aptos, IOTA, or Movement halting block production. It is an oracle infrastructure incident, and the impact depends on which applications rely on Switchboard feeds or services.

Still, oracle halts can be serious because DeFi applications depend on accurate, timely data to function safely.

For more details, visit the official Status platform.

TL;DR

• Switchboard halted oracle operations on SUI, Aptos, IOTA, and Movement.
• The move followed a potential security compromise.
• The affected chains did not necessarily halt; the issue concerns oracle infrastructure.

Why Oracle Incidents Matter

Oracles are critical infrastructure.

They bring external data into blockchain applications. Lending markets need prices. Perpetuals platforms need market data. Structured products need reference rates. DeFi protocols depend on oracles to decide liquidations, collateral values, and trading conditions.

If an oracle is compromised, stale, or unreliable, applications can become dangerous quickly.

That is why shutting down operations can be the safer move. A temporary halt may be disruptive, but bad data can cause far worse damage.

Switchboard’s response appears to fit that risk-management logic.

A Precautionary Halt Is Not A Confirmed Exploit

The language matters.

A potential compromise is not automatically the same as a confirmed exploit. Until the provider publishes full incident details, the safer wording is that operations were halted as a precaution after a possible security issue.

That protects readers from assuming funds were lost, chains were hacked, or every dependent application failed.

The incident may still be serious, but it needs to be described accurately.

Security coverage should clarify what is known, what is not known, and which systems are affected.

SUI And Aptos Depend On Reliable Data Layers

SUI and Aptos are both high-performance chains with growing DeFi ecosystems.

For these networks, oracle reliability matters because applications need trusted data to support lending, swaps, collateral, derivatives, and structured products. If oracle services are paused, some protocols may need to pause markets, adjust risk parameters, or rely on fallback systems.

That can affect users even if the base chain keeps running normally.

The same applies to IOTA and Movement if applications there rely on Switchboard services.

Multi-Chain Oracle Risk Cuts Across Ecosystems

One important lesson is that infrastructure incidents can span multiple chains.

A protocol like Switchboard may serve several ecosystems at once. That creates efficiency, but it also means a security concern can affect many networks simultaneously.

This is a broader DeFi risk.

Projects often think in chain-specific terms, but shared infrastructure can become a cross-chain dependency. Oracles, bridges, RPC providers, indexers, wallets, and middleware can all create shared points of failure.

Switchboard’s halt is a reminder of that.

The Next Signals To Watch

Users and developers will be watching for a full incident explanation.

The important questions are straightforward: what was compromised, what services were affected, whether any data was manipulated, whether any protocols took losses, and when operations will resume.

Until then, applications using Switchboard feeds may need to remain cautious.

For the wider market, the incident shows why oracle security remains one of DeFi’s most important issues.

Blockchains can keep producing blocks, but applications still need reliable data. When the data layer stops, the application layer can feel it immediately.

This article is based on Switchboard status materials and public incident information.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released by Status. at Status

Ethereum’s EIP-7702 wallet delegation feature is facing renewed scrutiny after security research presented at the USENIX Security Symposium linked a large share of analyzed authorization transactions to attacker-controlled contracts.

The research found that 63% of EIP-7702 authorization transactions in the analyzed sample were connected to malicious contracts, with automated wallet-draining activity contributing to more than $2.3 million in confirmed thefts.

That sounds alarming, but the framing matters.

This is not the same as saying EIP-7702 has an inherent protocol bug. The concern is that wallet delegation can expand the attack surface when users are tricked into signing malicious authorizations.

In other words, the danger sits at the intersection of protocol flexibility, wallet UX, user behavior, and phishing infrastructure.

TL;DR

• Security research linked 63% of analyzed EIP-7702 authorization transactions to attacker-controlled contracts.
• The research identified more than $2.3 million in confirmed thefts.
• The issue is malicious delegation and wallet attack surface, not necessarily a core Ethereum protocol bug.

What EIP-7702 Changes

EIP-7702 is part of Ethereum’s broader account-abstraction direction.

It allows externally owned accounts to temporarily behave more like smart contract accounts by delegating code execution. That opens the door to better wallet experiences, batched transactions, sponsored gas, automation, and more flexible account controls.

Those features can be useful.

But flexibility also creates new user risks. If a malicious site convinces a user to sign the wrong delegation authorization, the attacker may gain far more power than a typical phishing signature would allow.

That is why wallet design matters so much.

A powerful feature can become dangerous if users cannot clearly understand what they are authorizing.

Phishing Moves With The Tech

Attackers adapt quickly.

When crypto wallets become more capable, phishing campaigns evolve to exploit those capabilities. In earlier cycles, attackers focused heavily on seed phrases, malicious approvals, fake airdrops, and wallet-draining signatures.

Delegation adds another tool.

A user may think they are signing a routine transaction or interacting with a normal application, when they are actually authorizing code that gives an attacker dangerous control. Once that happens, automated systems can drain assets quickly.

The research’s $2.3 million loss figure shows that this is not just theoretical.

Wallet UX Is Now A Security Layer

Ethereum security is often discussed at the protocol level.

But for most users, wallet interfaces are the real security boundary. A protocol can be technically sound while users still lose funds because prompts are confusing, permissions are unclear, or malicious transactions are hard to interpret.

EIP-7702 makes that more important.

Wallets may need clearer warnings, better simulation tools, stronger delegation displays, contract reputation checks, and safer default flows. Users need to know when a signature gives a contract meaningful control over their account.

If they cannot understand the permission, they cannot judge the risk.

Do Not Blame The Feature Alone

It would be too simple to say EIP-7702 is “bad.”

Account abstraction is a major part of making Ethereum easier to use. Better wallets could reduce friction, improve onboarding, and help ordinary users avoid some of the problems that make crypto feel difficult today.

The problem is implementation and user protection.

New capabilities need matching safety tools. Otherwise, attackers get the benefit before normal users do.

That has happened before in crypto.

Every time the user experience becomes more complex, malicious actors look for confusion. EIP-7702 is no different.

What Comes Next

The next step is not panic. It is hardening.

Wallet teams, security researchers, dapp developers, and Ethereum infrastructure providers will need to improve how delegation permissions are displayed, simulated, and restricted. The goal should be to preserve the benefits of account abstraction without making phishing easier.

For users, the message is simpler: delegation signatures deserve extra caution.

If a wallet prompt is unclear, if a site is unfamiliar, or if a signature appears to grant broad account permissions, the safest move is to stop.

Ethereum’s account-abstraction roadmap remains important. But this research shows that better wallet power must come with better wallet safety.

This article is based on security research presented at the USENIX Security Symposium and public reporting on EIP-7702 authorization activity.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released in disclosures at primary source documentation.

BTCPay Server has released version 2.4.2 to patch a critical vulnerability that allowed unauthenticated remote access to LND credential files, after attackers used the issue to drain merchant Lightning wallets.

The project’s release notes describe a serious bug involving .macaroon files, which are used by LND to manage access permissions. In plain English, those files can act like keys. If an attacker gets hold of the wrong one, they may be able to interact with a Lightning node in ways the operator never intended.

BTCPay supporters have also backed a recovery bounty equal to 10% of returned funds, capped at 3 BTC. At current prices, that puts the maximum reward around $190,000.

This is not a Bitcoin protocol exploit. It is not a native on-chain wallet failure. It is a server-side security issue affecting certain BTCPay Server setups using LND.

That distinction matters.

For more details, visit the official Github platform.

TL;DR

• BTCPay Server v2.4.2 patches a critical LND credential exposure issue.
• Attackers reportedly drained merchant Lightning wallets through vulnerable setups.
• A recovery bounty offers 10% of returned funds, capped at 3 BTC.

Why The LND Credential Issue Matters

BTCPay Server is popular because it lets merchants accept Bitcoin payments without relying on a centralized payment processor.

That self-sovereign model is powerful, but it also means server security matters. When a merchant runs their own payment infrastructure, they are also responsible for keeping that infrastructure updated and properly configured.

The vulnerability patched in v2.4.2 is serious because LND macaroons can grant access to node functions. Depending on the permissions attached, an exposed macaroon can be extremely sensitive.

For Lightning operators, credential security is as important as private-key security in practical terms. A wallet can be technically sound, but if a server leaks access credentials, funds can still be at risk.

This Was Not An Attack On Bitcoin Itself

It is easy for infrastructure exploits to get misread.

When people hear that Bitcoin payment servers were drained, they may assume something broke in Bitcoin. That is not what this story shows.

Bitcoin’s base protocol was not exploited. The issue involved BTCPay Server deployments using LND and the exposure of credential files. That makes it an application and infrastructure security event, not a failure of Bitcoin consensus or the Bitcoin blockchain.

That does not make it minor.

For affected merchants, the difference may not feel comforting. Lost Lightning funds are still lost funds. But accurate framing matters because the remedy is different. Bitcoin does not need a protocol patch for this. BTCPay Server operators need to update, check configuration, and secure node credentials.

Lightning Infrastructure Has Different Risks

Lightning is designed for faster, cheaper Bitcoin payments, but it introduces operational complexity.

Node operators deal with channels, liquidity, backups, remote access, routing, credentials, and server exposure. That creates a different security model from holding BTC in cold storage.

A merchant running Lightning infrastructure is not simply holding Bitcoin. They are running live payment software connected to the internet.

That can be safe when managed properly, but it requires discipline. Updates matter. Permissions matter. Credential storage matters. Monitoring matters.

The BTCPay incident is a reminder that self-hosted payment systems are not “set and forget” products.

The Bounty Is A Recovery Attempt

The recovery bounty adds another layer to the story.

Offering 10% of returned funds, capped at 3 BTC, is an attempt to create an incentive for recovery or information. That may help if attackers, intermediaries, or people with knowledge of the funds decide cooperation is better than continued exposure.

Bounties do not guarantee recovery.

They can, however, create a channel for negotiation or disclosure. Crypto projects often use them after exploits because stolen funds can be traceable, exchange deposits can be monitored, and attackers may face difficulty cashing out cleanly.

For affected merchants, the bounty is not a complete solution. The more immediate step is making sure vulnerable systems are patched.

What Operators Should Take From This

The practical lesson is simple: update BTCPay Server and review LND exposure.

Operators should not assume that because a system has worked for years, it is safe indefinitely. Payment infrastructure lives in a changing threat environment. Attackers look for old versions, misconfigurations, leaked credentials, weak permissions, and internet-exposed services.

BTCPay Server remains an important tool for Bitcoin merchants, but self-custody and self-hosting come with responsibilities.

Version 2.4.2 is the fix point for this issue. Anyone running affected setups should treat the update as urgent.

Bitcoin payments can be sovereign, but sovereignty includes maintenance.

This article is based on BTCPay Server’s v2.4.2 release materials and the project’s recovery-bounty details.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released by Github. at Github

A Coldcard security issue has put Bitcoin hardware-wallet safety back under the microscope after reports that a firmware flaw affected seed generation on some older device versions.

According to the validated incident notes, the issue relates to Coldcard Mk3 firmware versions 4.0.1 through 5.0.3, along with Mk4 and Mk5 devices before firmware 5.6.0, and Q devices before 1.5.0Q. The core problem was a seed-generation weakness in which a hardware random number generator was replaced by a predictable software substitute, reducing entropy from the intended 128 bits to 72 bits.

That is a technical detail, but it matters enormously. A Bitcoin wallet is only as safe as the seed phrase behind it. If seed generation becomes predictable enough for an attacker to narrow the search space, the wallet can become vulnerable even if the user never shared their phrase, clicked a phishing link, or exposed a private key.

The reported sweep involved roughly 594 BTC from around 500 single-signature wallets on July 30 and 31, 2026.

For more details, visit the official Blog platform.

TL;DR

• A Coldcard seed-generation vulnerability affected certain older firmware/device versions.
• Reports point to about 594 BTC swept from roughly 500 single-signature wallets.
• Seeds generated with a BIP-39 passphrase or sufficient dice rolls are not considered at risk under the validated notes.

Why Entropy Is The Whole Game

Bitcoin security can sometimes sound complicated, but at the seed level, the principle is simple: randomness protects the wallet.

A seed phrase is not supposed to be guessable. The number of possible valid seeds is so enormous that brute forcing one should be effectively impossible. That assumption depends on proper entropy. If the random process used to create the seed is weakened, the attacker’s job changes from impossible to potentially feasible.

That is why this story is more serious than a normal firmware bug.

A display issue can confuse users. A signing bug can create transaction risk. But a seed-generation flaw goes right to the foundation of the wallet.

If the wallet seed was created under weak randomness, the user may be exposed even if they have behaved perfectly since then.

Not Every Coldcard User Is In The Same Position

The important caveat is that this does not mean every Coldcard device is currently unsafe.

The validation notes indicate that the affected set is tied to particular firmware and device versions. Fixed firmware releases are also referenced, including 5.6.0 for Mk4 and Mk5 devices and 1.5.0Q for Q devices.

There is another important distinction: seeds generated with a BIP-39 passphrase or at least 50 dice rolls are not considered at risk under the incident notes.

That matters because users may have created wallets in different ways. A seed generated entirely by the device under affected firmware may carry a different risk profile from one strengthened by dice-based entropy or a passphrase.

For users, the practical question is not “Do I own a Coldcard?” It is “Which device and firmware generated my seed, and how was that seed created?”

That is a much narrower and more useful question.

Why Single-Signature Wallets Are More Exposed

The sweep reportedly focused on roughly 500 single-signature wallets.

That makes sense from an attacker’s point of view. In a single-signature setup, one seed controls the funds. If that seed can be derived or guessed, there is no second approval layer.

Multisig setups create a different risk model. If one signer’s seed is compromised, the attacker may still need additional keys to move funds. That does not make multisig immune to all wallet failures, but it can reduce the damage from one weak seed.

This is one of the reasons serious Bitcoin custody setups often use multisig, passphrases, dice-generated entropy, geographically separated backups, and hardware from different vendors.

It is not because every user needs enterprise-grade custody. It is because Bitcoin custody has no customer-support reset button. Once funds move, the chain does not reverse them.

Hardware Wallets Still Need Trust, Updates And Verification

Hardware wallets are often marketed as the safest way to hold crypto, and for many users they are. But “hardware wallet” is not magic.

The user is trusting device firmware, supply chains, seed generation, backup discipline, signing screens, update practices, and their own operational security. A hardware wallet reduces many online risks, but it does not eliminate all possible failure points.

Firmware updates also create a difficult trade-off.

Users are often told not to rush updates unless they understand what is changing. At the same time, security fixes may be essential. If a user never updates, they may remain exposed to known vulnerabilities. If they update carelessly, they may introduce new risks through fake firmware or phishing.

The safest path is boring but important: use official sources, verify firmware, read security advisories carefully, and avoid panic moves.

The Takeaway For Bitcoin Holders

This incident is a reminder that self-custody is powerful because it removes reliance on exchanges and custodians. But it also puts the burden of security on the user and the tools they choose.

For Coldcard users, the immediate task is to determine whether their seed was generated on affected firmware and whether additional entropy or passphrase protection was used. Users with meaningful exposure should follow official guidance and avoid entering seed phrases into any website or unknown tool claiming to check vulnerability status.

For the broader Bitcoin market, the lesson is bigger.

The strongest form of custody is not just owning a hardware device. It is understanding how the seed was generated, how backups are stored, how signing is protected, and what happens if one part of the setup fails.

Bitcoin gives users final control. That control is valuable, but it is unforgiving.

This article is based on Coldcard security materials and related public reporting on the July 2026 wallet sweep.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released by Blog. at Blog

Ostium Halts Trading After $18M Oracle Key Breach Arbitrum-based perpetuals exchange Ostium has suspended trading after an $18.4 million exploit tied to a compromised off-chain oracle key, highlighting again how vulnerable trading venues can be when price infrastructure fails.

The attack did not appear to stem from a direct breach of Ostium’s smart contract code. Instead, the validated source material points to manipulation of price feed reports through a compromised oracle private key. That distinction matters because it shows the risk was not only in on-chain contracts, but in the off-chain infrastructure feeding data into the system.

Perpetuals exchanges depend on accurate prices. If the price feed can be manipulated, the entire trading venue becomes exposed.

Ostium’s response was to halt trading while investigating the incident.

TL;DR

• Ostium suspended trading after an $18.4 million exploit.
• The attack involved a compromised off-chain oracle private key.
• The incident highlights oracle key-management risk rather than a direct smart contract breach.

https://x.com/OstiumLabs/status/1814981204853092352

Why Oracle Failures Are So Dangerous

Perpetuals markets need reliable prices.

A trader’s collateral, liquidation level, profit and loss, funding exposure, and settlement value all depend on price data. If that data is wrong, the market can be exploited even if the core trading contracts behave exactly as designed.

That is why oracle infrastructure is one of DeFi’s most sensitive layers.

It sits between real-world or market data and on-chain execution. A protocol may have audited contracts, but if the data feeding those contracts can be manipulated, the system is still vulnerable.

In Ostium’s case, the issue appears to involve a compromised off-chain oracle key. That means the attacker was able to interfere with the trusted reporting path rather than simply finding a normal contract bug.

That kind of failure can be harder for users to understand because the problem is not always visible in the same way as a contract exploit.

The blockchain may record the transactions, but the weak point may be the infrastructure behind the data.

The Smart Contract Was Not The Only Risk

The distinction between smart contract risk and oracle risk matters.

Crypto users often ask whether a protocol’s contracts are audited. That is important, but not sufficient. A trading protocol also depends on pricing systems, administrative keys, keeper networks, bridges, liquidation bots, front ends, and operational security.

Any one of those layers can become a weak point.

If an oracle private key is compromised, attackers may not need to break the smart contract. They can feed the contract bad information and profit from how the system reacts.

That is why DeFi security has to be broader than code review.

Protocols need key management, monitoring, alert systems, circuit breakers, fallback feeds, and clear emergency procedures. The faster a venue can detect abnormal prices and pause dangerous operations, the more damage it may prevent.

Ostium’s trading halt shows that emergency controls are still essential.

Arbitrum DeFi Faces Another Security Test

Arbitrum remains one of the most active Ethereum layer-2 ecosystems for DeFi.

That activity brings liquidity, traders, and innovation, but it also attracts attackers. Perpetuals venues are especially attractive because they concentrate collateral and rely on real-time pricing.

An $18.4 million exploit is large enough to matter for the ecosystem, even if it does not threaten Arbitrum itself.

The incident should not be framed as an Arbitrum network failure. The issue is specific to Ostium’s oracle infrastructure. But for users, every exploit adds to the broader question of how safe layer-2 DeFi venues are in practice.

That question matters as more capital moves to faster and cheaper networks.

Layer-2 scaling lowers transaction costs, but it does not remove application-level risk. Users still need to evaluate each protocol’s design, security model, and operational controls.

What Comes Next For Ostium

The immediate priority is investigation, containment, and user communication.

Ostium needs to explain what happened, which systems were affected, whether user balances are recoverable, how trading will restart, and what controls will change before reopening.

For traders, the most important question is whether the oracle system has been rebuilt or secured enough to prevent a repeat.

A trading venue can survive an exploit if the response is transparent and the fix is credible. It becomes much harder if users are left unclear about where the failure occurred or whether the same path remains exposed.

The broader market should also pay attention.

Oracle key risk is not unique to one exchange. Any protocol relying on off-chain signing, price feeds, or privileged reporting paths needs to think carefully about compromise scenarios.

The lesson is straightforward: DeFi systems are only as strong as the weakest trusted component.

Ostium’s contracts may not have been directly breached, but the market still suffered a major exploit. That is why oracle security remains one of the most important issues in on-chain trading.

This article is based on Ostium’s public statement and Arbiscan transaction data.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released in official primary source disclosures at primary source documentation.

Reference: GitHub

Bitcoin BIP-361 Draft Puts Quantum Security Back On The Agenda

Bitcoin developers have introduced BIP-361, a draft proposal designed to prepare the network for a future migration away from legacy signature schemes that could become vulnerable in a post-quantum environment.

The proposal, titled “Post Quantum Migration and Legacy Signature Sunset,” was authored by Jameson Lopp and others. It lays out a phased approach for moving Bitcoin users away from older cryptographic signature types and toward quantum-resistant alternatives.

This is not a panic signal. Quantum computers are not suddenly breaking Bitcoin tomorrow. But BIP-361 matters because Bitcoin moves slowly by design, and cryptographic migrations can take years to plan, debate, test, and adopt.

If the network ever needs to retire vulnerable signature schemes, the planning has to start long before the emergency arrives.

TL;DR

• BIP-361 proposes a phased migration away from legacy Bitcoin signatures.
• The goal is to prepare for possible quantum-computing threats.
• The proposal is a draft and has not been scheduled for activation.

Why Quantum Risk Matters For Bitcoin

Bitcoin relies on cryptographic signatures to prove ownership of coins.

Today, that system is secure against known practical attacks. But a sufficiently powerful quantum computer could threaten some widely used public-key cryptography. That is why researchers and developers across the technology sector have been preparing for post-quantum security.

For Bitcoin, the challenge is especially complicated.

A bank can update internal systems. A software company can push patches. Bitcoin is a decentralized network with users, wallets, miners, developers, exchanges, custodians, and old addresses spread across the world.

Changing cryptographic assumptions is not simple.

Coins sit in different address types. Some coins have not moved in years. Some users may no longer have access to their keys. Some wallets may be slow to upgrade. Exchanges and custodians need time to support new formats. Any migration plan has to balance security, usability, and social consensus.

That is why BIP-361 is important even though it is only a draft.

It starts mapping the problem.

What The Proposal Tries To Solve

BIP-361 focuses on a phased sunset for legacy signatures.

The idea is not to suddenly invalidate large parts of Bitcoin. Instead, the proposal looks at how the network might gradually move away from signature schemes that could become risky in a quantum future.

A phased approach matters because Bitcoin cannot afford chaos around address formats and wallet compatibility. Users need time to migrate. Infrastructure providers need time to support new tools. The ecosystem needs clear milestones.

That kind of transition would be one of the most sensitive upgrades Bitcoin has ever considered.

It would involve not just technical safety, but also fairness. What happens to coins in old address types? How long should users have to move? What about dormant wallets? What about coins believed to be lost? At what point does protecting the network outweigh preserving indefinite spendability from legacy formats?

Those are difficult questions.

BIP-361 does not make them easy, but it gives the community a structured starting point.

Bitcoin Is Slow For A Reason

Some people will see the proposal and ask why Bitcoin needs to discuss quantum security now.

The answer is that Bitcoin’s upgrade process is slow because it has to be.

A controversial protocol change can take years to reach consensus, and many never do. That can frustrate developers who want faster progress, but it is also part of why Bitcoin has remained stable. The network avoids rushed changes that could damage trust.

Quantum migration would require even more caution.

It touches the deepest layer of Bitcoin ownership: signatures. A mistake could be catastrophic. A rushed proposal could divide the community. A poorly communicated migration could leave users confused or exposed.

That is why early discussion is healthy.

The proposal does not mean activation is near. It does not mean quantum computers are already a practical threat to Bitcoin. It means some developers believe the community should begin preparing before the pressure becomes urgent.

That is a reasonable position for a system designed to last for decades.

The Market Should Not Overreact

For traders, BIP-361 should not be read as a short-term price event.

Bitcoin is not suddenly insecure because a quantum-migration proposal exists. In fact, the opposite reading may be more useful: serious networks plan for long-term threats before they become immediate crises.

The draft shows that Bitcoin’s developer community is thinking about future-proofing the protocol.

The market should also remember that draft proposals can change, stall, or fail to gain consensus. BIP status does not equal activation. A proposal must be reviewed, debated, implemented, tested, and accepted by a broad set of stakeholders before it becomes part of Bitcoin’s rules.

Still, the topic is worth watching.

Bitcoin’s long-term credibility depends on its ability to handle risks without compromising its core values. Quantum migration may eventually test that ability. The network will need to balance security upgrades with decentralization, user sovereignty, and conservative governance.

BIP-361 puts that conversation back on the table.

Not because Bitcoin is broken, but because Bitcoin is important enough that its hardest problems need to be discussed early.

This article is based on the BIP-361 draft in the Bitcoin BIPs repository.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released by GitHub. at GitHub

A hacker tied to the Trusted Volumes exploit has returned 1,122 ETH to the protocol, closing part of a security incident that began with a multi-million-dollar exploit earlier this year.

The on-chain recovery is unusual because the attacker did not return everything. Instead, the wallet linked to the exploit sent back roughly $2 million worth of ETH while retaining another large amount as what now looks like a de facto bounty. That kind of outcome is familiar in DeFi, where projects sometimes negotiate with attackers after an exploit rather than risk losing the full amount forever.

The returned funds matter because they reduce the damage for the protocol and its users. But the structure of the settlement also shows how messy DeFi security remains. When smart contracts fail, the market often ends up relying on public pressure, wallet tracking, and informal negotiation rather than a clean legal process.

Reference: Etherscan

TL;DR

• The Trusted Volumes attacker returned 1,122 ETH to the protocol inventory.
• The exploit originally drained about $5.9 million through a smart contract vulnerability.
• The attacker appears to have retained roughly $2 million as a bounty-style settlement.

What Happened With Trusted Volumes?

The exploit traces back to a vulnerability in Trusted Volumes’ RFQ swap proxy. According to the on-chain evidence, the May 7 attack drained approximately $5.9 million in assets through a signature-check bypass.

That is the kind of vulnerability that can be especially damaging in DeFi because it sits close to the execution layer of a protocol. If a swap proxy accepts an invalid or improperly checked instruction, an attacker may be able to move funds in a way the system was never meant to allow.

The important update now is the return of 1,122 ETH from the attacker wallet to protocol inventory. The primary source for the story is the wallet and transaction evidence on Etherscan, which shows the recovery leg of the movement.

This does not necessarily mean the protocol has been made whole. It means a meaningful part of the exploited funds has come back.

That distinction matters. A partial recovery can be better than nothing, but it still leaves users and the wider market asking why the vulnerability existed, how quickly it was detected, and whether the protocol has made changes to prevent a repeat.

Why DeFi Exploit Settlements Keep Happening

Crypto has developed a strange pattern around major exploits.

In traditional finance, a theft usually leads to police reports, frozen accounts, and court processes. In DeFi, the first response is often public wallet tracking. The attacker’s address gets labelled. On-chain analysts follow the movement of funds. Protocol teams may publish messages offering a bounty if the money is returned.

Sometimes attackers accept. Sometimes they disappear into mixers, bridges, or exchange routes. Sometimes they return a portion and keep the rest.

That appears to be the shape of this case.

The reason this happens is simple: blockchains make funds visible, but not always recoverable. If an attacker controls the private keys, the protocol cannot simply reverse the transaction. The best practical outcome may be to offer a settlement before the funds are moved further away.

That is uncomfortable, but it is also realistic.

For users, the lesson is that code risk is not abstract. Even protocols with real activity can suffer from a small implementation flaw that becomes a major loss. For developers, the lesson is even sharper: signature validation, access controls, proxy logic, and upgrade paths need aggressive review because attackers only need one weak point.

The Recovery Helps, But It Does Not Erase The Exploit

The return of 1,122 ETH is clearly positive for Trusted Volumes, but it should not be treated as a full reset.

An exploit still happened. Funds were still removed. The attacker still appears to have kept a significant sum. The protocol still needs to show that the underlying issue has been addressed and that users can trust the system going forward.

That matters because DeFi confidence is fragile after security incidents. Users may forgive a protocol that responds quickly, communicates clearly, and recovers funds. They are less forgiving when teams stay vague, downplay the incident, or fail to explain what changed.

The strongest next step for Trusted Volumes would be a clear post-mortem: what failed, how the attacker used it, how the contract logic has been fixed, and whether any user balances remain affected.

Until then, the market can recognise the recovery without pretending the episode is over.

This is also a useful reminder for the wider sector. DeFi security is not only about preventing hacks. It is about incident response, transparency, on-chain monitoring, and whether projects can recover enough trust after something goes wrong.

Trusted Volumes got some funds back. The harder job is proving the system is safer than it was before the exploit.

This article is based on Etherscan wallet and transaction data.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released by Etherscan. at Etherscan

Ethereum Research Thread Puts Sybil Resistance Back In Focus For Decentralized Networks is a useful reminder that crypto coverage is not only about token prices. Sometimes the more important story is the infrastructure, regulation, security, or product layer sitting underneath the market noise.

The immediate point is straightforward: an Ethereum Research post examines Sybil risks in the AUCIL framework. That gives readers something concrete to work with, rather than another vague sentiment update.

TL;DR

• An Ethereum Research post examines Sybil risks in the AUCIL framework.
• The discussion focuses on how duplicate identities can distort decentralized systems.
• It adds to the broader security debate around validator and node-level trust.

Why This Matters Now

The timing matters because Ethereum is already part of a wider conversation across the market. Traders want to know whether the development changes liquidity or risk. Builders want to know whether it changes what can be deployed. Compliance teams want to know whether it changes how platforms operate.

In that sense, the story is bigger than one headline. It sits inside the ongoing shift from speculative crypto cycles toward more practical questions: who can use these systems, how safe are they, and whether the underlying incentives actually work.

The best way to read it is with discipline. It is not a guarantee of immediate upside, and it should not be treated as one. But it does add a fresh data point to the way the market is thinking about Ethereum.

The Ethereum Angle

For Ethereum, the important part is the specific mechanism. If this is a security issue, the risk sits in dependencies and user protection. If it is a listing or product launch, the question is access and liquidity. If it is a governance or research proposal, the question is whether the idea can survive implementation.

That is where this update becomes useful. It is not just a label attached to a trend. It gives readers a way to understand what might actually change if the development gains traction.

Crypto has a habit of turning every announcement into a broad market claim. This one deserves a narrower read. The value is in seeing how it affects the users, developers, institutions, or traders closest to the issue.

The Risk Side

There is also a caution attached. Source material can confirm that a development exists, but it cannot prove that adoption will follow. A proposal still needs support. A product still needs users. A chart still needs confirmation. A compliance tool still needs integration.

That is why the responsible reading is not to oversell the story. The stronger takeaway is that this adds to a pattern. The crypto market is steadily becoming more professional, more technical, and more sensitive to real operational details.

Readers should also watch for follow-up signals. That could mean developer feedback, exchange support, regulatory response, wallet adoption, liquidity data, or simply whether market participants continue reacting after the first headline fades.

What Comes Next

The next stage will decide whether this remains a narrow update or becomes part of a larger market theme. In crypto, that difference matters. Plenty of stories look important for a few hours and then disappear. The ones that last usually show up again through usage, liquidity, enforcement, governance, or developer adoption.

For now, this gives the market another piece of information to weigh. It is specific enough to be useful, but still early enough that readers should keep the caveats in view.

That makes it worth covering without pretending it settles anything. The story is a signal, not a final verdict.

The key is not to confuse coverage with certainty. Ethereum stories can move quickly, especially when they touch security, regulation, listings, infrastructure, or price levels. The useful approach is to track the next confirming detail rather than assume the first update carries the whole market story. That is how traders avoid chasing noise and how readers separate a genuine development from another passing headline.

This report is based on information from ethresear.ch.

This article was written by the News Desk and edited by Samuel Rae.