Executive Summary

August 2026 was another highly consequential month for cryptocurrency and blockchain security. The month was characterised not by a single dominant vulnerability class, but by the interaction of several increasingly important attack surfaces: smart contract logic, oracle and market-price manipulation, governance concentration, bridge infrastructure, privileged access, wallet security, phishing, and weaknesses in operational controls.

The source analysis identifies 27 major incidents during August, with approximately $162 million in losses. However, the distribution of those losses was highly concentrated. A single incident involving Tectonic on Cronos accounted for approximately $74 million, representing close to half of the month’s reported losses.

The Tectonic incident is particularly significant because it demonstrates that catastrophic losses do not necessarily require a conventional smart contract coding error. The attacker manipulated the market price of the thinly traded TONIC governance token, used the artificially inflated value as collateral, and borrowed substantially more valuable assets from Tectonic’s lending pools. External reporting similarly describes the incident as an approximately $75 million price-manipulation attack in which TONIC was artificially inflated and used as collateral.

The incident also demonstrated the importance of incident response at the blockchain layer itself. Cronos halted block production after identifying the exploit, preventing the majority of the affected funds from leaving the network. Approximately $6 million reportedly reached Ethereum before the halt, while most of the remaining funds remained on Cronos.

Tectonic was not the only important event. The month also included:

• A $25.6 million phishing loss affecting a private wallet.
• A $17 million Maya Protocol incident involving multiple software failures operating together.
• An $8.75 million Moonwell price-manipulation attack.
• An $8.5 million governance attack against Term Finance.
• A $7.9 million Coinsbuy wallet compromise.
• A $7.5 million TAC incident involving a shared Cosmos EVM precompile layer.
• A $3.2 million provisional Harmony incident.
• A $2.5 million Aquifer incident involving an alleged wallet credential compromise.
• Multiple bridge and cross-chain incidents affecting Coreum, Oraichain, Allbridge and other infrastructure.

The broader lesson from August is therefore not simply that “smart contracts remain vulnerable.” The more important conclusion is that security boundaries are expanding. Attackers increasingly exploit the relationship between contracts, tokens, governance, pricing infrastructure, bridges, wallets, privileged accounts, cross-chain messaging and off-chain operational processes.

The month also produced an important regulatory theme. Stablecoin payment infrastructure continued moving into mainstream financial corridors, while regulators simultaneously increased pressure around AML controls, sanctions exposure, beneficial ownership, market conduct, disclosure requirements and systems-and-controls failures.

The central security conclusion is therefore:

A protocol can be technically audited and still remain economically, operationally, governance-wise or institutionally exploitable.

Security programmes in 2026 must therefore move beyond periodic code audits toward continuous monitoring, economic-risk analysis, privileged-access controls, governance surveillance, oracle validation, wallet-security controls, cross-chain monitoring and intelligence-driven incident response.

1. August 2026 Threat Landscape

1.1 Overall Loss Environment

August produced approximately $162 million of losses across 27 major incidents in the source dataset. The incidents covered a broad range of blockchain infrastructure and applications, including:

• DeFi lending protocols
• Automated market makers
• Cross-chain bridges
• Layer 1 blockchains
• Layer 2 and EVM infrastructure
• Crypto payment platforms
• Self-custodial wallets
• Governance systems
• Smart contract platforms
• Private cryptocurrency wallets

This diversity is important because it shows that the threat environment is no longer concentrated exclusively around DeFi smart contracts.

Attackers increasingly target the complete digital-asset ecosystem.

That includes the code, the economic assumptions behind the code, the people controlling administrative keys, the data feeds used by financial contracts, the bridges connecting chains, and the users interacting with protocols.

The month’s headline figure was heavily influenced by Tectonic. Removing Tectonic from the dataset leaves approximately $88 million across the remaining incidents, showing that the underlying security problem remained significant even without the month’s largest event.

2.1 MOKE Token. 2 August 2026

Classification

Access Control

Reported Impact

Approximately $907,000

The MOKE Token incident began with an apparently simple access-control failure: an externally callable claim() function in the token release contract lacked an appropriate eligibility check.

As a result, an attacker was able to repeatedly invoke functionality intended for authorised or eligible participants and extract tokens from an internal reserve.

The attacker did not stop at simply taking the tokens.

The stolen MOKE tokens were incorporated into a larger transaction strategy involving:

1. Flash-loan liquidity.
2. Venus-based leverage.
3. Liquidity-pool manipulation.
4. LP removal.
5. Dividend-distribution mechanics.
6. Conversion of the extracted value into wrapped BNB.

This is a useful example of how an apparently narrow access-control defect can become significantly more damaging when combined with other DeFi primitives.

The lesson is that access control cannot be assessed only by asking whether a function contains an onlyOwner modifier.

Security review must establish:

