Data Security at PivLinks

Request path (simplified): User browser → TLS → Vercel edge / Next.js application → API routes → Supabase (PostgreSQL) + Privy (auth / payments) + Solana RPC → on-chain programs.

Design principle: Money movement is enforced on-chain by the escrow program; the backend coordinates metadata, verification, and signing workflows. This separation reduces reliance on opaque custodial ledgers while introducing blockchain-specific risks (see Terms).

• Anchor program — Escrow logic is implemented in a Solana program with explicit checks (e.g., USDC mint validation, vault balances, authorized flows).
• PDA vaults — Per-invoice PDAs isolate funds and reduce cross-invoice bleed.
• Fee split — Release paths enforce configured splits (e.g., 99% freelancer / 1% treasury) at the program level where deployed.
• Transparency signatures — We compute a SHA-256 digest over a structured payload (invoice id, wallets, amounts, tx signatures, status) and store it with the invoice record to support integrity checks of disclosed state.
• Public audit trail — Anyone with a Solana explorer can verify transactions; privacy is limited for amounts and addresses involved.

Authentication and embedded wallets are provided through Privy. We encourage users to enable multi-factor authentication where available, protect device passcodes, and revoke sessions on lost devices.

Wallet private keys are managed by Privy's infrastructure under their security model; review Privy's documentation for MPC/HSM and recovery details.

• Release passwords are hashed (e.g., bcrypt) before storage; plaintext is not retained.
• Passwords are not returned by APIs and should not be logged in application telemetry.
• Rate limiting and monitoring reduce brute-force attempts against release endpoints.
• Users must treat the release password like a wire authorization code—anyone with it may enable release.

• In transit: HTTPS/TLS 1.2+ for browser and API traffic.
• At rest: Supabase-managed encryption for database storage; backups inherit provider controls.
• Access control: Row Level Security (RLS) policies and service-role keys scoped to server environments only.
• Secrets: Environment variables in Vercel (or equivalent) for Supabase keys, Privy credentials, and signing material—never committed to source control.

• Input validation on API routes; parameterized queries via Supabase clients.
• Session verification through Privy before sensitive operations.
• CORS and security headers configured per deployment best practices.
• Dependency updates and static analysis integrated into development workflow (roadmap: CI gates).

• Least-privilege access to production data; administrative actions logged where feasible.
• V1 signing model: A controlled operational key may sign certain release transactions. This reduces client-side friction but concentrates operational risk—see README and roadmap for migration toward client-signed releases.
• Key rotation procedures for API keys and infrastructure credentials.

Security-relevant actions are recorded in the `activity_audit_events` table (see migration 004) with timestamps, actors, and JSON metadata for investigations.

Invoice-level transparency signatures (see `lib/api/transparency.ts`) help detect tampering of disclosed off-chain summaries relative to on-chain references.

Alerts may cover failed releases, unusual dispute volume, or authentication anomalies—coverage expands with product maturity.

• Supabase provides automated backups; point-in-time recovery options depend on your project plan.
• RTO/RPO targets (placeholder): RTO 4h / RPO 1h for database tier—confirm in production runbooks.
• Blockchain data is replicated by Solana validators; recovery focuses on off-chain state reconciliation.

• Regular dependency review; critical CVEs patched on expedited timelines.
• Smart-contract changes require testnet validation and peer review before mainnet promotion.
• Third-party penetration tests and formal audits may be scheduled as the product matures—results published when available.

We welcome coordinated disclosure of security vulnerabilities. Please email security@pivlinks.example.com with encrypted details if possible (PGP key placeholder: publish before production).

Scope (illustrative): pivlinks domains, API endpoints, smart-contract escrow flows, and mobile/web clients. Out of scope: third-party spam, social engineering, or physical attacks.

Safe harbor: We will not pursue legal action for good-faith research that complies with this policy, does not degrade service, and allows reasonable time to remediate before public disclosure.

SLA (goal): Initial response within 72 hours; critical issues prioritized for mitigation.

1. Detection — automated alerts, user reports, or provider notifications.
2. Containment — isolate affected systems, rotate credentials, pause risky features.
3. Eradication & recovery — patch vulnerabilities, restore from clean backups, verify chain reconciliation.
4. Notification — inform affected users and regulators as required (e.g., GDPR breach notifications without undue delay, within 72 hours where applicable).
5. Post-incident review — root-cause analysis and preventive controls.

Current state: We implement baseline security controls suitable for an early-stage product handling financial workflows. We are not yet SOC 2 Type II certified; certification may be pursued as customer demand requires.

Roadmap: Expanded logging, formal access reviews, vendor risk program, and continuous compliance monitoring.

Regulatory: We design processes with GDPR, CCPA, AML/sanctions screening, and recordkeeping obligations in mind—see Privacy Policy.

• Enable MFA on your Privy account; use unique passwords and device locks.
• Share invoice and release links only with trusted counterparties over secure channels.
• Verify domain names and TLS certificates before entering credentials.
• Store release passwords offline or in a password manager; never paste them into public chats.
• Report suspicious emails or impersonation attempts to security@pivlinks.example.com.

Security issues: security@pivlinks.example.com

Privacy: privacy@pivlinks.example.com

General contact