Structured Trust Assurance

When people think about "security", most of them imagine firewalls, audits and clever custody setups. In the digital asset world we also like to point to infrastructure and tools and say: this is where the safety comes from. These things matter of course. But there is a much simpler and more direct point where everything becomes real, and that's the moment when someone (or something) signs.

At the signing step an intention turns into an action that you can't easily take back. Money moves, roles and permissions change, contracts get upgraded, governance decisions are locked in. Before that point people discuss, plan and prepare. After the signature you deal with the concrete results, good or bad. My argument here is, that security has less to do with isolated controls spread around the system and much more with how trust is organized around those signing moments. I want to show how normal day-to-day processes quietly grow into a de facto trust model, how I am building a tool that makes this structure visible, and why it matters in systems where a few actions can have a huge impact.

Trust that grows in the dark

In practice organizations rarely sit down, design a complete trust model and then follow it consistently. The trust model grows over time, a bit messy and improvised.

You handle one exception because something is urgent, and then the exception stops being exceptional. A bot that was meant to be temporary becomes part of the normal workflow, because removing it is more work than keeping it. Some signer group gets reused because people are busy and don't feel like setting up a new configuration. One laptop is used for more and more tasks, until it quietly becomes the laptop for a set of critical operations.

Bit by bit these local decisions pile up and harden into a governance structure nobody ever wrote down, but everybody depends on. In the documentation you might see tidy diagrams of multisig wallets and roles, written policies about who approves which actions, and statements that separation of duties is in place. Then you look how things actually happen and you often find:

the same signers showing up in very different critical flows
"independent" paths that share devices, providers or vendors
shortcuts that only exist in people's heads or in some private chat
automation nobody fully understands anymore, and nobody dares to touch

The gap between the formal description of trust and how trust really works day to day is where a lot of the interesting risks are. I want to close some of this gap by turning real operations into an explicit trust model, something you can inspect and discuss, and not just assume.

Describing how work really happens

The tool I am building takes your real business processes, the way work is done when people are in a hurry or just follow habits, and turns them into a structured picture of trust. It's not about fancy visuals. The output should be something a reasonably technical person can read and argue about.

The starting point is simple. You describe your processes as chains of objects that interact with each other. A very common pattern looks like this:

a signer uses a hardware wallet → the hardware wallet plugs into a laptop → the laptop connects to a web interface → the web interface sends a transaction to an RPC node → the node broadcasts the transaction → the contract executes some change.

You can write it in arrow notation or in plain sentences, doesn't matter. What we capture is who interacted with what, through which path, and what came out at the end.

On top of that comes context you probably think about anyway when you design or review processes: how much value could be affected if something goes wrong, how often the process runs (once a year, once a day, dozens of times per hour), how often it is treated as urgent, which parts may be automated and which are expected to be manual, and any hard constraints you are stuck with, like jurisdictions, staffing limits, uptime requirements or regulatory expectations.

And some basic information about the objects: who owns or operates each one, roughly where they are (region, environment, time zone), whether it's a human, a bot, a backend service or an MPC party, and which dependencies they share. Same cloud provider, same fleet of devices, same team, same vendor.

The tool doesn't need a perfect and fully up-to-date inventory to be useful. A reasonably honest approximation of reality is enough, plus the willingness to adjust the model when you learn more.

Under the hood: graphs, paths, layers of risk

Internally all of this becomes a graph. Nodes are objects like people, devices, applications, infrastructure pieces or on-chain contracts. Edges are actions or relationships, like "uses", "connects to", "signs", "sends transaction", "broadcasts", "executes", "approves" or "changes policy". A business process is then just a path through a sequence of those nodes and edges.

Once you have the graph, you can ask questions that are surprisingly awkward to answer when all you have are policy documents and some spreadsheets:

Which concrete paths in the system can move funds from A to B?
Which paths can change who has long-term control over a pool of funds?
Which people, devices, vendors or components sit in the middle of several important processes at the same time?
What happens if one object fails or gets compromised, say a single laptop, one RPC provider or a specific CI pipeline?

I don't want one vague "risk score", so the tool looks at risk in separate layers. First, who or what could cause harm: external attackers, insiders, third-party providers, or just accidents. Second, how the harm would actually happen: technical compromise, social engineering, physical access, a manual process breaking down, or misuse of a policy or contract. And third, what makes it easier than it should be, like single points of failure, weak separation of duties, shared dependencies that were supposed to be independent, bad recovery planning or missing monitoring.

The point is not a long list of worst case horror stories. The goal is to attach realistic, concrete situations to the objects and paths you already rely on, and then see how well (or how badly) the organization would absorb them.

A really important step is to look where different processes intersect. This is often where comfortable assumptions meet awkward reality. Processes can look well controlled on their own, but combined the whole structure turns out fragile, because the same small group of signers or systems sits in positions where they can, in effect, override everything else. For example:

the same quorum of signers can approve both contract upgrades and large treasury transfers
an upgrade path quietly grants new transfer capabilities, which was not obvious from the documentation
a single CI pipeline or admin key indirectly controls many systems that should be independent

When you see patterns like this, you realize you may have built a universal takeover path. Not because anyone wanted it, just because of how separate processes were put together over time. And this is exactly the kind of thing the graph brings to the surface.

What comes out of it

I know, it sounds like a mix of different threat modeling approaches. It is more than that though, the main point is automating and simplifying the whole process. And the tool should produce a few concrete outputs you can use to change things, not to decorate slides.

A minimal signer pool and hierarchy. First, a proposal for a minimal signer pool and signer hierarchy across all the processes you modeled. If you optimize the signer setup for each process in isolation, it's easy to convince yourself that everything is fine. The real picture is how all of them fit together. So the tool tries to keep everyday operations practical (no unrealistic approvals for simple, low-risk tasks), to reduce dangerous overlaps between actions that can change a lot, and to separate clearly between control plane powers (upgrades, role admin, config changes) and funds plane powers (transfers, withdrawals). Signer reuse is not automatically bad. The tool only highlights where reuse concentrates too much power in the same hands or systems.

A "to-be" graph. Second, a modified version of your system with the same business outcomes but a different trust structure. That can mean replacing single signers with threshold schemes for some actions, splitting sensitive flows into propose, approve and execute, putting policy enforcement between the UI and the RPC layer, or separating devices, vendors or teams across paths that should not be able to compromise each other. You put the "as-is" and "to-be" graphs side by side and see exactly what changed and which problem each change is supposed to solve.

Policy rules and guardrails. Third, a set of policy rules that can be enforced in code or configuration, so the system doesn't depend completely on people always doing the right thing. Transaction size limits and allowlists, timelocks for changes with big or long lasting impact, extra approvals when certain risk thresholds are crossed (amount, asset type, destination), and constraints on which kinds of transactions can come from which process paths. If you ever saw a perfectly reasonable process break because one "special urgent case" was handled informally, you know why it's good when the system enforces this by itself.

Organizational controls. Fourth, organizational and administrative controls. Some of the more important risks don't live in cryptography or smart contract code at all. They live in who reports to whom, where people are, how they travel and what incentives they have. From the graph the tool might tell you that certain signers should not be in a direct reporting line, that some groups would be safer in different regions or time zones, that specific people should not all be at the same place at the same time during certain periods, or that a few roles need clearer rules about conflicts of interest. In those cases the answer is not "add another key". The answer is to change how people and responsibilities are arranged around the keys and systems you already have.

Making trade-offs explicit

The main benefit I am aiming for is not that the tool tells you to "add more security". It gives you a clearer picture of how things really work, so you can discuss trade-offs in concrete terms and not in guesswork.

You get one map that shows how authority and value move through your organization. And you can see how decisions made for convenience (reusing signers, more automation, one standard vendor, skipping a step in the approval chain) slowly reshape the trust model, even if nobody updates the documentation.

It also makes it possible to talk about trade-offs more calmly. Sometimes speed really is important, automation is necessary or a smaller signer set is simply the practical option. The tool doesn't shame those choices. It shows what they cost in terms of trust and suggests where compensating controls could go: more separation in the control plane, stronger guardrails on high-risk actions, or some simple organizational changes.

For audits, incident reviews or internal governance debates you then have something to point at. Instead of arguing from intuition or fear you can say: these are the paths we really use in production, these are the overlaps and shared dependencies we rely on, this is how one action or system can dominate another, this is the redesigned hierarchy we consider, and this is the risk that remains and that we choose to accept. Not every discussion becomes a simple yes or no. But the conversation is anchored in structure and not in vague feelings.

Why now

I work on this now because the ecosystem reached a point where the old pattern of "a few smart people with hardware wallets" is obviously not enough anymore. There is more value under management, more bots moving that value, more third-party integrations, more regulation and scrutiny, and attackers who are more capable and more motivated. The informal trust models from the times when teams were small and systems simple don't hold up very well in this environment.

Distributed ledgers are also quite unforgiving. They don't care how confident someone sounded in a meeting, or how sure a team was about an exception. If the wrong thing gets signed, it will be executed. In a way this harshness makes it very clear that most of what we call "security" is actually governance, and how the day-to-day operations are designed.

If the tool does its job, the result should be more than nicer diagrams or a bit tidier multisig configs. I want a reusable way to translate business decisions into explicit trust structures, and over time to distill a baseline of patterns that work whether it's a stablecoin, a protocol treasury, a fintech approval workflow or any other system where a small number of actions can have very large effects.

I call it STACKED, Structured Trust Assurance in Crypto Key Environment Deployments. It's not a magic solution. It's a practical way to see how your trust actually works today, and to shape it on purpose, instead of letting it grow by accident.