• Who should be able to call the function?
• Under what conditions?
• How frequently?
• What assets can the function affect?
• Can the caller manipulate the surrounding protocol state?
• Can flash loans amplify the impact?
• Can the extracted assets be immediately converted into liquid collateral?

The incident demonstrates the importance of end-to-end privilege and economic-flow analysis rather than isolated function-level inspection.

2.2 LOOPSDAO 2 August 2026

Classification

Oracle / Price Manipulation

Reported Impact

Approximately $573,000

LOOPSDAO suffered an economic attack involving the reuse of manipulable PancakeSwap reserves for multiple financial calculations.

The central weakness was that the protocol relied upon a spot-market state that the attacker could influence.

The same manipulated reserves were effectively used to determine both:

• The value of an order; and
• The amount of interest that could subsequently be redeemed.

The attacker could therefore influence the economic state used to calculate their entitlement.

This illustrates a critical oracle-security principle:

A price source should not automatically be considered safe merely because it comes from a decentralised exchange.

If the protocol consumes an instantaneous AMM spot price, an attacker may be able to manipulate liquidity temporarily and execute a financially advantageous operation within the same transaction or transaction sequence.

Recommended protections include:

• TWAP-based pricing.
• Independent oracle aggregation.
• Price-deviation limits.
• Liquidity-depth checks.
• Maximum position limits.
• Minimum observation windows.
• Circuit breakers.
• Sanity checks against external markets.

The LOOPSDAO incident therefore represents the broader problem of using manipulable market state as trusted financial input.

2.3 RiseX. 3 August 2026

Classification

Smart Contract / Configuration Vulnerability

Reported Impact

Approximately $673,000

RiseX experienced an unauthorised withdrawal associated with its real-world-asset strategy and XLP vault.

The underlying problem was traced to a configuration issue that had existed since the strategy’s deployment on 13 July.

This incident is particularly relevant to security programmes because it demonstrates that vulnerabilities do not necessarily originate from maliciously written code.

A system can become vulnerable because:

• A deployment parameter is incorrect.
• A privileged role is incorrectly assigned.
• An implementation points to the wrong address.
• A strategy is configured with excessive permissions.
• A safety limit is not enabled.
• A deployment assumption changes after launch.

RiseX detected the problem within minutes, patched it on the same day and compensated affected depositors using part of the platform’s previous-month fees.

This demonstrates the importance of continuous post-deployment security monitoring.

An audit performed before deployment can identify a code-level weakness, but it cannot necessarily detect a dangerous production configuration introduced later.

Therefore, production security should include:

• Configuration monitoring.
• Deployment-diff monitoring.
• Privilege-change alerts.
• Strategy-address monitoring.
• Contract upgrade monitoring.
• Abnormal withdrawal detection.

2.4 Unistreets. 6 August 2026

Classification

Smart Contract Vulnerability / Arbitrary Calldata Injection

Reported Impact

Approximately $17,750

The Unistreets LaunchpadFactoryAuto contract was exploited through arbitrary calldata injection.

The factory maintained custody of Uniswap V4 LP NFTs associated with projects launched through the platform.

Because attacker-controlled calldata could reach privileged functionality, the attacker was able to cause approvals and burn operations affecting multiple liquidity positions.

The security significance here extends beyond the amount stolen.

A factory or aggregator contract frequently has custody or operational authority over assets belonging to many independent projects.

This creates a blast-radius problem.

A vulnerability in one central factory can therefore compromise assets belonging to:

• Project A
• Project B
• Project C
• Project D

even though those projects may have independently secured their own contracts.

Security reviews of factory architectures should therefore examine:

• Arbitrary calldata.
• Delegatecall.
• External calls.
• Callback mechanisms.
• Token approval persistence.
• NFT custody.
• User-supplied function selectors.
• Cross-project asset isolation.

The key question is not merely whether the factory can execute an operation.

It is:

Can an untrusted caller influence which operation the factory executes against assets it controls?

---

2.5 RRWallet. 6 August 2026

Classification

Supply Chain / Wallet Security

Reported Impact

Approximately $2 million

RRWallet illustrates an entirely different attack surface.

According to the source analysis, the wallet generated vulnerable seed phrases because of a weak random-number generator in a bundled JavaScript dependency.

The result was potentially catastrophic because deterministic or predictable wallet generation undermines the fundamental security assumption behind self-custody.

A wallet can have:

• Secure transaction signing.
• Strong encryption.
• A hardened UI.
• Good smart-contract interaction controls.

and still fail if its entropy source is predictable.

This makes software supply-chain security a critical part of wallet security.

Wallet applications should therefore continuously assess:

• Randomness generation.
• Dependency provenance.
• Package integrity.
• Dependency versions.
• Build reproducibility.
• Cryptographic libraries.
• Seed-generation pathways.
• Entropy sources.
• Browser/runtime assumptions.

