Protocol v1

What DealSeal actually verifies.

The protocol is deliberately narrow: canonicalize one claim, authenticate it on two independent axes, and issue portable evidence.

1. Canonical tuple

Each party receives deterministic JSON covering the room, numeric X identities, purpose, terms hash, wallet address, origin, nonce, expiry and binding scope. Keys are sorted recursively and unsafe numbers are rejected.

2. Authenticated X event

The bot decrypts an X Chat event with the official X Chat SDK, requires a valid event signature and verified identity-to-signing-key binding, and checks the decrypted bytes exactly against the prepared tuple. A DealSeal receipt is a service attestation to that verification; it is not a public proof of encrypted plaintext.

3. Wallet signature

The listed Solana address signs the identical UTF-8 bytes with an offchain message signature. No transaction is broadcast by the ceremony.

4. Receipt and continuity

DealSeal signs the receipt with Ed25519. Opted-in continuity records commit complete daily account leaves into a domain-separated Merkle tree, then anchor the root through OpenTimestamps and an optional Solana memo.

Privacy boundary

Observatory pages are opt-in. The system does not silently profile arbitrary X users. Revoking monitoring stops future observations; previously issued receipts remain immutable evidence.