Raw Signing Is a Liability, Not a Feature

Some of the most dangerous decisions in institutional crypto rarely look dangerous at the time. Instead, they look like routine configuration. Raw signing is one of them.

Third-party risk remains a material issue across this industry, and most especially for organizations using self-custody, MPC wallets. We have seen it play out time and time again, across firms of every size and sophistication. As our customer base has grown to include hundreds of institutions, we have found ourselves in more and more conversations where customers reach out, often just looking for a straight answer, about the pros and cons of enabling raw signing. Those conversations have followed a consistent pattern. It usually starts with a vendor asking them to enable it, nobody on their team pushing back, and the risks not fully explained.

To understand why raw signing is high risk, you have to understand what it removes. Raw signing strips out the policy layer that makes institutional custody defensible. When you authorize a raw transaction, you are bypassing the guardrails your risk team believes are in place: the controls that restrict what can be signed, by whom, and under what conditions. Some of the most widely used self-custody wallet providers in the industry display an explicit warning when you attempt to enable this feature. That warning exists for a reason. Most firms click past it because a vendor told them to.

The specific risks of raw signing worth understanding:

• You cannot verify what you are signing. Raw signing bypasses transaction parsing entirely. What looks like a routine transfer could encode a contract interaction, a permissions change, or a full wallet drain.

• Your policy controls do not apply. Allowlists, velocity limits, and approval thresholds are built around standard transaction flows. Raw signing routes around them.

• You inherit your vendor's entire risk surface. If their infrastructure is compromised, your signing capability is implicated. If their code is buggy or their controls are weak, you will not know until after the fact.

• Every vendor granted raw signing capability is a new point of failure inside your signing process.

The question of who should actually be using this has a short answer: firms with serious in-house expertise, tight controls, and a documented risk acceptance process. That is a much smaller group than the number of firms currently enabling it. You need engineers who understand precisely what is being signed, what controls are bypassed, and what the failure modes look like. If that expertise does not exist internally, enabling raw signing is a serious risk you are ignoring.

Beyond internal readiness, my recommendations are straightforward. Vendors should not be asking you to do this as a matter of normal course of business. If a vendor requires raw signing to make their product work, they have built their operational dependency into your signing process. That is a meaningful red flag, not a standard integration requirement. Know your vendors. Any third party with access to your signing layer should have robust internal security teams, documented audit histories, and clear answers to what happens when they get breached. If they cannot answer those questions clearly, walk away. And do not enable raw signing because a vendor asked you to. The ask may be framed as routine, when it clearly shouldn’t be.

For those institutions that genuinely require it, the technical bar for responsible use is high. Policy controls must tightly constrain what the capability can authorize. Audit infrastructure and independent validation are required at every step. Robust centralized logging, alerting and incident management frameworks are a must-have. Risk acceptance needs to be documented and reviewed regularly. And there must be a clear, tested answer to what happens if the upstream vendor is compromised. If you cannot put all of that in place before you flip the switch, the answer is to wait until you can.

The institutions that will navigate this landscape successfully are the ones asking hard questions before enabling raw signing, not after something goes wrong. Your vendors should be able to justify every access point they require. If they cannot, that right there is your answer.