Problem
destinations.json explicitly states its addresses are synthetic and not real/funded — meaning they likely don't exist as funded accounts on Stellar testnet at all. That's fine for the JSON-level ground truth, but it creates ambiguity for the transactions/ XDRs: an unsigned transaction built with a synthetic, unfunded source account is still structurally decodable (which is all the decode step needs), but it's worth explicitly settling and documenting whether this repo ever intends its fixtures to be resolvable against live testnet state (e.g. for a future integration test that submits to testnet) or whether "synthetic and offline-only, forever" is a permanent design constraint.
Requirements
- Decide (document the decision, e.g. as a follow-up to the static-stub-scores ADR) whether fixtures are permanently synthetic/offline-only or whether a future subset should be real, funded testnet accounts kept alive via a periodic friendbot top-up.
- If synthetic-only is confirmed as permanent: add a one-time CI check (or a clearly-labelled manual script, not a blocking CI gate) that queries Horizon's testnet API for each address and asserts none of them resolve to a funded account — regression-testing the "these are definitely not real accounts" guarantee itself, since a coincidental real-world collision, however unlikely, would be worth knowing about.
- If a live subset is instead desired: scope that as a separate, larger follow-up issue rather than folding it into this one.
Acceptance Criteria
- A documented decision exists.
- If synthetic-only is chosen: the collision-check script exists and passes for all current addresses.
Part of the Gryd-lock organization. This repo supplies the labelled testnet fixtures and stub scores consumed by grydlock-oracle-adapter's StubOracle and evaluated end-to-end by grydlock-research.
Problem
destinations.jsonexplicitly states its addresses are synthetic and not real/funded — meaning they likely don't exist as funded accounts on Stellar testnet at all. That's fine for the JSON-level ground truth, but it creates ambiguity for thetransactions/XDRs: an unsigned transaction built with a synthetic, unfunded source account is still structurally decodable (which is all the decode step needs), but it's worth explicitly settling and documenting whether this repo ever intends its fixtures to be resolvable against live testnet state (e.g. for a future integration test that submits to testnet) or whether "synthetic and offline-only, forever" is a permanent design constraint.Requirements
Acceptance Criteria
Part of the Gryd-lock organization. This repo supplies the labelled testnet fixtures and stub scores consumed by
grydlock-oracle-adapter'sStubOracleand evaluated end-to-end bygrydlock-research.