Documentation
Everything Damla does, and everything it deliberately doesn't.
What is Damla?
Damla is dollar-cost averaging (DCA) for Stellar: you commit to buying a fixed amount of XLM with USDC at a frequency you choose (daily, weekly, or monthly), sign in one sitting, and the purchases execute automatically on Stellar's built-in DEX. It is non-custodial: your USDC stays in your own wallet until the moment each swap settles. It uses no smart contract.
Architecture
Damla is built on pre-signed transaction chains using classic Stellar features (CAP-21 preconditions, Protocol 19). No Soroban, no contract accounts. It works today with Freighter and a regular G-address.
One transaction per purchase, signed up front
When you create a plan, Damla builds one Stellar transaction for each scheduled purchase. Every transaction contains a single PathPaymentStrictSend operation: send a fixed amount of your USDC, receive XLM, with a destMin floor protecting you from bad fills. You sign all of them in one sitting (one Freighter prompt each). The amount, asset, destination, floor and time window are inside each signed hash and can never be altered afterwards.
A fresh channel account per plan
Each plan gets its own brand-new channel account. It is the source of every transaction (it pays the sub-cent fees and owns the sequence clock), while the operation's source is you. Two reasons. First, the chain lives on the channel's sequence numbers, so nothing you do in your own wallet can invalidate or delay it. Second, the channel does nothing else, so its clock is clean. The channel never holds user funds: only its own 1 XLM reserve, which a pre-signed merge returns to the service after the plan ends.
The channel's secret key is destroyed the moment your plan is activated. It signs your purchases once, then it is deleted. After that, the only transactions that can ever be built on that account are the ones you co-signed.
The protocol keeps time, not our server
Purchase i carries time bounds for its calendar window (it opens at t0 + (i-1)·P and closes two periods later) and a minSeqAge of one full period: it is invalid by consensus until the channel's sequence number has been untouched for a whole period. So a purchase can never run before its date, and two purchases can never land closer together than one period, no matter what our server does. Submitting early is not "against the rules": every validator simply rejects it with tx_too_early.
Skipped purchases don't break the chain
Every transaction carries minSeqNum = the channel's starting sequence, so purchase i is valid for any channel sequence between the start and its own number, not for a single point. If purchase 3 is skipped (window closed, XLM above your ceiling, no USDC), purchase 4 still works. Executing any purchase advances the sequence and invalidates all earlier envelopes for good. A swap that fails at the operation level consumes its slot and the chain continues.
The trigger service
A small service stores your signed envelopes and submits each one when its window opens. Before submitting it checks that the market currently gives at least your floor and that your wallet holds the USDC, because a transaction that fails on-chain still burns its slot. It cannot do anything else: it holds no keys that matter. You can export your signed envelopes at any time and submit them yourself if the service ever disappears.
Security model
There is no contract to audit because there is no contract. The trust assumptions reduce to Stellar's own protocol rules. Even a fully compromised trigger service:
- cannot submit a purchase early: time bounds and
minSeqAgeare checked by consensus - cannot run two purchases inside one period:
minSeqAgeagain - cannot change the amount, asset, destination or floor: they are inside your signed hash (
tx_bad_authotherwise) - cannot touch anything else in your account: each signature covers exactly one operation
- cannot create new transactions on the channel: its key no longer exists
- can at worst fail to submit, or pick a bad moment inside a window. No purchase happens, or you get a fill no worse than your floor.
All of this was exercised on testnet: docs/PROOF-testnet.md lists the rejected early submission, the rejected tampered envelope, four consecutive automatic purchases and the invalidated stale envelope, with hashes.
Cancelling a plan
Your USDC never leaves your wallet in advance, so cancelling is trivial: move or spend the USDC and future purchases simply wait for funds until their window closes. There is no lockup and nothing to withdraw. The plan page also has a Stop button that tells the service to stop submitting; the signed envelopes themselves stay valid inside their windows, which is why moving the USDC is the hard stop.
The floor (destMin)
Because transactions are signed weeks in advance, the minimum amount of XLM you accept per purchase is fixed at signing time. Damla does not treat this as a slippage setting, because a DCA buyer wants to keep buying as the price moves. It is a ceiling: you choose how far above today's price you are still willing to buy (+10%, +25%, +50%). The floor is today's quote divided by that factor.
If XLM rises past your ceiling, that purchase waits and, if the market does not come back within its two-period window, is skipped. Falling prices never block a purchase; you simply receive more XLM. The floor is also the hard bound on how badly any submission can fill, honest service or not.
Roadmap
- NowPlanner, Freighter signing, trigger service, plan page, export. Testnet, with a 1-minute demo cadence and a testnet USDC helper.
- NextMainnet switch-on (a funded treasury for channel reserves), monthly re-sign option, e-mail or Telegram receipts.
- LaterMore pairs (EURC, yXLM), wallet-side batch signing when wallets support it, a self-hosted trigger you can run yourself.