If our smart contracts are audited, what is left for a penetration test to cover?

Everything around the contracts: the front end users load, the build and deploy pipeline behind it, the workflow your signers use to review and approve privileged transactions, keeper and relayer infrastructure, backend APIs and the cloud accounts and CI secrets that support them. An audit reads code; a pentest attacks the path by which a legitimate-looking transaction reaches the contract. The two answer different questions and neither replaces the other.

What does the Bybit hack tell a DeFi protocol about testing scope?

In February 2025 attackers stole roughly $1.4–1.5 billion from Bybit's cold wallet. Forensic reviews found no vulnerability in the Safe smart contracts or in Safe's front-end source; the attackers compromised a Safe{Wallet} developer machine and injected malicious JavaScript that showed signers a legitimate transaction while a different one was signed. The lesson for scoping is that the signer-facing workflow, and what the signers' devices actually display, is an attack surface that no contract audit examines.

Do you test on mainnet or against live contracts?

No. Testing runs against a mainnet fork, a testnet deployment or a staging copy of the front end and off-chain services agreed in the Rules of Engagement. Anything that would submit a privileged transaction to live contracts, or touch funds, is excluded by default. Findings that need a live-chain condition to prove are documented and reasoned through with your team rather than executed.

Can you test our RPC provider, wallet vendor or multisig software vendor?

Only assets you own and can authorize. A third party's infrastructure — an RPC host, a wallet vendor, a hosted signing interface — needs that party's own permission and is out of scope by default. What we can test is how your own systems depend on them: what your front end loads from external origins, how you pin or verify it, and what your signers see before they approve.

Is a pentest a substitute for a bug bounty or a contract audit?

No. A contract audit reviews code before or after deployment, a bug bounty offers continuous open-ended coverage, and a pentest is a time-boxed, authorized attack against a named off-chain scope with a report and a retest. A protocol with real value at stake usually needs the first and the last, and treats the bounty as an addition rather than a replacement for either.

Penetration Testing a DeFi Protocol: Your Signing Path Is the Scope

The short answer

For a DeFi protocol that already has a smart-contract audit, a penetration test should target the off-chain path a transaction travels before it reaches the contract: the front end users load, the pipeline that builds and serves it, the workflow signers use to review privileged transactions, and the keeper, relayer and API infrastructure around the protocol. The contracts themselves stay with the auditor. The signing path is the scope because that is where a legitimate-looking approval can be manufactured without any contract bug.

Who this is for

This is written for a protocol security lead, CTO or founding engineer at a live or pre-launch DeFi protocol who has an audit report in hand and has been asked, by an investor, an insurer or their own board, "have you been penetration tested?" It is not for you if the open question is a contract code review, which is a specialized separate engagement, or if you run a custodial exchange, where scoping a pentest for a crypto exchange applies instead.

What Bybit changed about scoping

The clearest public case of an attack that never touched contract code is the February 2025 theft from Bybit's cold wallet. According to NCC Group's technical analysis, malicious JavaScript identified Bybit's signers, showed them the intended transaction, and had them approve a modified one that used a delegatecall to an attacker-controlled contract; the hardware-wallet display was a data blob in which, in NCC's words, "the underlying data is not human-readable, making it easy to mistake one for the other."

Per BleepingComputer's report on the Safe Ecosystem Foundation's findings, the forensic reviewers by Sygnia and Verichains found the attack came through a compromised Safe developer machine and injected code in the web interface, and found "no vulnerabilities in the Safe smart contracts or the source code of its frontend and services."

Bybit is a centralized exchange using a multisig, not a DeFi protocol. The relevance is structural: any protocol whose admin actions are approved through a web interface by human signers has the same class of exposure. A contract audit cannot see it, because the contract behaved exactly as written.

What is in scope on a DeFi protocol

Surface	What a tester does	Why it belongs here
Front end and its third-party origins	Maps every script, dependency and external origin the dApp loads; tests whether integrity is verified and whether a change would be noticed	The interface is where a user or signer decides what to trust
Build and deploy pipeline	Reviews CI secrets, build-server access, dependency and deploy-permission paths	A tampered build ships without touching the registrar or a contract
Signer workflow	Walks how privileged transactions are proposed, reviewed and approved; tests whether a signer can tell what they are signing	This is the Bybit class of failure
Keeper, relayer and oracle infrastructure	Tests exposed services, key storage and access from an attacker's position	These hold operational keys and run continuously
Backend APIs and indexers	Application-layer testing: authorization, input handling, data exposure	Standard web and API surface, often under-tested for protocols
Cloud accounts	Tests reachable consoles, over-permissioned roles, exposed storage	The developer-machine-to-cloud path is how the Safe interface was altered

The registrar and admin-key questions belong in a hardening plan; Hardening a DeFi Protocol: What Comes First covers the order. A pentest is the adversarial check of whether that hardening holds.

Rules of engagement that differ from a web-app test

No live privileged transactions. Proof runs on a fork, testnet or staging copy; the RoE names them.
Third parties stay out unless they consent. RPC hosts, wallet vendors and hosted signing interfaces need their own authorization. Your dependency on them is testable; their systems are not.
Social engineering is opt-in and named. Testing signer-targeting phishing is a separate, explicitly agreed line item with named participants.
Stop conditions are written down for anything that could interact with real funds.

What you receive

The deliverables follow the Penetration Testing service: an executive summary, a technical report with CVSS ratings and reproduction steps, per-finding remediation guidance, and a retest validation report after fixes. For a protocol, the report should map each finding to the path it sits on, so your team can see which findings shorten the distance between an attacker and a privileged transaction.

Limitations

A pentest does not audit contract logic and does not prove the absence of a vulnerability in code. It is a point-in-time test of a named scope: a clean report says nothing about the interface change shipped next week. It does not watch for live attempts — that is what Managed SOC for a DeFi protocol addresses — and it cannot reverse anything already settled on-chain, which is the boundary Incident Response for a DeFi protocol is built around.

How to decide

Book the audit for the code and the pentest for the path. If your admin actions are approved through a web interface by human signers, put that workflow and the pipeline that serves the interface at the top of the scope list. Send us your architecture and signer setup and we will reply with a fixed quote and draft Rules of Engagement.

Sources and review

The Bybit facts are third-party reported and drawn from NCC Group's technical analysis and BleepingComputer's report of the Safe Ecosystem Foundation findings; NCC reports over $1.4 billion and BleepingComputer over $1.5 billion, so this post uses the range. Scope and deliverables follow AnySec's published Penetration Testing service terms; no AnySec performance figure is cited. Author: AnySec Engineering. Published 2026-09-29; last reviewed 2026-09-29.