PRD: Dara RWA Platform on Stellar

Requirement IDs (FR-, NFR-, INV-, AC-) are stable. Tests and ../TRACEABILITY_MATRIX.md refer to them.

1. Problem and objectivesCopy Anchor Link

Dara holds verified backing in real-world assets. Customers want fractional, transferable, verifiable ownership without physical delivery. The platform must:

1. Issue one Classic Stellar asset per RWA strictly within approved backing (Q-02).
2. Let KYC-approved customers buy from and sell to the Treasury, and transfer to other customers, through a custodial wallet where every trade is a Stellar transaction (Q-01).
3. Record every movement of money and tokens in an immutable, balanced double-entry ledger.
4. Run on self-hosted Stellar RPC and its own indexer; no hosted RPC or indexer is required for correctness.
5. Keep reserve sourcing behind ReserveCapacityProvider, so the Layer-2 capacity engine plugs in without redesign.

2. MVP scopeCopy Anchor Link

In: asset definitions (generic), manual reserve snapshots, four-eyes issuance and burn via issuer multisig, hot/cold Treasury, customer onboarding (sponsored account + trustline + authorization), BUY, SELL, TRANSFER between platform customers, manual price, quotes, manual cash deposit/withdrawal records (maker-checker), freeze/unfreeze, clawback (dual approval), reconciliation, audit, admin console, customer wallet, public scanner, landing site, trading gate, make demo.

Out (MVP): payment rails and on/off-ramps (cash is recorded by operators); physical redemption; external Stellar withdrawals and deposits (Q-09); self-custody and key export; DEX usage; Soroban contracts and SAC deployment; automated KYC provider; price feeds; trading while Stellar is unavailable; validators; Layer-2 sources; native mobile apps.

Assets: GOLD (1 GOLD = 1 g of 750 gold). SILVER and OIL are demo-only until their units are defined (Q-04).

3. PersonasCopy Anchor Link

Visitor; Customer; and staff roles from ../security/AUTHORITY_MATRIX.md §3. Human issuer/Treasury signers (H, T) act through the signing procedure (§4 there).

4. JourneysCopy Anchor Link

5. Functional requirementsCopy Anchor Link

AssetsCopy Anchor Link

• FR-01: Create a generic asset definition: internal ID, code, name, unit of measure and definition, display precision (≤ 7), min/max order quantity, buy/sell spread and fee (bps), transfer limits. No asset-specific code paths.
• FR-02 [XLM]: An asset becomes tradable only when its on-chain identity (code + issuer + passphrase) is registered, the issuer's flags and signer set match the approved configuration, both Treasury accounts have authorized trustlines, and a fresh price exists.
• FR-03: Suspend or resume trading per asset (off-chain).

Reserves, issuance and burnCopy Anchor Link

• FR-04: Layer 1 reads backing only through ReserveCapacityProvider (MVP: ManualReserveCapacityProvider).
• FR-05: Backing changes are four-eyes, absolute values with an attestation reference and an as-of date. One attestation reference cannot back two assets or two snapshots. A snapshot below current supply is refused. Backing older than its validity window blocks issuance.
• FR-06 [XLM]: Issuance: amount ≤ approved backing − on-chain supply − pending issuance, checked at request, at approval and again when the proposal is built. The destination is always TREASURY_COLD. One approved request yields one signing proposal and at most one on-chain effect.
• FR-07 [XLM]: Burn: amount ≤ COLD available inventory (reserved inventory excluded). Executed as Payment COLD → issuer. Backing release is allowed only after the burn is applied and reconciliation of that asset passes.
• FR-08 [XLM]: Treasury refill COLD → HOT is four-eyes plus a human multisig; sweep HOT → COLD above the configured ceiling is automatic.

Customers and walletCopy Anchor Link

• FR-09: Registration with email + password; server-side sessions.
• FR-10 [XLM]: KYC approval triggers onboarding (../stellar/STELLAR_ARCHITECTURE.md §4). The customer sees one wallet per asset, not trustlines.
• FR-11 [XLM]: Freeze/unfreeze per customer: off-chain block + on-chain trustline de-authorization; unfreeze is four-eyes.
• FR-12: The wallet shows per-asset total/available/reserved, cash, the Stellar account, orders, and history with transaction hash, ledger and state.
• FR-13: Cash deposits/withdrawals are maker-checker; withdrawal holds cash immediately.

Pricing and quotesCopy Anchor Link

• FR-14: Manual mid price per asset in IRR per unit; a move above max_price_move_bps needs a second approver; prices older than price_max_age are stale.
• FR-15: A quote holds asset, side, quantity, reference price, spread, fee, unit price, gross, total, price ID/source/time, created/expires (30 s). Immutable. Executes once, only by its owner, before expiry.
• FR-16: Quotes are refused when the price is stale, the asset is not tradable, the quantity is out of bounds, the customer is not ACTIVE, or the gate is closed.