The incident also demonstrates why application security and blockchain security increasingly overlap.

The blockchain itself may be operating correctly while the software used to generate the keys is compromised.

2.6 Atomic Green. 8 August 2026

Classification

Signature Replay / Price Manipulation

Reported Impact

Approximately $29,984

Atomic Green suffered from a signature replay issue affecting manager authorisations.

The same manager signature could reportedly be reused across 21 separate Uniswap V3 LP positions.

The attacker combined this weakness with flash-loan-based price manipulation and triggered unauthorised LP burns.

This is a classic example of why signatures require explicit domain separation and replay protection.

A secure signed authorisation should normally bind the signature to relevant contextual information, such as:

• Contract address.
• Chain ID.
• Position ID.
• Nonce.
• Operation type.
• Expiry.
• Recipient.
• Specific asset or position.

Without sufficient binding, a valid authorisation may become reusable in contexts that the signer never intended.

The attack reportedly resulted in approximately 29,984.27 USDC being drained.

---

2.7 Coreum Bridge. 9 August 2026

Classification

Bridge Logic Vulnerability

Reported Impact

Approximately $200,000

The Coreum Bridge incident targeted the relationship between deposit verification and relayer logic.

The attacker created fake deposit activity involving the bridge’s own wrapped assets and valid memo structures.

Relayers then interpreted those transactions as legitimate deposits and authorised genuine XRP withdrawals.

This highlights one of the fundamental security challenges of cross-chain systems:

The destination chain cannot independently observe the truth of the source chain.

It depends on some combination of:

• Relayers.
• Validators.
• Proofs.
• Light clients.
• Message verification.
• Event interpretation.

If the bridge’s interpretation layer is flawed, attackers can create activity that looks legitimate to the verification system while being economically fraudulent.

Bridge security should therefore include independent validation of:

• Source-chain transaction authenticity.
• Deposit uniqueness.
• Asset provenance.
• Event ordering.
• Replay protection.
• Message identifiers.
• Relayer behaviour.
• Withdrawal limits.

2.8 Oraichain. 9 August 2026

Classification

Cross-Chain / Token Minting Vulnerability

Reported Impact

$0 realised

Oraichain experienced a vulnerability in its EVM cross-chain transfer pathway that enabled unauthorised ORAI minting.

Unlike many incidents, however, the vulnerability was detected and contained before the attacker could realise a corresponding financial loss.

The network was halted, bridges and cross-chain routes were restricted, and unauthorised balances were burned.

This is an important example of why detection speed is itself a security control.

Two protocols can contain essentially similar vulnerabilities but experience radically different financial outcomes because one detects exploitation within minutes while the other detects it hours later.

Security monitoring should therefore measure:

• Time to detection.
• Time to triage.
• Time to containment.
• Time to privileged intervention.
• Amount moved before intervention.
• Number of affected addresses.

The goal should not simply be “prevent every exploit.”

It should also be:

Minimise the time between exploitation and containment.

2.9 Coinsbuy. 9 August 2026

Classification

Access Control / Credential Compromise

Reported Impact

Approximately $7.9 million

Coinsbuy experienced simultaneous wallet drainage across Ethereum and TRON.

Security researchers assessed the incident as consistent with compromise of hot-wallet private keys or administrator privileges, although the exact root cause remained unconfirmed in the source material.

This incident highlights the distinction between:

Code security

and

Operational key security.

A protocol can have secure smart contracts but still suffer catastrophic losses if an attacker obtains:

• Hot-wallet keys.
• Administrator credentials.
• Deployment keys.
• Cloud credentials.
• Signing keys.
• Multisig keys.
• API credentials.

The cross-chain nature of the event is also important.

A compromised operational credential can potentially affect several blockchain environments simultaneously, increasing the blast radius.

The reported attacker activity included conversion toward Monero, while exchanges reportedly froze portions of the funds in transit.

This demonstrates the importance of real-time transaction intelligence and cross-chain fund tracing.

2.10 USM. 10 August 2026

Classification

Smart Contract Pricing / Accounting Vulnerability

Reported Impact

Approximately $136,000

USM was exploited through the pricing behaviour of defund().

The critical issue was that ethFromDefund() was not invariant with respect to transaction splitting.

In practical terms, redeeming a position through many smaller transactions produced a different and more favourable outcome than redeeming the same economic position through one larger transaction.

The attacker combined:

• Flash-loan capital.
• Price manipulation through fund().
• Repeated redemption.
• State contraction through adjShrinkFactor.
• Rounding effects.

The position was then split across 64 small defund() calls.

This is an important category of vulnerability because standard unit tests may verify:

Deposit → withdraw → expected amount.

but fail to test:

Deposit → split position → repeatedly redeem → compare aggregate result.

