$1,000,000 in security audit grants are live now, Apply here →
Programs · Digital Asset Security Pilot

A security pilot for regulated digital asset programs.

We work with your organization to assess your architecture and design against secure best practices and regulated standards. We bring the hands-on experience and lessons from hundreds of prior engagements to your digital assets program.

Pressure test your architecture in a security pilot
Pick your modules
Module 01 Architecture assessment

A wholistic architecture & design assessment.

A digital asset system is mostly not onchain. It is a custody arrangement, an issuance path, a reserve ledger and the operators around it. The security model is concerned with every piece of the architecture.

  • Custody and key ceremony Where the keys live, who holds what share, what a quorum actually requires in practice, and what happens the day somebody leaves or a device is lost.
  • Privileged control surface Who can upgrade, pause, mint, set parameters or move funds, whether that authority sits behind a threshold or a single key, and how long it takes to use it.
  • Every route value can take Issuance, redemption, reserve movement, and the oracles and bridges you inherit risk from. Most designs have more routes than originally intended, and the extra ones are rarely guarded.
  • The operational security model How the organization actually runs the system: who approves what, how joiners and leavers are handled, and what single points of failure need to be diversified.
  • Threat modeling A wholistic attack surface map, with every way that funds can be moved or the system can fail.
Your architecture and weak points, under reviewthreat model
PEOPLE & OPS SERVICES & CLOUD CONTRACTS operator engineer signer vendor console signing CI/CD oracle Vault Timelock Token REVIEWED AGAINST A ROBUST SECURITY MODEL custody controls operations threat model
Module 02 Standards alignment

Review for standards and regulatory alignment.

MiCA, DORA and their equivalents make specific demands of custody, resilience, incident handling and third-party risk, and almost all of them are architectural rather than administrative.

Regimes, obligations, and where you standcompliance
REGIME OBLIGATION STATUS MiCA Client assets segregated DORA Incidents reported in window DORA Critical third parties mapped NYDFS 500 MFA on every privileged path CCSS L2 Key ceremony witnessed ISO 27001 Change control enforced

Put into practice your legal and regulatory requirements at an engineering level.

  • MiCA Safeguarding and segregation of client assets, the custody arrangement you have to be able to evidence, and the obligations that land on issuers of asset-referenced and e-money tokens. Most of it is decided by how the system holds keys.
  • DORA ICT risk management, incident classification and the reporting window you are committing to, and the critical third parties you depend on. A reporting deadline you cannot meet is a design problem found at the worst moment.
  • Control standards, mapped to the system CCSS levels, ISO 27001 and NIST CSF mapped onto the actual key ceremony and change control, plus NYDFS Part 500, the FCA regime, MAS and VARA where they apply and where two of them disagree.
Module 03 Assurance engineering

Assurance built into how you ship.

A design is only as good as what holds it up between releases. We build the suites that prove your properties still hold, the gates that stop a change that breaks them, and the checks that confirm what reached the chain is what you staged.

  • Invariant suites and fuzzing The properties the system must never violate, written as executable suites and driven by fuzz campaigns that look for the sequence nobody thought to write a test for.
  • Engineering processes and review gates What has to be true before a change can merge: who approves, what is signed, which suites must pass, and what happens to the branch when one of them does not.
  • Deployment operations and validation practices Storage layout, initialisers and roles checked against what was staged, then the onchain state read back and compared to what you intended to deploy.
From commit to livegates
GATE WHAT RUNS BLOCKS ON Review 2 approvals, signed unsigned commit Invariant suite 46 properties any violation Fuzz campaign 40M sequences new counterexample Deploy validation bytecode, configuration drift from staged Post-deploy check state vs intended mismatch NOTHING REACHES LIVE WITHOUT ALL FIVE Built with your engineers, and left running after the engagement ends.
Module 04 Smart contract audit

A scoped Smart Contract audit.

