Subscriptions with Wraith Names tutorial

[truthixify]

Tier: M (2-4 days) | Type: tutorial

Context. Recurring payment mechanics are already scattered across two pages: guides/spectre-stellar-cookbook.mdx has "Recipe 2: DAO Weekly Payroll in USDC on Stellar" (lines 289+) with a monthly-destination-rotation step and a full payroll scheduler; guides/stellar-payment-links.mdx lists subscription billing as a row in the expiry table (line 312). What no page covers is the .wraith name composition angle: how using a .wraith handle instead of a raw meta-address changes cancellation, migration, and name-expiry behavior in a subscription flow. This tutorial focuses on that composition, with the cookbook and payment-links pages linked as prerequisite reading.

Scope.

• New guides/stellar/subscriptions-with-wraith-names.mdx.
• Model: recipient publishes a .wraith name; payer schedules recurring stealth transfers keyed off the name (not the meta-address), so the recipient can rotate address without breaking the subscription.
• Contrast against the cookbook's raw meta-address flow: what changes for cancellation, missed-payment behavior, and name-expiry edge case.
• Off-chain scheduler pattern (link to cookbook Recipe 2 for the mechanics, do not duplicate).
• End-to-end example (monthly USDC to merchant.wraith) showing a name rotation mid-subscription.

Acceptance.

• Example runs against futurenet fixtures
• Renders in mint dev
• Passes Compile docs snippets CI
• Cross-linked with wraith-names-lifecycle.mdx, stellar-payment-links.mdx, and spectre-stellar-cookbook.mdx Recipe 2
• Nav entry under Guides

Files. guides/stellar/subscriptions-with-wraith-names.mdx (new), docs.json.

[Salauayo]

@Salauayo has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I’d like to contribute to this issue. I’ve worked on similar tasks before and can start right away.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Salauayo to this issue.

[kelvin1738-sys]

@kelvin1738-sys has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I'm interested in contributing to this task and can deliver a clean, reliable implementation within a reasonable timeframe while meeting the project's quality standards.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @kelvin1738-sys to this issue.

[drips-wave]

Congratulations, @kelvin1738-sys! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @kelvin1738-sys: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[kelvin1738-sys]

Before implementing this tutorial, I found a network mismatch in the current repository:

• Issue Subscriptions with Wraith Names tutorial #127 requires the example to run against Futurenet fixtures.
• reference/stellar-networks.mdx currently states that Wraith contracts are not deployed on Futurenet.
• getDeployment(futurenet) therefore provides RPC/passphrase details but no Wraith contract addresses.
• The requested subscription flow depends on .wraith name resolution and rotation, which require the wraith-names contract.

Should this tutorial target Stellar Testnet for now, or are Futurenet Wraith deployments/fixtures expected to land separately? I do not want to document a flow as runnable on a network where the required contracts are unavailable.