Raw signing is a liability, not a feature

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

Third party risk remains a material issue across this industry, 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 find 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 follow a consistent pattern: a vendor asking them to enable it, nobody on their team pushing back, and the risks not fully explained.

What raw signing removes

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 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 worth understanding

Who should actually be using it

The 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.

Recommendations

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 should not be.

For 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 are must haves. 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.