Summary
Pools currently accept a single hardcoded settlement token. The rotational contract already exposes set_supported_tokens (rotational/src/lib.rs), but the deposit flow is entirely single-token — the deposit route (/api/pools/deposit) and deposit UI render one fixed amount/symbol only. Wire up end-to-end multi-token (SEP-41 asset) deposit support.
Requirements
- Configurable supported tokens — add an admin pool-setting UI calling the existing contract
set_supported_tokens and persist the chosen assets to Supabase so the frontend knows what's accepted.
- Asset balance & trustline — on the deposit panel, show balances for each supported SEP-41 asset, handle missing trustlines (create/allow before deposit), and validate sufficient balance (handle the Stellar 7-trustline limit gracefully).
- Token-aware deposit route — extend
/api/pools/deposit/route.ts to accept a token selection and compute the correct trailing-decimals amount (stroops vs. 7-digit native) per asset, plus fee calc (treasury/relayer bps remain in the settlement token).
- Deposit UI — a token picker on the deposit/batch-deposit panels; display the chosen unit (e.g. USDC at 7 decimals vs. XLM native) consistently using the shared number-formatting conventions.
- Round/payout accounting — ensure payout and round state track which token each round settles in, and the activity feed / on-chain event indexing reflects the asset (reuse
soroban-event-mapping).
Notes / context
- The contract's
set_supported_tokens already exists — verify its semantics (whitelist vs. replace) and test it; add contract tests if behavior is under-specified.
- Reuse pure-logic layout convention (
frontend/lib/…) for amount/decimals/balance math so it is unit-testable like deposit-calendar.test.ts.
- Ensure the number-display follows the repo's number-formatting guidance (decimals, zero handling).
Acceptance criteria
Summary
Pools currently accept a single hardcoded settlement token. The rotational contract already exposes
set_supported_tokens(rotational/src/lib.rs), but the deposit flow is entirely single-token — the deposit route (/api/pools/deposit) and deposit UI render one fixed amount/symbol only. Wire up end-to-end multi-token (SEP-41 asset) deposit support.Requirements
set_supported_tokensand persist the chosen assets to Supabase so the frontend knows what's accepted./api/pools/deposit/route.tsto accept a token selection and compute the correct trailing-decimals amount (stroops vs. 7-digit native) per asset, plus fee calc (treasury/relayer bps remain in the settlement token).soroban-event-mapping).Notes / context
set_supported_tokensalready exists — verify its semantics (whitelist vs. replace) and test it; add contract tests if behavior is under-specified.frontend/lib/…) for amount/decimals/balance math so it is unit-testable likedeposit-calendar.test.ts.Acceptance criteria