Guardian performs a full audit of the contracts in scope, on the approach every Guardian engagement runs on: two competing teams over the same code in parallel, one driving expert manual analysis and one leveraging frontier AI, with an exhaustive invariant suite fuzzing underneath both.

One audit in scopefindings
IN SCOPE READ AGAINST FOUND Vault.sol 8 invariants 3 Router.sol 6 invariants 1 Issuance.sol 11 invariants 4 Timelock.sol 4 invariants 0 RewardDist.sol 7 invariants 2 SEVERITY 1 critical 2 high 4 medium 3 low Ten findings, all resolved and re-reviewed against the fix before the report closed.
  • Read against the invariants State transitions, access control, accounting, upgrade paths, and the assumptions the contracts make about every protocol and oracle they touch.
  • Findings with severity and remediation Each one written with the impact, the conditions needed to reach it, and the fix, then re-reviewed against your change before the report closes.
  • The same bar as any Guardian audit Same reviewers, same methodology, same report. The pilot decides how much goes in scope, not how carefully it is read.
Module 05 Offchain pentests

Offchain pentests for critical surfaces.

Most of what can move value in a digital asset program is ordinary infrastructure: consoles, APIs, signing services and the cloud account holding them. We test it the way somebody trying to reach your keys would, and every finding is reproduced by an engineer before it reaches you.

  • Infrastructure pentest Hosts, ports, edge and cloud configuration, and the privilege paths between them, tested from outside and again from the position of a first foothold.
  • WebApp pentest The console and the customer-facing app: authentication, session handling, authorization between roles, and the logic behind the buttons that move money.
  • API pentest Authorization between accounts, injection, rate and replay handling, and everything the documented endpoints do not say they also do.
  • Browser extension pentest Wallet and signing extensions: message passing, permissions, the content script boundary, and what a malicious page reaches through it.
  • SDK audit The libraries you hand to integrators, read for the assumptions they make and the ones they quietly let a caller break.
  • Offchain automation pentest Keepers, bots, sequencers and anything else holding a key on a schedule, reviewed at source and tested for what it does under conditions nobody planned for.
One engagementoffchain
TARGET TESTED FOR FOUND admin console auth, session, roles 2 public API authz, injection, limits 3 signing service key reach, session reuse 1 cloud account privilege paths 4 code host token scope, branch rules 1 Scoped penetration testing to the critical pieces your digital asset system relies on.
$45B+In digital assets secured across Guardian engagements
300+Critical vulnerabilities reported and resolved
150+Teams trusting Guardian with their contracts
25+Global security competition wins

Guardian has already pressure tested hundreds of digital asset systems, let's see what we'll find in yours.

Book your pilot overview call
The pilot

Designed around your digital asset program's roadmap.

The pilot is deliberately structured to be low commitment and easy for your vendor process to accept. This is a bounded way to work with Guardian and see what digital asset security services look like for your organization. You choose the modules within the pilot which are most applicable to your digital asset program roadmap.

Pick the modules that accelerate your roadmap.

Design

The custody model, issuance path and operator roles are still being decided.

Build

Contracts, services and the engineering process that ships them are being written.

Pre-launch

The code is finished and the infrastructure that will hold client assets is standing up.

Live and scaling

Client assets are onchain, regimes phase in, and new chains keep arriving.

An example roadmap. Your pilot is scoped to where your program actually sits.

Security & compliance

Standards and controls we hold ourselves to.

The evidence your risk team will ask for, stated as it actually stands rather than as it reads best.

  • NIST CSF 2.0 Aligned Internal controls mapped to the framework your reviewers already read.
  • CCSS Aligned Our own key management held to the same bar we assess yours against.
  • SOC 2 Type II Auditor engaged Underway. We will tell your risk team exactly where we are in it.

Get Guardian involved in a low risk engagement with maximal upside.

Start with the overview call. By the end of it you will know whether the pilot is the right next step, and what it should cover for you.

Book your pilot overview call