ProtocolBanks implements a Non-Custodial architecture where:
- Users maintain full control of their private keys
- ProtocolBanks cannot access, move, or freeze user funds
- All data is encrypted and isolated per customer
Every database table has RLS policies ensuring:
-- Users can only see their own data
CREATE POLICY "View own data" ON table_name
FOR SELECT USING (
owner_address = current_setting('app.current_user_address', true)
);| Data Type | Isolation Method |
|---|---|
| Vendors | created_by = user wallet address |
| Payments | from_address = user wallet address |
| Batch Payments | wallet_address = user wallet address |
| Multi-sig Wallets | created_by OR member of signers |
| Embedded Wallets | user_id = authenticated user ID |
- Read customer private keys
- Decrypt customer wallet shares
- Execute transactions on behalf of customers
- Access customer payment history without authorization
- Modify customer data without user action
┌────────────────────────────────────────────────────┐
│ Safe (Gnosis Safe) │
│ │
│ Signers: [CFO, CEO, Controller] │
│ Threshold: 2 of 3 │
│ │
│ ProtocolBanks: NOT A SIGNER │
│ ProtocolBanks cannot execute transactions │
└────────────────────────────────────────────────────┘
- Proposal - Any signer can propose a transaction
- Review - Other signers review transaction details
- Sign - Each signer cryptographically signs the transaction
- Execute - When threshold is met, anyone can execute
- Audit - All actions are logged immutably
Private Key → Split into 3 shares
├─ Share A: Device (encrypted, never leaves browser)
├─ Share B: Server (encrypted with user PIN)
└─ Share C: Recovery (user-stored backup)
Threshold: 2 of 3 shares required to reconstruct
| Attack Vector | Protection |
|---|---|
| Server breach | Only encrypted Share B, cannot reconstruct key |
| Device theft | Requires PIN + Share B from server |
| Admin access | No admin can access 2 shares |
| Man-in-middle | All shares encrypted, HTTPS enforced |
All sensitive actions are logged:
INSERT INTO audit_logs (
actor,
action,
target_type,
target_id,
details,
ip_address
) VALUES (
'0x...user_address',
'batch_payment_created',
'batch_payment',
'uuid',
'{"amount": 10000, "recipients": 5}',
'xxx.xxx.xxx.xxx'
);Audit logs are immutable - no updates or deletes allowed.
- Session-based authentication with HTTP-only cookies
- JWT tokens with short expiration
- Device fingerprinting for session binding
- Per-IP rate limits
- Per-user rate limits
- Per-action rate limits (e.g., 10 payments/minute)
- All wallet addresses validated with checksum
- Amount validation (positive, within limits)
- SQL injection prevention via parameterized queries
- Data encrypted at rest (Supabase)
- Data encrypted in transit (TLS 1.3)
- GDPR-compliant data handling
- SOC 2 Type II (Supabase infrastructure)