How your data is protected

1. 01

   Envelope encryption + KMS

   Every account credential (email, password, recovery, 2FA seed) is written to the application database only encrypted. The encryption key itself is also encrypted by a master key (envelope). The master key never lives on the application server; it sits in an external Key Management Service (KMS). Decrypt is called only at transaction time, through an audited channel.

2. 02

   Row Level Security on every table

   RLS policies active at the Postgres level. A user cannot reach a single row that isn't theirs — even if an application bug exists, the database refuses directly. This is a stronger guarantee than defensive programming: the failure chain is broken.

3. 03

   Money movement in ACID transactions

   Escrow, ledger and audit_log entries — the three legs of money movement — are written in the same database transaction. Two cannot succeed while the third fails; either all commit or all roll back. There is no possible 'paid but no log' or 'log exists but escrow empty' inconsistency.

4. 04

   Complete and signed audit logs

   Vault credential access, payout calls, dispute decisions, Hand-off ceremony transitions — each produces a signed audit log entry. Reversible, hashed, ordered. Even moderators have read-only access to this log.

5. 05

   HMAC-chained provenance

   Every sale receipt is linked to the previous sale's signature — Bitcoin's blockchain intuition, at low throughput. No sale history can be silently rewritten: if the chain breaks, it shows immediately.

6. 06

   Transparent enforcement

   If an account is suspended, the reason lands in the audit log and is made visible to the user. No silent bans. Appeals are open — the audit mechanism runs on a semi-independent line, not just internal.

Legal framework

Data processing is KVKK + GDPR compliant. Data collected/stored is minimal — what we keep and why is listed line-by-line in the Privacy Policy.