Communication Contracts
Bilateral cryptographic agreements that establish secure channels between identities — no data flows without mutual consent.
Formal spec: DCTRL-0003 — Communication Contracts defines the contract schema, creation/acceptance flows, root secret derivation, and rotation protocol.
Communication contracts are the core innovation of Decentrl. They are bilateral cryptographic agreements that establish secure channels between two identities. Unlike platforms that decide who can message whom, Decentrl requires explicit mutual consent before any private communication can occur.
What's in a Contract
Each contract contains:
- Both parties' DIDs — who is in this relationship
- Ephemeral encryption keys — fresh X25519 key pairs, generated specifically for this contract, used to derive a shared root secret via Diffie-Hellman
- Expiration timestamp — contracts have a natural lifetime
- Bilateral Ed25519 signatures — both parties must sign under identical terms
The dual-signature requirement prevents coercion, spam, and unauthorized communication. You can't send someone a message unless they've explicitly agreed to receive messages from you.
How Contracts Are Established
The full contract establishment flow is walked through step-by-step in the Alice and Bob protocol walkthrough. The key insight:
- Alice generates a fresh ephemeral X25519 key pair and signs a contract request
- The request is encrypted with Bob's pre-key — only Bob can read it, not even his mediator
- Bob decrypts, verifies, generates his own ephemeral key pair, and counter-signs
- Both parties independently derive an identical root secret via
X25519(own_ephemeral_private, their_ephemeral_public)— no secret is ever transmitted - The contract ID is a deterministic
SHA256hash of the contract data
What Contracts Solve
Contracts solve multiple problems simultaneously:
- Spam prevention — you can't message someone without a mutual contract. The mediator rejects messages from identities without an active contract.
- Shared encryption — both parties derive a shared root secret without exposing it to any server.
- Proof of consent — bilateral signatures provide cryptographic proof that both parties explicitly agreed to communicate.
- Bounded exposure — contracts expire, limiting the window of any key compromise. Contracts can be rotated to further limit exposure.
- Revocability — either party can revoke a contract at any time, immediately cutting off communication.
Contracts Are Universal
The same contract primitive handles every relationship in the network:
- User-to-user — Alice and Bob establish a contract to chat
- User-to-mediator — Alice establishes a contract with her mediator (this is registration)
- User-to-group — Alice establishes a contract with a group's DID
- User-to-service — Alice establishes a contract with an automated news feed
One primitive, every relationship.
Contract Schema
type CommunicationContract = {
requestor_did: string
recipient_did: string
requestor_signing_key_id: string
recipient_signing_key_id: string
requestor_encryption_public_key: string // ephemeral X25519
recipient_encryption_public_key: string | null // null until recipient accepts
expires_at: number
timestamp: number
}
type SignedCommunicationContract = {
communication_contract: CommunicationContract
requestor_signature: string // Ed25519 (signs contract with recipient key = null)
recipient_signature: string // Ed25519 (signs completed contract)
}The asymmetric signature scope is intentional — the requestor signs before the recipient's key is known, and the recipient signs the complete contract. This prevents either party from modifying the terms after the other has signed.