Security Research & Advisory

Advisory work brings security reasoning into design decisions before code is written or before an architecture becomes hard to change. It covers protocol design, key management, governance, infrastructure and development practice, and produces decisions and documents the team can keep using.

Security decisions made early, while they are still cheap.

Discuss your requirements Audit-readiness checklist

Illustration of an architecture drawing under review: components grouped by dashed trust boundaries, numbered threats at the boundary crossings, a brass rule and a set square on the sheet.

Service overview

Security reasoning, applied while the design can still change.

Advisory covers the decisions that shape a protocol before and between audits. Each area produces something written that your team can act on.

An audit tests code that exists. Many of the most expensive findings, though, trace back to decisions made long before the code was written: a single admin key, an upgrade path with no delay, an oracle with one source, a bridge that trusts a small committee. At design stage those are conversations; after deployment they are rewrites.

Advisory brings the same adversarial reasoning used in audits to architecture documents, threat models, key-management plans and governance parameters. The output is a set of written decisions with the reasoning behind them, ranked by the loss they prevent.

Independence is protected. If we advise on a design, any later audit report from Quantix discloses that, and you may prefer a different reviewer for the audit itself.

Best timing: Before the design is fixed, and between audits
Formats: Architecture review, threat-model workshop, ongoing advisory
Output: Memos, threat models and checklists your team keeps

Applies to

Protocols in design or pre-audit stages
Key-management and custody architectures
Governance and upgrade frameworks
Cross-chain and bridge designs
Security programmes for growing engineering teams

Threat modellingArchitecture reviewKey-management designSecurity roadmaps

Threats addressed

Design decisions that become critical findings later.

Each of these has caused real losses in the ecosystem. All of them are cheaper to change in a design document than in deployed code.

Key compromise
Single key with unlimited power
An owner or admin key that can upgrade, mint or drain, with no threshold, delay or scope limit.
Upgrade risk
Upgrades without a delay
Implementation changes that take effect immediately, leaving users no time to react to a malicious or faulty release.
Oracle manipulation
One price source
Prices read from a single pool or feed, with no deviation checks, staleness limits or circuit breakers.
Governance manipulation
Capturable governance
Voting power that can be borrowed, low quorums, or proposals that execute before anyone can review them.
Bridge message validation
Small trust committees
Cross-chain designs where a handful of signers or a single relayer can release funds on another chain.
Business logic
Unwritten invariants
No written statement of what must always hold, so neither tests nor reviewers can check it.
Composability risk
Unexamined dependencies
Assumptions about external tokens, vaults or lending markets that nobody has written down or tested.
Infrastructure exposure
Operational keys on servers
Keepers, relayers and deployers holding keys on infrastructure with a broad attack surface.
Incident readiness
No plan for the first hour
No tested pause, no named roles and no prepared communications when something goes wrong.

Technical capabilities

Eight areas of security advisory.

Scope follows the decision in front of you. Most engagements combine two or three areas.

Protocol architecture review
Contract boundaries, trust assumptions, upgrade paths and external dependencies, reviewed while they can still change cheaply.
Threat modeling
Who could attack the system, through which boundary, with what gain. Prioritised so effort goes where loss would be largest.
Secure development practices
Review gates, testing strategy, invariant and fuzz testing, dependency management and release discipline for contract code.
Key-management architecture
Which keys exist, who holds them, how they sign, how they rotate, and what a single compromised key could do.
Governance security
Multisig thresholds, timelock delays, proposal validation and the paths by which governance itself could be captured.
Infrastructure risk assessment
Frontends, RPC providers, keepers, CI pipelines and cloud accounts: the operational dependencies of on-chain code.
Security-readiness planning
What to fix, review and monitor before launch, in what order, and how to sequence audits against the release plan.
Incident readiness
A written response plan, named roles, a tested pause procedure and the communications to prepare in advance.

Assessment methodology

From the question you have to a decision you can defend.

Every advisory engagement is framed around a decision or milestone, and ends when there is a written answer to it.

The seven-stage Quantix workflow

01
Frame the decision
Agree the question, the milestone it serves and what a useful answer looks like.
02
Gather design material
Architecture documents, diagrams, early code, governance parameters and operational runbooks.
03
Map trust boundaries
Draw where trust changes hands and which actors, keys and dependencies sit on each side.
04
Threat model and prioritise
Enumerate threats per boundary and rank them by the loss they would cause and how likely they are.
05
Recommend and review
Written recommendations, reviewed with your engineers so they are practical as well as correct.
06
Plan the next milestone
A readiness plan for launch or audit, with what to fix, test and monitor first.

Draw the boundaries, then ask what crosses them.

A threat model maps where trust changes hands: between users and the frontend, operators and contracts, governance and code, contracts and their dependencies. Each boundary gets its threats and the controls that answer them.

Threats and mitigations in the illustrative threat model
ID	Boundary	Threat	Typical mitigation
T1	Users → frontend	Malicious transaction served by a compromised frontend	Subresource integrity, DNS and hosting hardening, transaction simulation in the wallet
T2	Users → contracts	Price manipulation within a single transaction	Manipulation-resistant pricing, deviation guards, bounded actions per block
T3	Operations → contracts	Leaked keeper or deployer key used to call privileged functions	Least-privilege roles, separate keys per function, monitoring of privileged calls
T4	Governance → contracts	Malicious or mistaken upgrade executed without review	Timelock with enforced minimum delay, release hash verification, public queue
T5	Dependencies → contracts	Stale or manipulated oracle value accepted	Staleness and deviation checks, fallback feed, circuit breaker
T6	Contracts → bridge	Forged cross-chain message accepted	Message verification review, rate limits, independent watchers

