Security & privacy

Good contracts need good math.

You're writing something sensitive. What you write should not slip away, change without a trace, or be impersonated. This page describes SEAL's security architecture in detail — encryption, signing, data storage, even our limits.

Device-based signing

Each device generates its own Ed25519 keypair. The private key stays on your phone — the server only stores your public key and uses it to verify your signatures.

Ed25519 · TweetNaCl / PyNaCl

Tamper-evident audit chain

Every signed action on a receipt is added to an append-only log, each entry chained to the one before it with SHA-256. Removing or altering an entry in the middle is mathematically detectable.

SHA-256 append-only

Passwordless, phone-verified

We store no passwords. Phone verification uses Twilio WhatsApp with a 6-digit OTP. Codes are stored as salted SHA-256 hashes, compared in constant time, and expire in 5 minutes.

WhatsApp OTP · Salted SHA-256

Minimum data

No email, no password, no address. Only your phone (E.164) and the display name you enter when pairing. Phone numbers are masked on the public verification page.

PII minimization

Encrypted in transit and at rest

All connections (app → API, OTP, push) use HTTPS, and the MongoDB Atlas database is encrypted at rest.

TLS 1.3 · Atlas at-rest

Public verifiability

Every receipt has a unique code. Anyone with the code can see its status, content hash, signature status and audit-chain records at getseal.app/verify — no app needed.

Public verifiability

Detailed view

Signing model

The first time you pair or take a signed action, your device generates its own Ed25519 keypair. The private key is kept in the phone's secure storage (iOS Keychain / Android Keystore) and is never sent to the server. Key actions on a receipt — including the approval that seals it — are signed by the device with its private key, and the server checks each signature against the public key registered for your account. The server stores only public keys: it can check a signature but cannot produce one. It does decide which key belongs to which account: if you move to a new phone, you verify your number over WhatsApp and the new phone's key replaces the old one.

Audit chain

Every signed action on a receipt (create, edit, accept or reject an edit as a whole, approve, reject) is added as an entry to one append-only audit log shared by all receipts. Each entry is normalized to JSON and hashed with SHA-256 together with the hash of the entry before it, and the result is stored as the new chain hash. We call this the "audit chain". Changing or deleting an entry in the middle would break every later hash, so tampering is detectable. When an edit is resolved item by item instead, the merged text is saved as a new version without a chain entry of its own; what seals the receipt is a separate signed approval, which is chained and covers the content hash of exactly that version.

OTP & session

Phone verification is done via Twilio WhatsApp Business with a 6-digit, 5-minute, single-use code. The OTP is never stored in plaintext — it is salted and SHA-256 hashed; comparison is constant-time (timing attack protection). 10 OTPs per phone per hour, locked after 5 failed attempts. There is no JWT in our session model; every request travels with the device UUID and the relevant Ed25519 signatures.

Data storage & PII

No password, email, address, or card or bank details are stored on the server — only the verified phone number (E.164), the display name you enter when pairing, and your receipts and drafts. These live in MongoDB Atlas in the EU (AWS Frankfurt, eu-central-1), which encrypts data at rest (AES-256); connections use TLS. Our application server runs on Railway with managed HTTPS. Field-level encryption is not applied today; it's on our roadmap.

Public verification

Every receipt has a unique code in the form "SEAL-XXXXXXXX". The getseal.app/verify page is public: without installing the app, anyone with the code can see the receipt's status, subject, dates, the parties' names and masked phone numbers, its content hash, and each audit-chain entry with the signature status our server recorded and the key fingerprint. The agreement's items are not shown on the public page; only the parties can see them in the app or in the PDF.

Legal note

SEAL produces strong evidence — a tamper-evident record of device-signed actions, whose status anyone with the receipt code can look up — but it does not replace qualified e-signatures (e.g. Turkish NES, EU eIDAS QES). For high-value or formal transactions like deeds and corporate filings, combine SEAL with a notary or a qualified e-signature.