I spent the last few months thinking about how autonomous AI agents could coordinate real-world actions, not just write or analyze code. What I ended up designing was a protocol I called Aegis — a decentralized escrow and verification system built on Bitcoin that lets AI agents fund, verify, and settle real-world work without trusted intermediaries.
In theory, the architecture was elegant: the agent defines a job, locks BTC in escrow, a worker does the task, oracles attest to completion, and funds are distributed automatically. Multisig with timelocks, oracle quorums, and refund rules meant no single party controlled the money.
Then I looked at what that really meant.
You can build a system that posts anonymous bounties, moves funds, and verifies completion. That same system could be used to pay someone to verify a person no longer exists at a given address. In other words, I had unknowingly designed a murder-for-hire protocol. That realization changed everything.
Rather than abandon the idea entirely, I went back to the drawing board. What follows are the defense layers and design principles I ended up with — not a set of rules in prose, but structural constraints built into the protocol itself so certain classes of tasks are literally impossible to escrow.
Structural Safety Through Task Class Gating
The key insight is that you can’t just try to filter bad actors or write policies; decentralized systems don’t stop misuse with rules, they stop it with design. If a protocol can mechanically prevent certain tasks from ever forming valid escrow, then even a malicious agent can’t make the system do harm.
The first defense layer is task class gating. Every job must belong to a task class that the protocol understands:
DIGITAL_WORKINFORMATION_GATHERINGDELIVERYMAINTENANCEINSPECTIONCREATIVEPHYSICAL_NON_HAZARDOUS
There is no “open-ended physical task” class. If it doesn’t map to something safe and whitelistable, escrow creation fails at the schema layer.
Evidence Whitelisting Prevents Harmful Validation
A protocol that relies on evidence to verify completion must be careful about what evidence it accepts. Hitman-style tasks rely on proof of harm or injury — explicitly disallowed at the protocol level.
Allowed evidence types include:
- Git commits and hashes
- Photos of objects or locations
- Signed delivery confirmations
- Device presence attestations
- Receipts
Disallowed types include:
- Evidence of injury
- Proof of death
- Threats, coercion, or weapons
No valid evidence → no valid quorum → escrow never settles. Money never moves.
Oracles, Liability, and Arbitration as Safety Mechanisms
Oracles aren’t just robots checking boxes. In my design:
- Oracles stake value and reputational capital
- They can only attest to specific safe task classes
- Arbitration is mandatory for all non-trivial tasks
If a job is ambiguous or malicious by design, arbitrators can freeze the escrow forever and burn fees. That’s a feature, not a bug: the economics disincentivize misuse.
Protocol-Level Constraints Beat Policy Promises
Trying to stop misuse with policies, terms, or moderation doesn’t work in true decentralized protocols — you end up with gatekeepers. Instead, you need structural impossibility: if a class of task is harmful, the protocol doesn’t even express it. Schema validation, evidence types, oracle selection, and economic incentives all work together to make certain misuse cases impossible.
There are limitations — money is still money outside the protocol, and bad actors can always operate elsewhere. But this design means you can’t construct a valid escrow that settles into violence using this system.
Why I’m Writing This Instead of Shipping Code
I’m confident in the defense layers I outlined. But once code is released, you can’t take it back. Instead of throwing software into the wild, I want expert review from cryptographic protocol designers, security researchers, and game theorists. If there are failure modes I missed, I want to know.
AI agents interacting with the physical world is inevitable. The question is whether we build that infrastructure with structural safeguards, or let someone else build the naive version that becomes a decentralized murder market.
This is my attempt at thoughtful design — not perfect, but a starting point.
If you work on protocol security, cryptographic systems, or game theory and want to review the design, reach out. I want adversarial feedback — not validation.
Top comments (0)