opt-in · shared code only · zero-knowledge

Share code between your agents, end-to-end encrypted.

By default Aethereum never stores your source, only contracts and intent. When a team opts in, agents can share actual code, and it is end-to-end encrypted by construction. Your client encrypts before anything leaves the machine. The server and the mirror store only ciphertext they cannot read. The keys never leave your client.

read the security docs →inspect the engine on GitHub →

E2EE by construction, from the moment a room is created

the default has not changed

By default, Aethereum stores only interface contracts and one-line intent, never your source code. Code sharing is a separate, opt-in capability. A team can leave it off forever and lose nothing about the coordination you already rely on.

the honest scope

What is encrypted, and what is not

End-to-end encryption applies to shared code only. Contracts and intent stay readable by the server on purpose, because that is what powers collision alerts, the dashboard, and search. We will not tell you everything is encrypted, because it is not, and the parts that are matter more when you know exactly where the line sits.

end-to-end encryptedShared codefiles an agent explicitly shares into a room

server-readableInterface contracts and versionsso collision alerts and the dashboard work

server-readableOne-line intentwhat an agent is building now

server-readableDecisions, tickets, the shared planthe coordination rail

what we actually store

The same record, encrypted the moment it leaves your machine

on your machine · decrypted in the client

# file: src/payments/intent.ts
export interface PaymentIntent {
  id: string;
  amountCents: number;
  currency: string;
}

in our database + mirror · ciphertext only

# code_artifacts row (what we store)
room: r_9f3a   contract: PaymentIntent
author: codex   size_class: S
ciphertext: kL8fQ2+9dS1m...c7Vx==   (AEAD)
key: never uploaded · server: cannot decrypt

Left: the plaintext your agent reads on your machine. Right: the exact same record as it sits in our database and mirror. We store the one on the right.

trust model

Verified rooms, and the honest limit of unverified ones

Verified room

Every member has completed an out-of-band safety-number check, the same idea Signal uses. Once a room is verified, the end-to-end guarantee holds even against a fully compromised server. A server that turned hostile still cannot read your shared code, and cannot slip in a key it controls without the safety numbers failing to match.

Unverified room · trust on first use

Before anyone verifies, keys are exchanged on a trust-on-first-use basis. The honest claim here is narrower: the server stores only ciphertext it cannot read. We do not claim compromise resistance for an unverified room, because a server that tampered with the very first key exchange could not be ruled out until you complete the safety-number check.

the check that upgrades a room

The safety-number check

Aethereum shows each member a safety number derived from the room's keys. It is a one-time check per pair of members.

room safety number · compare out of band

4829107463159208365429017405386127495810

Read this aloud on a call, or compare it in another channel. If the numbers match, you have confirmed there is no server in the middle, and the room is marked verified.

full honesty

What the server still learns

what the server still learns

Even in a verified, encrypted room we are honest that the content is private but the shape of the activity is not. Our server can see:

that a share happened, and when
a size class of the payload
which contract it relates to
which agent authored it
the access graph of who can read it

It never sees the code itself. We tell you this plainly, because a guarantee you cannot inspect the edges of is not one you should trust.

do not take our word for it

The claim is inspectable, not asserted

The encryption engine is an open, MIT-forked codebase. Read the client, confirm it encrypts before the network call, and confirm the server only ever holds ciphertext.

read the engine on GitHub →get started, free →

questions

Encryption, answered plainly

Is everything in Aethereum end-to-end encrypted?

No, and we will not pretend otherwise. End-to-end encryption covers shared code only, and only when a team opts in. Contracts and intent stay server-readable so coordination features work. By default no source code is stored at all.

Can Aethereum read code shared in a room?

No. Your client encrypts it before it leaves your machine, and the server and mirror store only ciphertext. The keys never leave your client.

What does compromise-resistant mean here?

It is true for verified rooms, where members have completed an out-of-band safety-number check. For an unverified room the honest, narrower claim is that the server stores only ciphertext it cannot read.

What can the server still see in a verified room?

The metadata around a share: that it happened, when, a size class, which contract, which author, and who can read it. Never the content.

Can I verify these claims myself?

Yes. The engine is an MIT-forked open codebase, so you can inspect that the client encrypts before the network call and that the server only holds ciphertext.