TradingCopy Anchor Link

• FR-17: BUY atomically reserves the total from cash and the quantity from HOT available inventory, then settles HOT → customer on-chain.
• FR-18: SELL reserves the customer's tokens, settles customer → HOT, then credits cash (gross − fee). The customer is never paid before the token payment is applied.
• FR-19: TRANSFER moves tokens between two ACTIVE customers, with no fee, within limits.
• FR-20 [XLM]: An order is COMPLETED when its transaction is applied in a closed ledger. A failed or expired attempt releases holds by reversing entries (an expired attempt may first be retried as a new attempt while the order's own deadline allows).
• FR-21 [XLM]: The trading gate closes on: no healthy RPC node; latest ledger close older than max_ledger_age; signer unhealthy; FUNDER below the critical floor; too many UNKNOWN attempts; or an open CRITICAL incident marked blocks_trading.
• FR-22: Configurable user limits: min/max per trade, daily buy/sell/transfer per customer and per asset.

Blockchain [XLM]Copy Anchor Link

• FR-23: Every on-chain action is an intent with attempts and the lifecycle in ../stellar/STELLAR_ARCHITECTURE.md §7. The signed envelope and hash are persisted before submission; a timeout is UNKNOWN, never FAILED.
• FR-24: Sequence numbers come only from the channel pool; the issuer, Treasury and customer accounts are never transaction sources.
• FR-25: Every transaction has an upper time bound and a MEMO_HASH linking it to its intent.
• FR-26: The gateway routes across our own RPC nodes by health; writes resubmit identical envelopes only.
• FR-27: Startup refuses mismatched passphrase, issuer, flags, signer sets, Treasury or channel accounts, and dev signers on public networks.
• FR-28: The self-hosted indexer processes every ledger in order from its checkpoint and raises CRITICAL on any unexpected issuance, clawback, authority change, foreign holder or unknown movement.

Scanner, landing, adminCopy Anchor Link

• FR-29: The public scanner shows assets, supply, the approved backing summary, Treasury balances, issuer flags/signers/thresholds, transactions of our assets, account pages (no identity), issuance/burn/clawback history and the latest reconciliation. It reads only chain-derived and explicitly published data.
• FR-30: Landing site (fa/en, RTL) explains the assets, units, backing, issuer powers (freeze, clawback) and on-chain visibility.
• FR-31: The admin console covers assets, reserves, issuance/burn/refill with signing status, prices, cash, customers/KYC/freeze/clawback, orders, Treasury and XLM health, RPC health, reconciliation and incidents, audit, staff and roles, gate.

Reconciliation, audit, APICopy Anchor Link

• FR-32: Reconciliation compares on-chain supply, HOT/COLD and every customer account against the ledger and backing; checks supply ≤ backing; issued − burned − clawed back = supply; no foreign holders; no claimable balances; issuer configuration = approved. Findings are never auto-corrected.
• FR-33: Every administrative and financial action writes an append-only audit event.
• FR-34: Financial mutations require Idempotency-Key; replay returns the original response; key reuse with another payload returns 422.

6. Invariants (machine-checked; ../finance/INVARIANTS.md at implementation)Copy Anchor Link

• INV-01: On-chain supply ≤ approved backing capacity.
• INV-02: On-chain supply = HOT + COLD + Σ customer accounts (closed holder set).
• INV-03: BUY, SELL, TRANSFER, refill and sweep leave supply unchanged.
• INV-04: Each approved issuance/burn changes supply exactly once by exactly its amount.
• INV-05: Every ledger transaction balances (debits = credits) per currency/asset.
• INV-06: No customer cash or token position below zero; reserved ≤ total.
• INV-07: HOT reserved inventory ≤ HOT on-chain balance.
• INV-08: One attestation reference backs at most one snapshot; one approved request yields at most one applied transaction.
• INV-09: A duplicated API request has one economic effect.
• INV-10: An UNKNOWN attempt is never rebuilt until proven EXPIRED.

7. Non-functional requirementsCopy Anchor Link

Ported unchanged from the sibling PRD (precision, atomicity, concurrency, crash recovery, security, observability, auditability, local performance baseline, independence, portability, i18n), with one addition:

• NFR-12 [XLM]: No hosted Stellar service in the production path. SDF's public Testnet RPC is allowed only in TESTNET as a read fallback.

8. Acceptance criteria (summary)Copy Anchor Link

The brief's §166 list, plus the E2E scenarios of brief §116–118 adjusted for hot/cold: "Treasury" = HOT + COLD, and issuance lands in COLD.