Skip to content

Privacy, Transparency & Coercion-Resistance

Another “hack” that wasn’t: the Kelp DAO incident shows how social engineering, self-custody, and privacy tools converge – protecting users on paper while quietly amplifying theft incentives and eroding accountability when governance itself is designed to resist oversight.

Table of Contents

We now know the Kelp DAO incident began, yet again, with social engineering. This is the Nth in a long long line of "hacks" that attacked people rather than systems. It has been more than 25 years since Bruce Schneier wrote "Only amateurs attack machines; professionals target people" and all the empirical evidence points to people still being the weakest link. For anyone that deals with people on a daily, or even annual, basis this is hardly news.

Then add in self-custody and this gets difficult quickly. If you can attack a person and get total control over their assets there is obviously a bigger incentive to attempt a heist than if you just get the keys to, say, a safe or online banking account. Sure you might be able to raid the safe or account. But there is a lot more work post-theft to secure the loot. When the theft itself gives unilateral control that is at the margin better for the thief. All else equal self-custodied digital assets are about the best imaginable thing to steal because there is little to no cost or hassle realizing value from what you stole once you have the keys. To the extent it might be difficult to sell the loot because transactions are publicly visible then, again, it is strictly better for you the more private the stolen digital assets are. This is not hard to understand.

But we can find interesting emerging themes on adjacent fronts that raise more complex questions. First: safety. As wrench attacks increase there are more calls for privacy tools as a defense. The logic goes, it seems, that if criminals cannot identify who has money then they will not have anyone to attack. Certainly it is in everyone's interest to make crime more difficult. But, this is always going to involve some trade-off and it is far less clear what sorts of compromises or inconveniences are reasonable to expect for the general population.

Now consider specialists that opt-in to operate services. If a protocol has a safety mechanism, or really any kind of admin control, that it might be an interesting target for thieves. Kelp, ByBit, etc. Every bridge hack was about this problem. This, again, is not a new observation. But we have now set the table for some interesting problems. Why? Because this admin-mechanism-as-vulnerability feature also intersects with some reactions to how the Arbitrum Security Council responded to the Kelp incident when a court got involved. We would summarize this work by borrowing a phrase from Nick Bax: coercion-resistant voting. The idea is that courts cannot enforce orders if they cannot figure out who is in charge. Or at least where to apply the force bit of enforcement. And so protocols with possibly-legally-vulnerable admin functions should run those functions through tools that resist legal "coercion" like court orders and sanctions. We will cover a few details of coercion-resistant voting below but it is roughly as the term sounds: a way to evade responsibility for not doing what you promised to do.

We are going to argue that using privacy to protect your own assets from thieves is reasonable to a point and that most people looking at this problem are probably already way past that point. But more importantly, we are then going to argue that using the same math to evade legal accountability is bad from a point much closer to home as it demonstrates bad faith intent. As a result nearly all the work in this later area is counterproductive.

Privacy Helps the Thief Too

Privacy protects those with assets because criminals cannot find them. And privacy “protects” products which rely on pseudonymous administrators from the law so long as nobody can link the pseudonyms to real-world identities. If you go back and look at the major darknet market legal actions from the first decade of crypto – Silk Road, AlphaBay, Hansa, etc. – the issue was finding who ran the thing. Most of the big marketplaces and similar went down when the team was arrested. And you cannot arrest a team until you first identify that team. Basic law enforcement stuff.

Probably some tension is already visible. If technology exists to run the Arbitrum Security Council in a coercion-resistant way it surely will also help rich people to remain anonymous and the operators of illicit services to hide. There is simply no way to provide privacy tech only for “good” users. And whatever security one does develop faces a number of issues which are well laid out in this interview with Linux creator Linus Torvalds from a decade ago and this more recent talk by another senior Linux developer.

These two people have long been part of the core team maintaining the most widely used piece of software in the world – it runs substantially all the world's servers and most of the world’s mobile devices – which is also therefore a major target for security vulnerabilities. Their experiences are worth reviewing. And roughly speaking Linux leadership's experience is consistent with the Schneier quote above: software is rarely the real problem, working explicitly on security comes at the expense of many other things which can turn out to be security problems and anyway almost all bugs can be repurposed into security vulnerabilities.