Illustrative threat model for a generic DeFi protocol. Not drawn from a client engagement.

Three formats, chosen by the question you need answered.

Advisory engagements are scoped in reviewer-days around a specific decision, design or milestone, and end with written output.

Architecture review

A focused review of a design document or early codebase, delivered as a written memo with prioritised recommendations and a walkthrough with your engineers.

Threat-model workshop

Working sessions with the people who built the system, producing a threat model the team owns and updates as the protocol changes.

Ongoing advisory

A standing arrangement for design reviews, second opinions on findings and security questions as they arise, scoped in reviewer-days per month.

Tools & techniques

Public frameworks, adapted to how protocols actually fail.

Advisory relies on established methods so your team can continue the work without us. Each is adapted to on-chain systems.

Tools and techniques used for Security Research & Advisory
Tool or technique	Category	What it is used for
STRIDE per trust boundary	Threat modeling	Structured enumeration of spoofing, tampering, repudiation, disclosure, denial and elevation threats at each boundary.
Attack trees	Threat modeling	Breaks a high-value goal, such as draining the treasury, into the paths that reach it and the controls on each.
Data-flow and trust-boundary diagrams	Architecture	Shared picture of components, actors, keys and dependencies that the threat model is built on.
OWASP Smart Contract Top 10 and SCSVS	Checklists	Public references for smart contract weakness classes and verification requirements.
EEA EthTrust Security Levels	Checklists	Public specification of security requirements for EVM smart contracts, used as a reference.
NIST SP 800-57 principles	Key management	Key lifecycle, separation of duties and rotation principles applied to signer and multisig design.
Slither printers	Architecture	Inheritance, call-graph and authorisation summaries that check the code matches the intended design.
Governance parameter review	Governance	Thresholds, quorums, voting periods and timelock delays compared with the actions they protect.

Ecosystem coverage

Technical depth per execution environment.

Architecture risk differs by execution model: account and storage models, upgrade mechanisms and governance tooling vary across ecosystems.

Ethereum

Layer 1, proof of stake EVM

Programming languages: SolidityVyperYul
Assessment methodologies: Line-by-line manual review
Invariant fuzzing (Foundry, Echidna)
Symbolic execution and formal verification
Economic attack modelling
Typical vulnerabilities: Reentrancy, including read-only reentrancy
Oracle and spot-price manipulation
Access control on privileged functions
Proxy storage collisions and initializer misuse
Signature replay across chains and contracts
Front-running and MEV exposure
Monitoring capabilities: Proxy admin and implementation changes
Governance proposals and timelock queues
Large transfers and treasury outflows
Oracle deviation against reference feeds
Supported standards: ERC-20ERC-721ERC-1155ERC-4626EIP-2612EIP-712ERC-1967ERC-4337

Ecosystems indicate technical specialisation only, not partnerships or endorsements.

Relevant research

Read the work behind the service.

Research on the design decisions that most often become findings, and the assessments where architecture was reviewed.

Research hub

Publications

Case studies

All case studies

Research assessments

Security assessments library

Compare all services

FAQ

Questions teams ask before an engagement

Before the design is fixed. An audit tests code that exists; advisory shapes the decisions that determine what the code will look like. Problems found at design stage cost a conversation rather than a rewrite.

Independence matters. If we advise on a design, we disclose that in any subsequent audit report, and you may prefer a different reviewer for the audit itself. We will discuss this openly at the start.

Advisory produces reviews, decisions and documentation. We may sketch an approach or a test, but your team owns the implementation, which keeps reviews of that code independent.

Written artefacts your team can keep using: an architecture memo, a threat model, recommendations ranked by risk, and a readiness checklist for the next milestone.

No. It is an illustrative model for a generic DeFi protocol, showing the format a delivered threat model takes.

Make the security decisions while they are still cheap.

Share a design document, a repository or just the question you are trying to answer. We will tell you which kind of review would help most.

Discuss your security requirements Read the methodology

Security Research & Advisory

Applies to

Single key with unlimited power

Upgrades without a delay

One price source

Capturable governance

Small trust committees

Unwritten invariants

Unexamined dependencies

Operational keys on servers

No plan for the first hour

Protocol architecture review

Threat modeling

Secure development practices

Key-management architecture

Governance security

Infrastructure risk assessment

Security-readiness planning

Incident readiness

Frame the decision

Gather design material

Map trust boundaries

Threat model and prioritise

Recommend and review

Plan the next milestone

Draw the boundaries, then ask what crosses them.

Three formats, chosen by the question you need answered.

Architecture review

Threat-model workshop

Ongoing advisory

Ethereum

Architecture memo

Threat model

Key-management matrix

Governance review

Readiness plan

Incident plan outline

Key assessment areas

Typical deliverables

Is your code ready to be audited?

Publications

Case studies

Research assessments

Other disciplines

Questions teams ask before an engagement

When is advisory more useful than an audit?

Will advisory work conflict with an audit later?

Do you write code for us?

What do we receive at the end?

Is the threat model on this page from a client engagement?

Make the security decisions while they are still cheap.