Testnet evidence
Replaying a shrunk failing sequence on Testnet is part of the demo (scripts/replay-testnet.sh, see docs/DEVELOPMENT.md). Local fuzzing stays local; only the exported reproduction goes on-chain. Deployed and replayed on Testnet on 25 October 2026:
| Item | Value |
|---|---|
| Demo smart-account contract (policy-bypass) | CBKDNENFLCLUE3U4NH55T5N5JIX6S6WS2FFDXCPWMXJM7ZQGPXVH3HJI |
| Spending-limit policies (50 USDC per ledger, 100 USDC per 1 728 ledgers) | CCIEVOGO…CS247, CC6Z5UZY…RRD7 |
| Ed25519 verifier, owner key account | CA7UFPQ3…5OJN, CC2N5OKR…PSCB |
Test asset USDC (Stellar Asset Contract) | CDDSS44L…PDMM |
| Replayed bypass: payment 1 (49 USDC, ledger 5383703) | b5ea4498…6772 |
| Replayed bypass: payment 2 (49 USDC, ledger 5383715) | 82be1eb8…5608 |
| Replayed bypass: payment 3 (49 USDC, ledger 5387240) | 3f30f306…aa8e |
| Demo payment-stream contract (ttl-archival) | CBS6AO2L5RKKLHIC2FJOH66UIL2OHCPSSO6GAUCYNXMMI3RRQLG3D5KP |
create_stream (1 000 USDC over 365 days, ledger 5383730) | aa8cb83f…5f99 |
withdraw by the recipient six ledgers later (ledger 5383736) | 43ce190b…14d2 |
Each payment above went through the smart account’s real __check_auth: the agent’s Ed25519 key signed the OpenZeppelin AuthPayload, and the two SpendingLimit policies ran on-chain and let all three through: 147 USDC reached the merchant within 3 537 ledgers (about 4.9 hours, well inside one day of 17 280 ledgers), against a cap the operator meant as 100 USDC per day. The third payment was sent later than the earliest ledger it could have used (5385431, one 1 728-ledger window after the first); any ledger past that window and inside the day shows the same bypass.
The stream’s expiry itself cannot be waited for within the hackathon: Testnet’s minimum persistent TTL is currently 120 960 ledgers, about seven days (stellar network settings --network testnet, state_archival.min_persistent_ttl), and the stream entry, created at ledger 5383730 and never extended, is live until ledger 5504689 (stellar ledger entry fetch contract-data), roughly 1 November 2026. What the on-chain evidence shows is the stream being created and used; what the local suite shows is the entry being archived with most of the stream still to run. On a real network the consequence is not a failing call but a cost: the next transaction that touches an archived entry must restore it and pay for the restoration, a transaction built without the restore fails, and because the contract never extends TTL the entry is archived again after every quiet period of at least the minimum TTL.