Recall you cannot keep widely-available tools out of the hands of whoever you think is "bad." And whatever problems exist in your software will eventually be turned into security problems by a sufficiently motivated and clever developer anyway. That means for "good" actors to hide they need to make zero mistakes. And for "bad" actors to hide they also need to make zero mistakes. This is what Linus meant by software not being the real problem. Your perfect privacy system will eventually be broken by user error just as Kelp's core problem, like ByBit’s before it, was simple social engineering and human mistakes. Relying on flawless human performance never goes well. And you are better off just fixing bugs and keeping things tight as opposed to focusing too explicitly on security. If you do not believe this go read an explanation of how one turns a bug that on the surface has nothing to with security into an exploit. You cannot predict what is and is not a security vulnerability reliably. Accept it.

Coercion-Resistance

The term "coercion-resistance" is laden with meaning. And that is before you pair it up with voting. So it is critically important to understand what this term means. In the original paper defining the term the authors consider a population of voters and an "adversary" that is trying to coerce voters into voting a certain way. The simplest way to think of this is as a politician handing out cash to buy votes in an election where the actual balloting process is provably secure. We need to assume the politician cannot literally "stuff" the ballot box with doctored voting forms and that they cannot check who voted for what afterwards to keep this interesting.

The challenging case is when politicians can only hand voters money – or, presumably, threaten them in some way – and then follow whatever procedures are agreed around the voting itself. The "provably secure" bit is important because you are never going to have coercion-resistant voting if, for example, voting is done publicly in a town square by a show of hands.

The definition is that a system is coercion-resistant if it is infeasible for the adversary to determine whether a coerced voter complies with the demands. What you want to think of here are entire voting systems where there is no way for a voter to produce evidence that proves or disproves that they did what was requested of them which can include their voting or not voting at all. Politicians can still hand out cash. And organized crime can still threaten people to vote a certain way. But there is, by design, no way for them to tell if the voter did what they wanted.

You can see the appeal of these sorts of systems. If there is no way to figure out if your cash handouts worked then you have less incentive to hand out cash. And what is the point of threatening people if you cannot ever tell whether they did what you wanted? This is not a column on how to run a mafia but it seems like protection rackets will not work terribly well if nobody can figure out if the protection worked.

Anyway this is what the term means. Now you can ask yourself how this might work for a protocol governance mechanism and why anybody might want it. One platform working on this problem describes itself as a way for independent parties to produce shared, verifiable outcomes from private inputs. This is how political elections are supposed to work. It might be how shareholder votes at public companies are supposed to work. But it is definitely not how management of collective enterprises is supposed to work in general. If we break the link between decision making and accountability there will be no accountability.

Also notice none of this is required to secure your private assets. None of this is required to operate collective decision-making mechanisms in public. The only reason to do this is to obscure from public view the records of who voted for what. But protocol governance is not political governance. Unless you subscribe to the (insane) view that on-chain activities are not and should not be subject to the laws which apply to the rest of the world it is hard to understand a legitimate application for these techniques in financial services.

Intent

In cases that are truly about protecting personal assets from theft and physical attacks, and nothing more, then the argument at root is that you are exercising your rights in good faith. As discussed above we think most people should try to go a bit in this direction. But they should be mindful of the totality of the circumstances and not waste time or effort pushing too far.

But what about cases where privacy tools are used to produce coercion-resistant governance systems? Or to hide who operates an illicit service? Are these good uses of privacy? We are not asking about "good" in a moral sense but rather in a more basic "is this going to work?" sense ala the discussion of privacy tools that are so complex a real user always leaks all their information anyway.

It is helpful here to start with a real example. The members of the Arbitrum Security Council that chose to freeze the Kelp DAO hacker funds are publicly known. To the extent Arbitrum has processed DPRK funds, or Iranian funds, or the funds of any actor sanctioned by the authorities in any country where the Arbitrum Security Council has members (this includes the USA and Israel) then those members may have problems. But at least with the current setup they can claim good faith participation in an open and transparent process. The rules have been known for a while and are public and as a result everyone has had a lot of time to make their intent clear.

