docs: add Trigger V2 DCA docs

[0xanmol]

Adds developer docs for DCA on the Trigger API, requested by the Suzi.trade / Send.fun team.

What's in it:

• New trigger/dca page: order types (time-based and price-conditional), the create flow, tracking, how rounds fill, fees and slippage, cancel, and errors.
• Trigger overview reframed around two order families: price orders and DCA.
• DCA endpoints added to the OpenAPI spec and API reference, plus nav and a changelog entry.

I tested all of it against the live API on mainnet, including the full create and cancel lifecycle and the edge cases (validation rules, the 10-active-order cap, native SOL input). The response examples are real captured responses, not hand-written.

Earn While You Wait (jlEnabled) is written but commented out in both the page and the spec, since it is deployed but not publicly released yet (LODCA-133). One block to uncomment when it ships.

Linear: https://linear.app/raccoons/issue/DEV-623/dca-v2-docs

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Jupiter	🟢 Ready	View Preview	Jun 26, 2026, 9:02 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[0xYankee-Raccoons]

Review — DCA docs verified against jup-ag/trigger-order source

Reviewed with the evidence-based methodology (authority order: live API + on-chain > source code > docs). Cross-referenced the DCA schema, validation, route handler, and keeper against current trigger-order main. Overall a strong PR — real captured mainnet responses, correct gating of the unreleased Earn While You Wait feature, keeper fees/slippage/Ultra routing all verified accurate. Two things to resolve before merge, plus one medium.

⚠️ Open decision (affects the page path)

Confirming with the team whether DCA is publicised under Trigger or Recurring. Same backend, but the FE brands this "Recurring"/"Limit", and there's already a V1 recurring/ section titled "Recurring (DCA) API". This PR places it under trigger/, which matches the live API path (/trigger/v2/orders/dca). If we move it, we need redirects. Resolving separately so it doesn't block the content.

🔴 Must fix

1. orderCount limit contradicts itself across the PR. Three places say "no fixed maximum" (the DCA page params table + its llmsDescription, llms.txt, the OpenAPI description) while two say "2–100" (the changelog entry and the overview "What is a DCA order?" accordion). The product-learning notes contradict themselves too (a "Limits (prod)" line says 2–100, an edge-case line says no upper bound). One of these ships wrong regardless of the live truth — reconcile all of them to a single answer.

2. Current source enforces the limits the PR documents as absent — re-verify against live before merge. On current main, orderCount is capped at 100 in two layers (the zod schema wired into the route, and a validateOrderCount check), and triggerMint is optional and defaults to outputMint — the opposite of what the PR documents (no max / triggerMint required). The PR's conclusions come from live mainnet tests, and the local source is provably behind the deployed API on the adjacent deposit-craft surface, so live likely wins here. But if the deployed API has since realigned to source, the docs are wrong on both counts. Re-run these two live checks right before merge; keep the docs if they still hold and add a source-vs-live divergence note, otherwise flip to "2–100" / "triggerMint optional".

🟡 Medium

3. The $10-per-round minimum is environment-driven, not a fixed rule. In source it's max(env minimum, floor constant), where the floor constant is currently a TEMP value lowered for testing and the env minimum isn't present in the committed config. It's likely 10 in prod, but presenting it as a hard, permanent rule is risky — phrase it as "currently 10 USD per round" and fix the corresponding product-learning source note.

🟢 Verified correct

Keeper routing through Ultra (no slippage param, AutoSettle, keeper pays fees), retryWindowSeconds clamp, max 10 active orders + active-state set, interval bounds, beginFillAt 30-day cap, dust-to-last-round, response schema and order-state table, no em dashes in rendered prose, internal links resolve, nav + API-ref stubs added with no orphans.