Trust does not scale. A system that works fine among three people who share a Slack channel and a coffee machine can fall apart the moment it has to serve three thousand strangers, three network operators with conflicting business models, or three jurisdictions with incompatible legal assumptions. The political economy of internet protocols is, at bottom, a long argument about what to do when participants cannot be trusted. This article looks at the design patterns that make systems function under distrust: explicit threat models, verifiable claims, economic incentives, and failure isolation. It draws on routing security, certificate transparency, distributed consensus, and content moderation infrastructure to show how technical choices distribute power among network operators, end users, and platform providers.
Distrust is not a bug to be eliminated. It is a design input. The systems that survive contact with real-world incentives are usually the ones that assumed someone would cheat, lie, or defect, and built accordingly.
Start with the Threat Model, Not the Architecture
Most failed systems do not fail because their cryptography was weak. They fail because nobody wrote down who was allowed to misbehave and what the consequences would be. A threat model is a list of participants, their capabilities, their incentives, and the specific harms the system must prevent or detect. Without it, security becomes a collection of rituals.
Consider the Border Gateway Protocol (BGP). BGP was designed in an era when network operators were assumed to be competent and mostly honest. The protocol has no built-in mechanism to verify that a route announcement is true. A network can announce a prefix it does not control, and that announcement can propagate globally. The result is route hijacking, traffic interception, and occasional multi-hour outages. The threat model was implicit and optimistic. The operational cost of that optimism has been substantial.
A more useful approach is to ask three questions before writing any code or deploying any service:
- Who can act? Identify every class of participant, including those who are not supposed to exist.
- What can they do that would harm others? Be specific. Vague harms produce vague defenses.
- What evidence would prove harm occurred? If the answer is “none,” the system cannot be audited, and auditing is the only reliable backstop when prevention fails.
This is not a theoretical exercise. The Resource Public Key Infrastructure (RPKI) exists because BGP’s original threat model was too permissive. RPKI lets network operators cryptographically attest that they are authorized to originate specific IP prefixes. It does not make BGP trustworthy. It makes some BGP announcements verifiable, which is a smaller and more achievable goal.
Verification Beats Trust, but Verification Has Costs
The phrase “trust but verify” is popular and mostly useless. Verification is not a supplement to trust; it is a replacement for it. When you verify a claim, you are not trusting the claimant. You are trusting the verification mechanism, which is a different and often smaller target.
Certificate Transparency (CT) is a useful case study. Before CT, a certificate authority could issue a certificate for any domain, and the domain owner might never know. The system relied on the honesty of hundreds of certificate authorities, some of which were compromised or sloppy. CT changed the model by requiring certificates to be logged in public, append-only ledgers. Domain owners can monitor those logs for certificates they did not request. Browsers can require that certificates be logged before they are accepted.
CT did not make certificate authorities trustworthy. It made their actions observable. That is a meaningful distinction. Observability creates accountability, and accountability changes behavior even when it does not change incentives perfectly.
The cost is real. CT logs are large, and running a log requires operational discipline. Monitors must be deployed and maintained. The ecosystem added complexity to reduce reliance on trust. That tradeoff is usually worth it, but it is not free, and pretending otherwise leads to systems that look secure on paper and collapse under operational load.
Incentives Are Part of the Protocol
Technical designers often treat incentives as someone else’s problem. That is a mistake. A protocol that assumes participants will act against their economic interest is a protocol that will be ignored, bypassed, or gamed.
Email authentication provides a clear example. SPF, DKIM, and DMARC are designed to make it harder to forge email from a domain. But adoption has been uneven for years. The reason is not technical complexity alone. The reason is that the costs and benefits are distributed unevenly. A domain that sends no email has little incentive to publish a DMARC policy. A domain that sends email through many third-party services has a strong incentive to avoid a strict policy, because a misconfigured policy can break legitimate mail. The protocol works, but only where the incentives align.
Distributed consensus systems face a sharper version of this problem. Bitcoin’s proof-of-work mechanism is often described as a way to prevent double-spending. It is also a way to make defection expensive. A participant who wants to rewrite history must spend real resources, and the rest of the network can see that expenditure. The system does not assume miners are honest. It assumes that dishonesty is unprofitable under most conditions. That assumption has held, more or less, though the concentration of mining power has introduced new trust assumptions that are rarely discussed as candidly as they should be.
The lesson is not that incentives solve everything. They do not. But a system that ignores incentives is designing for a world that does not exist.
Failure Isolation: Assume Something Will Break
Systems built for distrust must also be built for failure. A single compromised component should not give an attacker control of the whole system. This principle is old, but it is violated constantly.
The Domain Name System (DNS) is a useful example. DNS is hierarchical, which means that a compromise at a high level can affect many domains. DNSSEC was designed to add cryptographic authentication to DNS responses, but it also introduced new failure modes. A misconfigured DNSSEC zone can make a domain unreachable. The system added security but also added a new way to break things. That is not an argument against DNSSEC. It is an argument for designing failure modes as carefully as success modes.
Content delivery networks and platform moderation systems face a different version of this problem. A platform that centralizes moderation decisions creates a single point of failure, both technically and politically. A platform that distributes moderation to communities creates inconsistency and abuse. There is no clean answer, but there are better and worse tradeoffs. The better ones tend to isolate failures so that a bad decision in one community does not become a global policy.
Failure isolation also applies to organizational design. A system that requires a single administrator to hold all the keys is a system that will fail when that administrator is unavailable, compromised, or simply wrong. Multi-party authorization, rotation schedules, and break-glass procedures are not bureaucratic overhead. They are the operational expression of a threat model that includes the system’s own operators.
What This Means for Internet Governance
The governance of internet infrastructure is often discussed as a contest between governments, corporations, and civil society. That framing misses the deeper point: the technical design of protocols already encodes governance decisions. Who can verify a route? Who can revoke a certificate? Who can update a root zone? These are not neutral engineering questions. They are decisions about power.
When a protocol assumes trust, it concentrates power in the hands of those who are trusted. When a protocol requires verification, it distributes power to those who can perform or request verification. When a protocol aligns incentives, it shapes behavior without requiring anyone to be virtuous. These are political choices, made by people who often do not think of themselves as political actors.
The internet has survived as long as it has partly because many of its core protocols were designed with a healthy pessimism about human behavior. That pessimism is worth preserving. It is not cynicism. It is the recognition that systems which depend on universal good behavior are systems that will eventually be exploited by someone who does not share the designer’s assumptions.
Practical Takeaways for System Designers
If you are building a system that must work across organizational boundaries, start with these steps:
- Write the threat model in plain language. If you cannot explain who is allowed to misbehave and what happens when they do, you do not have a threat model.
- Prefer verifiable claims over trusted assertions. Every time you accept a claim without evidence, document why verification was not possible or not worth the cost.
- Map the incentives. For each participant, ask what they gain by following the rules and what they gain by breaking them. If the second number is larger, expect the rules to be broken.
- Design for partial failure. Assume that some component, some operator, or some process will fail. Make sure the failure is contained and observable.
- Treat observability as a security control. Logs, monitors, and audits are not just for debugging. They are how you detect defection when prevention fails.
These steps will not make a system perfect. Nothing will. But they will make it more likely to survive contact with people who do not share your assumptions, which is the only kind of people a real system will encounter.
Frequently Asked Questions
What does it mean to build a system that does not require trust?
It means designing so that participants can verify the behavior of others instead of relying on their promises. Verification can take many forms: cryptographic proofs, public logs, economic penalties, or independent audits. The goal is not to eliminate all trust. Some trust in the verification mechanism itself is unavoidable. The goal is to shrink the trusted base to the smallest possible set of components and people.
Why do some protocols still rely on trust if verification is possible?
Because verification has costs. It adds latency, complexity, storage requirements, and operational burden. In some cases, the cost of verification exceeds the expected cost of the harm it would prevent. That calculation is often implicit and sometimes wrong. Protocols that rely on trust should be able to explain why verification was not worth the cost, and that explanation should be revisited as the threat environment changes.
How do incentives fit into protocol design?
Incentives determine whether participants will follow the rules when no one is watching. A protocol that aligns incentives with desired behavior is more resilient than one that depends on goodwill. But incentives are not a substitute for verification. They are a complement. A system with good incentives and no verification can still be gamed by a participant who finds a way to profit from defection. A system with verification and no incentives may be ignored by participants who see no reason to use it.
What is the relationship between technical design and power?
Technical design distributes power by determining who can act, who can verify, and who can be held accountable. A protocol that centralizes trust centralizes power. A protocol that distributes verification distributes power. These effects are often unintended, but they are real. Designers who ignore them are still making political choices; they are just making them without looking.
This article is part of a continuing series on the political economy of internet protocols. Future pieces will examine the governance of root zone operations, the economics of certificate authority markets, and the design of distributed moderation systems.