Also: everyone knows digital assets are used by some criminals and have been for a long time. And most everyone agrees that operating a blockchain node does not mean you are part of those crimes. Views differ on whether or not it is acceptable for an American company to mine or validate a block that itself contains a transaction involving a US-sanctioned address. But everyone agrees it is perfectly fine to accept that block as part of a blockchain's history and process derivative outputs. Nobody claims any and all connections to crimes render you liable for some kind of criminal conspiracy charge.

But what if you are participating in a coercion-resistant governance mechanism where nobody can see who is in charge or who is voting for what? Now the defenses are a lot weaker. You are not participating in an open and transparent system. You are participating in a system in which the outcomes of collective decisions organized among unknown participants are announced once they are completed with no accountability or even acknowledgement of who decided what. Permissionless systems are not necessarily transparent.

Yes, you might have some kind of fancy cryptographic process to prove the votes were cast as claimed. And that different source addresses cast the votes. And whatever other bells and whistles someone designed. Ask yourself how this is different from a political leader announcing their own re-election with 90% of the vote 20 minutes after the polls close and offering boxes of hand-written ballots as evidence. Are they lying? You of course need more information like whether there was widespread violence at polling places or if the Army was out intimidating voters. It matters if the opposition was allowed to run a real campaign. Whatever. There are lots of reasonable questions to help decide because it is of course possible for someone to win re-election fairly with 90% of the vote. But you need the opportunity to ask these questions to form a reasonable opinion on what happened.

If you run a custodial trading service via a multisig and claim transparency as your only defense you will probably have legal problems. But you have an argument and can at least try to negotiate. If you have your spokesperson declare you were re-elected and offer no further details or proof nobody will believe you. Whatever legal position you are in, in the limit it is still better strategically to point at some transparency somewhere. Plausible, even plausible-ish, arguments are better than naked bluster. Further, in collective control arrangements of this sort you can only have accountability for nobody or everybody. And "everybody" is going to mean whoever gets caught first.

How exactly is this going to work for coercion-resistant voting? In a public election – the original venue in which coercion-resistant voting was conceived – it makes sense to give the voters power to escape coercion. That is the essence of democracy. But to use the same techniques to evade legal accountability is to flip any argument in favour of these schemes on their head. Voters are not supposed to be accountable to anyone but themselves and their own conscience in democratic elections. That is the entire point.

That does not mean the members of a group collectively running anything are entitled to that same privilege. The managers of collective enterprises are supposed to be accountable for the consequences of their decisions. It makes zero sense to allow or encourage the strategic evasion of liability for members of private associations. And by joining such a scheme one is signaling their intent to ignore court orders and the like. Using these mechanisms to manage financial services is clear evidence of bad faith. It is not conclusive proof – but there will surely be future cases where this weighs against defendants.

The Key Difference

Coercion-resistance is a good, desirable, socially beneficial property for voting systems when it comes to politics. But that does not mean coercion-resistance is a positive attribute for all possible governance use cases.

This, in fact, is similar to the issues with self-custody and privacy discussed above. These things can help people protect assets. And they can help thieves profitably dispose of recently-stolen assets too. These are all properties – which can be described with math using some combination of statistics, game theory and economics – with no inherent good or bad or fairness or political bent at all. They are just statements we can make about different schemes.

But what one chooses to use to manage money can, and often does, have an inherent good or bad or fairness or political bent. If you want to run a centralized financial service, call it decentralized, and then lean on the openness and transparency of the whole thing if the police ever come knocking: fair enough. We have written extensively about this problem. And while our position has consistently been that many people are exploiting this perceived loophole to knowingly violate the law we readily acknowledge there are more than zero cases where ignorance might be a real defense. There are also arguments as to why handing control to a sufficiently-dispersed group via a transparent mechanism might give some legal protection. And the legal standard for liability is generally higher than “might have been trying to do the wrong thing” so quite a few folks that probably are guilty will get off with good defenses.

You throw all of that away when you design a governance system to stifle court orders and the like. That signals an intent to not listen to the legal system. This may not be a crime in and of itself – and absent any underlying business it is hard to see how merely setting up a wonky governance system can be too bad – but it should significantly tilt the tables against you if the thing you are governing enters a grey area. And on a more practical level it is unlikely all the participants are going to use the thing correctly anyway. So all this will produce, in practice, is prosecutions of people that make mistakes using delicate software. That is a weird world. And it may well be the world we are seeing built today.

Latest