Consolidate the event layer, single-source the network config, and validate build args (#108, #109, #111, #112)

[mhikel66]

Four SDK issues — two type-check bugs in the event layer, a network-config duplication, and missing input validation.

#108 — two conflicting TrustFlowEventType systems

src/events.ts (the real XDR parser) used escrow_created + ParsedEvent; src/types/events.ts + EscrowMonitor independently used escrow.created + a different TrustFlowEvent shape. The names collided when both were imported, and parseEvent's output could not be fed into a monitor handler.

• src/events.ts is the single source — underscore vocabulary (matching the emitted Soroban Symbol topic), one ParsedEvent / ParsedEventBase shape, one set of payload types.
• src/types/events.ts re-exports those; TrustFlowEvent is now an alias of the parser's discriminated union and EventHandler takes it. The dot-notation type and { escrowId, payload, blockNumber, txHash } shape are gone.
• EscrowMonitor handlers receive ParsedTrustFlowEvent directly. New deliver(events) dispatches a pre-parsed batch (used by startPolling, callable on its own).
• End-to-end test: parseEvents([raw], contractId) → monitor.deliver(...) → handler receives a narrowed escrow_created event, no adapter.

#112 — ParsedEvent<T> generic errors in src/events.ts

parseEvent's three typed branches (escrow_created, escrow_released, dispute_raised) failed tsc with TS2322 — EscrowCreatedData etc. have no index signature, so they don't structurally match the Record<string, unknown> default T.

Fixed via the better option from the issue: parseEvent now returns ParsedTrustFlowEvent, a discriminated union keyed on type. Each branch is correctly typed with no as cast, and callers get .data narrowing from a switch/if on .type. The parser functions are exported from the package root.

#109 — three copies of the Stellar network config

src/constants.ts (HORIZON_URLS, SOROBAN_RPC_URLS), src/stellar/network.ts (NETWORK_CONFIGS, which also has the passphrase), and TrustFlowClient.getNetworkPassphrase() (inline strings) all encoded the same TESTNET/MAINNET values.

• NETWORK_CONFIGS is canonical. HORIZON_URLS / SOROBAN_RPC_URLS and a new NETWORK_PASSPHRASES in constants.ts are a view of it (NETWORK_CONFIGS.TESTNET.horizonUrl, …), not a copy.
• getNetworkPassphrase() returns NETWORK_PASSPHRASES[this.network].
• Test asserts constants, TrustFlowClient, and NETWORK_CONFIGS resolve identically for both networks — by construction, not coincidence.

constants.ts → stellar/network.ts is a one-way import (network.ts imports nothing), so no cycle.

#111 — no address validation before ScVal construction

buildCreateEscrowArgs, buildReleaseArgs, buildDisputeArgs fed caller strings straight into new Address(...).toScVal(). A malformed address surfaced as a raw @stellar/stellar-sdk error, not a TrustFlowError.

All three now call assertStellarAddress(...) / an isValidEscrowId guard up front and throw TrustFlowError.validation(...) — consistent with escrow/create.ts / escrow/client.ts. Tests cover invalid sender / recipient / caller / escrowId for each.

---

Not built or run in this environment (per your instruction). All src changes are typed for tsc --noEmit; tests/monitor.test.ts is updated for the new event shape. No version bump.

Closes #108, closes #109, closes #111, closes #112

[drips-wave]

@mhikel66 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