Where authority sits
We map who can move value, who can approve it, and where those two must never be the same person.
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 assess
We define authority, trust boundaries, recovery paths, and implementation requirements with your engineers.
What moves, and who can move it
We trace keys, funds, and messages across the system, marking every point where trust changes hands.
What happens when it goes wrong
We design the exception, break-glass, and recovery paths before an incident forces your team to invent them.
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.
Our approach
How we turn your design into requirements.
Map the architecture and trust boundaries
Agree the system’s purpose, constraints, and open design questions. Document actors, assets, authority, data flows, and dependencies in a shared model.
Compare controls against threats
Examine credible failure scenarios and compare ways to prevent, detect, and recover from them. Identify who would operate each control.
Record decisions and requirements
Document the selected controls, the threats they address, and why they were chosen. Turn those decisions into requirements for the implementation team.
Define readiness actions
Order the implementation work, assign owners, and define the checks that must pass before go-live.
What you receive
A design your team can build against.
Architecture and trust model
A shared view of boundaries, authority, and dependencies.
Decision log
The threats we considered, the requirements that followed, and why each control was chosen.
Readiness actions
What to build first, who owns it, and what has to be true before go-live.
Your engagement team
Meet the specialists
A principal leads each engagement. Your proposal names the specialists assigned to the scope.
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 experience in product security, IAM, cloud, DevSecOps, and blockchain. Previously held security roles at Tensor, EY, Broadcom, and ADP.
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.
FAQ
Frequently asked questions
How is this different from a security review?
Design work defines security requirements before implementation. A review checks the implemented system. The two can be scoped together.
What if the architecture is already built?
An existing system may need a review or risk assessment. Design work applies when you are planning a migration, a new custody model, or a change to an operational workflow.
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. If the engagement includes reviewing existing code, we need access to that code during scoping.
Who needs to be in the room?
The people who can change the design. That means 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.
Can you work from an existing design or threat model?
Yes. Share the current design, known risks, and decisions still open. We check the assumptions and focus on the changes or unresolved questions that need security input.
Related services
Other ways we can help
Signing & Custody Security Reviews
Review key generation, signing approvals, key use, and recovery across MPC, HSM, multisig, and custody platforms.
Explore 
Risk Assessment
Give leadership a prioritized view of where security risk concentrates and what to address first.
Explore 
Digital Asset Program Advisory
Make security, custody, vendor, and operating-model decisions across a broader digital asset program.
ExploreChallenge the design while it can still change.
Describe the proposed system, open design questions, and deadline. We will define the design scope.
Discuss your scope