Contract Overview
Detailed architecture of the SplitPay Soroban smart contract (v22).
The SplitPay smart contract (splitpay-contracts) is written in Rust targeting the Soroban v22 smart contract runtime on Stellar.
Overview & Compilation Target
The contract compiles into a standalone WebAssembly (WASM) bytecode package (target/wasm32-unknown-unknown/release/splitpay.wasm). It has zero external server dependencies and operates autonomously on the Stellar ledger.
Storage Architecture
SplitPay uses Soroban's typed key-value storage deliberately to maintain predictable ledger footprint sizes:
| Data Key | Type | Storage Scope | Description |
|---|---|---|---|
| Config | ContractConfig | Instance | Contract admin identity |
| Pool(u64) | Pool | Persistent | Pool configuration (owner, asset, status) |
| Member(u64, Address) | Member | Persistent | Individual member basis points |
| PoolMembers(u64) | Vec<Address> | Persistent | Ordered list of member addresses in pool |
| Payment(u64) | Payment | Persistent | Payment record and status |
| Distribution(u64, Address) | Distribution | Persistent | Historical payout record per recipient |
| PaymentRecipients(u64) | Vec<Address> | Persistent | List of recipients in settled payment |
SEP-41 Token Integration
SplitPay does not implement custom token ledger balances. Instead, it interacts directly with any Stellar Asset Contract conforming to the official SEP-41 token interface using soroban_sdk::token::Client.
Structured Event System
Every state-changing method publishes structured events onto the ledger for indexing:
- ("pool_created", pool_id) → (owner, asset, created_at)
- ("member_added", pool_id) → (address, share_bps)
- ("member_removed", pool_id) → address
- ("share_updated", pool_id) → (address, old_share, new_share)
- ("pool_status_changed", pool_id) → status
- ("payment_created", payment_id) → (pool_id, payer, amount)
- ("payment_settled", payment_id) → (pool_id, payer, amount)
- ("distribution_created", payment_id) → (recipient, amount, share_bps)