The internet has never had a satisfying answer to a simple question: how do you enforce the law on content that is stored nowhere in particular, served by volunteers, encrypted end-to-end, and accessible from anywhere on Earth?
Previous answers have all required collapsing one of those properties. Either you give up encryption (so servers can scan content). Or you give up decentralization (so a single company can take content down). Or you give up jurisdiction (so no laws apply). None of these is acceptable. The first destroys privacy. The second recreates the platform monopoly problem. The third is not a governance model — it is an abdication of one. While we do not want to simply rely on older systems with state actors simply banning things they don’t like – as developers designing distributed systems that can come to be used by millions of people, it is our responsibility to design them in such a way that tries to minimize the chances of the worst outcomes, and promotes the health of communities overall.
Safecloud proposes a fourth answer. It preserves encryption, decentralization, and legal jurisdiction simultaneously, by treating them not as competing values but as cooperating layers in the same system. This article traces exactly what must happen — step by step, party by party — for a single file to be banned in a single jurisdiction. The length of that list is the point.
The Participants
Before tracing the process, it helps to name who is involved.
Uploaders are the people who store files on the network. They choose which SafeBoxes are allowed to analyze their content, and they voluntarily agree to jurisdiction at upload time.
Jets are the routing nodes, typically run by operators who have registered for one or more jurisdictions. They route requests between consumers and storage providers, but they cannot read the content.
Drops are browser-based storage nodes. They hold encrypted chunks they cannot read. They know nothing about jurisdiction.
SafeBoxes are attested confidential compute environments. An AI model runs inside one, analyzes content, generates encrypted labels, and then provably deletes the plaintext. The attestation is cryptographic: anyone can verify that the SafeBox ran the correct software and that the analysis was performed honestly.
Jurisdiction accreditation authorities are on-chain addresses that certify which SafeBoxes, judges, and judicial delegates are recognized as legitimate within a given legal territory.
Judges and their delegates are individuals or institutions authorized by the accreditation chain to issue warrants. Their authority flows down a hierarchical delegation tree, and each level of the tree carries a rate quota — a limit on how many warrants can be issued per unit of time.
Watchers are ordinary users who consume content. They can also flag content, just as the AI in a SafeBox would, and their flags carry weight proportional to the stake they commit to the flag. Both AI flagging and human flagging are roles — the AI SafeBox is simply an early authorized watcher with a special cryptographic credential.
Requesters are consumers fetching content from Jets. They may be anywhere, and the question of whether a Jet must serve them depends on jurisdiction overlap, which we address at the end.
Layer One: Voluntary Agreement at Upload
Nothing in this system is imposed. Everything begins with consent.
When an uploader stores a file on Safecloud, they make several voluntary choices that determine what governance applies to that content for its lifetime on the network.
First, they choose which SafeBoxes are permitted to analyze their content. A SafeBox is not a corporation with a privacy policy — it is a specific machine running specific attested software, identified by a cryptographic attestation key. The uploader can choose a SafeBox run by a civil liberties organization, a government contractor, a university, or themselves on their own laptop. What matters is that the SafeBox’s identity is verifiable and that the uploader’s authorization is signed.
Second, they choose which jurisdiction authorities they accept. This means selecting one or more accreditation roots from on-chain addresses. Country X’s accreditation root certifies judges. Those judges can delegate to sub-judges. The delegation tree has rate quotas at every level. By accepting a jurisdiction’s accreditation root, the uploader is saying: I acknowledge that entities authorized by this tree may request a warrant to decrypt labels on my content, following the due process specified in this tree’s governance parameters.
Third, they commit a stake denominated in SafeBux. The size of this stake determines their upload quota — how much content they can store per period. Quota can be increased as watchers engage positively with content, because those watchers also stake SafeBux when they rate or flag. The system is self-regulating: popular, positively-rated content earns the uploader more quota; content that gets flagged costs quota. Astroturfing is limited because SafeBux vests gradually — a watcher cannot watch something once, drain their stake into a rating, and start over. The stake takes time to regenerate.
Layer Two: Analysis by an Authorized SafeBox
Once content is uploaded, the authorized SafeBox receives the content — not the plaintext — for analysis. The process is as follows.
The uploader and the Jet cooperate to produce a session key that allows the SafeBox to decrypt one copy of the content for analysis. This is not a backdoor: the SafeBox is a specific machine the uploader chose, running specific software they can verify. The cooperation is intentional and cryptographically auditable.
Inside the SafeBox, the AI model reads the content. It generates labels: descriptive tags that characterize what it observed. Crucially, these labels are immediately encrypted to the public key of the relevant jurisdiction authority before leaving the SafeBox. The SafeBox then provably deletes the plaintext and the session key. What remains is an encrypted label blob that only the jurisdiction authority can read, attached to the file’s manifest on-chain.
The SafeBox signs this entire operation with its attestation key. Anyone — the uploader, the Jets, the public — can verify that the correct model ran on the correct content and produced the correct encrypted output, without ever seeing either the content or the labels. This is the SafeBox invention: confidential compute with public accountability.
At this stage, no one has read the labels. The jurisdiction authority has a blob it could decrypt, but has not. The content is still encrypted. The uploader’s privacy is fully intact.
Layer Three: A Human Watcher Flags the Content
Meanwhile, ordinary users consume content. If a watcher finds something they believe warrants attention, they can file a flag — exactly like the AI does, except it comes from a human. The flag is a signed OpenClaim with a context describing what the watcher observed and what they believe it means.
Filing a flag costs SafeBux stake. The watcher is putting skin in the game. If the flag leads to nothing, the stake is slowly returned. If the flag leads to a warrant and a confirmed finding, the watcher who flagged it earns a portion of the slashed stake of the uploader, distributed through the lottery mechanism that propagates Proofs of Corruption through the network.
Flags from watchers and labels from SafeBoxes feed into the same pipeline. Both are signed OpenClaims attached to the file’s manifest. The AI in the SafeBox is simply an early authorized flagger — its credential comes from the accreditation tree rather than from stake, but it plays the same structural role.
Layer Four: A Judge Issues a First-Step Warrant
A judge who has been authorized by the jurisdiction’s accreditation tree decides whether to investigate. Their authorization is a delegation proof: accreditation root → regional authority → district judge, each level with a signed OpenClaim and a rate quota.
The rate quota is not advisory. It is enforced structurally. The judge holds stake. Issuing a warrant burns a small portion of stake. The stake regenerates at a rate specified in their delegation — the regeneration rate is the rate limit. A judge who wanted to issue warrants faster than their quota allows simply cannot, because they do not have the stake. A jurisdiction that tried to create a thousand sub-judges to multiply its effective warrant rate would find the total subtree quota unchanged — the invariant holds at every level of the delegation tree.
The judge’s first warrant authorizes only one thing: decrypting the encrypted label blob attached to this file. Nothing else. The content remains encrypted. The judge now knows what the AI labeled the content, or what the human watcher described, but has not seen the content itself.
This is the structural anti-rubber-stamping mechanism. The judge must make a real decision between warrant one and warrant two, because warrant one only reveals the label — not the content. A judge who signs warrant two without reading warrant one’s result is creating an audit trail showing they acted without information. That audit trail is permanent and public.
Layer Five: A Judge Issues a Second-Step Warrant
Having read the label, the judge decides whether to proceed. If they decide the label is sufficient to warrant access to specific chunks of the content, they issue a second OCP-signed warrant specifying the rootCid, the chunk indices, and the justification.
This warrant is verifiable by any Jet. It chains up through the delegation tree to a jurisdiction accreditation root. Jets in this jurisdiction check:
- Is this warrant signed by an entity in my jurisdiction’s accreditation tree?
- Is the signature chain valid at every level?
- Does each level’s rate quota permit this warrant, given the current stake balance?
- Does the warrant cover only the specific chunks requested, with a valid expiry?
- Is the warrant within the subtree’s total quota — not just the issuing judge’s individual quota?
If all checks pass, Jets serve the decrypted content to the authorized parties. The decryption requires cooperation between the jurisdiction authority (which holds the label decryption key) and the infrastructure authorized for this specific warrant. The content is made available only to the parties specified in the warrant, for the duration specified, covering only the chunk indices specified.
The uploader is notified that a warrant has been executed against their content.
Layer Six: The Case
Having accessed the content, the authorities open a case. This is a legal proceeding, not a technical one. The Safecloud system does not automate legal outcomes — it provides the cryptographic infrastructure for evidence collection and audit trails. The case proceeds according to whatever legal framework applies in that jurisdiction.
The uploader has the right to see the warrant chain, verify its legitimacy, and challenge it through whatever legal channels exist. The signed OCP proof chain is public and auditable. Nothing about how the warrant was issued is hidden.
Layer Seven: A Ban Decision
If the case results in a finding that the content violates the jurisdiction’s laws, the jurisdiction authority issues a signed ban claim. This is another OCP-signed document: rootCid, basis for the ban, issuing authority, jurisdiction, and expiry.
Jets in this jurisdiction receive the ban claim. The protocol specifies that honest Jets do not route requests for banned content within their jurisdiction. This is enforced not by a central server but by each Jet independently verifying the ban claim’s signature chain and refusing to serve the content.
The ban only applies in that jurisdiction. Jets registered in other jurisdictions are not bound by it. The content continues to be routable elsewhere.
The Question of Location
This raises the final question: what stops a requester in the banning jurisdiction from simply routing their request through a Jet in another jurisdiction?
The honest answer is: the protocol does not prevent this, but it creates friction. A Jet in another jurisdiction would be serving a requester across a geographic distance, which means higher latency. A Jet operator who wants to maintain good standing in their own jurisdiction has an incentive not to become a routing backdoor for banned content originating elsewhere. Jurisdiction authorities can issue a secondary claim noting that a specific Jet has been observed routing content banned in jurisdiction X, which begins to affect that Jet’s standing with its own accreditation tree.
The system could go further. Jets could be required to prove their location, and requesters could be required to prove theirs, by measuring round-trip latency to a set of known geographic anchors. A requester who claims to be in Country X but whose latency profile is inconsistent with Country X would be flagged. This is imperfect — latency can be gamed — but it raises the cost of circumvention substantially.
There is no perfect answer here, and the system does not pretend otherwise. What it provides is a framework in which honest actors — Jets, Drops, uploaders, watchers — have clear and economically rational incentives to operate within the rules of their chosen jurisdiction, and in which bad actors face escalating costs rather than a single point of failure they can route around.
How Many Things Must Happen
To ban a single file in a single jurisdiction, starting from zero, the following must all occur:
- The uploader voluntarily selects a jurisdiction accreditation root at upload time.
- The uploader authorizes one or more specific SafeBoxes to analyze the content.
- The SafeBox runs the authorized AI model, generates encrypted labels, and provably deletes the plaintext.
- Either the SafeBox’s AI flags the content, or a human watcher independently stakes SafeBux to file a flag.
- A judge with sufficient stake quota in their delegation decides to issue a first-step warrant, burning stake.
- The judge reads the decrypted label and decides it warrants proceeding.
- The judge issues a second-step warrant specifying exact chunk indices, signed with a valid quota token.
- The Jet verifies the full warrant chain — signature validity, quota sufficiency, subtree rate limit, expiry.
- The authorized parties access only the specified chunks, for the specified duration.
- A case is opened. Due process proceeds. The uploader is notified and has the right to challenge.
- The jurisdiction authority issues a signed ban claim based on the case outcome.
- Jets in that jurisdiction independently verify the ban claim and cease routing that content.
Twelve steps, each requiring a separate cryptographic operation, a separate authorization, and a separate human or institutional decision. At no point does any single party have unilateral power to ban content. The SafeBox cannot ban — it only labels. The judge cannot decrypt without the label. The label cannot decrypt without the warrant. The warrant cannot exceed the rate quota. The quota cannot be gamed by Sybil sub-judges. The ban applies only where the uploader agreed it could.
This is not a perfect system. No system is. But it is a system in which the cost of abuse is high, the audit trail is public, and the architecture forces human judgment at multiple independent checkpoints.
Why This Matters
The standard argument against encryption is that it enables crime. The standard argument for encryption is that it protects privacy. Both arguments are correct, and they are usually presented as if they are in fundamental conflict.
They are not in fundamental conflict. They are in conflict only when the only available tool is a blunt one: either scan everything, or scan nothing. The system described above is a sharp tool. It scans the minimum necessary, with the maximum accountability, at each step requiring more justification than the last.
The AI in the SafeBox is not a surveillance system. It is a first-pass filter with no power of its own — its output is encrypted and unreadable without a warrant. The warrant system is not a backdoor — it is a cryptographically auditable sequence of human decisions. The ban is not censorship at the infrastructure level — it is a jurisdiction-specific policy that applies only where the uploader agreed it could.
What makes this possible is the combination of several technologies that did not exist together until recently: attested confidential compute, content-addressed encrypted storage, hierarchical capability delegation with rate limits, and decentralized routing with jurisdiction registration. None of these alone is sufficient. Together, they create something that has not existed before: a network that can enforce the law without becoming an instrument of surveillance.
For more on the foundational thinking behind this approach — how privacy and accountability can reinforce rather than undermine each other — see the original essay that began this line of thinking: