Ask where the biggest crypto losses actually come from, and it's rarely a flaw in the smart contract code. It's usually a hijacked domain, a compromised signer, a treasury transaction that looked routine, a support account that got phished, a deploy key sitting in the wrong place. The biggest hacks of the past few years went around the contract instead of breaking it. Operational failures are now the nine-figure headlines. For years, "security" in crypto mostly meant the audit on the code, and not much else.
That gap is where we've spent the last two years. When we started running operational security audits for crypto teams, the whole market was focused on Solidity. Signer hygiene, registrar locks, incident response drills, account takeover monitoring: the things that actually get organizations compromised had no shared definition of "good" and no one to give a verdict on them. You could have your contracts audited by five firms and still run a treasury that's one social-engineering call away from empty.
Now that surface has a standard. The Security Alliance (SEAL) built SEAL Certifications, and Opsek is an accredited assessor for it.
What the standard actually covers
SEAL Certifications look at the operational security practices code audits don't. The assessment spans six domains: Multisig Ops (governance, signer security, transaction verification, emergency procedures), Treasury Ops (architecture, fund management, custody, transaction security), Incident Response (team structure, monitoring, response playbooks, drills), DevOps & Infrastructure (development environments, source code security, CI/CD, cloud), DNS & Registrar (domain management, DNS controls, registrar security, email authentication), and Identity & Accounts (account inventory, phishing-resistant MFA, credential management, lifecycle, takeover monitoring).
That's the map of how protocols get drained when the contracts hold. Historically none of it was visible from outside. A partner, an exchange, or a user had no way to check it, because there was nothing to point at.
The way the standard is built matters as much as what it covers. SEAL sets and maintains the framework and accredits independent firms to run the assessments; it doesn't assess protocols itself. Certification is a single pass/fail decision across the agreed scope, and the assessment is based on judgment rather than a checklist. What matters is whether a team's practices hold up for its scale and risk. That's the right approach, because operational security is contextual: what's fine for a two-person team with a small treasury would be negligent for a protocol securing nine figures, and scoring both against one rigid list wouldn't help either of them.
This isn't a draft framework. SEAL validated it over the past year through pilot analyses with more than 25 protocols and feedback from over 10 auditing firms before opening accreditation. It's stable and in use.
How a certification works
The engagement is collaborative rather than adversarial. We scope the assessment with the protocol team, agreeing on which controls apply and what infrastructure is in scope; some controls get scoped out depending on how a given team is set up. The team then gathers evidence that their practices meet the controls: signer lists, incident playbooks, DNS configurations, access policies. We review that evidence against the open-source framework criteria.
Where there are gaps, we give you specific recommendations. Your team can close them, or we can do it for you, and then we verify the fixes are actually in place. Once the practices meet the standard, the protocol gets a formal on-chain attestation issued through the Ethereum Attestation Service, publicly and cryptographically verifiable.
A typical engagement runs a few weeks from scoping to certification, and most of that time goes to coordinating on evidence rather than the review itself. The detailed report and the evidence behind it stay confidential between the protocol and us. Only the attestation is public.
An attestation doesn't mean a protocol is unbreakable. Security is never finished, and no certificate freezes a moving target. What it does show is that a team has put real operational practices in place and had them checked by someone independent, rather than just claiming to.
Why this is good for the ecosystem
For years, operational security was the thing everyone knew mattered but no one could prove. A team could invest heavily in signer discipline and incident readiness and have no way to show it. A team that had done none of it looked exactly the same from outside, at least until it ended up in the news.
A shared standard with a verifiable attestation changes that. Partners can ask for it, exchanges can factor it in, and users can check it. Teams that have quietly done the work now have something to point to, and teams that haven't have a clear path to follow instead of a vague sense that they should "improve their opsec." Code audits went from optional to expected the same way, and operational security is heading there too.
We've been making this case, and doing the work behind it, since before there was a certificate to hand out. The accreditation just puts a formal credential on something we were already doing.
If your team wants to get certified, you can see the domains and the full process at sealcertifications.opsek.io.