Schnorr Signature Authentication
Every authenticated request is signed with a BIP-340 Schnorr signature tied to the user’s Bitcoin public key.- The user signs a message containing the HTTP method, request path, timestamp, and body hash.
- The protocol verifies the signature against the user’s registered public key.
- No passwords, cookies, or session tokens are used for user authentication — identity is proven cryptographically on every request.
Timestamp Binding
Each signed request includes a Unix timestamp. Requests where the timestamp diverges from the current time by more than a narrow window are rejected, preventing replay attacks using captured signatures.Body Integrity
The SHA-256 hash of the request body is included in the signed message. Any modification to the body after signing invalidates the signature, ensuring end-to-end integrity of every request.Rate Limiting
A per-IP token-bucket rate limiter protects the protocol from abuse. Each IP address is allocated a sustained request rate with burst capacity. Requests exceeding the limit are temporarily rejected until the bucket refills.MuSig2 Custody Guarantees
User deposit addresses are secured by 2-of-2 MuSig2 key aggregation between the user and the platform. Neither party can unilaterally move deposited funds. See the Custody Model for full details on the address structure and spend paths.CSV Recovery Timelocks
Dual CheckSequenceVerify (CSV) timelocks provide independent recovery paths:| Recovery Path | Approximate Timelock | Purpose |
|---|---|---|
| User recovery | ~30 days | User reclaims funds if the platform goes offline |
| Platform recovery | ~60 days | Platform recovers dormant funds after a longer wait |
Session Expiry and Balance Release
MuSig2 signing sessions have a limited lifetime. When a session expires without completing:- All balances locked for that session are automatically released back to the user’s available balance.
- The expired session cannot be resumed; the user must initiate a new signing flow.
Reorg Detection
The protocol maintains a rolling window of recent block hashes. On each new block, the parent hash is compared against this window. A mismatch signals a chain reorganization, triggering re-evaluation of affected deposits:- Deposits that were credited but are no longer confirmed on the new chain tip are rolled back.
- The deposit state machine re-processes affected transactions against the reorganized chain.