Financial contracts require economic invariance testing.

Examples include:

• Splitting vs. combining withdrawals.
• Splitting vs. combining deposits.
• Repeated rounding.
• Repeated state transitions.
• Partial liquidation sequences.
• Multiple redemption paths.

The source reports approximately 70.83 ETH being drained.

2.11 Harmony Protocol. 11 August 2026

Classification

Protocol Logic / Cross-Shard Validation

Reported Impact

Approximately $3.2 million, provisional

Harmony suffered a breach involving cross-shard receipt validation.

The vulnerability reportedly allowed forged receipts to be accepted, resulting in unauthorised ONE token minting.

Cross-shard systems are particularly sensitive because the destination environment must establish that an event genuinely occurred elsewhere.

A forged receipt can effectively become a counterfeit proof of value.

The incident therefore reinforces the importance of:

• Receipt authentication.
• Cross-shard message integrity.
• Replay protection.
• Sequence validation.
• State-root verification.
• Finality assumptions.
• Validator-set integrity.
• Proof verification.

Harmony proposed a rollback to a pre-exploit checkpoint, illustrating another difficult question:

At what point does incident response become a consensus intervention?

Once fraudulent state has been incorporated into a blockchain, recovering from the incident may require action above the application layer.

---

2.12 Whale Wallet Drain — 13 August 2026

Classification

Phishing / Social Engineering

Reported Impact

Approximately $25.6 million

A single private individual reportedly lost approximately $25.6 million in a phishing attack.

This was the largest loss in August outside the Tectonic incident and demonstrates that individual users remain a major target.

The significance is broader than the particular victim.

Traditional security models often concentrate heavily on protocol-level vulnerabilities.

However, a high-value wallet can represent an extremely attractive target even when:

• The blockchain is secure.
• The wallet software is secure.
• The smart contracts are audited.

The weakest component may instead be the human operator.

High-value wallet security should therefore incorporate:

• Transaction simulation.
• Address allowlisting.
• Hardware signing.
• Out-of-band transaction verification.
• Spending limits.
• Session isolation.
• Anti-phishing controls.
• Domain monitoring.
• Social-engineering awareness.

The incident demonstrates that human-layer security is now financially comparable to protocol-layer security.

2.13 FoxMarket.15 August 2026

Classification

Flash Loan / Price Manipulation

Reported Impact

Approximately $118,700

FoxMarket’s exploit involved manipulation of a PancakeSwap spot price used inside FoxLpBondsPool.stake().

The protocol calculated the stake amount using a manipulable market price before performing a large USDT-to-FOX swap.

That swap itself changed the pool’s reserves.

The critical failure was that the protocol did not subsequently reconcile:

• The value initially calculated.
• The actual assets deposited.
• The resulting LP-token backing.

The attacker could therefore obtain an economic entitlement based on stale or manipulated information.

The exploit was amplified using flash-loan capital and completed within the transaction sequence.

The source identifies three principal missing safeguards:

1. Manipulation-resistant pricing.
2. Verification that accounted value matches actual backing.
3. Delayed reward settlement.

These are broadly applicable controls for protocols involving tokenised positions or rewards.

2.14 Maya Protocol. 18 August 2026

Classification

Smart Contract / Protocol Logic / Cross-Chain Vulnerability

Reported Impact

Approximately $17 million in the source dataset

Maya Protocol was one of August’s largest incidents.

The attack was particularly notable because it was not dependent on one isolated coding mistake.

Instead, multiple vulnerabilities interacted across:

• Trade account handling.
• Outbound transaction processing.
• Liquidity-pool accounting.
• Balance management.

External reporting likewise described a chain of six bugs that combined to create a false balance and enable the attacker to extract real assets.

This is an important lesson for audit methodology.

Individual vulnerabilities may appear low or medium severity when analysed separately.

But security analysis must also ask:

Can vulnerabilities compose into a critical attack path?

For example:

Bug A → creates incorrect balance

Bug B → prevents reversal

Bug C → allows attacker to acquire economic ownership

Bug D → allows withdrawal

The result can be substantially larger than the severity of any individual defect.

Maya therefore demonstrates the importance of multi-step attack-path modelling.

2.15 Allbridge.19 August 2026

Classification

Bridge Logic Vulnerability

Reported Impact

Approximately $190,000

Allbridge experienced a bridge logic exploit affecting its cross-chain infrastructure.

The source also highlights a separate architectural concern involving privileged ownership and the ability of an owner account to alter contracts and potentially drain liquidity.

This distinction is important.

A system may have:

Incident vulnerability

and separately:

Structural centralisation risk.

They should not automatically be treated as the same vulnerability.

However, both need to be incorporated into the protocol’s overall threat model.

Bridge security should assess:

