Security Model
Formal invariants, audit status, non-custodial assurances, and threat vector analysis.
Security in SplitPay is grounded in compile-time type safety, authorization assertions, and mathematical invariants verified through automated unit and fuzz tests.
Formal Financial Invariants
- Invariant 1 (BPS Exactness):
sum(member.share_bps) == 10,000. A pool cannot accept payments unless its shares sum to exactly 10,000 basis points. - Invariant 2 (Zero Loss):
sum(distributions.amount) == payment.amount. Every asset unit is distributed without truncation leakage. - Invariant 3 (Idempotent Settlement): A payment cannot be settled more than once.
- Invariant 4 (Historical Immutability): Mutating pool members after settlement has zero effect on past payment receipts.
- Invariant 5 (Strict Authorization): Only authorized actors can mutate pool state or release payment funds.
Security Audit Status
Threat Vector Analysis
Reentrancy: Soroban does not support reentrancy between contracts in the manner of Ethereum EVM call depth attacks. Furthermore, SplitPay executes external token transfers sequentially after calculating state snapshots.
Private Key Custody: SplitPay contracts and client applications never store, hold, or bridge private keys. Key signing is delegated entirely to user wallets.
Responsible Disclosure
If you discover a potential vulnerability, please report it via private security advisory on GitHub or email the core maintainers. Do not file public GitHub issues for security vulnerabilities.