# Blockchains Experts

> Source: https://www.blockchainsexperts.io

---

# Wallet Drainer Evolution: The 2026 Threat Landscape

Source: https://www.blockchainsexperts.io/en/blog/wallet-drainer-evolution-2026
Published: 2026-05-28
Updated: 2026-05-28

The [wallet drainer](/glossary/wallet-drainer) ecosystem has matured into a full-blown industry. By 2026, drainer-as-a-service operators run franchises with affiliate networks, hosted phishing infrastructure, and 24/7 cash-out support. Individual drains have crossed the $20M mark. The patterns have evolved beyond what most users (and many security teams) recognise. This piece walks through the 2026 drainer landscape and what defends against it.

## The drainer-as-a-service economy

Modern wallet drainers operate like SaaS:

- **The operators** build and maintain the drainer kit: smart contracts, signing logic, drain UIs, mixer infrastructure.
- **The affiliates** drive traffic through phishing campaigns, fake X / Discord posts, malicious browser extensions.
- **Revenue split** is typically 70/30 in favour of the affiliate (sometimes inverted for low-skill affiliates using the operator's full kit).
- **Tooling** includes dashboards showing drain success rate, wallet types targeted, fund flow per address, and "VIP" support for large drains.

The economic model means drainer operators can spend significant resources on technical innovation. The gap between a drainer's sophistication and a typical user's defences keeps widening.

## Pattern 1: gasless approval phishing

The classic [approval phishing](/glossary/approval-phishing) attack required the user to sign a transaction (`approve(spender, max)`) and pay gas. Modern drainers eliminate the friction:

- **Permit-based drains**: the drainer asks the user to sign an off-chain `permit` (EIP-2612) message. The signature itself authorises the transfer; no on-chain transaction from the user is required. The drainer then submits the permit and immediately drains.
- **Permit2-based drains**: many tokens don't support EIP-2612 permits. Uniswap's Permit2 contract added a universal permit layer. A signed Permit2 message can authorise transfers of *any* token the user has approved Permit2 for, and most users have, given Permit2's wide adoption.

The user sees a "free" signature request. They sign. The funds are gone before they realise the signature was authorisation to drain.

Defence: **never sign an off-chain message you don't fully understand**. Wallets that show the decoded permit / Permit2 details before signing are a partial defence. Hardware wallets that display the raw EIP-712 structure help. Most users are not trained to read these.

## Pattern 2: EIP-712 typed data abuse

EIP-712 typed data signing was supposed to make signatures readable: instead of signing an opaque hash, users sign a structured message they can review.

In practice, drainers exploit two gaps:

1. **Domain confusion**: the EIP-712 domain separator includes a name and version. Drainers craft domains that look like legitimate dApps ("Uniswap V3 Router", but pointing at a malicious contract). Users see "Uniswap" in the wallet UI and sign.
2. **Field misdirection**: the typed data fields can be named anything. A drain transaction can be presented as a "Login" or "Verification" message with a field labeled "amount" that the user assumes is gas, but is actually the drain amount.

Defence: read the domain's `verifyingContract` address, not just the name. Contract addresses are the ground truth. Names and versions are display strings.

## Pattern 3: ERC-7702 delegation traps

The 2026 emerging pattern: drainers using ERC-7702 to permanently delegate an EOA to a malicious contract.

The flow:
1. User is phished into signing an ERC-7702 delegation message.
2. The signed message authorises the user's EOA to delegate execution to a drainer contract.
3. Once submitted, the EOA *is* the drainer contract for any subsequent transaction.
4. Crucially, the delegation persists until explicitly revoked. A user who delegates and forgets has a permanently compromised wallet.

The drain doesn't even need to happen immediately. A patient drainer waits weeks, drains when funds appear, and the user never realises the original signature was the compromise.

Defence: ERC-7702 delegation requests should be presented in wallet UIs with a much higher friction level than ordinary signatures. Some 2026 wallets are starting to require explicit acknowledgement ("I understand this delegates my account permanently"). Most aren't.

## Pattern 4: drainer-as-a-page (drainer link in legitimate-looking sites)

Drainers no longer require obvious phishing pages. The 2026 technique:

- **Compromised search results**: drainer URLs paid into Google ads, indexed via SEO poisoning, or surfaced via compromised partner sites.
- **NFT mint hijacking**: a legitimate NFT project's official mint URL is briefly hijacked (DNS poisoning, compromised social, BGP hijack) and serves a drainer instead.
- **Wallet-connect prompts on legitimate dApps**: a compromised dApp serves the drainer signature request from the same domain users trust.
- **Browser extension supply chain**: a popular extension is sold to a malicious operator and updated to inject drainer prompts.

The user did everything right: went to "the right" URL, used "the right" wallet, signed what looked like a normal transaction. The compromise was upstream.

Defence: anything from any URL should be treated as untrusted before signing. Hardware wallets that display the decoded transaction data give the user a chance to spot anomalies. Wallet-side simulation (Blockaid, Wallet Guard, native simulation in Rabby / Frame) is the practical defence layer.

## What dApp operators owe their users

If you operate a dApp that prompts wallet signatures, the bare-minimum 2026 standard:

- **Never request a permit without explicit context**. The signature prompt must clearly state what the permit authorises.
- **Use type-safe signatures (EIP-712)** with a verifying contract that is your real production contract.
- **Don't request signatures with overly broad approval scopes** (e.g., max approval to a generic spender) when scoped approvals would do.
- **Implement transaction simulation hints** when integrating with wallets that support them (Blockaid, Wallet Guard).
- **Have a clear "report phishing" path** for users who believe they were targeted via your brand.

## What protocols owe their treasuries

For protocol operators and DAO treasuries, the drainer threat lands differently. The treasury usually doesn't visit phishing sites, but its **signers** are individuals with personal wallets that *are* targeted.

- **Treasury and personal wallets must be separated**. A signer who is drained personally must not have access to treasury authority through the same path.
- **Hardware wallets with display verification** are the floor. A signer who clicks through a software wallet prompt is signing what the prompt says, which may not be what they intended.
- **Transaction simulation before signing**: wallet UIs that show what *will* happen, not just what is being signed, are critical.
- **[Wallet surveillance](/services/wallet-surveillance) on treasury and signer-adjacent addresses**: continuous monitoring catches the post-compromise activity even when the initial signature couldn't be prevented.

## When a drain happens

The first hour matters. Our piece on [DeFi incident response in the first hour](/blog/incident-response-defi-first-hour) walks through the playbook. Specifically for wallet drains:

1. **Revoke approvals immediately** on the compromised wallet, but only via a different, uncompromised wallet, since signing from the drained one may be intercepted.
2. **Trace the funds** as they move. The trace is what enables eventual recovery (sometimes weeks later).
3. **Contact the off-ramps**. Exchanges and custodians can freeze funds if the trace reaches them in time.
4. **Document everything**. The drain trace is the artifact that any law enforcement engagement will need.

[Incident response engagements](/services/incident-response) for wallet drains succeed sometimes, usually when engagement is within hours, not days.

---

# Stablecoin Security in 2026: Reserves, MiCA, and the Smart Contract Layer

Source: https://www.blockchainsexperts.io/en/blog/stablecoin-security-mica-2026
Published: 2026-05-21
Updated: 2026-05-21

By 2026, regulated stablecoins under [MiCA](/glossary/mica) (EUR-denominated and USD-denominated) sit at the centre of the European crypto economy. Their security posture matters far beyond their issuers: every DeFi protocol, every CASP, every treasury holding stables inherits a slice of the issuer's risk. This piece walks through the three layers of stablecoin security and what each side of an integration should be looking at.

## Layer 1: reserve management

A fiat-referenced stablecoin under MiCA must maintain reserves at least equal to the outstanding token supply, segregated from the issuer's own assets, and audited periodically. Reserve quality matters more than reserve quantity:

- **Cash and high-quality liquid assets** (HQLA) are credit-equivalent risk to the underlying instruments. Treasury bills and overnight repos with sound counterparties are the floor.
- **Bank deposits** carry deposit-insurance limits and bank credit risk. Spreading deposits across multiple institutions (and jurisdictions) is a structural requirement, not a nice-to-have.
- **Counterparty risk on the custody side** is real: even fully-reserved stablecoins have failed when the custodian was compromised or went insolvent.

For integrators (DeFi protocols, treasuries) holding regulated stables, the relevant questions are:

- Where is the reserve attestation published, and how often?
- Who is the auditor? Is the methodology Big-4-grade or self-attested?
- What is the redemption mechanism in stress conditions: direct issuer redemption, or only through market makers?

## Layer 2: MiCA compliance

MiCA's stablecoin regime distinguishes between:

- **EMTs (e-money tokens)**: pegged to a single fiat currency (EUR, USD). Must be issued by an authorised electronic money institution or credit institution. Reserve and redemption requirements are the strictest.
- **ARTs (asset-referenced tokens)**: pegged to a basket of currencies, commodities, or other assets. Subject to additional governance, reserve, and disclosure requirements.

For both, [MiCA](/glossary/mica) imposes:

- **Authorisation by a competent authority** (in France: ACPR for EMTs, AMF for crypto activities adjacent).
- **White paper publication** with the precise composition of reserves and redemption rights.
- **Significant token thresholds**: above certain transaction volumes or holder counts, the issuer is classified as significant and falls under direct ECB supervision. The threshold also locks issuance growth.
- **Reserve quality and segregation**: the white paper must specify reserve composition; the reserve must be ring-fenced from issuer creditors.
- **Redemption rights**: at par, at any time, by the holder. No fees beyond actual costs.

The compliance layer overlaps with [DORA](/glossary/dora) for ICT risk and pentest expectations: see our piece on [MiCA pentest requirements](/blog/mica-pentest-requirements-casp).

## Layer 3: the smart contract

The token contract itself is where the rubber meets the road. The patterns to audit:

### Mint / burn authority

Who can mint? Who can burn? Production stablecoin contracts almost always have:

- A small set of `MINTER_ROLE` and `BURNER_ROLE` addresses.
- Multi-sig or MPC behind those roles.
- Often a timelock on role grants (so adding a new minter is not a fast-path attack).

Audit questions:

- Are minter / burner roles transferable? On what timelock?
- Is there a `pause()` function, and is it gated correctly?
- Are roles separable (can the same key both mint and burn)?

### Blacklist and freeze

Most regulated stablecoins implement a `blacklist(address)` function for AML / sanctions compliance. A blacklisted address cannot send or receive the token.

This function is necessary but dangerous:

- Compromise of the role that controls it lets an attacker freeze any address.
- Bugs in the role's access control are catastrophic.
- The function must be auditable and the criteria for blacklisting transparent.

Audit questions:

- Who can blacklist? Multi-sig with a documented compliance process?
- Are there off-chain controls (legal review, AML team approval) before on-chain action?
- Is there a remediation path if a wallet is mistakenly blacklisted?

### Cross-chain and bridge interactions

Most stablecoins exist on multiple chains. The native vs bridged distinction matters:

- **Canonical issuer-issued on each chain** (Circle's CCTP for USDC) preserves redemption rights across chains.
- **Lock-and-mint via third-party bridges** introduces bridge counterparty risk between the user and the issuer.

For an integrator: prefer native versions where the issuer has a presence. Audit bridges that hold non-trivial supply.

### Upgradeability

Most regulated stablecoins are upgradeable proxies. The proxy admin path is the entire trust assumption:

- Who controls the proxy admin?
- Is the upgrade path timelocked?
- Are upgrade events publicly tracked and reviewable?

A proxy admin controlled by a single EOA, regardless of the issuer's reputation, is a single point of failure. Multi-sig with a multi-day timelock is the floor.

## Stablecoin depeg as a security event

A depeg event (even a transient one) can cascade through DeFi protocols that hold the stablecoin as collateral, in liquidity pools, or as an oracle reference. Security teams holding stables should:

- **Maintain monitoring** on the on-chain price (DEX TWAPs) and off-chain price (CEX feeds).
- **Pre-define depeg playbooks**: at -X bps, do Y. At -Y bps, do Z.
- **Know the redemption mechanics** for the stable: can your treasury redeem directly with the issuer, or only via market makers?
- **Diversify across stables**: a treasury holding only one stablecoin is concentrating issuer risk regardless of the issuer's reputation.

## Audit scope for an integrator

For a [DeFi protocol](/for/defi-protocols) integrating a stablecoin, the [audit](/services/smart-contract-audit) should cover:

1. How does the protocol handle the stable's blacklist function being invoked on a protocol address?
2. How does the protocol handle a temporary depeg (oracle returning stale or off-peg price)?
3. How does the protocol handle the stable's pause function?
4. What is the protocol's liquidation behaviour if the stable depegs while it's the collateral?
5. Are there any assumptions of 1:1 redemption baked into invariants that break under stress?

The stables of 2026 are far better-regulated than those of 2022. The integration risk is still there. The audit that doesn't model it is incomplete.

---

# Account Abstraction Security: ERC-4337 Pitfalls in Production

Source: https://www.blockchainsexperts.io/en/blog/account-abstraction-erc4337-security
Published: 2026-05-14
Updated: 2026-05-14

By 2026, account abstraction (ERC-4337 in production for two years, ERC-7702 widely adopted post-Pectra) has shifted the wallet landscape. Smart contract wallets, gasless transactions, social recovery, and session keys are no longer experimental. They are how a meaningful chunk of users now interact with on-chain protocols. This piece walks through the security pitfalls we see in production AA deployments, and what an [audit of an ERC-4337 stack](/services/smart-contract-audit) should actually cover.

## The new trust model

A traditional EOA-controlled wallet has one trust assumption: the holder of the private key. Compromise the key, drain the funds. Account abstraction expands that into a programmable model with multiple actors:

- **The smart contract account itself**, with custom validation logic.
- **The bundler**, which packages user operations and submits them to the EntryPoint.
- **The paymaster**, which sponsors gas (or accepts ERC-20 payment) on behalf of the user.
- **Session keys / sub-accounts**, with scoped permissions and time bounds.
- **Social recovery guardians**, who can rotate the master key.

Each is a new surface. The wallet drainer of 2026 doesn't always need the user's signature: it might exploit an over-permissioned session key, a buggy paymaster, or a recovery path that bypasses intended protections.

## Pitfall 1: paymaster economic griefing

A **paymaster** can sponsor gas for any user operation it accepts. The classic attack: a malicious user submits operations that consume the paymaster's deposit faster than the legitimate user base does, draining the dApp's treasury.

What to audit on a paymaster:

- **Validation cost is bounded**. If validation can call into arbitrary contracts (state reads, oracle calls), the bundler may not include the op due to gas estimates. But a malicious op can still consume the bundler's verification budget.
- **Per-user rate limits**. A paymaster that doesn't track per-sender consumption is trivially drainable.
- **Acceptance rules**. Paymasters that accept any operation are paymasters that go bankrupt. Validate the target contract, the function selector, the calldata shape.
- **Withdrawal protection**. The paymaster owner should not be able to drain the paymaster faster than users in flight expect.

A well-known production paymaster lost $200k in a 2025 incident from a missing per-op gas check. The bug was in fewer than 10 lines of Solidity.

## Pitfall 2: validation-phase reentrancy and storage access

The ERC-4337 spec restricts what a wallet's validation function can do, specifically which storage slots it can read and which other contracts it can call. The reason: bundlers need to be able to predict whether an op will succeed without executing it.

Wallets that violate the validation restrictions (intentionally or via composition with library code) get rejected by reputation-tracking bundlers. But more subtly: wallets that *technically comply* with the rules can still be designed in ways that make the validation behaviour different from execution. That gap is exploitable.

What to audit:

- Validation must not depend on mutable global state that can change between validation and execution.
- Validation must not call into external contracts whose return values affect the validation outcome (the spec restricts this, but composition can sneak it through).
- The wallet's `validateUserOp` and `execute` paths must agree on what is "the same operation": different signature schemes here are an entry point.

## Pitfall 3: session keys with too-broad scope

Session keys are the AA feature that most directly shifts UX: a dApp can request the user grant a scoped, time-bounded key for a series of operations (a game session, a trading session) without prompting for every transaction.

The common mistakes:

- **Scope is too broad**. "Allow this dApp to call any contract" is functionally equivalent to "give this dApp your private key for the duration."
- **Scope expressions are wrong**. ABI-decoded scope rules with off-by-one errors are common. A session key meant to allow "trades up to $100" that allows "trades up to $1,000,000" is a bad day.
- **Revocation is not tested**. Some session-key implementations have on-chain revocation paths that don't propagate immediately. Revoke + assume revoked is a security gap.
- **Key storage on the dApp side**. A session key compromised on the dApp's frontend (XSS, malicious extension) is functionally equivalent to a key compromise on the user side.

## Pitfall 4: social recovery edge cases

Social recovery (a set of guardians who can collectively rotate the master key) is a powerful UX feature with real security trade-offs.

What to audit:

- **Guardian onboarding**. Are guardians verified out-of-band, or can they be added by the wallet owner alone (which collapses social recovery to the original key)?
- **Guardian compromise**. If a single guardian is compromised, what is the impact? Threshold + timelock is the standard answer.
- **Race conditions**. Recovery flows that involve a timelock plus a guardian quorum can have race conditions where a guardian is added or removed during a recovery in flight.
- **Recovery abuse**. Some implementations let guardians initiate recovery without the owner's consent. With enough guardian collusion, this *is* the master key.

## Pitfall 5: ERC-7702 transient delegation

ERC-7702 (live since Pectra) lets an EOA temporarily delegate to a smart-contract wallet for a single transaction. It is a powerful UX win, bringing AA features to existing EOAs without migration. It is also new attack surface.

What to audit:

- **Delegated code**. The contract being delegated to runs with the EOA's authority. If it has any "drain to caller" function, the EOA is now drainable by anyone who can trigger it.
- **Delegation revocation**. EIP-7702 delegations are persistent until explicitly revoked. A user who delegates once and never revokes is permanently subject to the delegated contract's logic.
- **Phishing surface**. The phishing attack of 2026 is "sign this innocent-looking 7702 delegation": the resulting delegation grants the malicious contract permanent control until revoked.

## What a credible AA audit covers

An audit of an ERC-4337 / 7702 stack should explicitly answer:

1. Does the wallet's `validateUserOp` comply with the ERC-4337 storage and call restrictions?
2. Does the paymaster (if present) have per-sender rate limits and bounded validation cost?
3. Are session keys' scope expressions correctly ABI-decoded and bounded?
4. Are recovery paths timelocked, threshold-gated, and revocation-tested?
5. (For 7702) is the delegated contract's interface deliberately minimal and replay-protected?
6. Are there any "fast paths" (admin functions, emergency pauses) that bypass the intended trust model?

## Building production AA

Account abstraction is genuinely good for UX. The security bar is also higher than EOA-controlled wallets, because the wallet *is* a smart contract and bugs in it carry the same consequences as bugs in any DeFi contract.

If you are shipping AA infrastructure (a wallet provider, a paymaster, a session-key system), the [smart contract audit](/services/smart-contract-audit) should be scoped explicitly to the AA risks above, not just the wallet's "core" logic. The interesting attack paths in 2026 are the ones the spec doesn't forbid but the implementation gets wrong.

---

# L2 and Rollup Security: New Attack Surfaces for DeFi in 2026

Source: https://www.blockchainsexperts.io/en/blog/l2-rollup-security-defi
Published: 2026-05-07
Updated: 2026-05-07

By 2026, most new [DeFi protocols](/for/defi-protocols) launch on an L2 first and bridge to mainnet later, if at all. The cost-of-block-space economics make this rational. The security trade-offs are still under-discussed. This piece walks through the attack surfaces that are *new* on L2 (the ones that don't apply to a mainnet deployment of the same code) and what to look for in a [smart contract audit](/services/smart-contract-audit) that targets a rollup deployment.

## The L2 security delta

A smart contract deployed on mainnet inherits Ethereum's full security: about 1 million validators, finality after ~12 minutes, and roughly 18 GW of inelastic capital securing the chain. The same contract on an L2 inherits a much smaller, narrower trust set. Specifically:

1. **The sequencer**. Almost every production rollup in 2026 has a single sequencer, run by the rollup's parent company. That sequencer can re-order, censor, or delay transactions for as long as the rollup's "force inclusion" window allows.
2. **The proof system**. Optimistic rollups depend on at least one honest watcher submitting fraud proofs within the challenge window. ZK rollups depend on the soundness of their verifier and the trusted setup (when applicable).
3. **The bridge**. Every L2 has a canonical [bridge](/glossary/bridge) to mainnet. The bridge contract on L1 holds the entire L2 TVL. If it is compromised, every protocol on the L2 loses everything custodied at L1, regardless of the L2's own security.
4. **The data availability layer**. If transaction data is unavailable, users cannot reconstruct state to challenge fraud or exit. The DA layer (whether the L1, a separate DA chain, or off-chain committees) is a hard dependency.

These are not theoretical. Several 2024–2025 incidents stemmed from one of those four surfaces. The audit that ignores them treats the L2 deployment as if it were L1.

## What changes in the audit scope

For a DeFi contract deploying on an optimistic rollup:

- **Sequencer-level MEV**. The sequencer can extract value the same way miners did pre-Flashbots. If your protocol pricing is sensitive to ordering, model what a malicious sequencer can do.
- **L1 force-inclusion path**. Users can force-include transactions on L1 if the L2 sequencer censors them. Verify your contract behaves correctly when called via that path, including signature validation and gas accounting.
- **Cross-domain message replay**. L1↔L2 messages are passed through canonical messengers. Make sure messages have nonces, can't be replayed, and degrade gracefully if the messenger is paused.
- **Reorg sensitivity**. Optimistic rollups have a long challenge window. State that looks final at the L2 RPC may still be challenged. Cross-chain message consumers should treat L2 finality with appropriate delay.

For a ZK rollup deployment, replace the fraud-proof analysis with verifier soundness: trust the math, but verify the verifier is the audited one and that no upgrade can swap it without timelock.

## Bridge risk: the silent killer

Bridges hold more value than the protocols deployed on them. The 2022 Ronin and Nomad incidents drained over $800M combined. Bridge audits get a small fraction of the attention DeFi protocol audits get, despite carrying disproportionate risk.

Practical implications for a DeFi team deploying on an L2:

- **Don't aggregate canonical bridge risk**. If your protocol holds USDC on Arbitrum, you are exposed to the USDC bridge risk *and* the canonical Arbitrum bridge risk. Both are systemic events.
- **Native vs bridged assets**. Native USDC (Circle's CCTP path) reduces bridge risk vs bridged USDC.e. Use native where available.
- **Multi-bridge exposure**. If your protocol's TVL flows through multiple bridges (LayerZero, Wormhole, Across), each adds attack surface. Document and bound it.
- **Bridge pause behaviour**. Audit how your protocol behaves when a bridge is paused. Stuck withdrawals can become solvency events.

## Sequencer centralisation: realism over ideology

The "decentralised sequencer" roadmap is real but slow. As of 2026, the production sequencer reality is:

- Most rollups still have a single sequencer.
- Some have committee-based sequencing (still small N).
- A handful are running shared sequencers (Espresso, Astria) in production.
- True permissionless sequencing remains rare.

Your audit should model what a malicious or compromised sequencer can do, even if the rollup roadmap promises decentralisation later. The audit window is the present.

## ZK rollups: soundness vs liveness

ZK rollups split risk differently. The validity proof eliminates the need for fraud proofs and challenge windows; finality at L1 is fast. But:

- **Verifier soundness**. The L1 verifier contract is the trust anchor. Bugs in the verifier compromise the whole rollup. Recent verifier vulnerabilities have been found in production code: audit it as carefully as the protocol logic.
- **Trusted setup**. zkSNARK-based rollups depend on a trusted setup ceremony. Compromised setup means forged proofs.
- **Prover liveness**. If no prover submits a valid proof, withdrawals stall. The escape hatch (withdrawing without the prover via direct L1 interaction) must work or the rollup is partially custodial.
- **Circuit complexity**. The arithmetic circuit that proves L2 execution is itself a piece of software. Bugs at that layer are harder to find than Solidity bugs and have full-state implications.

## Data availability: the new attack vector

DA-as-a-service (Celestia, EigenDA, Avail) is reshaping the cost structure of L2s. It also reshapes the security model:

- A rollup that posts data to its own DA layer is only as secure as that DA layer's economic security.
- Data unavailability blocks fraud proofs and exits, even if execution is correct.
- The DA layer's own consensus mechanism is part of your protocol's threat model.

For a DeFi protocol on a "modular" L2 (execution + DA on different layers), the audit needs to model DA failure modes explicitly.

## Practical audit checklist for an L2 deployment

In addition to the standard [smart contract audit](/services/smart-contract-audit) checklist, an L2-deployed protocol audit should answer:

1. Which bridge does liquidity flow through, and what is the bridge's failure mode?
2. What does the protocol do during a sequencer outage of >24 hours?
3. What does the protocol do during a sequencer-driven censorship attack?
4. Is the L1 force-inclusion path tested in the contract's signature / nonce handling?
5. Does the protocol assume L2 RPC finality, or treat it as conditional?
6. Are cross-chain messages idempotent and replay-protected?
7. What is the protocol's behaviour during a multi-day bridge pause?
8. (For ZK rollups) is the verifier address upgradeable? Through what process?

If your audit didn't ask those questions, you didn't get an L2-aware audit. You got a mainnet audit that happens to deploy somewhere else.

---

# Smart Contract Audit Cost: A 2026 Pricing Guide

Source: https://www.blockchainsexperts.io/en/blog/smart-contract-audit-cost-2026
Published: 2026-04-29
Updated: 2026-04-29

The single most common question we get on a first call is some version of *"how much does a [smart contract audit](/services/smart-contract-audit) cost?"*. The honest answer is **from $5,000 for a small, well-scoped engagement up to $80,000 or more for larger or novel protocols**, and the variance inside that range is mostly explainable. This piece walks through how serious audit firms price, why the cheap quote is rarely cheap, and how to scope your own engagement so the number you get back is the number you pay.

## The pricing axes that matter

A senior auditor who quotes you in five minutes is either running on intuition or selling you a templated number. The real scoping looks at five axes:

1. **Lines of in-scope Solidity / Vyper / Cairo.** Not total lines, *in-scope* lines. A 4,000-LOC repo where you only ship 800 lines of new code re-prices accordingly.
2. **Novelty of the design.** A vault that wraps a known yield strategy is faster to audit than a custom AMM with a novel curve. Novelty means the auditor can't lean on prior pattern-matching.
3. **External integration count.** Every external contract your code calls into is a new threat surface. Oracles, bridges, lending markets, governance: each adds review time.
4. **Upgrade and access-control complexity.** Proxies, timelocks, governance modules, and privileged roles compound review effort. A single owner-only function is trivial; a 12-role permissioned protocol with conditional access is not.
5. **Re-audit scope.** Most audits include one re-audit after fixes. Multiple rounds, or fixes that touch wide surfaces, can extend the engagement.

When we send a fixed-fee proposal, those five inputs are visible in the math. There are no hourly surprises later.

## Where the price lives

Rough 2026 ranges we see in the market for credible firms:

- **$5k–$15k**: Low end. Almost always a small scope (single contract, well-understood pattern), or a junior-led tool-driven review marketed as an audit. Useful as a sanity check, not as the audit you stake mainnet on.
- **$15k–$40k**: The typical mid-market range. Senior-led, 2–3 weeks, full report, re-audit. Most DeFi vaults, NFT mints, and small protocols sit here.
- **$40k–$80k**: Larger or more novel protocols. Multiple auditors, longer engagement, deeper threat modeling.
- **$80k+**: Lending markets, perpetuals, large governance systems, novel cryptography. Multi-week, multi-auditor, often paired with a public competition (Code4rena, Sherlock) and a [bug bounty](/glossary/bug-bounty).

Numbers below the floor of those ranges should make you pause. The cost of a missed [reentrancy](/glossary/reentrancy), [oracle manipulation](/glossary/oracle-manipulation), or [access control](/glossary/access-control) bug is the protocol's TVL, not the price difference between two auditors.

## Why the cheap quote is rarely cheap

Three patterns we see in cut-rate quotes:

1. **Tool-driven "audits".** A Slither + Mythril run is a starting point, not a deliverable. Senior auditors use the same tools, but the value they add is reading every in-scope line manually with the protocol's economic logic in mind. If the report you receive looks like a tool dump, you bought a tool dump.
2. **Junior-only staffing.** Audit reports have author lines. If the people listed are all junior, the firm priced for junior throughput. Senior eyes catch the patterns that pattern-matching tools cannot.
3. **No re-audit.** The audit you ship is the *post-fix* audit, not the initial-finding audit. If the engagement doesn't include re-auditing the changed code, you are publishing findings against a state that no longer exists, and shipping a delta that nobody reviewed.

The [smart contract audit checklist](/blog/smart-contract-audit-checklist-defi) we wrote walks through what a credible scope statement looks like, useful to compare against any incoming proposal.

## What to ask before you sign

Three concrete questions to put to any auditing firm:

1. *Show me a recent report you wrote on a similar protocol.* The report is the deliverable. Read the writing quality, the depth of finding descriptions, and the post-fix re-audit section.
2. *Who specifically will work on this engagement?* Senior auditors are the value. Junior staff plus tooling is not what you are paying for.
3. *What is included beyond the initial review?* Re-audit scope, public summary you can publish, communication during the engagement, post-engagement support: confirm in writing.

## Compliance pentest is priced differently

If you need a [Web3 penetration test](/services/penetration-testing) for **MiCA, DORA, or PSAN compliance**, the pricing logic shifts. The deliverable is not just findings: it is a documented methodology, an attestation letter your supervisor (AMF, ACPR, or local NCA) can rely on, and a defensible re-test cadence. That bumps the engagement scope by 20–40% over a standard pentest of the same surface, but it replaces a separate compliance workstream that would otherwise cost you weeks of internal effort.

## Scoping your own engagement

When you reach out, the information that lets us send a fixed-fee proposal in 24–48 hours is:

- A **commit hash** and a list of in-scope contracts.
- The **chain(s)** and a brief design doc or whitepaper.
- A list of **external dependencies** (oracles, bridges, other protocols).
- Your **target launch date** and any regulatory deadline.

If you have those, [book a scoping call](/pricing) and we can give you a number, in writing, the same week.

## What this isn't

This is a guide, not a price list. Every protocol is different, and the cheapest credible audit for your protocol may be at the high end of the typical range or below it depending on the five axes above. The point of writing this piece is to show that the number is not arbitrary, and that any auditor who refuses to walk through the math with you should not be running adversarial review on your code.

---

# MiCA Pentest Requirements: A Compliance Guide for CASPs

Source: https://www.blockchainsexperts.io/en/blog/mica-pentest-requirements-casp
Published: 2026-04-28
Updated: 2026-04-28

The phrase *"MiCA pentest requirements"* shows up in roughly half of our scoping calls with [crypto exchanges](/for/crypto-exchanges), custodians, and stablecoin issuers preparing for European authorisation. The honest summary: MiCA itself does not write the pentest playbook. It relies on the broader EU ICT-risk framework, anchored by [DORA](/glossary/dora), with the [PSAN](/glossary/psan) regime in France adding ANSSI-aligned specifics. This piece walks through what that actually looks like in practice.

## Where the requirement lives

There is no single MiCA article that says *"run a pentest."* The compliance bar is built from three overlapping sources:

1. **[MiCA](/glossary/mica) Article 9** and the related Level-2 / Level-3 measures: CASPs must maintain "robust" ICT systems, business continuity arrangements, and tested incident response. The detail is left to DORA.
2. **DORA Articles 24–27**: this is where the testing programme is defined.
   - *Article 24*: ICT risk-based testing programme covering all relevant ICT systems and applications.
   - *Article 25*: **vulnerability assessments and pentests** at least annually on systems deemed relevant to the firm's risk profile.
   - *Article 26*: **threat-led penetration testing (TLPT)** for entities classified as significant, every three years, following a TIBER-EU-aligned methodology.
   - *Article 27*: requirements for the testers themselves (independence, certifications, methodology documentation).
3. **National regimes** (France's PSAN, Germany's BaFin, others): these layer additional national-supervisor expectations on top of MiCA + DORA. In France in particular, the AMF aligns with **ANSSI** technical guidance for PSAN-approved firms.

The practical effect: every CASP under MiCA needs an annual pentest cadence, with documented methodology and an attestation usable by their national competent authority. Significant entities additionally need TLPT every three years.

## "Vulnerability assessment" vs "TLPT": what each means

These are not the same exercise, and they are not interchangeable in the eyes of supervisors.

A **vulnerability assessment** under DORA Article 25 is closer to what most teams already call a pentest: scoped, time-boxed, looking for exploitable weaknesses across in-scope systems. Methodology is documented; findings are ranked; remediation is tracked.

A **threat-led penetration test** (TLPT) under Article 26 is a different beast. It is intelligence-led, simulating the tactics of a specific threat actor against a wider scope of production systems, often with red-team and purple-team components. It is more expensive (often 5–10× a standard pentest), takes longer (months, not weeks), and follows the TIBER-EU framework if the firm operates in jurisdictions that adopted it.

Most CASPs are not classified as "significant" entities and will only need vulnerability assessments. Significant CASPs (the largest exchanges and stablecoin issuers) need both.

## What your supervisor expects to see

A CASP's compliance file for ICT testing should contain:

- **A documented testing programme**: scope, frequency, methodology, ownership.
- **Most recent vulnerability assessment / pentest report**: scope statement, methodology, findings ranked by severity, remediation status, re-test results.
- **An attestation letter** from the testing provider: independence statement, qualifications of the lead tester, dates, executive summary.
- **A risk treatment plan**: which findings were accepted as residual risk, with sign-off at the right governance level.
- **Evidence of remediation**: tickets closed, fixes deployed, re-tests passed.
- **For TLPT-bound entities**: the threat intelligence brief, the test plan validated with the supervisor, the post-test debrief.

The mistake most teams make is treating the pentest as the deliverable and the file as administrative housekeeping. From the supervisor's perspective, the file *is* the deliverable. A great pentest with a missing attestation letter looks weaker than an average pentest with a clean file.

## How often, and on what scope

MiCA + DORA expects:

- **At least annually** for vulnerability assessments on relevant systems. "Relevant" means anything customer-facing, anything in the trade execution path, custody systems, signing infrastructure, admin panels, and the supporting cloud / network infrastructure.
- **After every material change**: a new chain integration, a new custody architecture, a major API revision, an acquisition. "Material" is interpreted by your supervisor: when in doubt, scope a targeted re-test.
- **Every three years** for TLPT, for significant entities.

In practice, a credible cadence for a typical PSAN-approved exchange looks like:

- Annual full-scope pentest of platform + APIs + custody-adjacent infrastructure.
- Targeted re-tests after each major release.
- Continuous [wallet surveillance](/services/wallet-surveillance) on operational and custody addresses (not strictly mandated by MiCA, but the kind of evidence supervisors increasingly expect).
- A documented [incident response](/services/incident-response) plan with tested escalation paths.

## What this costs

Compliance pentests are priced higher than a standard pentest of the same surface. The premium pays for:

- Methodology documentation aligned with DORA Article 25 / 26.
- The attestation letter and the supporting evidence package.
- Post-engagement support during supervisor review (responding to follow-up questions, re-running specific tests).
- Independence from the firm's existing security vendors.

For a typical PSAN-registered exchange, expect $30k–$80k for an annual compliance pentest, depending on platform complexity. Significant entities running TLPT should budget $150k–$500k+ per cycle.

## Why this matters beyond compliance

The teams we work with that treat MiCA pentest as box-ticking get the worst of both worlds: a meaningful security spend that doesn't actually improve their security posture. The teams that scope the engagement *as a real pentest first*, packaged with the compliance documentation second, get genuinely safer systems and a defensible file. The marginal cost of doing it right is small; the cost of doing it wrong is finding out at the same time as your regulator.

If you are scoping a [pentest for MiCA, DORA or PSAN compliance](/services/penetration-testing), [book a scoping call](/pricing) and we can walk through the file you'll need before any testing starts.

---

# DORA TLPT: What Threat-Led Penetration Testing Actually Looks Like

Source: https://www.blockchainsexperts.io/en/blog/dora-tlpt-explained
Published: 2026-04-27
Updated: 2026-04-27

If you operate a financial entity in the EU classified as "significant" under [DORA](/glossary/dora) (that includes the largest [crypto exchanges](/for/crypto-exchanges), stablecoin issuers, and qualifying custodians), you are in scope for **threat-led penetration testing (TLPT)** every three years. This is not a standard [Web3 pentest](/services/penetration-testing) with a different name. The methodology, the scope, the budget, and the supervisor involvement are different. This piece walks through what TLPT actually looks like.

## What DORA Article 26 requires

The text of Article 26 establishes TLPT as a periodic obligation for significant entities. The implementing technical standards (RTS) align it with **TIBER-EU**, the EU's existing framework for intelligence-led red-team testing of financial market infrastructure, originally developed by the ECB.

The headline requirements:

1. **Threat intelligence-led**: tests must simulate the tactics, techniques, and procedures (TTPs) of a specific threat actor that is realistically capable of targeting your firm.
2. **Live production systems**: TLPT runs against production, not staging. The scope includes critical functions and supporting ICT systems.
3. **Independent testers**: testers must meet certification, independence, and methodology requirements (Article 27).
4. **Supervisor involvement**: the test plan is shared with the supervisor; sometimes a "white team" within the firm coordinates with the supervisor and the testers.
5. **Three-year cadence**: the cycle repeats, with the threat intelligence refreshed each round.

## How TLPT differs from a standard pentest

A standard [Web3 penetration test](/services/penetration-testing) is scoped, time-boxed, and looking for exploitable findings across an in-scope surface (a dApp, an API, a node, a custody system). The deliverable is a findings report.

TLPT is a different exercise:

- **Scope is the firm's critical functions, not a list of systems.** The testers map which systems support those functions and decide where to focus.
- **The starting point is threat intelligence**, not a system inventory. A TI provider produces a brief on the actors plausibly targeting the firm, their typical TTPs, and the likely entry vectors. The red team then plays one of those actors.
- **Detection is part of the test.** The blue team (your security operations) is not informed in advance: TLPT measures both the resilience of systems and the detection-and-response capability of the SOC.
- **The deliverable is a debrief, not just findings.** A purple-team session reconstructs the attack chain, what was detected, what wasn't, and what the response looked like end-to-end.

In practice, TLPT for a large CASP can run 6–12 months end-to-end (threat intelligence + planning + execution + debrief). The execution phase alone is typically 12–16 weeks.

## What gets tested

TLPT scope is decided at the firm level, but for a typical CASP it includes:

- **Customer-facing platforms** (web, mobile, API).
- **Trading infrastructure** (order matching, market data, FIX gateways).
- **Custody and signing infrastructure** (KMS, HSM, signer infrastructure, hot/cold/warm wallet boundaries).
- **Supporting cloud and identity infrastructure** (IAM, secret management, CI/CD, internal tooling).
- **Operational human surfaces** (phishing of operations and engineering teams, supplier supply chain).

The point is not to run a vulnerability scan over each: vulnerability assessments under [DORA](/glossary/dora) Article 25 already cover that. TLPT is about whether a determined adversary can chain access across all of those surfaces to reach a high-value objective.

## What an engagement looks like

A TIBER-EU-aligned TLPT engagement has five phases:

1. **Preparation** (4–8 weeks): supervisor engagement, white-team setup, scope definition, contractual scaffolding.
2. **Threat intelligence** (4–6 weeks): a TI provider produces the targeting brief (which actors, which TTPs, which crown jewels) that drives the test plan.
3. **Red-team execution** (12–16 weeks): the red team operates against production, with the white team coordinating and the supervisor informed of major events.
4. **Closure** (2–4 weeks): findings are written up, the attack chain is reconstructed.
5. **Purple team and remediation** (ongoing): the red team and the blue team review the engagement together, gaps are tracked, remediation is planned.

## Budget realities

TLPT is the most expensive testing exercise in any financial firm's calendar. Budget realities:

- A small TIBER-style TLPT for a regional bank typically lands at €200k–€500k all-in.
- A large CASP TLPT can exceed €1M when the threat intelligence, red team, and white-team coordination are all priced.
- Costs scale with scope (number of critical functions in scope) and duration.
- The cost is not optional for in-scope entities: it is a regulatory requirement under DORA.

## What to start now if you'll be in scope

If your firm is heading toward "significant" classification under DORA (large balance sheet, large user base, large custody exposure, or designation by your supervisor), start preparing now. Specifically:

- **Establish a white team.** A small group inside the firm that knows the TLPT is happening and coordinates with the testers and the supervisor. Without it, TLPT cannot run.
- **Document your critical functions.** TLPT scope is built from this; if it doesn't exist, the test plan is a guessing game.
- **Run pre-TLPT vulnerability assessments.** Under DORA Article 25 you owe these annually anyway. Doing them well dramatically improves your TLPT outcome: most TLPT findings start as un-remediated vulnerability assessment findings.
- **Build the detection capability.** TLPT measures detection. A TLPT against a SOC that doesn't detect anything generates the same findings every cycle.

For most CASPs, the journey from "we're under MiCA" to "we passed our first TLPT" is 18–24 months. If you are scoping that path, a [pentest engagement](/services/penetration-testing) on the production surface is the natural starting point, both because DORA Article 25 mandates it, and because it is the first place TLPT findings will surface in three years' time.

---

# Rug Pull Detection: A Guide to On-Chain Red Flags

Source: https://www.blockchainsexperts.io/en/blog/rug-pull-detection-on-chain-red-flags
Published: 2026-04-25
Updated: 2026-04-25

Rug pulls are not random misfortune. They are designed in. The contract is written so that the team can drain the protocol, and on-chain you can almost always see it before the rug happens, if you know where to look. This piece walks through the [rug-pull](/glossary/rug-pull) red flags we check on every due-diligence engagement, and the heuristics retail can apply with a block explorer and 15 minutes.

## What "rug pull" means in practice

The term is used loosely. The useful taxonomy:

- **Hard rug**: the contract has explicit functions that let the deployer drain liquidity, mint unlimited tokens, or block selling. The exit was coded in. This is what most people mean by "rug pull."
- **Soft rug**: the team abandons the project after raising capital. Less malicious, but the holders are still left with an unsupported token.
- **Slow rug**: the team gradually sells holdings, pulls liquidity in tranches, and stops shipping. The price death spirals. Hard to distinguish from organic failure.

This piece focuses on hard rugs, the ones where the contract itself is the smoking gun.

## Red flag 1: privileged mint functions

The single biggest hard-rug pattern: an `onlyOwner` (or equivalent) function that can mint arbitrary token amounts, with no cap. Sometimes labeled `mint`, sometimes hidden as `claimRewards`, `airdrop`, or `setBalance`.

What to check on a token contract:

- Is `totalSupply` capped, or can the owner mint more? Look for a `MAX_SUPPLY` constant or equivalent.
- Are mint-capable roles transferable? An `onlyOwner` mint where ownership is renounced to `address(0)` is far safer than one where ownership sits in an EOA.
- Is there a timelock? `onlyOwner` with a 30-second delay is functionally `onlyOwner` with no delay.

A clean token has either no mint function after deployment (fixed supply), or a mint function gated by a timelocked multi-sig with a published policy.

## Red flag 2: liquidity that can be pulled

The classic rug: the team supplies all the liquidity to the AMM pool, then pulls it. To check:

- **Liquidity holder concentration**: who holds the LP tokens? If a single address (especially the deployer) holds >50%, they can drain.
- **Liquidity lock**: legitimate projects lock LP tokens with a verifiable lock contract (Unicrypt, Team.Finance) for a stated duration. The lock is a public address you can verify directly.
- **Lock duration**: a 30-day lock is not a lock. Real projects lock for 1+ years.
- **Multiple pools**: if liquidity is spread across multiple pairs (token/ETH, token/USDC, token/WBTC), pulling all of them simultaneously is harder to mask.

For a token claiming "liquidity is locked", verify the lock contract holds the LP tokens, the duration matches the claim, and the unlock date is real.

## Red flag 3: blacklist and pause functions that block selling

A favourite rug pattern is a token contract that can pause transfers or blacklist addresses: used legitimately by the team to "block bots" pre-launch, used maliciously to block holders from selling once the price has been pumped.

What to check:

- `pause()` / `unpause()` functions controlled by an EOA or fast-acting role.
- `blacklist(address)` functions that prevent a specific address from transferring.
- Transfer logic that includes conditional reverts based on owner-set state.

A clean token either has no pause function (after launch), or has it gated by a timelocked governance process with documented use cases.

## Red flag 4: malicious upgrade paths

For upgradeable contracts (proxies), the upgrade path *is* the contract. The current implementation can be replaced with a malicious one in a single transaction.

What to check:

- Who can upgrade? An EOA-controlled proxy is a rug waiting to happen.
- Is there a timelock on upgrades? 24-48 hours minimum gives users time to exit.
- Has the proxy admin renounced control? Sometimes shown as "ownership renounced": verify the admin slot, not just the implementation's `owner()`.
- Are upgrade events publicly tracked? Legitimate projects publicise upgrade proposals.

Upgradeability is not inherently bad. It allows bug fixes and feature evolution. But upgrade-control concentration is the single most common path from "audited contract" to "drained protocol".

## Red flag 5: missing or shallow audits

A "[smart contract audit](/services/smart-contract-audit) report" that:

- Lists only auto-tool output (Slither, Mythril dump).
- Has no scope statement.
- Doesn't name specific auditors.
- Was performed weeks before launch with no time for fixes.
- Has no re-audit section.

…is closer to a marketing checkbox than a security artifact. Our [guide on reading audit reports](/blog/reading-smart-contract-audit-report) walks through what credible reports actually contain.

The presence of an audit is not safety. The absence of one is a red flag, but a thin audit can be worse than none. It provides false confidence to retail.

## Red flag 6: token holder concentration

A glance at the holder distribution tells you a lot:

- Top 10 holders should not control >50% of supply.
- The deployer wallet should be either renounced or hold a small allocation.
- "Marketing" or "treasury" wallets concentrated under EOAs are a slow-rug risk.
- Vesting contracts holding team allocation are good: verify the vesting contract, the cliff, and the duration are real.

Etherscan's "Holders" tab on any ERC-20 gives you this in 30 seconds.

## Red flag 7: source code mismatch

Verify on the block explorer that the deployed contract is **verified** (source published) and matches what was audited. Common patterns:

- Contract is unverified: you have no idea what's running.
- Contract is verified but the source diverges from the audit's commit hash.
- Multiple proxy targets exist; the audit covered one but not the current one.

Etherscan / Routescan / equivalent block explorers show "Contract Source Code Verified" on the contract page. If it's missing, the project chose to ship opaque bytecode. That choice has implications.

## What the on-chain trace looks like after a rug

For completeness, the post-rug pattern is consistent:

1. Liquidity is removed in a single transaction (or a small burst).
2. Token is dumped into the residual pool.
3. Funds are moved through a mixer (Tornado, eXch) or bridged to a different chain.
4. The deployer's social accounts go dark, sometimes deleted.
5. A new "team" emerges weeks later under a new project name with the same wallet patterns.

This is where [incident response and on-chain forensics](/services/incident-response) comes in: tracing the funds across mixers and bridges, coordinating with off-ramps, and producing the documentation that enables recovery weeks or months later.

## When to engage professional due diligence

For institutional capital allocators, individual checking isn't enough. A formal pre-investment due diligence on a [DeFi protocol](/for/defi-protocols) covers all of the above plus:

- Code review of in-scope contracts.
- On-chain analysis of related deployer wallets and prior projects.
- Team background verification.
- Liquidity sustainability modeling.

If you are deploying meaningful capital into a DeFi position, [a scoped due diligence engagement](/pricing) is cheap insurance compared to the position size.

---

# Smart Contract Audit Checklist for DeFi Protocols

Source: https://www.blockchainsexperts.io/en/blog/smart-contract-audit-checklist-defi
Published: 2026-04-15
Updated: 2026-04-15

A clean audit report does not mean your protocol is safe. It means a specific firm, in a specific window of time, examined a specific scope of code. The gap between "audited" and "safe" is where most exploits live.

This is the checklist we use internally when we run a [Smart Contract Audit](/services/smart-contract-audit), and the one we recommend protocol teams use when evaluating any auditor's proposal, ours included.

## 1. Scope is written down before any code is read

The single most important sentence in any audit report is the scope statement. Read it first. It tells you which contracts, which functions, which commit hash, and which assumptions were in scope.

A scope that excludes the deployment process, the upgrade path, the initialization logic, or integration with external protocols is a scope that misses where exploits actually happen. If your auditor's scope statement is one paragraph, that's a problem.

## 2. Manual review is the deliverable, not the tooling

Slither, Mythril, and Foundry tests are baseline. Any auditor showing you a tool report as the deliverable is selling you a cheaper version of something you can run yourself.

The work you are paying for is **senior auditors reading every line of in-scope code**, with the protocol's economic logic in mind, hunting for the patterns that pattern-matching tools cannot find: [oracle assumptions](/glossary/oracle-manipulation), [reentrancy](/glossary/reentrancy) across function boundaries, broken [access control](/glossary/access-control), upgrade-path risks.

## 3. Threat modeling happens before line-by-line review

A serious audit starts with one or two days of *not reading code*. The auditors model:

- What does the protocol do, in plain language?
- Who would attack it, and what would they target first?
- What are the highest-value invariants that, if broken, drain the protocol?
- What dependencies (oracles, bridges, other protocols) does it inherit risk from?

That model then directs the line-by-line review. Without it, the review becomes generic and misses the protocol-specific risks.

## 4. Invariant tests are written, not just run

Foundry invariants and Echidna properties are how you prove the contract behaves as designed under conditions humans cannot enumerate. The auditor should be writing new properties, not just running yours.

Specifically, ask: *what invariants did you write that we didn't have?* That answer separates a real audit from a checkbox audit.

## 5. [Flash loan](/glossary/flash-loan) conditions are tested explicitly

Almost every major DeFi exploit since 2020 used flash loans to amplify a smaller vulnerability. The audit should explicitly test:

- Can a single-block sequence drain any function?
- Does any pricing logic depend on spot prices that flash loans can move?
- Is the [TWAP](/glossary/twap) window long enough that a single block cannot manipulate it?
- Are state changes from the same address within a block bounded?

If the auditor cannot tell you they specifically tested under flash-loan conditions, the audit is incomplete.

## 6. The upgrade path is in scope

Most audited contracts are upgradeable. Most upgrade paths have their own privileged contracts (proxies, timelocks, governance). A bug in the upgrade path bypasses the audit of the implementation contract.

Verify: who can upgrade, on what timelock, with what protections, and is the multisig that controls upgrades reviewed as part of the audit?

## 7. Privileged roles are enumerated and held by the right addresses

For every privileged function, the report should answer: *which address can call this, and what kind of address is that?* An EOA holding `onlyOwner` on a treasury contract is a finding. A 2-of-3 multisig with all signers on the same hardware vendor is a finding. A timelock with a 30-second delay is a finding.

We cover this in depth on the [Wallet Setup](/services/wallet-setup) engagement, which often runs in parallel with the contract audit.

## 8. Re-audit after fixes is in the contract

The audit you ship is the post-fix audit, not the initial-finding audit. Make sure the engagement includes a re-audit of the changed code, not just an issue-by-issue patch review. Patches frequently introduce new bugs.

## 9. Public summary is owned by you

Your community will ask to see the report. Negotiate up front who publishes, in what format, and on what timeline. A good auditor does not block publication after fixes are applied.

## 10. The audit is not the end

Once mainnet is live, the relevant disciplines are [Wallet Surveillance](/services/wallet-surveillance) on treasury and admin keys, an [Incident Response](/services/incident-response) retainer for the moments where the first hour matters, and a [bug bounty](/glossary/bug-bounty) program with payouts proportional to the value at stake.

If you are launching a [DeFi protocol](/for/defi-protocols), all four, audit, surveillance, response, bounty, are baseline. Anything less is hope, not security.

## What to ask before you sign

Three questions to put to any auditing firm before signing:

1. *Show me a recent report you wrote.* Read the writing quality, the depth of finding descriptions, the post-fix re-audit. The report is the deliverable.
2. *Who specifically will work on this engagement?* Senior auditors are the value. Junior staff plus tooling is not what you are paying for.
3. *What are three vulnerabilities you've found in protocols similar to ours?* If they cannot answer with specifics, they have not done this work before.

The protocols that survive their first year are the ones that treated the audit as the start of a security function, not the end of a checklist.

---

# How Approval Phishing Drains Wallets, and How to Stop It

Source: https://www.blockchainsexperts.io/en/blog/approval-phishing-explained
Published: 2026-04-08
Updated: 2026-04-08

Most wallet drains we investigate share a single root cause: the user signed a token approval to a malicious contract, and the attacker drained the assets weeks later.

This pattern has a name, [approval phishing](/glossary/approval-phishing), and it is responsible for a large share of the value lost to crypto scams every year. The good news is that it is preventable, and the prevention does not require new technology. It requires the same discipline that made password managers normal.

## How the attack works

EVM chains have a function called `approve()` (and its NFT cousins). When you call it, you are giving a smart contract the right to move tokens out of your wallet, up to a specified amount, until you revoke the approval.

The mechanic is foundational to DeFi. Every swap on Uniswap, every deposit into Aave, every NFT listing on OpenSea begins with an approval. Without it, the protocol could not move your tokens to do what you asked.

The exploit reuses that mechanic against you:

1. The attacker stands up a phishing site, a fake mint page, a fake airdrop claim, a "verify your wallet" prompt.
2. You connect your wallet. The site immediately requests an approval.
3. The approval looks normal in the browser pop-up.
4. You sign.
5. Hours, days, or weeks later, the attacker calls `transferFrom()` on the approved contract and drains your tokens.

The transaction that drains you is signed by the attacker, not by you. There is no second prompt. By the time your wallet shows the loss, the funds are already in a mixer.

## Why it works

Approval phishing is effective for three reasons:

**The UI hides what's happening.** Most wallet pop-ups display "Approve" with a contract address and a token. The amount is often `2^256 - 1`, "unlimited", but rendered as an opaque hex string. Most users do not parse the difference between "swap 0.1 ETH" and "approve unlimited USDC to 0xA1B2…".

**The damage is delayed.** A swap fails in the same transaction. An approval scam succeeds silently and waits for your wallet balance to be worth taking. By the time a victim notices, they have already forgotten which site they connected to.

**The vector is everywhere.** Every dApp connection is a potential phishing site. A compromised Discord moderator account, a sponsored Google ad, a Twitter post from a hijacked verified account, the attacker only needs one click.

[NFT projects](/for/nft-projects) are particularly exposed because their entire community lives in Discord and on X, where account compromises are routine.

## What does not work

Several common defenses are weaker than they look:

- **"I only sign on official sites."** Official sites are routinely cloned on near-identical domains. Bookmark and verify.
- **"My hardware wallet protects me."** A hardware wallet shows you what you are signing, but only if you read it. Most users press "approve" without reading.
- **"I'll just be careful."** Phishing sites are designed to bypass careful. The whole industry of [wallet drainers](/glossary/wallet-drainer) is professional and well-funded.

## What works

Five practices that, combined, make approval phishing very hard to land on you:

### 1. Separate wallets by role

Treasury, operations, dApp interaction, and personal funds should never be the same address. A drain on the dApp-interaction wallet should leave treasury untouched. We cover the architecture in detail in the [Wallet Setup](/services/wallet-setup) engagement.

For an individual: one cold wallet with the long-term holdings (hardware, never connects to dApps), one hot wallet with no more than a month of working funds, one burner with $50 for trying new mints.

### 2. Use transaction simulation before signing

Wallet add-ons like Pocket Universe, Tally, or built-in simulation in MetaMask and Rabby tell you what a transaction *will actually do* before you sign. They catch the difference between "swap" and "approve unlimited USDT to a random address."

This single habit defeats the majority of approval phishing.

### 3. Read what your hardware wallet shows

The display on a Ledger or Trezor is the source of truth. The dApp UI can lie; the device cannot. If the device says "Approve" and you expected "Swap", reject. Every time.

### 4. Revoke approvals you no longer need

Tools like Revoke.cash list every active approval on your address and let you revoke them in one click. We recommend doing this monthly. Cleared approvals cannot be exploited.

### 5. Use limited allowances when supported

Many wallets and dApps now support setting a specific allowance instead of unlimited. Use it. The convenience cost is a re-approval next time; the security benefit is that a future drain is bounded.

## For protocols and projects

If you operate a protocol or run a project, your users are exposed to this pattern by default, and they will blame you when it happens. Three things to do:

- **Publish the canonical contract addresses your users should approve, prominently.** Make the comparison easy.
- **Educate your community.** A short post explaining approvals, with simulation tool recommendations, costs you nothing and saves users.
- **Watch your project wallets.** [Wallet Surveillance](/services/wallet-surveillance) on the official addresses gives you early warning when an attacker mass-approves through a fake mint, because their drainer contract surfaces in alerts.

## When it has happened

If you discover an old approval to a malicious contract, revoke it before transferring assets in. Drainers monitor approved wallets and trigger immediately on incoming transfers.

If a drain has already happened, an [Incident Response](/services/incident-response) engagement focuses on tracing the funds across mixers and bridges. Recovery is possible in some cases, particularly when off-ramps cooperate, but only when the trace is started within hours, not days.

The pattern is solved. The discipline to apply the solution is not. Build the discipline once and approval phishing becomes a non-event.

---

# Multi-Sig vs MPC: Choosing a Treasury Wallet Architecture

Source: https://www.blockchainsexperts.io/en/blog/multi-sig-vs-mpc-treasury
Published: 2026-04-01
Updated: 2026-04-01

The first question every serious project asks us about treasury custody is the same: [multi-sig](/glossary/multi-sig) or [MPC](/glossary/mpc-wallet)?

The answer is "it depends," but the variables are concrete enough that you can decide without hand-waving. This piece is the framework we use when we run a [Wallet Setup](/services/wallet-setup) engagement.

## What each one is

**Multi-signature wallets** are smart contracts. They require *m of n* signatures from designated signers before a transaction executes. The dominant implementation on EVM chains is [Safe](/glossary/safe). On-chain, the wallet is a smart contract address; everyone can see its signers, threshold, and full transaction history.

**MPC (multi-party computation) wallets** use cryptographic protocols to split a single key into shares held by multiple parties. The shares jointly compute a signature without ever assembling the key in one place. On-chain, the wallet is a normal externally-owned address (EOA); nobody can see how the signing was done.

These are different mechanisms with different failure modes. Choosing between them is choosing between different threat models, not picking the "more secure" option.

## Where multi-sig wins

**On-chain transparency.** Every signer, every threshold change, every transaction is visible on-chain. Auditors, community members, and your own future self can verify the state. For a [DAO treasury](/for/dao-treasuries), this transparency is non-negotiable.

**Smart-contract-native features.** Modules, recovery contracts, time-locked operations, role-based access, transaction simulation in the front-end, Safe's ecosystem is mature.

**Operational legibility.** A 4-of-7 multi-sig with a documented signer list is easier to explain to investors, regulators, and a court than a "threshold MPC scheme with 5 of 9 share-holders."

**Audited at scale.** Safe is the most-used and most-audited multi-sig contract in production. The vulnerabilities affecting Safe-based treasuries are almost never in the contract, they are in operational mistakes, signing UX, or social engineering.

## Where MPC wins

**Chain-agnostic.** MPC produces a normal signature, which means it works on every chain, Bitcoin, Solana, Cosmos chains, Tron, every EVM L2. Multi-sig requires a chain that supports smart contracts, and even then each chain has its own contract version. For [custodians](/for/wallets-custodians) who hold assets on many chains, MPC is operationally cheaper.

**Privacy of signing structure.** The threshold and signers are not visible on-chain. For institutional custody, this is sometimes a feature.

**Rotation without changing the address.** Refreshing key shares does not change the wallet address. This is genuinely useful for institutional operations that issue static deposit addresses to clients.

**Higher signing throughput.** MPC signing is sub-second; multi-sig requires a quorum of signers to interact with the contract over time. For high-frequency operations, MPC is the only practical choice.

## Where both fail

The failure modes that have actually drained treasuries:

**Signers under the same roof.** A 5-of-9 multi-sig where 6 of the signers are employees of the same company in the same office is, effectively, a 1-of-1. Same for MPC shares held on machines on the same network.

**Phished signing.** Both schemes assume the signer reviews what they are signing. In practice, signers approve transactions presented by a UI without simulating them. A malicious dApp gets the same signature as a legitimate one.

**Compromised signing devices.** A laptop with malware can present one transaction to the user and sign another. Hardware wallets defeat this for multi-sig signers; MPC implementations vary in how well they isolate.

**Bad cryptographic implementation.** MPC protocols have shipped real bugs, biased nonces, weak randomness, recovery paths that bypass thresholds. Multi-sig contracts have the same risk in principle, but the dominant implementation (Safe) has been beaten on for years.

**Recovery paths that bypass the threshold.** "Lost device" recovery procedures often have weaker authentication than the threshold itself. An attacker who can claim a lost device can drain the wallet through the back door.

## How to choose

Three questions, in order:

### 1. Do you need on-chain transparency?

If the answer is yes, DAO treasury, public protocol admin, anything where the community needs to verify governance, multi-sig wins. The on-chain audit trail is the feature.

If the answer is no, institutional custody, internal operational wallet, exchange hot wallet, MPC's privacy of structure is acceptable and sometimes preferable.

### 2. How many chains do you operate on?

One chain or one EVM ecosystem: multi-sig.

Many chains, including non-EVM: MPC. The operational overhead of running separate multi-sigs on Bitcoin, Solana, Cosmos, and EVM chains is real and accumulates fast.

### 3. What is your operational tempo?

Slow and deliberate (treasury operations, governance, large rebalances): multi-sig. The friction of getting *m of n* signers to sign is a feature, not a bug.

Fast and high-volume (exchange withdrawals, market-making operations): MPC.

## A pattern that works

For most projects in our experience, the right answer is *both*:

- **Cold treasury and protocol admin: multi-sig**, with hardware-wallet signers, geographically distributed, on a Safe with a transaction-review module and a 24-48h timelock for non-emergency operations.
- **Hot operational wallet: MPC**, with a low cap on outstanding balance, programmatic policies, and tight monitoring.

Each wallet's loss is bounded by what it holds. A drain of the hot wallet is a bad day; the protocol admin and the treasury are untouched.

## What we do

The architecture is a written deliverable. The runbooks for "rotate a compromised key", "onboard a new signer", "execute an emergency pause" are written deliverables. The signer training is a delivered training session. None of it is more secure than what your team can actually operate under pressure, that is what the engagement is designed to make sure of.

Once the architecture is live, [Wallet Surveillance](/services/wallet-surveillance) keeps an eye on every relevant address: queued transactions in the multi-sig, unusual signing patterns from the MPC operational wallet, approvals to unfamiliar contracts. The first 30 minutes of any incident is where the fight is won or lost.

Multi-sig versus MPC is not a religious question. It is an architecture question with a defensible answer for every team, once you write down what you are actually defending and how you intend to operate.

---

# The Anatomy of a DeFi Oracle Manipulation Attack

Source: https://www.blockchainsexperts.io/en/blog/oracle-manipulation-defi-attacks
Published: 2026-03-25
Updated: 2026-03-25

If you read DeFi exploit post-mortems for a year, you start to notice a pattern: most of them say "oracle manipulation" somewhere in the first paragraph. Not reentrancy, not access control, [oracle manipulation](/glossary/oracle-manipulation), executed with a [flash loan](/glossary/flash-loan).

The pattern keeps working because the underlying design mistake, pricing valuable protocol decisions off a single, manipulable on-chain source, keeps shipping in production code. This piece walks through how the attack works, why protocols keep building this way, and the specific design choices that prevent it.

## The attack, end to end

A canonical oracle manipulation attack has four steps:

1. **Borrow.** The attacker takes a flash loan of, say, $100M of WETH. No collateral, no credit check; just a smart-contract function call.
2. **Manipulate.** They use the borrowed capital to swap a large amount through a low-liquidity AMM pool, which the target protocol uses as a price oracle. The pool's reported price moves dramatically.
3. **Exploit.** They interact with the target protocol, borrowing, minting, withdrawing, at the manipulated price. Maybe they borrow $50M against $5M of real collateral, valued at the wrong price by the oracle. Maybe they redeem an LP position priced at the wrong NAV.
4. **Repay.** They repay the flash loan in the same transaction. Net result: they walk away with the target protocol's funds, and the borrowed capital is back where it started.

The whole sequence happens in one block. There is no opportunity for the protocol to react.

## Why it works

The on-chain price of any AMM pair is whatever the next swap can move it to. In a deep, liquid pool, ETH/USDC on Uniswap, billions of dollars of liquidity, moving the price meaningfully costs more than any flash loan can fund. In a low-liquidity pool, a few million dollars can swing the price by 50% or more.

A protocol that prices its operations against a low-liquidity pool is, definitionally, pricing them against a number an attacker can choose for the duration of one transaction.

The original sin is reading spot price from a single AMM and trusting it. The fix is to never do that.

## Why it keeps shipping

In our [Smart Contract Audit](/services/smart-contract-audit) practice, we still find this pattern in new code. It keeps shipping for a few reasons:

**TWAP feels like overkill in development.** Spot price is one line of code; a [TWAP](/glossary/twap) requires accumulator logic, time-window management, and additional gas. In test environments where prices don't move adversarially, the spot price works fine.

**The integration is convenient.** Pulling price from your own AMM means no external dependency, no oracle subscription, no Chainlink integration. It feels like simplicity, but it is coupling.

**The attack is non-obvious without flash loans in the threat model.** A developer who is not actively thinking about flash loans will reason: "an attacker would need to own $100M to move this price; nobody owns $100M; this is fine." The flash-loan threat model breaks that reasoning.

**It works until it doesn't.** Many protocols ship with manipulable oracles, run for months without incident, and accumulate enough TVL that they become worth attacking. Then one day a researcher (or a thief) writes the exploit, and the post-mortem reads "oracle manipulation."

## The specific patterns that prevent it

Three design choices, used together, defeat the attack:

### 1. Use TWAPs, not spot prices

A time-weighted average price computed over a 30-minute (or longer) window cannot be moved by a single block, regardless of the attacker's capital. An attacker who wants to manipulate a 30-minute TWAP has to hold the manipulated price for 30 minutes, exposing themselves to arbitrage from every other actor in the market.

Uniswap v3 exposes a TWAP oracle natively. Use it. The few extra lines of code are the cheapest insurance you will ever buy.

### 2. Use redundant oracle sources

If your protocol's pricing depends on one oracle, your protocol's safety depends on that oracle. Use two: a Chainlink feed plus a TWAP, for example. Require the two to agree within a tolerance before allowing privileged operations to proceed; revert otherwise.

The cost is a bit of complexity in the price-reading function. The benefit is that an attack that compromises one oracle does not drain the protocol.

### 3. Cap protocol exposure to oracle errors

Even with TWAPs and redundant sources, oracle errors happen. A real depeg, a Chainlink feed deviation, a bridge price mismatch. Build the protocol so that worst-case oracle error produces bounded loss, not catastrophic loss.

This means: caps on borrowing per epoch, liquidation discounts that absorb small mispricings, circuit breakers that pause the protocol when oracle deviation exceeds a threshold. The goal is that a 5% oracle error costs you 5%, not 100%.

## What this looks like in code review

When we review a [DeFi protocol](/for/defi-protocols), the price-reading function is one of the first things we look at. The questions we ask:

- Where does this price come from?
- Can a single block move it? Can a flash loan move it?
- What happens if the source returns zero, or a stale value, or a value 100x off the real price?
- Is there a fallback or a sanity check?
- Is the contract using `getReserves()` directly on a Uniswap v2 pair? (If yes, full stop, that's the vulnerability.)

A protocol that has good answers to all of these has thought about its threat model. A protocol that does not is one flash loan away from the front page.

## After mainnet

Even with the design done correctly, the threat model changes when the protocol is live. New AMMs deploy. Liquidity migrates. Bridge representations of your collateral assets appear with different price profiles. The TWAP window that was safe at launch may not be safe at $1B TVL.

[Wallet Surveillance](/services/wallet-surveillance) on the protocol's admin keys and treasury catches the cases where governance is the next attack vector after the contracts are hardened. An [Incident Response](/services/incident-response) retainer makes sure that if the next exploit slips past everything else, the response is measured in minutes, not days.

Oracle manipulation is solved as a class of vulnerability. Every team that gets exploited by it could have not been. Building correctly is cheaper than the post-mortem, by orders of magnitude.

---

# NFT Mint Security: 12 Things to Check Before Launch

Source: https://www.blockchainsexperts.io/en/blog/nft-mint-security-checklist
Published: 2026-03-18
Updated: 2026-03-18

Most NFT incidents we are called for are not contract bugs. They are compromised mod accounts posting phishing links, leaked deployer keys, fake mint URLs in announcements, and webhook leaks. The contract is usually fine; the operation around it is the attack surface.

This is the pre-launch checklist we run with [NFT projects](/for/nft-projects), covering both the contract and the operational layer that tends to get skipped.

## The contract

### 1. The mint logic actually matches the spec

Off-by-one in supply, broken allowlist logic, signature replay across chains, missing access control on `withdraw`, missing pause function, ETH being sent to a hardcoded EOA instead of a [Safe](/glossary/safe). These are common findings in NFT contracts, and they all originate from the same cause: the contract is written in a hurry the week before launch.

A real [smart contract audit](/services/smart-contract-audit) catches them. A friend "having a quick look" rarely does.

### 2. Reentrancy on the mint function

NFT contracts often call back into the receiver via `_safeMint`, which invokes `onERC721Received`. A malicious receiver contract can re-enter the mint function before its supply counter is updated, minting more NFTs than intended in a single call. The fix is the [checks-effects-interactions](/glossary/checks-effects-interactions) pattern: update state before calling external code.

### 3. Allowlist verification cannot be replayed

If you use signed allowlist entries (a common pattern), the signature must be bound to the chain ID and to a per-user nonce. Without that, a signature valid on one network can be replayed on another, or by another wallet.

### 4. The withdraw function is on a multi-sig, not an EOA

The contract collects ETH from minters. The address that can pull that ETH out is the address that controls the mint revenue. If that address is a hot EOA on the deployer's laptop, you have rebuilt the FTX commingled-wallet problem on your own project. Use a [multi-sig](/glossary/multi-sig). Always.

### 5. Royalty configuration is set correctly on every marketplace

ERC-2981 is the standard, but every marketplace handles it differently. Test royalties end-to-end on OpenSea, Blur, Magic Eden, X2Y2, whichever venues your collection will trade on. Misconfigured royalties cost real money over a collection's life.

## The deployment

### 6. The deployer wallet is single-use and clean

The wallet that deploys the contract should not hold funds, should not have history with malicious contracts, and should be retired after deployment. The deployer key is the most-attacked address in your project, leak it once and the attacker has the keys to your contract's privileged functions.

### 7. Privileged roles are transferred immediately

Right after deployment, transfer ownership and any admin roles from the deployer EOA to the [Safe](/glossary/safe). Verify on-chain that the transfer happened and the deployer no longer has privileges. Many incidents we have investigated traced back to "we meant to do that and forgot."

### 8. The contract is verified on Etherscan

Verified source matches the deployed bytecode. Buyers, scanners, and your community can read the actual logic. An unverified contract is a red flag for sophisticated buyers and an open invitation to fake "verified" copies on the same chain.

## The community

### 9. Discord and X are locked down

Most NFT incidents start on Discord. Concrete defenses:

- **2FA enforced for every moderator and admin role.** Not optional. Authenticator app, not SMS.
- **Bot-token permissions audited.** A leaked webhook can post phishing links from inside your server, with the project's branding.
- **Channel permissions reviewed.** Only specific roles should be able to post in announcement channels; only specific bots should be allowed to embed links.
- **Founders' personal accounts hardened separately.** A hijacked founder X account is the highest-value phishing platform in your project's universe.

### 10. The mint URL is canonical and announced

There should be one mint URL, hosted on a domain you control, communicated through every official channel before launch. If your community sees a different URL on launch day, they should be skeptical by default. Repeat the URL in every announcement, and tell holders explicitly: *we will never DM you a different mint link*.

### 11. There is a written incident playbook

Before launch, write down:

- Who in the team has the authority to pause the contract?
- Who posts the official "we are aware" message, and where?
- Who contacts the marketplaces if a stolen item starts moving?
- Who has the [Incident Response](/services/incident-response) firm's emergency number?

The first hour of an incident decides what the next year looks like. A team that has rehearsed recovers; a team that improvises does not.

## Post-launch

### 12. The treasury and creator wallets are surveilled

Post-mint, the project wallet holds the revenue and the unminted reserve. The creator wallets hold the founder allocations. These addresses are on-chain billboards for attackers.

[Wallet Surveillance](/services/wallet-surveillance) on these addresses is real-time alerting on:

- Approvals to unfamiliar contracts.
- Outgoing transfers that diverge from the established pattern.
- Interactions with addresses linked to phishing infrastructure.
- Queued multi-sig proposals before they execute.

The cost is small. The benefit is that the moment a signer's device is compromised, you find out, before the attacker drains.

## The one thing nobody wants to do

Ship the contract three weeks before mint, not three days. The audit needs time. The fixes need re-audit. The deployer process needs a dry run on testnet that mirrors mainnet exactly. The community needs to see the contract, the URL, and the official channels well before the moment of FOMO.

Every project we have helped recover from a botched launch had the same regret: they shipped on the announced date instead of the ready date. Move the date once. Save the project.

---

# Incident Response for DeFi: The First Hour

Source: https://www.blockchainsexperts.io/en/blog/incident-response-defi-first-hour
Published: 2026-03-11
Updated: 2026-03-11

When something goes wrong on-chain, the difference between a recoverable incident and a project-ending one is usually decided in the first hour. The teams that survive have rehearsed; the teams that improvise lose more value to the response than to the original exploit.

This piece is the first-hour playbook we run when we are paged for an [Incident Response](/services/incident-response) engagement. Not every step applies to every incident, but every step exists because we have seen it skipped and regretted.

## Minute 0 to 5: Confirm and contain

The first instinct is always to communicate. The right instinct is to stop the bleeding.

**Confirm the exploit is real, not a false alarm.** A spike in withdrawals can be a panic, not an exploit. A funny-looking transaction can be MEV, not a drain. Look at the on-chain trace. Identify the function being called, the address calling it, and what value is leaving the protocol.

**Pause if you can pause.** Most well-designed protocols have an emergency pause function held by a multi-sig or a guardian. This is the moment it earns its keep. Get the threshold of signers on a call and execute the pause. Every block of delay is more value out the door.

**Revoke if you cannot pause.** If a wallet's been compromised, revoke active token approvals from that wallet, but only after the wallet's remaining assets have been moved to a clean address, because revocations cost gas and a drainer often racing transactions.

If your team does not know who has the authority to pause, who holds the keys, and how fast you can assemble the threshold, you do not yet have an incident response posture. We address that during a [Wallet Setup](/services/wallet-setup) engagement, before the first incident.

## Minute 5 to 15: Assemble the team

A standing list of who you call when an incident happens is worth more than any tool.

**The internal team:**

- Engineering lead (technical assessment).
- Communications lead (drafts the first post).
- Legal counsel (if applicable jurisdiction).
- A board or investor representative (notification, not approval).

**The external team:**

- Your incident-response firm. (If you do not have one on retainer, this is the moment you wish you did. Emergency engagements are accepted when capacity allows but cost more and respond slower.)
- Counsel familiar with crypto-specific incident-response procedures.
- Your auditor (they may have context on the affected contracts).

The list lives in a shared document with phone numbers, not just emails. Email response times are not incident-response times.

## Minute 15 to 30: Trace and document

Two activities run in parallel.

**On-chain forensics:**

- Identify the attacker address(es) and write them down.
- Trace the stolen funds. Where did they go in the first hop? The second?
- Identify whether funds went into Tornado, Railgun, a centralized exchange, a bridge, or a dormant address.
- Note any addresses that were funded by the same source as the attacker, they may be operational accounts of the same actor.

This trace becomes the foundation of any recovery, any law-enforcement engagement, and any insurance claim. Get it right early.

**Internal documentation:**

- Open an incident channel. Restrict access. All decisions go through it.
- Start a timeline. Who did what at what time. This document will be the basis of the post-mortem.
- Take screenshots of the on-chain state at the moment of the incident. State changes after this point.

## Minute 30 to 45: Communicate

The first communication has three properties: it is honest, it is brief, and it does not commit to anything you cannot deliver.

A first post says: *we are aware of an incident affecting [scope]. We have [actions taken]. We are investigating. The protocol is [paused / not paused]. Users should [specific actions, e.g., revoke approvals, do not interact with the front-end]. Updates will be posted here every [X] minutes.*

That is it. No "we are confident", no "no funds are at risk" until you actually know. Bad communication turns a survivable incident into an unsurvivable one, usually because someone said something definitive that turned out to be wrong.

In our [Incident Response](/services/incident-response) engagement we draft these posts, the team approves and publishes. The drafting is tactical; the approving is yours.

## Minute 45 to 60: Reach out

The recovery options outside your protocol now matter.

**Centralized exchanges.** If funds went to a CEX, they may freeze on request, *if* you reach the right person before the attacker withdraws to fiat. Most major exchanges have law-enforcement and security desks; reach them through your incident-response partner if you don't have a direct line.

**Stablecoin issuers.** USDC and USDT can blacklist addresses on request. Tether is faster than Circle in our experience, but both have process. The earlier you reach them, the better the outcome.

**Bridges.** Some bridges have emergency pause capability and are willing to use it. Others do not.

**Mixers and privacy tools.** Once funds enter Tornado Cash or similar, recovery options narrow but do not vanish. The trace remains useful for downstream actions.

**Other protocols affected.** If your incident has spillover risk to other protocols (say, you are the oracle source for someone), notify them. They will return the favor when the situation reverses.

## Hours 1 to 24: Stabilize

Past the first hour, the work shifts:

- A more thorough on-chain trace, often crossing chains and mixers.
- A second public post with confirmed details, what happened, what was lost, what the immediate plan is.
- Engagement with law enforcement, where applicable. The trace document is the input.
- Initial decisions on remediation: hard fork, rollback, treasury reimbursement, governance vote.

These are governance decisions, not technical ones, and they are where projects most often make their reputation in the long run. A protocol that loses 10% of TVL but handles it transparently can recover trust. A protocol that loses 10% of TVL and lies about it does not.

## What you need before the incident

You cannot draft a first-hour playbook in the first hour. You need it written before. The minimum:

- **A pause path** held by a multi-sig with documented signers.
- **A signing rota**, at least one signer awake in every major time zone.
- **An incident contact list**, internal and external, with phone numbers.
- **A drafted "we are aware" template** that just needs the specifics filled in.
- **A retainer with an [incident-response firm](/services/incident-response)** so the trace and the comms support start immediately, not after a sales call.

For [DeFi protocols](/for/defi-protocols), [exchanges](/for/crypto-exchanges), and [DAO treasuries](/for/dao-treasuries), this preparation is part of the cost of operating. It is significantly cheaper than not having it.

## What we do, specifically

When a client pages us:

- Live incident commander on a call within the SLA.
- On-chain forensics running in parallel with the call.
- Drafted communications passed back to your team for approval.
- Coordination with exchanges, custodians, and counsel.
- A written post-mortem at the end, plus an internal lessons-learned document.

The first hour is the hardest. The work after is where the project's reputation is earned back. Both are easier with a team that has done this before.

---

# Bridge Security: Why Cross-Chain Bridges Get Exploited

Source: https://www.blockchainsexperts.io/en/blog/bridge-security-explained
Published: 2026-03-04
Updated: 2026-03-04

Cross-chain [bridges](/glossary/bridge) have lost more money to exploits than any other category of DeFi protocol. Ronin, Wormhole, Nomad, Harmony, Multichain, Poly Network, the list is long, the dollar amounts are enormous, and the underlying causes are repetitive.

This is the explainer we give to teams designing or operating bridges, and to teams whose protocols depend on them. Understanding the architecture is the first step to not being on the next list.

## The fundamental problem

Blockchains cannot natively read each other's state. Ethereum has no idea what just happened on Polygon; Arbitrum has no idea about Bitcoin. So a "bridge" between two chains is, by necessity, a system that *attests* that an event occurred on chain A and *unlocks* corresponding value on chain B.

The attestation is the security model. Every bridge, regardless of marketing, comes down to: *who or what attests, and what stops them from lying?*

There are four common architectures:

### 1. Multi-sig of validators

A set of operators (5, 9, or 21 keys, typically) sign messages confirming events on chain A. Chain B trusts the signatures.

This is the simplest design and the most exploited. Ronin (\$625M) lost five of nine validator keys to a phishing attack. Multichain (\$130M+) was an effective single-signer, contradicting its marketing. The threat model is: *steal the threshold of keys, drain the bridge*.

### 2. Light client of the source chain

Chain B runs a light-client implementation of chain A as a smart contract, verifying chain A's consensus directly. No trusted intermediaries; the bridge inherits chain A's security.

This is the strongest model in principle but is operationally heavy. Light clients need to keep up with chain A's headers, which can be expensive and complex (especially for chains with frequent reorgs or PoS slashing logic). Implementations are subtle and have shipped bugs.

### 3. Optimistic with fraud proofs

Chain B accepts attestations from a set of relayers, but anyone can submit a fraud proof during a challenge window (typically days). If unchallenged, the attestation finalises.

Nomad's $190M loss came from this category, but not from the optimistic logic itself; from a botched upgrade that allowed any input to pass verification. The architecture is sound; the implementation has to be exact.

### 4. Zero-knowledge proofs

Chain B verifies a [ZK proof](/glossary/zk-proof) that a specific event occurred on chain A. The cryptography substitutes for trust. This is the newest and most expensive class of bridges; the trust model is excellent but the bug surface is large and the operational maturity is still developing.

## Why bridge bugs are catastrophic

A successful bridge holds the locked supply of every asset that has been bridged through it. A small bug anywhere in the trust pipeline drains the lot, not just the next user's transaction, but every user's deposit since the bridge launched.

This is what makes bridges different from other protocols. A reentrancy in a lending protocol drains a position. A reentrancy in a bridge drains the bridge. The economic stakes are not comparable.

## The repetition in incident reports

Reading bridge post-mortems for a year, the same root causes appear:

**Operational compromise of validator keys.** Multi-sig validators are run by humans on machines. Phishing, supply-chain compromise, social engineering, the same vectors that hit any organization, applied to keys that hold nine or ten figures. The fix is not "more validators", it is the discipline of [key management](/glossary/key-management) and [wallet hygiene](/glossary/wallet-hygiene), applied to the most adversarial environment in software.

**Verification logic that admits invalid inputs.** Nomad's bug was a single line in an upgrade that initialised the verification root to zero, which made every message with a zero proof valid. The bug was subtle, the audit missed it, and once one address noticed and started exploiting, copy-paste exploiters drained the rest within hours.

**Upgrade paths controlled by a small group.** Even when the contract logic is correct, the upgrade path often is not. A bridge whose admin keys can change the contract is only as secure as those admin keys.

**Incomplete coverage.** A bridge between five chains has more than five attack surfaces, it has the cross-product of the chains plus the relay logic. Audits that cover one chain, not the integration, miss the cracks.

## What good bridge security looks like

If you are operating a bridge, or your protocol depends on one, these are the things to verify:

### Limit per-epoch flow

A bridge that can move 100% of its TVL out in one block has built no defense in depth. Real bridges cap outflows per epoch, by chain, by asset, sometimes per address. The cap is the difference between a $10M loss and a $500M loss.

### Time-lock the upgrade path

Upgrades to bridge contracts should require a multi-day timelock with public visibility. The community needs time to see and react. An immediate-execution upgrade path is where Nomad died.

### Diverse validator set

If you are running a multi-sig bridge, validators should be operationally independent: different organizations, different infrastructure providers, different geographies, different signing devices. Five validators on the same Kubernetes cluster is one validator.

### Continuous monitoring of cross-chain invariants

The total locked on chain A should equal the total minted on chain B, at every block, for every asset. A divergence is the first signal of an attack, sometimes the first signal of a bug, and it should page someone immediately. [Wallet Surveillance](/services/wallet-surveillance) on the bridge contracts and validator operational addresses is part of how we deliver this.

### Bug bounty proportional to TVL

A $1M bounty on a $1B bridge is not an incentive, it is a number that an attacker laughs at. Serious bridges have bounties that scale with the value at risk: 5-10% of recoverable value, capped reasonably. [Immunefi](https://immunefi.com) hosts bridge programs with eight-figure caps, and they have paid out.

### A documented incident response plan

If the worst happens, who pauses the bridge? Who notifies the chains? Who notifies the dependent protocols? Who runs the on-chain trace? The plan exists, in writing, before the incident. We help teams write theirs as part of the [Incident Response](/services/incident-response) engagement.

## For users

If you are an end user moving funds across chains, three rules:

1. **Treat the bridge as a counterparty.** You are accepting bridge risk for the duration of the bridged position. Understand the bridge's architecture and accept it deliberately.
2. **Don't park funds in bridge representations of assets.** USDC.e is not USDC; bridged ETH is not ETH. Use the canonical asset on the chain you are operating on, and bridge in only when you intend to use the funds immediately.
3. **Diversify bridges.** If you are moving large amounts repeatedly, spread the route. A single bridge compromise is bad. Concentrating all your cross-chain exposure on one bridge is worse.

## Where this is heading

The space is converging on better architectures. ZK bridges are maturing. Light-client bridges are seeing more deployments. Per-epoch flow caps are becoming standard. Immutable bridge contracts (no upgrade path) are being deployed for high-value lanes.

But the operational layer, the keys, the validators, the monitoring, the response, is still a discipline that has to be practiced. The next bridge incident will not be a novel category; it will be a familiar one, in a new project. Don't be the new project.

---

# DAO Treasury Security: A Practical Playbook

Source: https://www.blockchainsexperts.io/en/blog/dao-treasury-security-playbook
Published: 2026-02-25
Updated: 2026-02-25

[DAO treasuries](/for/dao-treasuries) sit on balance sheets that would put them in the top quartile of mid-cap funds, and run on signing setups that would not pass a credit-card company's onboarding. Closing that gap, without sacrificing the decentralisation that defines DAOs, is the work.

This is the playbook we run through with DAO operations teams. None of it is novel; all of it is consistently underdone.

## The four risks every DAO treasury faces

**1. Signer compromise.** A 5-of-9 [multi-sig](/glossary/multi-sig) where signers don't know each other personally is a real social attack surface. Spoofed Discord DMs, fake calendar invites, malicious transaction simulation, the social layer of the multi-sig is where attackers focus, because the cryptographic layer is hard.

**2. Governance approving the wrong calldata.** DAOs routinely approve proposals calling unaudited contracts. The community sees the proposal title; the [Safe](/glossary/safe) signs the calldata. Without a review process, governance becomes the vulnerability, and there is no exploit needed, just a successful Snapshot vote.

**3. Cross-chain complexity.** Funds on Ethereum, L2s, lending markets, LSTs, RWAs. The treasury surface grows with every yield strategy. Tracking exposure, custody, and counterparty risk is a continuous job, not a quarterly one.

**4. No CEO to call when things break.** When something goes wrong, there is no clear escalation path. Every incident becomes a forum thread instead of a coordinated response.

## The architecture

The default architecture we recommend has four wallets, each with a different threshold and a different scope:

### Cold treasury

The bulk of the assets. 5-of-9 or 6-of-9 multi-sig, signers on hardware wallets, geographically distributed, with at least two signers in each major timezone. No regular operations, just rebalances voted on by governance, with a 48-72h timelock.

This wallet is touched on the order of once a month. Touching it is a deliberate, scheduled event with a review checklist.

### Working treasury

The operational float, typically a few weeks of grant payments, contributor compensation, and operational expenses. 3-of-5 multi-sig, signers on hardware wallets, faster threshold to assemble. Low cap on outstanding balance; replenished from cold treasury on a schedule.

A drain of the working treasury is a bad day. It does not touch the cold treasury.

### Per-strategy wallets

Each yield strategy or external integration gets its own multi-sig. If the strategy goes wrong, only that wallet is exposed. If the strategy needs to be exited, only the relevant signers need to coordinate.

This is the principle of compartmentalisation, applied to DeFi. It costs a bit more in operational overhead and is worth orders of magnitude more in incident bounding.

### Emergency pause

If your protocol has emergency pause functions, the holder of those functions is its own multi-sig, typically a smaller set of signers chosen for availability and timezone coverage rather than political balance. The mandate is narrow: pause when needed, nothing else.

## Signer selection and operational hygiene

Who signs is an operational decision, not just a political one.

**Diversity of identity and infrastructure.** Signers should not all work for the same entity, all use the same email provider, all run the same browser, all keep their hardware wallet in the same physical building. If a single attacker can compromise one organisation and reach five signers, the threshold is fictional.

**Hardware wallets, no exceptions.** Every signer signs from a hardware wallet (Ledger, Trezor, GridPlus, Keystone). The signer is responsible for verifying the calldata on the device, not on the dApp UI, not in the simulation. The device display is the source of truth.

**Documented signing procedure.** Every transaction goes through:

1. Proposal posted in the multi-sig with the calldata.
2. Signers review the calldata. Senior or technical signers should run [Tenderly](https://tenderly.co) or equivalent simulation independently and post the result.
3. Signers verify on hardware-wallet display before signing.
4. Threshold reached, transaction executed.

Skipping any step has cost real DAOs real money. The procedure exists because the failures exist.

**Onboarding and offboarding signers is a ceremony.** Adding a signer is a multi-step procedure with hardware procurement, testnet drills, identity verification. Removing a signer is a ceremony too, and not optional when a contributor leaves.

We deliver this as part of a [Wallet Setup](/services/wallet-setup) engagement: the architecture, the signer list, the runbooks, and a live training session for the signers themselves.

## Governance hardening

A multi-sig that signs whatever Snapshot tells it to is a governance vulnerability disguised as decentralisation.

**Calldata review before voting.** Every executable proposal should have a calldata review attached, what addresses it touches, what functions it calls, what value it moves, what permissions it grants. The forum post that lacks a calldata review should not be voted on, full stop.

**Standardised contract patterns.** The DAO maintains a library of approved contracts (governance modules, treasury managers, distribution mechanisms). New patterns require review by the security working group before use. This dramatically narrows the calldata-review surface for any single proposal.

**Timelocks proportional to value.** Routine rebalance: 48 hours. Smart-contract upgrade: 7 days. Treasury policy change: 14 days. The timelock is the time the community has to react to a bad proposal, including the time to socially coordinate a counter-proposal.

**Quorum that costs money to defeat.** Snapshot votes that pass with 2% participation are not governance; they are theatre. Adjust quorum requirements upward as TVL grows.

## Continuous monitoring

The architecture and the procedures are static; the threat surface is not. New strategies launch, new bridges deploy, new exploit patterns appear.

[Wallet Surveillance](/services/wallet-surveillance) on the treasury wallets and on the addresses they interact with is the continuous layer:

- Queued transactions in the Safe surface in alerts before they execute.
- Approvals to unfamiliar contracts trigger review.
- Outflows that diverge from baseline are flagged.
- Interactions with sanctioned or known-malicious addresses are blocked at the alerting layer.

The cost is small. The benefit is the difference between catching a malicious proposal in the queue and reading about it in a post-mortem.

## When something goes wrong

A DAO without a written incident-response procedure will run its first incident through its forum. This is bad for the funds and worse for the community.

The procedure that works:

- A pre-authorised Working Group of contributors with the mandate to coordinate response.
- A written escalation path: who gets paged, in what order.
- A standing relationship with an [Incident Response](/services/incident-response) firm, engaged on retainer or at least pre-vetted, so the first hour is execution, not procurement.
- Drafted communication templates for "we are aware", "we have contained", "post-mortem", to be filled in and approved fast.

The DAOs that have survived incidents, and there have been a few, survived because they had the response in place before they needed it. The ones that did not, did not survive.

## Where this lands

A DAO treasury that is properly structured can run for years through every kind of market without a serious incident. The work is upfront, architecture, runbooks, signer training, monitoring setup, and ongoing, quarterly review, annual exercises, regular signer rotation.

The alternative is the long tail of DAOs whose treasuries have been drained, often by a single signer's mistake, often documented on-chain forever. That outcome is not random; it is the predictable result of skipping the work.

We do this work for [DAO treasuries](/for/dao-treasuries) of every size, from small protocol DAOs to nine-figure ecosystem treasuries. The pattern transfers across scale; only the dollar value of the consequences scales.

---

# How to Read a Smart Contract Audit Report

Source: https://www.blockchainsexperts.io/en/blog/reading-smart-contract-audit-report
Published: 2026-02-18
Updated: 2026-02-18

Most DeFi users, and a surprising number of investors, read audit reports the same way: open the PDF, check whether the critical findings count is zero, close the PDF, decide the protocol is safe.

This is a useful filter for filtering out unaudited code. It is a terrible filter for distinguishing safe protocols from unsafe ones.

This is how we read [Smart Contract Audit](/services/smart-contract-audit) reports, ours and other firms', when we are doing real diligence.

## Page one: the scope statement

Before any finding, before the cover page, find the scope statement and read it. Twice.

A scope statement says, in concrete terms: *which Solidity files were reviewed, at which commit hash, by which auditors, over which window of time, with which assumptions held constant.*

The good ones list specific files with specific line counts. The bad ones say "the protocol's smart contracts." If the scope is vague, the audit is vague. If the scope is one paragraph, the audit is one paragraph.

Specifically check:

- **Are the files in scope the files actually deployed?** Compare to mainnet. Protocols sometimes audit one branch and ship another.
- **Is the upgrade path in scope?** A protocol whose implementation is audited but whose proxy is not is a protocol whose admin can swap in unaudited code at will.
- **Is the deployment configuration in scope?** Wrong constructor arguments, wrong initial owner, wrong oracle address, these have lost money and live below the contract logic.
- **Are integrations in scope?** "We assumed the Chainlink feed is correct" is a real assumption; whether it's the right one depends on the protocol's actual integration.

A scope statement that explicitly enumerates exclusions is a sign of a serious audit. A scope statement that hand-waves is a sign of a marketing document.

## Page two onwards: not just the criticals

Every report ranks findings by severity: critical, high, medium, low, informational. Most readers focus on critical and high.

The signal is often in the mediums.

Medium-severity findings are the ones the auditors thought were real but did not yet have a concrete exploit for. They are reentrancy patterns that *might* be exploitable depending on how the protocol is integrated. They are oracle assumptions that *might* fail under conditions the team thought unlikely. They are access-control patterns that *might* be bypassed in an upgrade.

A protocol with five medium findings, all responded with "acknowledged, not fixing because we believe the impact is limited", that is a different protocol from one where five mediums were patched. The latter is more careful; the former is making bets you may not have made.

Read the team's responses to mediums and informationals. The pattern of responses tells you how the team thinks about security. "Will fix" is a mature response. "Disagrees" with no justification is a less mature one. Both are valid in some contexts; the texture matters.

## The post-fix reaudit

A first-draft audit report is interesting; a post-fix re-audit is what you actually want to read.

The first-draft report describes the code as it was when the audit started. The team applies fixes. The re-audit describes the code as it is when the team plans to deploy. The first-draft report findings should mostly say "Fixed in commit X" or "Acknowledged, not fixing for reason Y."

If the protocol publishes the first-draft report and not the re-audit, you are reading marketing, not security. If the re-audit shows new findings introduced by the fixes, that is also useful information, fixes regularly introduce new bugs.

## What the report cannot tell you

Audit reports are bounded by their scope, which means they are silent on a lot of risk:

**Operational security.** The most secure contract in the world is exploitable if the deployer EOA has its private key on a Discord backup. Audits do not check this. We do as part of [Wallet Setup](/services/wallet-setup) and ongoing [Wallet Surveillance](/services/wallet-surveillance).

**Economic design.** Whether the tokenomics make the protocol stable, whether the LP incentives create sustainable liquidity, whether the staking mechanism is incentive-compatible, these are economic questions, not bug questions. A protocol with no findings can still die from bad design.

**External dependencies.** Audit reports usually say "we assumed Chainlink works correctly", "we assumed the integrated lending protocol behaves as documented", "we assumed bridge X is honest." These assumptions are real risks, just not in the audit's scope.

**The next deploy.** An audit at commit 0xabc is not an audit at commit 0xdef. Protocols that ship continuously must have continuous review, not annual snapshots. [Bug bounties](/glossary/bug-bounty) and code-review hygiene are the missing layer.

## Three signals of a serious audit

Beyond the scope statement, three signals suggest you are reading a serious audit:

### 1. The findings include things you do not understand

A serious audit surfaces issues that require domain knowledge. If you read the report and every finding is intuitively obvious, the auditor probably did not look very hard. Real findings often involve specific [reentrancy](/glossary/reentrancy) variants, [oracle manipulation](/glossary/oracle-manipulation) under [flash-loan](/glossary/flash-loan) conditions, signature replay across forks, EIP-specific edge cases. They take a paragraph to explain.

### 2. The recommendations are specific

"Add input validation" is a non-recommendation. "Add `require(amount > 0 && amount <= MAX_AMOUNT)` at the start of `deposit()`, with revert reason `INVALID_AMOUNT`, and emit a corresponding error event" is a recommendation. A report full of vague recommendations is a report from auditors who did not engage with the code.

### 3. The auditors are named, with bios

The cover page lists "John Smith, Senior Auditor, [profile link]", not "Audit Team." The named auditors have prior reports under their name and a track record of finding things in production. If the report is anonymous, the firm is hiding either junior staff or the absence of staff.

## Three signals of an unserious audit

Conversely, signs that the audit may not have done much:

- **No findings or only informational findings.** Real code has real issues. A clean report on a complex protocol means either the code is exceptional (rare) or the auditors were not looking hard (common).
- **A short engagement window.** A 5-day audit on a 5,000-line codebase is a code review, not an audit. The review work scales with the code complexity, not the auditor's calendar.
- **The same firm audits everyone, every time.** Firms with bottomless pipelines often deliver shallow work. Real audit teams have capacity constraints.

## What to do with the report

Reading a report does not make a protocol safe to use. It tells you what you can defensibly believe about a specific commit at a specific moment in time.

Combine with:

- **A bug bounty** with a payout proportional to the value at stake.
- **Continuous monitoring** of the protocol's actual on-chain behavior and admin keys.
- **An incident-response plan** for the bugs that nobody, including the auditors, found.

These are the three legs of a security posture. The audit is one leg. Reports without the other two are reports without legs.

The protocols that survive their first year are the ones that read their audit reports the way they would read any other expert report, with full attention to what the report covers and to what it explicitly does not.

---

# MEV and Sandwich Attacks: What Your Users Lose on Every Trade

Source: https://www.blockchainsexperts.io/en/blog/mev-sandwich-attacks-explained
Published: 2026-02-11
Updated: 2026-02-11

[MEV](/glossary/mev), *maximal extractable value*, is one of those terms that gets used to mean three different things in the same conversation. Some of it is structural and necessary; some of it is a quiet, regressive tax on retail users; some of it is a security problem that affects whether your protocol can be safely used.

This piece is the explainer we give to founders building a [DEX](/glossary/dex), to traders trying to understand why their executions look bad, and to protocol teams whose price-sensitive operations need a credible answer to "is my protocol exposed to MEV?"

## What MEV is

The mechanic is simple. Someone, historically a miner, now a block builder under proposer-builder separation, has the right to choose the order, inclusion, and exclusion of transactions in the next block. That right has economic value because **transaction order matters**: putting a buy before someone else's buy executes at a different price than after.

MEV is the value that can be extracted by exercising that right. It is not necessarily extractive of users; some MEV is essential infrastructure. But the MEV that affects users falls into three categories worth distinguishing.

### Category 1: Necessary MEV

**Arbitrage** between DEXes. When ETH/USDC trades at \$3,000 on Uniswap and \$3,001 on SushiSwap, an arbitrageur converges the price by buying low and selling high. This MEV is what keeps decentralised markets in line with each other and with centralised price discovery. Without it, DEXes would drift wildly.

**Liquidations** of unhealthy positions in lending markets. When a borrower's collateral falls below the maintenance ratio, someone has to liquidate. The MEV from liquidations rewards the liquidator and protects the lending protocol from bad debt.

These activities are competitive but not extractive. Users benefit indirectly through tighter spreads and protocol solvency.

### Category 2: Extractive MEV

**[Sandwich attacks](/glossary/sandwich-attack)** are the canonical extractive pattern.

The mechanic:

1. Attacker sees a pending swap that will move the price (e.g., a buyer wants to buy ETH).
2. Attacker submits their own buy first, with a higher priority fee, executing before the victim. This raises the price.
3. The victim's transaction executes, paying the new (higher) price.
4. Attacker submits a sell immediately after, executing against the price impact the victim's transaction created.

The victim gets worse execution than they would have without the attack. The difference goes to the attacker. The protocol gets nothing. The pool sees no improvement in price discovery.

**[Front-running](/glossary/front-running)** of oracle updates and large swaps is similar in pattern: someone exploits the visibility of pending transactions to trade ahead of them.

These patterns are not necessary infrastructure. They are a regressive tax on users who are visible enough in the mempool to be picked off.

### Category 3: Toxic MEV

**[Oracle manipulation](/glossary/oracle-manipulation)** combined with [flash loans](/glossary/flash-loan) is the most dangerous category. An attacker uses MEV machinery, atomic transactions, mempool visibility, to drain a protocol entirely. This is not extraction at the margin; it is exploitation.

The defense is not at the MEV layer; it is at the protocol design layer, as we covered in our [post on oracle manipulation](/blog/oracle-manipulation-defi-attacks).

## What users lose

The numbers vary by ecosystem and tooling, but the order of magnitude is meaningful.

A retail user swapping a few thousand dollars on a public Uniswap pool through a default DEX UI, with default slippage settings, is regularly paying 10-50 basis points to MEV. On a $10,000 swap, that's $10-50. Compounded over many trades, it adds up to a meaningful chunk of trading volume captured by sandwich bots.

Larger users (institutional desks, treasury operations) often lose more in absolute terms. A $5M swap with default slippage on a public mempool can lose tens of thousands of dollars to MEV in a single transaction.

This is not catastrophic, but it is a continuous tax. And, importantly, **it is largely avoidable**.

## What users can do

The mitigations exist and are not technically difficult.

### Use a private mempool

Flashbots Protect, MEV Blocker, and similar services route your transaction directly to block builders without broadcasting it publicly. Sandwich bots cannot sandwich what they cannot see.

In MetaMask, this is a one-time RPC change. Other wallets have similar settings. Most of the cost is the awareness that this option exists.

### Set realistic slippage

A common UI pattern is "slippage tolerance: 50%" because the default failed for the user once and they raised it without thinking. 50% slippage is an explicit invitation: take up to half the value of this trade as MEV.

Realistic slippage for most pools is 0.1-1%. Raising it should be a deliberate choice based on actual pool depth, not a UI default that was clicked away.

### Trade on protocols with batched auctions

CoW Swap, Balancer's CowSwap-style integration, 1inch Fusion, protocols that batch trades and match them at a uniform price within each batch eliminate sandwich attacks structurally. They also tend to give better execution on average.

### Avoid trading from an obviously rich wallet

If the same wallet that holds eight figures of ETH does a $10M swap on a public DEX, sandwich bots will optimise their attacks on it specifically. Operational separation between treasury and trading helps; we cover the architecture in [Wallet Setup](/services/wallet-setup).

## What protocols can do

If you operate a [DEX](/for/defi-protocols) or any protocol that does price-sensitive operations, MEV is part of your threat model.

**Default users into protected execution.** A DEX UI that defaults to private-mempool routing is a DEX that captures less of its volume for MEV bots. The friction is small; the user benefit is large.

**Use slippage limits, not user-set tolerance, for protocol-internal operations.** Liquidations, automated rebalances, oracle-fed operations should have hard slippage caps in the contract, not user-set parameters.

**Watch your own execution quality.** A protocol whose own treasury operations regularly get sandwiched is a protocol whose treasury is bleeding to MEV, and which therefore should be doing those operations through a private mempool or a batched auction.

**Treat MEV in your audit.** A serious [Smart Contract Audit](/services/smart-contract-audit) considers MEV as a threat. Specifically: which protocol operations are price-sensitive, can they be sandwiched, what is the worst-case loss?

## Where this is going

The MEV landscape changes faster than most security topics. Proposer-builder separation, encrypted mempools, threshold encryption schemes, application-level batching, the cryptographic and protocol-level mitigations are maturing.

For protocol teams, the practical posture is:

- Assume your users are exposed by default.
- Make protected execution the path of least resistance.
- Treat MEV as a security topic, not a "trader concern."

For users, the practical posture is:

- Use a private mempool.
- Set realistic slippage.
- Use protocols built for protected execution when the trade size is meaningful.

The cost of awareness is low. The cost of unawareness compounds on every trade.

---

# Crypto Exchange Security: From MiCA Readiness to Hot-Wallet Hardening

Source: https://www.blockchainsexperts.io/en/blog/exchange-security-mica-readiness
Published: 2026-02-04
Updated: 2026-02-04

[Crypto exchanges](/for/crypto-exchanges) sit at the intersection of two threat models: traditional fintech (with everything that implies about API security, internal access, and compliance) and crypto-native (with everything that implies about [key management](/glossary/key-management), on-chain surveillance, and the impossibility of un-doing a transaction).

[MiCA](/glossary/mica), DORA, and the various national PSAN/VASP regimes raise the bar for documented security across the EU. Modern attackers raise the bar for the actual security underneath the documentation. This piece covers what we look for when we run a security review for an exchange, and what teams need to have in place, operationally and on paper.

## Custody: hot, warm, cold

The architecture exchange operators converge on, and the one we recommend, looks like this:

**Cold storage holds the vast majority of customer funds.** Air-gapped, multi-sig or threshold MPC, geographically distributed signers, hardware-wallet operations only. Touched on a defined schedule for replenishment, never on demand.

**Warm storage holds the operating buffer.** Several days of expected withdrawal volume. Signed by a smaller threshold, faster to mobilise, but still through hardware-backed signing.

**Hot wallets hold the immediate operational float.** Signed automatically by HSM- or KMS-backed services, with strict programmatic policies, per-transaction caps, per-hour caps, address whitelists where possible.

The relevant question is not "is this architecture good?", it is "what is the worst-case loss?" A drain of the hot wallet should be a bad day. A drain of the warm should be a serious incident. A drain of the cold should be impossible without compromise of multiple independent organisations.

We design and review these architectures during a [Wallet Setup](/services/wallet-setup) engagement, and we monitor them continuously through [Wallet Surveillance](/services/wallet-surveillance).

## The withdrawal pipeline

The most-attacked endpoint in any exchange is the withdrawal flow. It is also the hardest to secure because it must remain fast enough to deliver a competitive product.

The questions we ask in a [Penetration Testing](/services/penetration-testing) engagement:

- What is the path between a user pressing "withdraw" and a transaction being signed? How many systems sit between request and signature?
- Where is the signing key? What is the trust boundary?
- Can a compromise of the user-facing API result in a withdrawal? Can a compromise of internal admin tooling? Of CI/CD? Of a single engineer's laptop?
- What rate limits apply, in what dimensions (per user, per IP, per address, globally)?
- What out-of-band confirmations exist for new withdrawal addresses?
- What automatic anomaly detection runs, and what does it page on?
- How fast can a withdrawal be paused once an anomaly is detected?

The exchanges that have lost customer funds usually had one of these answers wrong, not all of them. The defense is layered: every step that could fail should also be backstopped by another step.

## API surface and internal access

Exchanges accumulate APIs faster than they accumulate API reviews. REST, WebSocket, FIX, internal admin panels, partner endpoints, market-maker gateways. Each is a potential entry point.

Common findings in our pen-test reports:

- **Insecure direct object references** on internal admin tooling, where a moderately privileged user can act on accounts they should not see.
- **Tenant isolation bugs** in white-label or sub-account setups, one tenant's transactions visible or actionable from another.
- **Authentication on internal endpoints** weaker than on customer-facing ones, on the assumption "internal traffic is trusted."
- **Rate-limit gaps** that allow account enumeration or credential stuffing at scale.
- **Secrets in CI/CD** that survived a since-deprecated workflow and remain valid.
- **API key permissions** that are coarser than they should be, a read-only key that turns out to also let the holder move funds.

Each of these has been a real finding in real engagements. None of them are exotic. They are what you find when a competent attacker spends a week looking, which is what we do, in advance, so the next one to look does not find them.

## On-chain monitoring

Exchanges' on-chain footprint is enormous and high-stakes. Hot, warm, cold, deposit addresses for every customer, internal sweep wallets, market-maker rebalancing flows. Each has a profile that, when it deviates, is a signal worth investigating.

[Wallet Surveillance](/services/wallet-surveillance) for an exchange covers:

- **Deposit address sweeps** that look unusual (volume, destinations, timing).
- **Hot-wallet outflows** that diverge from baseline, even by a small amount.
- **Cold-wallet activity** at all (any activity is, by design, an event).
- **Multi-sig proposals** queued before they execute.
- **Approvals to unfamiliar contracts**, sometimes the leading indicator of an internal compromise.
- **Interactions with sanctioned addresses** (OFAC SDN list, Tornado-tainted addresses), a compliance and a security signal.

The monitoring is continuous; the response is human. A real analyst on the other end of the alert is the difference between a tooled-out dashboard and an actual security function.

## Incident readiness

An incident at an exchange is existential. Customer funds lost is not a recoverable position, financially, reputationally, or regulatorily.

The minimum readiness:

- **A pause path** for the withdrawal pipeline, held by a small group on call, with a published response SLA.
- **A standing communications procedure**, drafts pre-approved with legal and counsel, ready to fill in.
- **A relationship with an [Incident Response](/services/incident-response) firm**, on retainer, with response SLAs commensurate with the value at stake.
- **A trace-and-recovery capability**, either in-house or contracted, that can produce an on-chain narrative within hours of an incident.
- **A regulator and law-enforcement contact list**, by jurisdiction.

These are not optional. MiCA and equivalent regimes increasingly require documented evidence of each, and the regulators ask for it during examination, not only after incidents.

## MiCA-specific notes

For exchanges operating in the EU, [MiCA](/glossary/mica) introduces specific operational expectations:

- **Custody segregation.** Customer funds not commingled with exchange operating funds. Documented, auditable, on-chain where possible.
- **ICT risk management** under DORA, overlapping heavily with security controls. A SOC 2 Type II or ISO 27001 program is increasingly the de facto evidence.
- **Outsourcing controls.** Third-party providers (custody partners, market-maker integrations, KMS providers) require contractual and operational controls.
- **Incident reporting** with defined timelines to competent authorities. A team that does not have a reporting pipeline at hour zero will miss the deadline.
- **Travel Rule** compliance for transfers above thresholds, including coordination with other regulated entities.

Exchanges getting authorisation today benefit from clearer rules of the road than the prior patchwork of national rules. The regulatory ramp-up is real, and the security controls underneath it are most of the work.

## What good looks like

The exchanges that do not appear in incident reports tend to share a profile:

- Custody architecture that an external reviewer would describe as *boring*. No exotic schemes, no clever shortcuts, no trust assumptions stated in slide decks instead of contracts.
- An API surface that has been beaten on regularly by external testers, with findings tracked, fixed, and re-tested.
- Continuous on-chain monitoring with a human analyst on the other end.
- Documented operational procedures the team can execute under pressure, because they have rehearsed.
- A standing relationship with an incident-response firm.
- Compliance documentation that reflects the actual operations, not aspirational ones.

None of these are exciting. All of them compound, year over year, into the kind of security posture that does not produce headlines.

The exciting alternative is the one that produces headlines. Pick.

---

# Web3 Game Security: When Your Players Are Your Threat Model

Source: https://www.blockchainsexperts.io/en/blog/web3-game-security-economy
Published: 2026-01-28
Updated: 2026-01-28

[Web3 games](/for/web3-gaming) are the strangest threat model in our practice. Three different security disciplines apply at once, game security (anti-cheat, server integrity), fintech security (the in-game economy is real money), and smart-contract security (the on-chain pieces). The players do not separate them. They will exploit whichever layer breaks first.

This piece is the framework we use when we work with GameFi teams, from pre-launch hardening through live-ops incident response.

## Three threat models, one product

**Game security** is what AAA studios have been doing for decades. Anti-cheat, server-authoritative state, replay protection, exploit detection, ban infrastructure. The threats are well-understood: client modification, packet manipulation, bot farms, account sharing.

**Fintech security** is what payment processors and exchanges deal with. KYC where applicable, anti-fraud, anomaly detection on transactions, regulatory compliance for in-game economies that touch fiat.

**Smart-contract security** is what DeFi protocols deal with. Audits of mint, transfer, claim, and redeem logic. Resistance to [reentrancy](/glossary/reentrancy), [oracle manipulation](/glossary/oracle-manipulation), and replay attacks. [Bug bounties](/glossary/bug-bounty) sized to the value at stake.

A Web3 game has all three problems. The bridge between game state and chain state, the moment when an in-game achievement mints an NFT or a staking action triggers a token transfer, is where the threat models compound, not where they cancel.

## The economic-design review

The single highest-leverage thing we do for a GameFi team is the **economic-design review**, which precedes the technical audit.

Questions in scope:

- What is the maximum amount of currency that can enter the economy in a unit of time, and through what mechanisms?
- Is the rate of currency entry plausibly proportional to the rate of currency removal (sinks)?
- What is the maximum payout from any single game action, and what fraction of total currency is that?
- What are the assumptions about player behavior that must hold for the economy not to collapse?
- What happens if those assumptions are wrong, slowly, or suddenly?

A game whose economy depends on player behavior that motivated players will exploit is a game whose economy will be exploited. The question is when.

The classic failure mode: a play-to-earn game launches with a positive ratio of in-game rewards to onboarding costs. New players multiply faster than the sinks can absorb them. The token inflates. The early players cash out. The new players are left holding worthless currency. The game economy collapses, often with a community that feels defrauded.

The defense is mathematical, not technical. Every play-to-earn loop must have a sink that closes in plausible market conditions. Every minting mechanism must be bounded. Every reward must be priced in a way that does not depend on perpetual new-player growth.

## The on-chain audit

Once the economic design is defensible, the contracts that implement it need a [Smart Contract Audit](/services/smart-contract-audit) like any other DeFi-adjacent code. Specific patterns we look for in GameFi contracts:

**Minting tied to off-chain state.** When the contract mints based on a server signature ("this player completed quest X"), the signature scheme has to be replay-resistant, chain-bound, expiry-bound, and tied to a per-player nonce. We have seen all four omissions in the wild.

**Reward claims with race conditions.** A claim function that computes rewards based on `block.timestamp` and lets the user call repeatedly within the same block is exploitable. So is one that uses a stale state read between calls.

**Cross-chain item movement.** Many games move assets between an L2 and L1, or between a sidechain and an L1. Each direction is a [bridge](/glossary/bridge), with all the bridge problems, and usually one with less institutional attention than the major DeFi bridges.

**Emergency pause and adjustment.** Games will need to make economic adjustments mid-life, adjust drop rates, deprecate items, fix exploits. The adjustment surface is privileged and needs to be locked down, time-locked, and reviewed.

## The game-server side

Pen testing for GameFi covers what every game studio knows it needs, server hardening, authentication, anti-cheat, plus the Web3-specific seams.

The bridge between game logic and chain logic is the highest-priority surface in our [Penetration Testing](/services/penetration-testing) engagements with GameFi teams. Specifically:

- **The signing service** that the game server uses to sign authorisations for on-chain claims. If a compromised game server can sign arbitrary authorisations, the game economy is compromised through the game server.
- **The matchmaker** that determines reward eligibility. If matches can be manipulated, rewards can be manipulated.
- **The replay or anti-cheat detection** layer. If banned accounts can still claim on-chain rewards, the bans are theatre.
- **The NFT-metadata pipeline.** If item attributes are computed off-chain and minted on-chain, the off-chain pipeline is part of the trust boundary.

## Live ops: the threat model never stops

Unlike most software, GameFi has the property that **users actively look for bugs**. Bot farms, reverse-engineered clients, oracle manipulation in PvP rewards, dupe exploits, the abuse patterns are continuous.

The teams that handle this well share three practices:

**Continuous monitoring of the economy itself.** Total currency in circulation, total currency minted per day, top earners by daily volume, player accounts with anomalous reward patterns. If the total currency is growing faster than expected, something is being exploited.

**A mature ban and rollback infrastructure.** When an exploit is found, the team can identify affected accounts, freeze them, roll back the on-chain state where possible, and communicate transparently. The teams without this infrastructure are forced to choose between leaving exploits live and visible community-broken hard forks.

**[Wallet Surveillance](/services/wallet-surveillance) on operational wallets.** The signing-service wallets, the treasury, the reward pools, all monitored for anomalies that suggest compromise.

**An [Incident Response](/services/incident-response) retainer.** Game-economy exploits move fast and are extremely public. A team that has rehearsed the response, with a partner on call, recovers faster and with less reputational damage than one that improvises.

## What launching looks like

A GameFi launch we have helped harden looks roughly like:

- Economic-design review six months before launch. Adjustments to incentive structures based on findings.
- Smart-contract audit three months before launch. Re-audit after fixes.
- Pen test of game servers and the on-chain/off-chain bridge two months before launch.
- [Wallet Setup](/services/wallet-setup) for treasury and signing-service wallets one month before launch.
- Bug bounty live two weeks before launch.
- [Wallet Surveillance](/services/wallet-surveillance) live at launch.
- [Incident Response](/services/incident-response) retainer in place at launch.

Every step that gets compressed has a corresponding cost in post-launch incidents. We have seen the math on both sides.

## The thing GameFi keeps relearning

Every cycle, a generation of GameFi projects launches with insufficient economic-design review, has a great first month, peaks, and then collapses through a combination of exploitation and inflationary game design. The collapses are often blamed on "the meta moved on" or "the market turned", but the post-mortems consistently show that the economic design was unsustainable from the start, and motivated players found the unsustainability faster than the team could patch it.

The GameFi projects that last are the ones that treat economic design with the same rigour as code design. The threats are different from DeFi's, and the motivated players are infinitely more numerous than the auditors any project can afford. Building correctly is the only viable strategy.

---

# Broker Defense Partnership

Source: https://www.blockchainsexperts.io/en/blog/partenariat-broker-defense
Published: 2024-05-05
Updated: 2024-05-05

## Introduction

We are pleased to announce our partnership with [Broker Defense](https://www.brokerdefense.net/2024/03/06/securite-web3-et-blockchain-broker-defense-et-blockchains-experts-sallient-pour-une-analyse-onchain-pointue/). This partnership is designed to help victims of cryptocurrency scams and fraud. Through this collaboration we contribute to the fight against cybercrime and support those who have been targeted.

## What is Broker Defense?

[Broker Defense](https://www.brokerdefense.net/) is a firm specialised in helping victims of online scams. Since 2014, they have supported clients against illegal entities, in coordination with law firms across European jurisdictions. With advanced investigative techniques and deep knowledge of international financial law, Broker Defense helps clients resolve financial disputes.

## How the partnership works

We work closely with Broker Defense for our clients. If you have been the victim of a scam that resulted in the loss of digital assets (crypto, NFTs…), reach out and we will do our best to help, together with Broker Defense. We stay involved through the whole process, providing support and guidance on request.

## Why we chose Broker Defense

We chose Broker Defense as a partner because of their experience and expertise in fraud. Their dedication to helping victims of online scams aligns with our mission of supporting our clients. Their track record of recovering funds for victims is a testament to their effectiveness and professionalism.

## Conclusion

We are excited to work with Broker Defense and to bring additional support to clients who have been targeted by online scams. With this partnership we expect to make a meaningful difference for those impacted by cybercrime.