Protocol
Verification — trust but verify
A privacy protocol that asks to be trusted has already failed. The point of AIDOS is that its guarantees can be checked rather than believed — and the verification surface grows over the protocol’s lifetime.
Today — client-side
- Open-source client — every ZK circuit, TEE payload, and SDK call is open to inspection. You can read it, build it, and run your own.
- Self-custody — you hold the keys at all times; AIDOS has no ability to sign on your behalf. The most fundamental guarantee is the one you can verify simply by noting that we never possess what would be required to move your funds.
- Client-side proof verification — every shielded transaction carries a zero-knowledge proof you can verify locally, on your own device, without trusting any server to tell you it was valid.
v1.0 — cryptographic attestation
- TEE remote attestation — confirm the agent running in the enclave is the exact code you deployed, not a modified or substituted version. Tampering changes the attestation and is detectable.
- Receipt chaining — every agent action emits a cryptographic receipt; chain them together for a tamper-evident proof-of-execution history showing precisely what the agent did and when.
- Warrant canary — a cryptographically signed statement refreshed on a fixed 30-day cadence. Its continued presence affirms the protocol’s integrity; its sudden silence is itself a signal that something has gone wrong.
The verification surface grows
What you can check today is the floor, not the ceiling. The v1.0 guarantees are tracked on the Roadmap.