Data model
Six tables, defined in prisma/schema.prisma. No Soroban contracts are involved anywhere; this is classic Stellar payments only.
Batch
The center of the schema. One row per batch, whether it's an anonymous draft or a claimed, sent batch.
| Field | Notes |
|---|---|
ownerPublicKey | Null until claimed. The wallet that owns and will sign this batch. |
anonId | Set at creation if there's no authenticated session yet. Scopes a wallet-less draft instead of ownerPublicKey. |
claimedAt | Set the moment a wallet claims an anonymous draft. |
network | TESTNET or PUBLIC. |
assetCode / assetIssuer | Both null means native XLM. |
sourceAccount | The account payments will be sent from. Set together with ownerPublicKey at claim time; a batch created while already signed in gets both set at creation instead. |
status | See How a batch moves through Sendall for the full state list. |
A batch is never owned without also having a sourceAccount, and vice versa. The two move together everywhere a batch is claimed or created already-owned.
Recipient
One row per line in the batch. Carries both the input (destination, amount, memo) and the results of validation and on-chain checks (addressValid, accountExists, currentBalance, hasTrustline, trustlineLimitOk), plus its own status (see the line-item status table in How a batch moves through Sendall).
PaymentAttempt
One row per transaction chunk built for a batch. Holds the built XDR envelope, the eventual result XDR, the transaction hash once submitted, and requiresSignature, which is false for a payment chunk that's authorized by a preAuthTx signer instead of a direct wallet signature (see Transaction building).
PaymentAttemptItem
Links a PaymentAttempt to the Recipients it pays, one row per operation in that transaction, with its own result code once the transaction lands. This is what lets Sendall report a per-recipient outcome even though several recipients share one transaction.
AddressList and AddressListEntry
A saved list of name-and-address pairs, always owned by a wallet from creation (no anonymous stage, unlike Batch). An entry stores its own addressValid flag from when it was added, but doesn't carry on-chain check state the way a Recipient does, since a list isn't tied to any specific network or asset until you start a batch from it.
RefreshToken
Backs the 30-day session refresh flow described in Authentication. Only the SHA-256 hash of the token is stored, never the raw value, and each row is single-use: redeeming one deletes it and issues a new one in its place.