Expertise / 08
Crypto operational security
Review the people, accounts, signing workflows and infrastructure that can change your protocol or move its funds.
Inspect public security work →Prepare scope and inputs →Prepare an optional project brief →
Preparing a launch, changing a signer or reviewing how production access is held? Start with the authority map and the evidence available.
Explore the control model and download the figure
Crypto operations connect signing, identity, devices, domains and recovery.
Original Web3Sec diagram. On small screens, scroll the figure or open the full-size version.
Who this is for
A clear question.
A useful outcome.
Crypto founders, protocol operators and treasury owners preparing a launch, changing signers or team access, adding a custody or deployment dependency, or checking operational controls after a near miss.
A contract audit examines code within an agreed scope. Operational security follows who can publish the frontend, recover an administrator account, approve a transfer, change DNS or restore access when a signer is unavailable. This assessment connects those paths across people, process and infrastructure. It begins with the actions that could cause material harm and asks what prevents one compromised identity, device or provider from authorizing them. Public SEAL frameworks and relevant technical guidance can inform the control questions; findings depend on your actual configuration and observed procedures. Raiders’ authorship of SEAL’s Domain & DNS Security framework is a research contribution, not a certification or accreditation for this service.
What you should leave with
- Identify the accounts, dependencies and recovery paths that concentrate authority over treasury, protocol administration and public infrastructure.
- Give operators a prioritized hardening plan with owners, prerequisites and evidence that would demonstrate each control is working.
- Practice agreed failure scenarios and record which detection, escalation and recovery steps were verified or remain untested.
Review boundary
What the work can cover.
Signing and treasury operations
wallet and role inventory, thresholds, proposers and approvers, transaction decoding and independent verification, policy limits, emergency powers and the effect of signer loss or compromise.
Signer workstations and recovery
device and browser separation, approved software, hardware-wallet workflows, backup ownership and loss-of-access procedures reviewed without collecting keys, seed phrases or recovery codes.
Identity and team changes
administrator and service-account inventory, phishing-resistant authentication where supported, account recovery, joiner/mover/leaver procedures, third-party access, session revocation and emergency access custody.
Domain and release infrastructure
registrar and DNS authority, registry-lock availability, email recovery dependencies, CDN and frontend publication, GitHub and CI/CD permissions, deployment approvals and secret lifecycle.
Detection and response dependencies
actionable alerts for privileged changes, log retention, vendor escalation contacts, alternate communication channels, named incident decisions and a rehearsed recovery path.
From context to evidence
How the engagement works.
Map authority and agree on evidence
Start with a high-level system and treasury overview, upcoming changes and the operational owner. After agreeing on confidential handling, provide an asset and account inventory, public wallet and contract addresses where relevant, sanitized role/configuration exports, existing runbooks, provider dependencies and sample alert records. Confirm permitted observations, test identities, exclusions and change authority. Missing evidence is recorded as a coverage limit, not treated as a failed or passed control.
Review controls and rehearse failure
Trace selected paths from account or device access to a consequential action. Compare documented approval and recovery procedures with authorized walkthroughs and configuration evidence. Use synthetic transactions, test accounts or tabletop exercises to check scenarios such as an unavailable signer, a departed contractor with a deployment grant or a registrar-account takeover. Agree on any configuration changes and rollback before implementation; the client retains signing and production change authority.
Prioritize changes and verify remediation
Deliver findings with observed conditions, prerequisites, impact, affected controls and proposed fixes. Assign practical implementation owners and identify specialist or provider dependencies. An agreed retest checks specified settings, permission exports or runbook revisions and repeats relevant positive and denied cases. Record the environment and assessment date so later account, signer and infrastructure changes trigger a fresh scope decision.
Concrete outputs
Deliverables you can use.
Examples below are illustrative. They describe possible work products, not past client findings or promised results.
Authority and dependency map
A scoped map of sensitive actions, accounts, signers, providers and recovery dependencies. Illustrative example: the same email recovery account controls both DNS administration and the frontend deployment owner.
Evidence-led hardening plan
Prioritized findings and operational tasks with an owner, implementation dependency and verification condition. Illustrative example: remove a former contractor’s deployment grant, revoke its associated tokens and confirm the old identity cannot publish a test release.
Drill and retest record
A record of the scenario rehearsed, observations, decisions and remaining gaps, plus remediation status for the agreed follow-up. A tabletop confirms decision readiness; it does not by itself prove that an unexecuted recovery procedure works in production.
Scope and responsibility
Boundaries worth agreeing early.
- The engagement covers the agreed accounts, infrastructure, workflows and evidence window. Contract-code review, exploit research, physical security and specialist custody architecture require explicit coverage decisions.
- Private keys, seed phrases, hardware-wallet PINs and live recovery codes are never review inputs. Raiders does not take custody, become a treasury signer or execute live-fund transactions as part of this assessment.
- Social engineering, employee-device inspection, production changes and testing third-party services require specific authorization. Provider capabilities and access constraints may limit what can be independently verified.
- This is a scoped assessment and hardening plan, not a SEAL certification, accredited certification service, staffed 24/7 monitoring arrangement or guarantee against compromise. Ongoing monitoring and incident availability need a separate agreement.
Before sharing code, customer information, or incident artifacts, agree on confidentiality and a private transfer channel. Keep the initial message high level.
Before we begin
Common questions.
What does a crypto OpSec assessment cover beyond a contract audit?
It examines operational authority: signing and treasury approvals, signer devices, identity and recovery, domains, frontend deployment, CI/CD, secrets and incident procedures where scoped. Contract-code correctness remains a separate review question. A strong contract can still depend on an administrator or release account that needs its own controls.
Can you review our setup without receiving wallet secrets?
Yes. Scope can use public addresses, sanitized configuration evidence, role exports and supervised walkthroughs. Recovery ownership and procedures can be assessed without revealing seed phrases, private keys or recovery codes. Sensitive artifacts are shared only after handling and access have been agreed.
Is this a SEAL certification or accredited assessment?
No. Public frameworks may inform the questions and evidence mapping, but this independent service does not issue a SEAL attestation or claim accredited status. Raiders’ published framework authorship is distinct from certification. A formal certification requires the relevant program’s authorized process and provider.
Can you help harden the controls and check the changes?
An implementation plan, supervised walkthroughs and a defined retest can be included. Your authorized owners approve and execute changes, including signer or production changes. Follow-up evidence identifies exactly what was reviewed and what remains open; it does not extend automatically to later changes.
- Name an owner for each critical asset and record who can change its permissions, recover access or authorize an emergency action.
- Inventory treasury and protocol-administration wallets, owners, thresholds and enabled modules or delegates; assign independent review of consequential transaction details.
- Separate signing from routine browsing and development where practical; document approved devices, software and a lost-device procedure without placing recovery secrets in the inventory.
- Protect privileged identities with phishing-resistant MFA where supported, review recovery dependencies and test an approved fallback using a synthetic account or controlled exercise.
- Reconcile joiner, role-change and departure records with actual identity-provider, GitHub, cloud, registrar and wallet authority; include service tokens and active sessions.
Start with an inventory and approved test evidence. Keep secrets out of the brief.
Framework references
Go a little deeper
Practical reading.
Connected work
Related services.
Smart contract security audits
Challenge the assumptions, permissions, and economic edge cases in the code that moves value.
Explore this service →03Incident readiness & response
Prepare the decisions, access, and evidence your team will need when normal assumptions stop holding.
Explore this service →04AI & supply-chain security
Examine what your agents can act on, what your build trusts, and how untrusted input can reach a privileged action.
Explore this service →