Roadmap and tranches#

Total requested: $120,000 worth of XLM, over approximately four months, delivered in three milestones ending with mainnet launch.

Per SCF Build Award structure, the award is paid in four tranches: 10% on approval (not itemised below), then 20%, 30%, and 40% against the three milestones. The deliverable budgets below therefore sum to $108,000 — the 90% attached to milestones.

Security audits are provided through the SDF Audit Bank at Tranche 3 and are excluded from this budget, as required. Engineering time to remediate audit findings is included. No marketing or promotional spend appears anywhere, as required.

Schedule assumption, stated explicitly. Dates below assume an award decision around 1 October 2026. The plan is sixteen weeks in total, split six / five / five. That matches the SCF Build guidance of roughly four months and the shape used by comparable RFP-track awards at this budget. The final tranche gets five weeks rather than four because it contains a security audit turnaround that is not under my control; compressing it would mean either rushing remediation or missing the date, and neither is worth the week.

Tranche #1 — Production hardening and discovery foundations (MVP)#

Total: $24,000 · Target completion: 15 November 2026
Six weeks from award.

Removes the two known limitations in the existing implementation, achieves full canonical conformance, and lays the catalog foundation with its integrity model in place from the start rather than retrofitted.

1. Concurrent settlement via channel account pool — $7,500#

Replace single-signer settlement with a leased pool of channel accounts, removing the per-account sequence-number bottleneck that currently serialises payments. Leases are held for the duration of a settlement and returned on confirmation.

Completion: a published load test in CI showing 20 concurrent settlements all reaching a ledger with zero lost transactions, reproducible from a committed script.

2. Ledger-skew resilience and full e2e conformance — $6,500#

Complete the mitigation for the upstream RPC ledger-skew defect I identified and reported, and run the canonical x402 Foundation e2e suite — not only my own harness — against Turnpike on testnet.

Completion: e2e suite green in CI on stellar:testnet, run linked publicly; a published probe dataset of at least 500 payments across varied RPC conditions including at least one recorded skew event where the retry succeeded, with the observed failure rate reported.

3. Bazaar catalog model, ingestion, and listing integrity — $10,000#

Catalog schema and the asynchronous cataloging worker that records resources off the settlement hot path. Listing ownership binds to the settled payTo address, first-writer-wins on (url, payTo), conflicts quarantined; routeTemplate percent-decoded before traversal checks; invalid fields soft-dropped and reported via the extension-responses header.

Completion: resources auto-catalogued after settlement on testnet; a published adversarial test suite in CI demonstrating that a hostile client cannot claim, overwrite, traverse, or poison a listing it did not settle to.

Tranche #2 — Discovery and the upto scheme (Testnet)#

Total: $36,000 · Target completion: 20 December 2026
Five weeks from Tranche #1.

The RFP’s highest-value deliverable, plus the scheme that requires authoring a specification that does not yet exist.

1. Discovery API — $8,500#

/resources and /search implemented per the x402 Bazaar extension specification, with the discovery extension advertised in 402 responses.

Completion: an unmodified, stock Bazaar-aware x402 client discovers a resource and completes payment for it end to end on testnet; settled hash published.

2. Hybrid search ranking and evaluation — $10,000#

BM25 over synthesised per-resource documents fused with dense vector retrieval via reciprocal rank fusion, plus a re-rank stage incorporating price, recency, and observed reliability.

Completion: a committed golden query set with published NDCG@10 scores, reproducible via a single evaluation script in CI.

3. Stellar upto scheme specification, authored upstream — $5,500#

No Stellar upto specification exists. Author it and submit upstream, covering the authorization-entry shape, settlement semantics, cap enforcement, error semantics, and the reference contract interface.

Completion: PR opened against x402-foundation/x402 adding specs/schemes/upto/scheme_upto_stellar.md, with the public discussion link published in my repository.

4. upto Soroban contract and integration — $12,000#

SEP-41 approve/transfer_from cannot bind the recipient or guarantee single settlement, so upto requires a minimal contract: the authorization entry authorises settle_upto(payer, payee, asset, cap, nonce), enforcing nonce-once semantics and actual ≤ cap. Apache-2.0, deployed to testnet.

Completion: contract deployed on testnet; a stock client completes an upto payment where the amount charged is strictly less than the authorised cap; a replayed nonce is rejected on-chain; both settled hashes published.

Tranche #3 — Mainnet launch#

Total: $48,000 · Target completion: 24 January 2027
Five weeks from Tranche #2, sized for the audit turnaround.

1. Mainnet deployment of facilitator, upto, and discovery — $15,000#

Deploy on stellar:pubnet: exact and upto schemes, fee sponsorship, channel pool, and the discovery layer serving live mainnet resources.

Completion: an unmodified stock x402 client completes both an exact and an upto payment on pubnet, and discovers-then-pays a mainnet resource; three settled mainnet hashes published on Stellar Expert.

2. Security audit remediation — $8,000#

Engineering time to remediate findings against the upto contract and the settlement paths, gated as a release blocker. The audit itself is provided through the SDF Audit Bank and is not part of this budget.

Completion: all critical and high findings resolved or formally accepted, re-verified in the codebase, remediation summary published.

3. Production operations — $9,000#

Monitoring and alerting, per-payer rate limiting, key management and rotation for sponsor and channel accounts, and a documented incident runbook.

Completion: public status and metrics endpoint live; runbook published; 14 days of stable mainnet operation evidenced by the metrics endpoint.

4. Adversarial and property-based test suite — $8,000#

Unit coverage of error mapping and payload construction; integration tests against live networks; an adversarial corpus covering forged listings, replayed payloads, malformed authorization entries, cap violations, and RPC degradation; property-based fuzzing over payment-payload shapes.

Completion: full suite green in CI including fuzzing and adversarial runs; every rejection path asserted to return a non-null, specific reason.

5. Documentation, maintenance, and community commitment — $8,000#

Integration guides for sellers and for agent developers, an architecture reference, and a published 12-month maintenance policy covering dependency audits and Stellar protocol upgrade compatibility. Monthly devlogs to the Stellar Developer Discord and GitHub Discussions throughout the grant period.

Completion: docs site live; maintenance policy published in-repo; devlogs posted monthly from Tranche #0 onward.

Budget summary#

Sequencing rationale#

Why hardening comes first. Two known limitations — single in-flight settlement, and an unvalidated skew mitigation — sit in code that already exists. Building discovery on top of an unhardened payment plane would mean debugging two layers at once. It also front-loads the deliverables that are cheapest to verify.

Why catalog integrity is in Tranche 1, not with the rest of discovery. The integrity model is not a hardening pass; it determines the catalog’s data model. Retrofitting ownership binding onto an existing catalogue means a migration and a window during which the index cannot be trusted.

Why upto sits before mainnet rather than after. The contract needs to exist, be deployed, and be exercised on testnet well before it enters an audit. Putting it in the mainnet tranche would compress specification, implementation, audit, and remediation into one milestone.

Why the specification is a separate deliverable. It has the longest reach beyond Turnpike. A facilitator serves its own users; a specification is used by implementations that have nothing to do with Turnpike. Separating it means it is completed and submitted upstream rather than absorbed into implementation work.

Beyond the grant#

Maintenance is a commitment, not an intention: 12 months of dependency audits, Stellar protocol upgrade compatibility testing within one release of each testnet candidate, and monthly community updates. Published as policy in the repository.

An on-chain resource registry is the natural next proposal, if the discovery layer proves out and demand for censorship-resistant listings materialises — with the delivery record of this grant behind it.