NullMeridian Back through the wormhole

Void Council

NullMeridian’s whitehat security practice. Protocols and smart contracts first. Fixed scope per codebase and commit; the timeline is set after scoping.

Open a ticket on Discord Engage

Primary

Smart-contract and protocol security.

We read the code, specify what must hold, and try to break it. Fixed scope per codebase and commit. The timeline is set after a scoping call.

  1. 01

    Manual review

    Line by line, against a written threat model and invariant specification.

  2. 02

    Formal verification

    SMT, symbolic execution and model checking on the properties that matter.

  3. 03

    Invariant and stateful fuzzing

    What must never break, tested across call sequences.

  4. 04

    Report and PoCs

    Severity-rated findings with reproduction steps and remediation guidance. Foundry PoCs for High and Critical findings.

  5. 05

    Fix review

    A pass over your patches, checked against the original findings.

Retainers are available for recurring review of ongoing changes.

Also

Other capabilities.

Contracts come first. The rest is scoped the same way.

Incident response: available on request; contact us.

No live system is tested without written authorization. How authorization works.

Method

Threat model first.

Then the reading. Then the proofs.

  1. 01

    Threat model

    Assets, actors and trust assumptions, written down before the reading starts.

  2. 02

    Manual review

    Line by line, in Foundry. Tools support the reading; they don't replace it.

  3. 03

    Fuzzing

    Echidna, Medusa and Foundry invariant fuzzing against the specified invariants.

  4. 04

    Formal methods

    SMT, symbolic execution and model checking where the properties call for it.

  5. 05

    Deployed vs source

    Bytecode fingerprinting of what is deployed, and diffing against prior audited code.

  6. 06

    Threat intel

    We track the bug classes that are live now.

Deliverables

  • A threat model and invariant specification.
  • Severity-rated findings with reproduction steps and remediation guidance.
  • Foundry PoCs for High and Critical findings, built on local forks.
  • The invariant specs and harnesses, ready for your CI.
  • A fix-review pass.

Process

Five steps, in order.

A fixed scope and version from the start.

  1. 01

    Intake

    You send the request. We read it.

  2. 02

    Scoping call

    We fix the codebase and commit, write the threat model, and set the timeline.

  3. 03

    Review

    Read-only, on local forks. Critical findings are disclosed to you early, not held for the report.

  4. 04

    Report and walkthrough

    We go through each finding with your team.

  5. 05

    Fix review

    Patches are re-checked against the original findings.

Limits

  • Authorized testing only. Nothing outside the written scope.
  • We do not test live or production systems in a contract review.
  • We do not publish or weaponize exploits. Disclosure is coordinated.
  • No review makes code bug-free. We state the residual risk.
  • Live-system work needs written authorization. See the terms.
  • A mutual NDA is available on request, signed before any scope detail is shared.

Limits

What we will and won't do.

The limits are stated before any work starts.

Authorization

No live system is tested without written authorization from someone who can give it. You confirm that in your ticket, and sign it before any testing.

Live-system work

Live-system testing begins only after the client signs a written Testing Authorization and Rules of Engagement that lists every in-scope host, URL, IP range, API, and cloud account, confirms the client owns or controls them (or holds the owner's written permission), and names a testing window and emergency contact. Nothing outside that list is tested.

Authorization is given by a person with authority to bind the client and the right to authorize testing of the in-scope systems, who warrants both in the Rules of Engagement. Where a third party hosts or operates an in-scope system, the client is responsible for that party's required permissions.

We prefer a staging environment that mirrors production. Production testing happens only where you name the targets in writing and only within agreed limits: no denial-of-service or destructive tests without separate written approval, no bulk data exfiltration (we capture the minimum to prove a finding), no social engineering or physical testing unless separately authorized, and an immediate stop-and-notify if anything looks unstable or already compromised.

Engage

Engage

Start with the code, not a call.

Already in touch with us? Mention it in your ticket and we'll pick up where we left off.

Bring us:

  • The repository, or say it's private and we'll arrange access
  • The exact commit you want reviewed
  • What's in scope, what isn't, and the chain(s)
  • Your deadline, and what it's tied to
  • The failure you fear most

How it works:

We read your request and reply with questions or a fit/no-fit answer. If it fits, we scope a fixed commit and write a threat model. Nothing starts until the scope is signed.

Rules for tickets:

  • Never post private keys, credentials or seed phrases.
  • Don't post exploit details for an unpatched bug. We'll set up a secure channel.
  • Code is shared through your own repo invite, never as uploads.
  • Opening a ticket doesn't create an engagement.

Open a ticket on Discord

Active incident? Open an Incident ticket and say what's happening on-chain right now.

Back through the wormhole