• Upgrade authorities.
• Emergency controls.
• Relayer privileges.
• Validator privileges.
• Contract ownership.
• Asset custody.
• Withdrawal limits.
• Administrative recovery mechanisms.

2.16 The Sandbox. 21 August 2026

Classification

Smart Contract / Cross-Chain Messaging Vulnerability

Reported Impact

Approximately $675,000

The Sandbox incident involved compromised LayerZero delegate permissions through an approveAndCall pathway on Base and BNB Chain bridges.

The attacker was able to mint SAND without equivalent backing.

The nominal face value of minted tokens was reportedly enormous, approaching tens of billions of dollars, but this figure should not be confused with the actual realisable economic loss.

This distinction is critical in incident reporting.

Security teams should differentiate:

• Tokens technically created.
• Tokens actually sold.
• Liquidity available.
• Assets actually withdrawn.
• Mark-to-market value.
• Realised loss.

Otherwise, incident reporting can dramatically overstate the actual financial impact.

The Sandbox disabled affected bridging infrastructure and indicated that affected liquidity providers would be repaid one-to-one.

2.17 TAC. 22 August 2026

Classification

Contract / Shared Infrastructure Vulnerability

Reported Impact

Approximately $7.5 million

TAC suffered an incident involving a vulnerability in the shared Cosmos EVM precompile layer.

The important point is that the vulnerability was reportedly not specific to TAC’s own application logic.

Instead, it affected shared infrastructure.

The chain was halted at block 24,671,475.

The incident was a drain rather than a mint: the source states that total supply remained unchanged while approximately 2.985 billion TAC moved between accounts.

This demonstrates the systemic risk created by shared blockchain infrastructure.

When multiple chains use:

• The same precompile.
• The same EVM module.
• The same library.
• The same bridge implementation.
• The same cryptographic component.

a single vulnerability can potentially propagate across ecosystems.

Therefore, dependency inventories must include blockchain-level shared infrastructure, not only npm, Rust or Solidity packages.

2.18 warp.green. 23 August 2026

Classification

Smart Contract / Cross-Chain Vulnerability

Reported Impact

Approximately $93,000

warp.green experienced a vulnerability affecting its ERC-20 bridge connecting Chia with Ethereum and Base.

The incident reinforces the recurring August theme:

Every bridge creates a new trust boundary.

The security of a bridge depends not only on its smart contracts but also on:

• Source-chain finality.
• Message verification.
• Token accounting.
• Mint/burn logic.
• Replay protection.
• Relayers.
• Destination-chain assumptions.

Bridge contracts should therefore be treated as high-value financial infrastructure rather than ordinary token contracts.

2.19 Arrakis V1. 23 August 2026

Classification

Flash Loan / Price Manipulation

Reported Impact

Approximately $7,018

Arrakis V1 was attacked through manipulation of the instantaneous Uniswap V3 spot price.

The attacker:

1. Flash-loaned approximately 1,800 WETH.
2. Manipulated the relevant pool price.
3. Minted vault shares at the distorted valuation.
4. Restored the market price.
5. Burned the shares.
6. Received a richer composition of underlying assets.

The underlying weakness was that the vault’s mint and burn operations relied directly on the pool’s spot price without sufficient manipulation resistance.

The vault had protection around its separate rebalancing mechanism, but that protection did not extend to mint/burn valuation.

This is a classic example of security-control coverage gaps.

A protocol can have an oracle protection mechanism and still remain vulnerable if another financial pathway uses an unprotected price source.

Auditors should therefore map:

Every location where a price enters an economic calculation.

Not simply:

Every oracle contract.

2.20 Term Finance. 23 August 2026

Classification

Governance Attack

Reported Impact

Approximately $8.5 million

Term Finance demonstrated the financial danger of concentrated governance ownership.

The attacker initially obtained approximately 2 ETH from Tornado Cash and used capital to acquire a majority of a thinly distributed DAO governance token.

Once voting control was obtained, the attacker passed proposals redirecting vault assets.

The underlying lending markets were not necessarily the direct vulnerability.

Instead, the attacker compromised the governance layer controlling financial infrastructure.

This distinction is essential.

Governance tokens should not automatically be considered harmless simply because they do not directly custody funds.

If governance can:

• Upgrade contracts.
• Change treasury addresses.
• Modify collateral factors.
• Change strategy addresses.
• Authorise withdrawals.
• Alter protocol parameters.

then governance itself becomes a privileged security boundary.

Security reviews should therefore assess:

• Token distribution.
• Voting concentration.
• Flash-loan voting possibilities.
• Delegation.
• Proposal delays.
• Quorum requirements.
• Emergency vetoes.
• Timelocks.
• Guardian roles.

Term Finance demonstrates that economic decentralisation and technical decentralisation are not the same thing.

2.21 Enjin. 25 August 2026

Classification

Smart Contract / Storage Collision

