SECURITY

Security model overview

Tab's security model is layered. Each layer assumes the layers above it could fail and tries to make a failure survivable. Here's the stack, from the user's device down to the chain.

1. Client-side encryption

The private key never leaves the browser unencrypted. AES-256-GCM under a PBKDF2-derived key from the user's PIN. If our entire backend were stolen tomorrow, the worst the attacker could find is a list of opaque encrypted blobs that they still need to brute force a PIN against.

2. Authenticated requests

Every call into the Tab API carries an Authorization header. API keys are scoped (read, write, admin) and revocable from the dashboard. The web app uses short-lived session tokens; bearer tokens never get embedded in URLs.

3. Gatekeeper

No application logic on the user's device talks to the database directly. Everything goes through a server-side gatekeeper that validates input, enforces rate limits, and checks authorization before any query runs. Details in Gatekeeper pattern.

4. Relayer validation

Relayers do their own preflight: signature shape, deadline, nonce, balance, allowance. A request that would revert on-chain is rejected before it eats anyone's gas.

5. On-chain enforcement

The router has the final say. Signature is recomputed and verified. Fee is recomputed and compared. Nonce is checked and consumed. Reentrancy is blocked. If anything is off, the call reverts and nothing changes.

Reporting a vulnerability

Email security@thetab.bar. Security reports are triaged ahead of everything else; a PGP key is available on request. The Immunefi bug bounty pays up to $250,000 for critical findings on the router contracts.