A smart contract audit reads deployed or to-be-deployed onchain code and reasons about what an adversary with capital and transaction ordering can make it do. The output is findings about logic, accounting, access control and economic assumptions.
A penetration test treats your systems as an attacker would: authentication, authorisation, API surface, key storage and signing flows, infrastructure configuration, and the frontend. The output is findings about how someone gets in and what they can reach once inside.
Most DeFi protocols are not purely onchain. They rely on backends for coordination, better UX, or cross-chain messaging. A contract auditor stops at the contract boundary and assumes the inputs are what they claim to be; a backend engineer assumes the chain enforces correctness.
Neither assumption is wrong in isolation and both are wrong together. We call this surface Web2.5, and a substantial share of our findings for exchanges, payment providers and custodians live there.
If your protocol has a backend that can influence what gets executed onchain — a relayer, a quoting service, a signer, an admin panel — you need both, and you need someone who will look at the boundary rather than at each side separately.
If you are a pure onchain protocol with a static frontend and no privileged off-chain component, a contract audit may genuinely be sufficient. That is rarer than most teams assume.
LAST UPDATED
Everything above is easier to trust if you can verify it. The full engagement record, with per-engagement severity counts and links to published reports, is public.
We would rather answer the hard questions before the engagement than during it.