Reported Impact

Approximately $162,000

The Enjin incident involved a particularly important proxy architecture issue.

Adapters were executed through a Managed Delegate Proxy using DELEGATECALL.

Because delegatecalled code executes within the proxy’s storage context, the storage layout of the adapter becomes security-critical.

The source describes a collision involving slot 1:

• The adapter’s initialize(uint256) function wrote to slot 1.
• The proxy used slot 1 for pendingManager.

The attacker invoked the adapter’s initialisation function through DELEGATECALL, overwriting the proxy’s manager-related state.

The attacker then called acceptManager() and obtained managerial control.

Once administrative control was acquired, a malicious adapter could be registered and used to steal assets.

This demonstrates why proxy security must include:

• Storage-layout compatibility.
• Initialisation restrictions.
• Delegatecall target validation.
• Upgrade authority protection.
• Function selector collisions.
• Role-transition logic.

The vulnerability was not simply “an initializer bug.”

It was a compositional proxy architecture failure.

2.22 CometDEX. 25 August 2026

Classification

Smart Contract Vulnerability

Reported Impact

Approximately $717,518

CometDEX, an open-source weighted AMM built on Stellar’s Soroban environment, suffered a smart contract vulnerability.

The incident is particularly useful from an ecosystem perspective because it demonstrates that smart contract security is no longer exclusively an EVM concern.

As smart-contract platforms diversify, security methodologies must adapt to:

• Different virtual machines.
• Different storage models.
• Different execution semantics.
• Different transaction models.
• Different permission systems.
• Different arithmetic behaviour.

Auditing frameworks therefore need platform-specific threat models rather than assuming that Solidity/EVM security patterns can be copied directly to every blockchain.

2.23 FH Token. 26 August 2026

Classification

Smart Contract Vulnerability

Reported Impact

Approximately $20,000

TenArmor’s monitoring system detected suspicious activity involving FH Token on BSC.

Although the reported loss was comparatively small, the incident reinforces an important operational principle:

Low-value attacks can still be valuable security signals.

A monitoring system that detects:

• Unusual transfers.
• Abnormal minting.
• Unexpected liquidity removal.
• Sudden price changes.
• Privileged function calls.

can provide early-warning indicators before a larger attack develops.

Security operations should therefore not measure success solely by money saved.

They should also measure:

• Detection time.
• False-positive rate.
• Investigation time.
• Number of suspicious events identified.
• Percentage of incidents contained before escalation.

2.24 Moonwell. 27 August 2026

Classification

Price Manipulation

Reported Impact

Approximately $8.75 million

Moonwell experienced a major price-manipulation attack.

The incident is significant because Moonwell is an established lending protocol operating across multiple networks and had an active bug-bounty programme and third-party audit history.

The lesson is not that audits are ineffective.

Rather:

Audits reduce software risk; they do not automatically eliminate economic or market-structure risk.

A contract may behave exactly according to its audited code while producing unsafe outcomes when the market data entering that code is manipulated.

For lending protocols, security reviews should therefore evaluate:

• Oracle source.
• Liquidity depth.
• Price deviation.
• Collateral concentration.
• Borrow caps.
• Supply caps.
• Liquidation thresholds.
• Market isolation.
• Governance-controlled parameters.

Oracle risk must be considered part of the financial risk model, not simply a technical integration.

2.25 Avici. 28 August 2026

Classification

Smart Contract / Wallet Security

Reported Impact

Approximately $500,859, estimated and unconfirmed

Avici, a Solana-based self-custodial neobank combining smart-contract wallet functionality, card infrastructure and fiat on/off-ramp integrations, suffered a security breach involving user funds.

The source notes that reported loss estimates varied and that Avici had not confirmed an official figure at the time of writing.

This qualification is important.

Incident intelligence should distinguish:

• Confirmed losses.
• Estimated losses.
• Claimed losses.
• Potential exposure.
• Maximum theoretical exposure.

For financial reporting, these categories should never be treated as interchangeable.

2.26 Tectonic. 30 August 2026

The Defining Incident of August

Classification

Price Manipulation / Governance Token Collateral

Reported Impact

Approximately $74 million

Tectonic was by far the most consequential incident of August.

The attacker manipulated the price of TONIC, Tectonic’s thinly traded governance token, causing its market price to increase approximately 100-fold within around 20 minutes.

The attacker then used the artificially inflated TONIC as collateral to borrow real assets from Tectonic’s lending pools.

External analysis also describes TONIC as having extremely limited liquidity relative to the amount subsequently borrowed.

Before the incident, Tectonic reportedly had approximately:

• $121.7 million TVL
• $82.7 million in active loans

The protocol therefore represented a significant concentration of Cronos DeFi liquidity.

Attack Sequence

The attack can be conceptually understood as:

1. Acquire/control thinly traded TONIC

