Every payment.
A clearer picture.

A settlement matches only when all identity dimensions agree: network passphrase, sender, recipient, asset type, asset code and issuer (case-sensitive for credit assets), and the time window. An operation_id disambiguates multiple payments inside a single transaction. A token contract address is never an issuer alias.

Values are exact stroop integers within the signed int64 range, including at the limit. Inputs with excess precision fail validation; amounts are never rounded and no monetary tolerance is applied.

A record supplies exactly one representation: a legacy timestamp or an explicit settlement_start/settlement_end interval. Intervals are closed and are not widened by time tolerance; they must fit the reconciliation window. A partially intersecting interval is reported, never silently filtered. business_reference is separate from reference_id, which means the transaction hash only — never a memo.

Coverage is provider evidence, not a cryptographic history proof. A complete scan means provider-declared retained history encloses the requested window, pages were traversed, and the retention boundary stayed stable. Incomplete coverage, ambiguous multiple candidates, competing claims, and malformed observations all remain UNKNOWN. Unknowns are reported separately and are not counted as financial discrepancies.

The legacy slice-only FetchOnChainPayments wrapper discards coverage and is unsuitable for definitive absence conclusions.

The ingestor traverses descending numeric paging tokens against the configured endpoint (no arbitrary redirects or next-links), verifies the network passphrase before and after the scan, enforces request/response size and retry bounds, stops on failure with no successful ingestion result, and never lets an error become an empty scan. Durable checkpoints and crash-restart resume are not implemented; scans restart intentionally.

A separate Node developer tool (tools/rpc-corpus) performs opt-in public-testnet reads only: getNetwork/getTransaction JSON-RPC and Horizon GET. It never signs, funds, or simulates. It captures ordinary-payment transactions and verifies that RPC results agree with Horizon operation semantics. Runtime ingestion in the Go modules remains Horizon-only.

Requirements

Go 1.22.2 or newer (a currently supported Go release is preferred). The RPC corpus uses Node 22+ with the pinned @stellar/stellar-sdk (npm ci).

Run the tests from any checkout

go test ./...
go vet ./...
go build ./...

Library flow (core)

h := ingest.NewHorizonIngestor("https://horizon-testnet.stellar.org")
h.Network = "Test SDF Network ; September 2015"   // exact passphrase

res, err := h.Fetch(ctx, accounts, start.Add(-tol), end.Add(tol))
// pass res.Coverage into ReconcileOptions; set Coverage.InternalComplete
// only if the export covers every relevant ordinary payment.

opts := engine.ReconcileOptions{TimeframeToleranceSec: tol, Coverage: res.Coverage}
report := engine.NewReconciler(opts).Reconcile(
    app, start, end, internalPayments, res.Payments)

Connectors (import exports)

ips, err := sdp.Parse(csvReader, network, "deployment-name", sdp.Scope{
    Release: sdp.Release, Sender: "GB…", Assertion: "…",
    SettlementStart: start, SettlementEnd: end,
})

• The reconciliation CLI never needs secret keys and never signs or submits transactions. The optional contract has separate signed testnet validation tooling.
• Treat exports and reports as sensitive — they contain account identifiers, amounts, and application references; keep them out of public commits. JSON files are created with private permissions where the OS supports it; Windows ACLs and pre-existing files need operator management.
• Horizon is a trusted data provider, not a locally verified ledger proof. Configure an endpoint you trust; do not expose the CLI as a service accepting arbitrary URLs or files.
• Exact account equality does not validate StrKey checksums; muxed identities are preserved with conservative base-account coverage limitations.
• For a sensitive bug, use each repository's GitHub Security → Report a vulnerability if available; otherwise open a minimal issue without disclosing secrets, customer data, or exploit details. Per-repository guidance is in each SECURITY.md.

LedgerParity is maintained as an honest, evidence-first preview. Decisions are recorded in each repository's DECISIONS.md; corrections are added rather than history being rewritten.

• Organization files — code of conduct, governance, license.
• Per-repository CONTRIBUTING.md, SECURITY.md, DECISIONS.md, and docs/backlog.md for contributor tasks.
• All repositories are MIT licensed; brand usage and honesty rules remain applicable regardless of license terms.
• The brand is original and deliberately distinct from the Stellar Development Foundation's brand; no affiliation is claimed.