[El-Chapo-Npm]

Summary
This PR bundles three independent fixes — one documentation gap and two correctness bugs — that were blocking new adopters and causing silent failures in concurrent transaction tracking and account streaming.

Changes
docs: add minimal working examples to README
Problem: The README explained the project well but gave no copy-paste-ready code for the two most common tasks. New users had to dig through recipes or the full API reference just to send their first payment or call a contract.

Fix: Expanded ## Examples with a ### Minimal working examples subsection containing two complete, runnable snippets — a full payment flow (connect → build → sign → submit) and a Soroban contract invoke, both using the SorokitResult no-throw idiom throughout. A read-only soroban.read snippet is included as a third variant.

Closes #798

fix(transaction): correlate batch results by ID in TransactionQueue.startScheduling
Problem: startScheduling called submissionFn(batch) but never handled the resolved BatchSubmissionResult — only .catch() was wired up. On success, every transaction in the batch stayed stuck in "processing" indefinitely. Because correlation was positional (array index), any concurrent submission where results arrived out of order would misattribute success/failure to the wrong queued entry, corrupting final state.

Fix: Added a .then() handler that iterates batchResult.results — a Map<string, { success, hash?, error? }> — and calls markCompleted(tx.id, hash) or markFailed(tx.id, error) keyed by the transaction's stable id, not its array position. Transactions missing from the results map are failed so they can be retried. The .catch() handler now uses an instanceof Error guard for safe message extraction.

Closes #835

fix(account): stop streamAccount polling loop on account deletion
Problem: streamAccount runs a while (true) loop with only two exit conditions: an AbortSignal and an optional maxPolls cap. When an account was deleted, getAccount returned ACCOUNT_NOT_FOUND on every tick. The loop yielded the error (or silently swallowed it) and continued polling forever — consuming unbounded CPU and network resources with no way to stop short of the caller manually aborting.

Fix: Added an explicit early-return guard in the error branch:

ts

if (result.error.code === SorokitErrorCode.ACCOUNT_NOT_FOUND) {
yield result; // notify the consumer once
return; // terminate the generator
}
The consumer receives the error exactly once to react (e.g. tear down UI state), then the generator exits cleanly. A debug log entry with reason: "account_not_found" is emitted for observability.

Closes #830

[drips-wave]

@El-Chapo-Npm Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits