sendPayment() in src/services/stellar.ts submits raw Stellar Operation.payment transactions directly against Horizon, with no interaction whatsoever with the Orbit-Wal/contract repo's globe-wallet Soroban contract, which implements per-user daily spend limits and an asset whitelist (record_spend, get_assets). This means any protection the contract layer is meant to provide (e.g. a user-configured daily cap intended to limit blast radius of a compromised device) provides zero actual protection today, because the mobile client never routes payments through it — the enforcement exists on paper in a different repo and nowhere in the actual signing path.
Definition of done:
- Documented decision: should ordinary payments route through the Soroban contract (adding complexity/fees) or should the contract's spend-limit only apply to a specific class of managed/custodial flows — this needs an explicit answer, not silent divergence
- If routing through the contract is the right answer, a Soroban RPC client integration added to
src/services/
- If it's not, the contract repo's spend-limit feature's actual scope/purpose needs to be re-documented so it stops implying protection the mobile app doesn't provide
Before opening a PR for this issue, read CONTRIBUTING.md.
This is not a starter-issue. The Definition of done above is the full
acceptance criteria, not a subset to sample from — a PR that addresses part
of it is an unfinished issue, not a smaller one. Your PR must include, in
the PR description itself:
PRs missing these will be sent back before review, not reviewed and rejected — please do this up front.
sendPayment()insrc/services/stellar.tssubmits raw StellarOperation.paymenttransactions directly against Horizon, with no interaction whatsoever with theOrbit-Wal/contractrepo'sglobe-walletSoroban contract, which implements per-user daily spend limits and an asset whitelist (record_spend,get_assets). This means any protection the contract layer is meant to provide (e.g. a user-configured daily cap intended to limit blast radius of a compromised device) provides zero actual protection today, because the mobile client never routes payments through it — the enforcement exists on paper in a different repo and nowhere in the actual signing path.Definition of done:
src/services/Before opening a PR for this issue, read CONTRIBUTING.md.
This is not a starter-issue. The Definition of done above is the full
acceptance criteria, not a subset to sample from — a PR that addresses part
of it is an unfinished issue, not a smaller one. Your PR must include, in
the PR description itself:
PRs missing these will be sent back before review, not reviewed and rejected — please do this up front.