SECURE ARCHITECTURE & PROCESS DESIGN
Make the security decisions before they become expensive to reverse.
Work through the architecture, custody model, approvals, and recovery paths with a senior engineer, before they are built into the system.
Design scope
What we design or challenge
Most of the security outcome is decided by four questions. We work them through with your engineers while the answers can still change.
-
01 Where authority sits We map who can move value, who can approve it, and where those two must never be the same person. -
02 What moves, and who can move it We trace keys, funds, and messages across the system, marking every point where trust changes hands. -
03 What happens when it goes wrong We design the exception, break-glass, and recovery paths before an incident forces your team to invent them. -
04 What the build team can act on We turn each decision into a constraint an engineer can implement and a reviewer can check.
Timing
Best used before you build.
Architecture is changeable
Core system and trust decisions have not yet hardened.
Automation is increasing
A high-impact workflow is moving from manual to automated.
A vendor is being selected
Custody, signing, platform, or integration choices need independent challenge.
A launch is approaching
A migration or launch needs design review before build completion.
Process
From open design questions to build-ready controls.
- 01
Frame the decisions
Define the system outcome, constraints, open architecture questions, and decisions that cannot be deferred.
- 02
Map trust and authority
Trace actors, assets, privileges, dependencies, data flows, and credible failure scenarios.
- 03
Design the controls
Compare options and define prevention, detection, response, recovery, and operational ownership.
- 04
Prepare for build
Turn the chosen design into requirements, a decision log, implementation priorities, and readiness checks.
Outputs / What you receive
A design your team can build against.
Architecture and trust model
A shared view of boundaries, authority, and dependencies.
Decision log
Threat scenarios, security requirements, and control choices.
Readiness actions
Implementation priorities, ownership, and go-live checks.
Typical engagement team
Who typically leads this work
The exact team depends on the scope. Every engagement has a principal who owns it from scoping through delivery, joined by the specialists the system calls for, and whoever is assigned is named in your proposal.
Timur Güvenkaya
Founder & Partner
Led a security engineering practice for Rust and non-EVM systems across Substrate and NEAR. Earlier, built vulnerability-detection engines at Invicti used by Fortune 50 and public-sector organizations.
Paul Vijender
Specialist Advisor
Head of Security at Gauntlet, with depth across product security, IAM, cloud, DevSecOps, and blockchain. Previously held security roles at Tensor, EY, Broadcom, and ADP.
Currently
Head of Security, Gauntlet
$1.6B+ TVL
Piotr Cielas
Principal Advisor
Head of Security at Agora, responsible for security, data protection, and corporate IT risk. Earlier at EY, led assessments across financial services, healthcare, and government.
Currently
Head of Security, Agora
$45B+ in volume
FAQ
Questions before scoping
How is this different from a security review?
A review examines a system that already exists and reports what is wrong with it. This engagement runs earlier: we work on the design itself, so the decisions a review would later flag never get built. Many clients do both: design first, review after implementation.
What if the architecture is already built?
Then the honest answer is usually a review or a risk assessment instead, and we will say so during scoping. Design work still applies where a significant change is coming: a migration, a new custody model, or a workflow moving from manual to automated.
Do you need access to our code?
Not necessarily. This work runs on architecture, data flows, threat scenarios, and conversations with the people who will build it. Code access helps when a design decision depends on how something already behaves, but it is not the starting point.
Who needs to be in the room?
The people who can actually change the design: the engineers who will build it, whoever owns the operational workflow, and someone who can make the call when there is a tradeoff. On our side a principal runs the engagement, with the specialists the system calls for.
What do we walk away with?
A trust model your team agrees on, a decision log recording what was chosen and why, and security requirements to build against. The decision log tends to matter most later, since it is the record of why the system looks the way it does.
Related services
Signing & Custody ReviewsReview how keys are generated, approved, used, and recovered across MPC, HSM, multisig, and custody platforms.Risk AssessmentGive leadership a prioritized view of where security risk concentrates and what to address first.Digital Asset Program AdvisoryMake security, custody, vendor, and operating-model decisions across a broader digital asset program.
Next step
Challenge the design while it can still change.
Share the proposed architecture, constraints, users, vendors, and critical decisions. We will define the right design workstream.
Discuss your scope