Project#

Licensing#

Turnpike ships under Apache-2.0. Everything: the facilitator, the demo server, the conformance harness, the upto contract, the SDK, and these docs.

This is a requirement of the RFP, which asks for a permissively-licensed OSI-approved implementation, and it is also the only licence choice that makes sense for infrastructure intended to be run by other people.

Why not build on the existing facilitators#

Two facilitator implementations exist publicly and both are AGPL-licensed: the “Built on Stellar” facilitator, and the OpenZeppelin Relayer x402 facilitator plugin. The AGPL network clause makes them unusable under a permissive-licence requirement — a service operator running a modified AGPL facilitator must publish their modifications, which is precisely the obligation this RFP is written to avoid imposing on the ecosystem.

Turnpike therefore builds on the Apache-2.0 @x402/stellar package, as the RFP directs. I have read the AGPL projects’ public documentation to understand expected endpoint behaviour; no code has been taken from them.

Every dependency is licence-checked before it is added. A single copyleft dependency would compromise the deliverable.

Maintenance commitment#

Infrastructure that stops being maintained stops being infrastructure. The following is committed for 12 months following mainnet launch, published as policy in the repository rather than stated once in a proposal:

Dependency audits — monthly npm audit and, for the contract, cargo audit, with findings triaged and patched.

Protocol compatibility — Stellar protocol upgrade compatibility tested within one release of each testnet candidate, so an upgrade does not silently break settlement.

Specification tracking — the x402 specification is under active development. Changes to the facilitator surface, the Bazaar extension, or scheme definitions are tracked and implemented.

Continuous conformance — the CI conformance harness continues to run against pinned and latest stock clients. A protocol change that breaks me produces a red build, not a silent regression.

Community updates — monthly devlogs to the Stellar Developer Discord and GitHub Discussions covering progress, decisions, blockers, and open questions. Beginning at Tranche #0 confirmation, not at launch.

Issue response — public issue tracker, with security reports handled privately per SECURITY.md: acknowledgement within 3 working days, assessment within 10, critical and high findings fixed or mitigated within 30 days of assessment.

Team#

Turnpike is built by one person.

Jagadeesh B — Founder and sole developer GitHub · LinkedIn

Prior x402 work#

ProcuraAI — built for the SKALE Agentic Commerce x402 Hackathon. An agent-commerce system in which an AI agent discovers tools, enforces a budget, authorises a payment, verifies the condition the payment was contingent on, and settles it with an auditable on-chain record.

The pieces, so the claim can be checked rather than taken:

Why this is the relevant experience. It is prior hands-on x402 work covering both halves of the problem Turnpike addresses: payment authorization and settlement, and the discovery of paid capabilities an agent has not been told about. Those are the facilitator and the Bazaar, in that order. The difference is the chain and the scale — ProcuraAI is EVM and hackathon-scale, Turnpike is Stellar and built to be run by other people — but the protocol, the 402 exchange, and the agent-side reasoning about whether to pay are the same material.

Stellar Soroban contracts and backends#

Rust contract work on Soroban, with the services around it. This is the experience the upto deliverable requires: upto needs a Soroban contract, and a contract is a different discipline from a service.

Maintainership scale#

The three frontends alongside the contracts and backends above, each run as an open contributor programme:

Across all nine repositories: 3,585 pull requests reviewed and merged from 905 distinct contributors. 905 is de-duplicated; the per-repository columns sum to 1,574 because contributors work across several projects. Counted from the GitHub API on 14 August 2026 and reproducible from it.

These are maintainership and delivery figures — pull requests reviewed and merged — not users, downloads, or adoption. The relevance to this RFP is direct: reviewing several thousand changes written by other people, holding a quality bar across many hands, and keeping a build green while it moves is the same work as maintaining infrastructure that other teams depend on. Throughout, CI gating, accessibility auditing, and end-to-end test coverage were maintained.

Cross-ecosystem breadth#

Supporting context rather than argument: HiveMind (Solana), StableLink (Etherlink), and Shadow-Settle (iExec confidential computing).

Active contributor to Stellar ecosystem projects through OnlyDust, Drips, and GrantFox.

Principal engineer and sole developer on Turnpike, available full-time for the duration of the engagement.

What I have already contributed#

Relevant to this RFP and independent of it:

• A conformant x402 facilitator for Stellar, published and running, with settled payments verified in CI on infrastructure I do not control.
• A conformance harness that validates against an unmodified stock client on every push — a pattern any x402 implementation could adopt.
• Identification, reproduction, and measurement of an interop defect between the public Soroban testnet RPC pool and @x402/stellar, reproduced on neutral CI infrastructure and reported upstream with a proposed protocol-level fix.

The last item is the one I would point to first. Finding a defect in the interaction between a package and the network it targets, measuring it, and proposing a specification change to eliminate the failure class is the kind of work this RFP exists to fund.

Contributing#

Issues and pull requests are welcome.

The conformance harness is the contract. A change that breaks conformance against the stock client is a bug regardless of what else it improves. CI runs the harness on every push, spending real testnet XLM, so a regression is caught before review rather than after deployment.

Every rejection path needs a specific reason. A pull request that introduces a rejection returning null, an empty string, or a generic message will fail the test suite.

No AGPL dependencies. Licence-check anything you add.

Reproducibility is a feature. If a change makes the demo harder to run from a clean clone, it needs a good reason.

Links#