Dara DocsXLM Reserve and Fee Model
Customers never see or hold XLM (Q-01). Facts: base reserve 0.5 XLM; minimum balance = (2 + subentries + numSponsoring − numSponsored) × 0.5 XLM; inclusion fee ≥ 100 stroops per operation (baseline §4).
1. Who pays what
| Cost | Paid by | Mechanism |
|---|---|---|
| Customer account base reserve (1 XLM) | RESERVE_SPONSOR | Sponsored CreateAccount with a 0 XLM starting balance |
Customer CUSTODY signer (0.5 XLM) | RESERVE_SPONSOR | Inside the same sponsorship |
| Customer trustline per asset (0.5 XLM) | RESERVE_SPONSOR | Inside the same sponsorship |
| Every transaction fee | The channel account that sources the transaction | Channel XLM, topped up by FUNDER |
| System accounts' reserves | Platform | Funded at the ceremony |
Per customer with GOLD only: 2 XLM locked in RESERVE_SPONSOR (1 + 0.5 signer + 0.5 trustline); +0.5 XLM per additional asset. The XLM is locked, not spent. Closing a customer account later (merge, or revoke the sponsorship after removing the trustline) releases it.
Automatic transactions do not use fee bumps: channels pay their own fees, and an expired 60-second attempt is simply rebuilt at the current fee. Human-signed proposals are the exception. They live for up to 24 h, and rebuilding one means asking the human signers to sign again. If surge pricing outbids a signed proposal, FUNDER wraps the unchanged inner envelope in a fee bump (at least 10× the original bid to replace it). This is planned for Stage 25. It needs a spike first to confirm how getTransaction resolves the inner and outer hashes, because the transaction manager tracks attempts by hash.
2. Operational XLM budget (formula; values are configuration, not hard-coded)
sponsor_locked = customers × (1.5 + 0.5 × assets_per_customer)
channel_float = channels × (1 + fee_runway)
fee_runway = expected_tx_per_day × ops_per_tx × fee_per_op × runway_daysExample at the base fee: 100,000 settlements/day × 1 op × 100 stroops = 1 XLM/day. Surge pricing is bounded by max_fee_per_op.
3. Thresholds and monitoring
| Account | Healthy | Warning | Critical (blocks new work) |
|---|---|---|---|
RESERVE_SPONSOR available | ≥ reserve for the next onboarding_headroom customers | below that | < 10 onboardings: KYC approvals queue, trading continues |
| Each channel | ≥ channel_target | < 50 % | < channel_min: channel removed from the pool; FUNDER top-up |
FUNDER | ≥ funder_runway_days of fees | < 50 % | < 3 days: trading gate closes before the pool runs dry |
TREASURY_HOT / COLD XLM | ≥ own minimum balance + 10 XLM | — | below minimum balance + 2 XLM |
"Available" = balance − minimum balance − selling liabilities, read from the ledger entry. Each transition is a metric and an alert. Reconciliation includes fee spend per day (indexer sum of feeCharged for our channels) against the ledger's fee expense account.