↓

2. Manipulate TONIC market price

↓

3. Protocol observes inflated price

↓

4. Deposit TONIC as collateral

↓

5. Lending protocol calculates inflated collateral value

↓

6. Borrow real assets

↓

7. Convert/bridge extracted assets

↓

8. Chain intervention limits further movement

This is an extremely important attack pattern.

The attacker did not need to “hack” the lending contract in the conventional sense.

Instead, the attacker exploited the relationship between:

Market price → collateral valuation → borrowing power

The underlying financial assumption was unsafe.

Why the Collateral Factor Was Not Enough

A 20% collateral factor may appear conservative.

However:

20% of an artificially inflated asset is still artificially inflated.

If the oracle believes an asset is worth $100 when its economically recoverable value is closer to $1, then a 20% collateral factor does not provide meaningful protection.

The correct question is therefore not simply:

“What is the collateral factor?”

It is:

“Can the collateral price itself be trusted during stress?”

Cronos Response

Cronos halted block production across the chain after detecting the attack.

The intervention was possible because of the chain’s validator architecture and allowed the network to prevent the attacker from moving most of the extracted value externally.

Approximately $6 million reportedly reached Ethereum before the halt, while roughly $68 million remained on Cronos at the time described in the source.

External analysis also reported that Cronos validators later rolled the chain back to a state preceding the attack, reversing funds that remained on Cronos.

Strategic Security Lesson

Tectonic demonstrates that protocols accepting thinly traded governance or reward tokens as collateral require substantially stronger controls.

Possible controls include:

• Minimum market liquidity requirements.
• Maximum collateral concentration.
• TWAP pricing.
• Multiple independent price sources.
• Price-deviation circuit breakers.
• Maximum oracle movement per block.
• Borrow caps.
• Asset isolation.
• Collateral-factor reduction during volatility.
• Minimum trading volume requirements.
• Maximum collateral-to-liquidity ratios.

The broader lesson is:

Collateral risk is not independent of market liquidity.

2.27 Aquifer. 31 August 2026

Classification

Access Control / Credential Compromise

Reported Impact

Approximately $2.5 million

Aquifer closed the month with another major incident.

The Solana-based AMM reportedly suffered an attack involving linked attacker addresses on Solana and Ethereum.

The source characterises the incident as involving a wallet credential compromise.

The response was notable.

Rather than relying solely on conventional investigation and enforcement, Aquifer published a cryptographically authorised on-chain whitehat offer directly to the attacker-controlled addresses.

The proposal offered:

• Return of at least 80% of the stolen assets.
• Up to 20% retained as a bounty.
• No civil claims by Aquifer, subject to applicable terms.
• A fixed return deadline.
• Explicit acknowledgement that the arrangement did not bind law enforcement, regulators or sanctions authorities.

This represents a shift toward on-chain incident negotiation.

The response demonstrates how protocols can use the blockchain itself as a communication and settlement mechanism during an incident.

However, such arrangements remain dependent on attacker cooperation and should not be interpreted as a substitute for:

• Key compromise investigation.
• Forensic analysis.
• Law-enforcement notification.
• Sanctions screening.
• Address attribution.
• Evidence preservation.

3. Attack-Type Analysis

3.1 Smart Contract and Protocol Logic

Smart contract and protocol logic vulnerabilities remained the most frequent category.

The source classifies 11 of 27 incidents, or approximately 41%, within this broad category.

Examples include:

• RiseX
• Unistreets
• USM
• Maya Protocol
• The Sandbox
• TAC
• warp.green
• Enjin
• CometDEX
• FH Token
• Avici

However, frequency and financial severity tell very different stories.

The source estimates approximately $27.5 million in losses from smart contract and logic exploits, around 17% of the month’s total.

This means that the most common category was not the most financially destructive.

3.2 Price and Oracle Manipulation

Price and oracle manipulation represented approximately five incidents, or around 19% of the dataset.

These included:

• LOOPSDAO
• FoxMarket
• Arrakis V1
• Moonwell
• Tectonic

Yet by financial value this category dominated the month.

The source estimates approximately $83.4 million, or around 52% of August’s total losses, largely because of Tectonic.

This is a major risk-management lesson:

Incident frequency does not equal financial risk.

A vulnerability class appearing only a handful of times can still represent the largest systemic risk if each event has a high blast radius.

3.3 Phishing and Social Engineering

Phishing accounted for approximately $25.6 million, almost entirely because of one high-value private-wallet incident.

This represented approximately 16% of the month’s losses.

The implication is clear:

Security programmes protecting large digital-asset holdings cannot treat phishing as merely an end-user problem.

High-value individuals, treasury operators, founders, administrators and institutional traders represent attractive targets.

3.4 Governance Attacks

Term Finance demonstrates that governance tokens can become direct financial attack surfaces.

