The expensive decisions are made before there is code to review.
Who can upgrade. What the pause path is. Whether custody sits with you, a vendor, or a threshold of people who have never met. An audit can tell you the code implements those decisions correctly. It cannot tell you they were the right ones. Guardian advises while they are still decisions, and builds what the answer requires.
- Architecture & controls
- Solutions
- Evidence & diligence
- Governance
Nothing here is about code quality. It is about which system you chose to build, and how much a different answer costs at each point on the curve.
Draw the trust boundaries before you build across them.
Most severe findings are not mistakes in a function. They are a privileged role nobody meant to create, a pause path that stops the wrong half of the system, or custody that turned out to depend on one laptop. Guardian works those out on paper, where changing your mind costs a meeting.
- Trust boundaries What each component is allowed to assume about the others, and which assumptions become exploitable the first time a dependency behaves badly.
- Privileged roles Every role that can move value, change parameters, or alter who holds a role — enumerated deliberately rather than discovered in an audit.
- Custody and signing Where keys live, who signs, what the threshold is, what happens when a signer is unreachable, and whether recovery has ever been tested.
- Upgrade and pause paths What can be changed after launch, who agrees to it, how fast it can happen, and what a pause actually stops on the worst day.
- Integration boundaries Bridges, oracles, and upstream protocols reviewed where their assumptions become yours, before you have built on top of them.
Nobody decides to ship an unbounded upgrader. It arrives by accretion, one convenient change at a time, and an audit meets it fully grown.
Advice you can act on, then the thing itself.
A recommendation that lands in a document nobody owns is not a control. Where the answer is work rather than an opinion, Guardian does that work: the threat model, the control specification, the runbook, the monitoring, and the confirmation that the whole thing is wired up the way it was drawn.
The test of an advisory engagement is whether anything is different six months later. These are the artefacts that make that answer yes.
- Threat model Who would attack this, what they would go for, and which of your assumptions they would test first — written down so it can be argued with.
- Control specification The controls named, scoped, and assigned, in enough detail that an engineer can implement them without another meeting.
- Runbooks Custody, signing, and incident procedures written for the person who will be holding the phone, then rehearsed with them.
- Monitoring What to watch, what should page someone, and what is only worth a weekly line — so alerting survives contact with a real week.
- Implementation review Confirmation that what was built matches what was specified. A control that exists on paper and not in the system is the most dangerous kind.
Answer the question once.
Exchanges, custodians, bank partners, institutional allocators and ecosystem programs all ask the same forty questions in different spreadsheets. Guardian assembles the answer as evidence — what was reviewed, what the controls are, what is still open, and who owns it — so the next request is a link rather than a fortnight.
- Security posture Current risk profile, known assumptions, mitigations, control owners, and residual exposure, stated plainly enough to be checked.
- Control mapping How controls map to the architecture you actually run rather than to a framework template that was never about your system.
- Evidence packages Audit outputs, retest status, monitoring coverage, operational controls, and release history, assembled so a reviewer can follow the chain.
- Partner diligence Technical responses for exchanges, custodians, institutional partners, and ecosystem programs — answered once and kept current.
- Residual risk, stated What you have accepted and why. Reviewers trust the pack that admits something far more than the one claiming everything is closed.
The cost of not having this is rarely a lost deal. It is the engineer-weeks a year that go into re-deriving the same answer.
What does this proposal actually change?
Governance proposals are written by the people who want them to pass. Guardian reads the change the way an attacker would and frames it in language a voter can act on: what permissions move, what becomes possible that was not before, and what the reversal path is if it turns out to be wrong.
No claim in the proposal is false. The framing is simply doing a lot of work, and that is what a plain-language read is for.
- Permission deltas Exactly which roles, thresholds, and timelocks a proposal moves, stated against the deployed state rather than the description.
- Plain-language risk framing What becomes possible that was not before, written for a voter rather than for a reviewer who already knows the system.
- Reversal path How the change is undone if it is wrong, who can do that, and how long it would take while value is moving.
- Upgrades and parameter changes Reviewed against the contracts actually deployed, including the ones the proposal does not mention but touches.
- Emergency actions The powers a team grants itself for a bad day, scoped so they are usable in an incident and not useful to anyone else.
Bring the question before it becomes a migration.
An architecture diagram and an hour is usually enough to tell whether the expensive version of this conversation is coming. Send us the one you have.