Review SEP-7 feasibility on a test donation-handler contract on stellar

[MoeNick]

• Make a simple test contract on donation handler
• Make a QR code with required params of 10 projects (including amounts, stellar address and memo for each)
• Scanning with Lobster wallet and testing the contract execution.

[ae2079]

Made a first pass on the test contract: a Soroban port of DonationHandler (single + batch donations, native XLM and any SAC asset, DonationMade event carrying the projectId).

• PR: feat: Soroban (Stellar) port of DonationHandler #8
• Deployed on testnet: CCAWXIU37ILOKXRPJVL56VJAVLJRKGNFSIXCAOLO3YFEDJV6DZRMJLAL — single + batch donations verified on-chain.

The SEP-7 / QR-code / LOBSTR-scanning analysis (incl. the 10-project batch and wallet support matrix) is covered in the feasibility report; remaining checklist items (QR generation + LOBSTR scan test) are the next step.

[ae2079]

QR batch sizing — dynamic N + upper bound

Built a parametric tool (stellar/tools/qr-batch/, in #8) that builds the real donate_many tx against the deployed testnet contract, encodes it as a SEP-7 web+stellar:tx?xdr=… URI, and measures the QR size as N (projects) grows. N is a parameter, not hardcoded to 10.

Key result — the upper bound depends on which SEP-7 flow:

Flow	Hard cap (fits one QR, V40)	Reliably scannable (~≤V20)
raw (wallet re-simulates)	~25 projects	~5–7
assembled (dApp pre-builds footprint+auth)	~3 projects	~1

• The requested 10 projects fits only via the raw flow, as a dense V26 QR — at the edge of reliable phone-to-screen scanning. Assembled N=10 is impossible (URI ~6,900 chars > QR max).
• Size scales ~76 B/project (raw) vs ~430 B/project (assembled — the auth tree + footprint dominate).
• The network is never the QR bottleneck: tx_max_size_bytes=132096, so even an assembled N=200 tx (~86 KB) is valid on-chain. The QR capacity binds 10–60× earlier. For larger batches use WalletConnect (only the pairing URI is in the QR); on-chain batch ceiling is then ~150–200 projects (tx_max_write_ledger_entries=200, tx_max_footprint_entries=400).

Caveat: the raw flow (and thus the 10-project QR) assumes the wallet re-simulates an incoming SEP-7 Soroban tx (a Soroban tx isn't submittable without SorobanData). If LOBSTR won't do that, only the assembled flow works → ~3 projects/QR max.

Remaining checklist item — the physical LOBSTR scan test is the manual step I will do it next

[MoeNick]

Your plan has four properties stacked together: (a) a Soroban contract call that batches up to 10 recipients, (b) delivered as a SEP-7 QR, (c) scanned on mobile, (d) with no wallet-connect/signature step in the Giveth UI. The first three can't coexist with the fourth on Stellar right now. Why:

SEP-7 is a classic-payment-era spec. It's still at version 2.1.0, last updated 2020, and predates Soroban entirely. It has two operations — pay (a single simple payment: one destination, one amount, one optional memo) and tx (a pre-built transaction XDR the wallet signs). There's no Soroban-aware operation. So a contract batch can only travel as a tx XDR.

A tx XDR can't be pre-built for an unknown donor. A Soroban InvokeHostFunction transaction needs a source account, a valid sequence number, and — critically — a simulated footprint, resource fees, and authorization entries that all depend on who is invoking. The simplest method to determine those Soroban resources is to simulate the transaction, which you can't do at QR-generation time because in your no-connect model you don't yet know the donor's account. SEP-7's replace field can ask the wallet to fill in a source account, but it can't make the wallet simulate-and-assemble a Soroban invocation from scratch — no SEP-7 wallet does that.

Mobile Soroban signing is a connected session, not a static QR. Freighter — which currently has the most complete Soroban support, including contract-invocation inspection and auth-entry signing — does mobile via WalletConnect v2, not via scanning a SEP-7 link. LOBSTR, Stellar's most widely used mobile wallet, only has partial Soroban parsing as of now, with full support still coming. WalletConnect is a paired, interactive session — the opposite of "show a QR and walk away."

So the contract-batch-via-static-QR-no-connect path is the infeasible combination. Everything else you described is fine.

What is feasible — and it's exactly v5

A SEP-7 pay (single recipient, address + amount + optional memo) is universally supported, needs no connect, and the donor's own wallet builds the whole transaction from those few params. That's precisely the v5 mechanism, and it's the only flow that gives you all of: QR-scan and copy-paste and no-connect and works-in-every-wallet. The backend detects it by watching the receiving account's payments (Horizon), same as v5.

The tradeoff is unavoidable and worth stating plainly in the proposal: on Stellar you can have batching, OR you can have the frictionless no-connect/universal/copy-paste property — not both. Batching needs a pre-built tx (contract or multi-op), which needs the donor's account up front, which means connect. Note also that a classic Stellar tx carries only one memo for the whole transaction, so you can't memo-route multiple shared-address recipients in a single classic tx anyway — another reason batching pushes you toward a contract, which pushes you toward connect.

Your web-to-web question, directly

Yes — for a single-recipient classic payment, the v5 copy-paste path works unchanged: show the destination address and the memo as two copyable strings, the donor pastes them into any web wallet's Send screen (Lobstr web, Freighter extension, etc.), sends XLM, and the new Stellar verifier matches it by address + amount + memo. No scan, no connect.

There is no clean "copy a string" equivalent for a contract invocation. Web wallets' Send screens do payments, not arbitrary contract calls. The only paste-able contract path is handing the donor a base64 XDR to import into Freighter or Stellar Lab — which isn't a consumer "copy a string," and still needs their source account baked in first.

The shape I'd recommend (and what the verifier looks like)

A hybrid keyed on cart size, all in the classic-payment lane to preserve the v5 properties:

• Single-project Stellar donation → SEP-7 pay + copy-paste. Covers scan and web-to-web, no connect, universal. This is your "simple way like v5."
• Multi-project Stellar cart → N separate classic payments, one PENDING donation row per project (the Stellar analogue of v6 EVM's "one createDonation per project"). Not atomic and N memos, but it keeps everything no-connect and universally compatible.
• Defer the Soroban batch contract to a later phase as the "connected wallet" path (WalletConnect, for wallets that support it), if true single-tx atomicity is later judged worth the connect requirement and narrower wallet support.

The new Stellar verifier then watches receiving accounts on Horizon for classic payments (proven in v5); only if/when you add the contract does it also need to read Soroban events off TransactionResultMeta via Stellar RPC getEvents — a different ingestion path. Your timebox / success / expiry / manual-reject / back-button states all map cleanly onto v6's PENDING → VERIFIED | FAILED | TIMEOUT. The one open piece is the push-to-frontend: v6 dropped v5's Redis-pub/sub + SSE fan-out, so you'll need to decide between re-introducing SSE for Stellar or leaning on the frontend timer-poll + manual-check fallbacks v5 also had.

https://claude.ai/project/019e8216-4729-73e8-939d-9b93890ccc42

[ae2079]

Agreed on the diagnosis — the no-connect / static-QR / Soroban-batch triple really doesn't hold, and the wallet re-simulation caveat I flagged earlier was the load-bearing assumption. SEP-7 pay + one payment per project (each with its own memo) is the right v5-parity path, and keeps the verifier simple — Horizon match by address + amount + memo, same as v5.

The Soroban contract and QR tool aren't wasted; they're the foundation for the connected-wallet path. Next from my side: test the contract via WalletConnect and via browser-extension wallets (Freighter, etc.) to lock down what the phase-2 connected flow actually looks like in practice.

On the auth side, separately: I dug into the SIWE Auth Microservice + giveth-v6-core for Stellar sign-in tied to the same user account. Good news — UserWallet in core already has chainType: STELLAR, so the path is to add a stellarAuthenticate endpoint to the microservice (parallel to the Solana one) that verifies an ed25519 signature and issues a JWT with the Stellar address; core then resolves it to the same userId via the existing findByWalletAddress lookup. No schema changes needed.