An attacker does not necessarily need to compromise:

• A private key.
• A smart contract.
• An oracle.

They may simply acquire enough voting power to change the protocol’s behaviour legitimately according to its governance rules.

This is one of the most difficult categories to defend because the malicious action can technically be:

valid governance.

3.5 Access Control and Credential Compromise

MOKE, RRWallet and Coinsbuy illustrate the continued importance of privileged access.

Together, these incidents accounted for approximately $10.8 million, according to the source analysis.

Security programmes therefore need to protect not only contracts but also:

• Deployment environments.
• Cloud accounts.
• Signing systems.
• Wallets.
• CI/CD pipelines.
• Administrator accounts.
• Recovery keys.
• Multisigs.

4. Major Security Trends

4.1 Tectonic Reshaped the Entire Month

The Tectonic incident accounted for close to half of the month’s losses.

Without it, the distribution would have looked significantly more diversified.

This creates an important analytical distinction:

Headline risk

The single largest incident.

Baseline risk

The recurring security losses that remain after removing the largest incident.

Even without Tectonic, approximately $88 million of losses remained in the source analysis.

Therefore, Tectonic should not be interpreted as an isolated anomaly that makes August otherwise safe.

---

4.2 Governance and Collateral Are Converging Risk Areas

Term Finance and Tectonic appear mechanically different.

One involved voting control.

The other involved collateral pricing.

But both rely on an underlying weakness:

An asset with insufficient economic depth was given disproportionate influence over a much larger pool of value.

At Term Finance:

Thin token distribution → cheap voting majority → control over funds.

At Tectonic:

Thin token liquidity → easy price manipulation → inflated collateral → borrowing against real assets.

This suggests that protocols should monitor not only smart-contract vulnerabilities but also:

• Token distribution.
• Market liquidity.
• Governance concentration.
• Collateral concentration.
• Token velocity.
• Price impact.
• Whale ownership.

4.3 Cross-Chain Infrastructure Remains a High-Risk Boundary

August included incidents involving:

• Coreum
• Oraichain
• Allbridge
• The Sandbox
• Harmony
• Maya Protocol
• warp.green

Cross-chain systems remain attractive targets because they connect separate security domains.

A bridge may depend on:

• Source-chain finality.
• Relayers.
• Validators.
• Oracles.
• Message verification.
• Token accounting.
• Destination-chain execution.

A failure in any one of these layers can create fraudulent value.

---

protocol-scale financial damage without a protocol exploit.

---

10. Conclusion

August 2026 delivered approximately $162 million in losses across 27 major incidents in the source dataset.

The month was dominated by the approximately $74 million Tectonic incident, which demonstrated the extraordinary financial consequences of allowing a thinly traded governance token to function as collateral without sufficient manipulation-resistant valuation controls.

However, the broader threat environment was considerably more diverse.

Attackers exploited:

• Smart contract logic.
• Access controls.
• Wallet software.
• Signature systems.
• Cross-chain bridges.
• Governance mechanisms.
• Market prices.
• Oracle assumptions.
• Human users.
• Privileged credentials.
• Shared blockchain infrastructure.

The month therefore reinforces a critical principle for Web3 security:

Security must be treated as a continuous system property rather than a one-time audit result.

A protocol may pass a smart contract audit and still be vulnerable to economic manipulation.

A wallet may use strong cryptography and still fail because of weak entropy.

A bridge may correctly execute its contracts and still be vulnerable because its relayer assumptions are flawed.

A DAO may be technically decentralised while remaining economically concentrated.

A regulated business may have sanctions-screening software while lacking the ability to distinguish unsolicited blockchain exposure from intentional customer behaviour.

And a protocol may detect an exploit too late even when the underlying vulnerability could have been contained.

The security architecture required for modern digital-asset infrastructure must therefore combine:

Code security + economic security + governance security + wallet security + infrastructure security + monitoring + incident response + compliance intelligence.

The most mature organisations will increasingly operate security as a continuous intelligence function.

That means continuously monitoring:

• Contract behaviour.
• Governance activity.
• Oracle prices.
• Liquidity.
• Collateral exposure.
• Privileged wallets.
• Cross-chain transfers.
• Administrative changes.
• Suspicious transactions.
• Attacker infrastructure.
• Sanctions exposure.
• Beneficial ownership.
• User-targeted phishing campaigns.

The central lesson from August is therefore not simply that crypto remains vulnerable.

It is that the definition of the attack surface is becoming much larger.

As blockchain infrastructure becomes more interconnected with financial markets, payment systems, stablecoins, AI-driven applications, bridges and regulated financial institutions, the most dangerous vulnerabilities will increasingly occur at the boundaries between systems.

The organisations that remain resilient will be those that identify and monitor those boundaries continuously—before an attacker discovers them first.