Loading...
Supporting developers, startups, and full-fledged companies building on Stellar and Soroban
© 2026 Stellar Development Foundation
Subscribe to the Newsletter
By Rail402: x402 Facilitator + Bazaar for Stellar
Rail402 is an Apache-2.0 suite for discovering, purchasing, settling, and inspecting x402 services on Stellar. It is built on the canonical @x402/stellar payment flow and can be used as a hosted service, self-hosted deployment, or in-process library.
Facilitator and settlement schemes
Provides standard /supported, /verify, and /settle endpoints compatible with stock x402 clients. It supports fixed-price exact payments and metered upto payments.
Stellar use: Buyers sign Soroban authorization entries for SEP-41 asset transfers, while Rail402 sponsors the XLM network fee. The upto contract enforces the recipient, spending cap, expiration, and single-use nonce.
Project impact: Enables non-custodial fixed and usage-based payments without requiring buyers to hold XLM. The hosted service currently operates on testnet; its mainnet settlement path was validated through a completed limited beta using real USDC.
Bazaar discovery and search
Automatically catalogs successfully paid HTTP endpoints and MCP tools. /discovery/resources provides structured filtering and pagination, while /discovery/search supports natural-language discovery.
Stellar use: Every confirmed listing is linked to a successful Stellar settlement and its network, payTo address, asset, and payment scheme.
Project impact: Allows agents to find payable Stellar services without knowing their endpoints in advance and gives sellers a discovery path without separate registration.
MCP discovery server
Provides search_stellar_resources for discovery and pay_and_call for completing a payment and invoking the selected service. Calls require an explicit spending cap and return structured results.
Stellar use: Agents create and settle Stellar payment authorizations directly from an MCP-compatible runtime.
Project impact: Lets agents discover, pay for, and call Stellar services without a custom x402 integration.
SDK and CLI
@rail402.dev/sdk supports buyer and seller integrations. The rail402 CLI provides search, purchase, payment, and transaction-inspection commands with machine-readable JSON output.
Stellar use: Both tools create Stellar payment authorizations, enforce payment limits, and return verifiable on-chain transaction hashes.
Project impact: Shortens the path from installation to a completed and independently verifiable x402 payment.
Explorer and Ecosystem Report
Indexes x402 activity across Stellar facilitators and reports payments, buyers, sellers, schemes, assets, and facilitator attribution at both transaction and ecosystem levels.
Stellar use: The Explorer reads Soroban transaction metadata and Stellar Asset Contract events to identify exact and upto settlements.
Project impact: Provides transaction-level debugging, public adoption metrics, and a dedicated view of the wider Stellar x402 ecosystem.
Playground
Provides a browser-based environment for creating, completing, and inspecting an x402 payment before integrating the SDK or CLI.
Stellar use: Playground requests create real testnet authorizations and settlements that can be verified through the Rail402 Explorer.
Project impact: Gives developers and reviewers a direct way to validate the complete payment flow, reducing onboarding and integration time.
$125.0K
Rail402 has completed 110 x402 payments on Stellar, covering both exact and upto payment schemes:
Testnet: 103 payments — 74 exact, 29 upto, 41 buyers, and 24 sellers.
Mainnet beta: 7 real USDC settlements — 3 exact and 4 upto.
The limited mainnet beta has concluded. Rail402 currently operates on testnet and is not currently offering active mainnet support. The completed mainnet settlements remain publicly accessible as proof of successful settlement with real USDC.
Representative on-chain transactions
Mainnet exact — 0.01 USDC with a Rail402-sponsored network fee.
Mainnet upto — 0.02 USDC settled from a 0.05 USDC authorization.
Testnet exact — 0.05 USDC paid to a protected API.
Testnet upto — smart-contract payer; 0.05 USDC settled from a 0.25 USDC authorization.
Rail402 Explorer and Ecosystem Report
Because conventional Stellar explorers do not label x402 buyers, sellers, schemes, or facilitators, we built the Rail402 Explorer and published the first and only report, you can read the below link.
State of x402 on Stellar Ecosystem Report: https://rail402.dev/ecosystem
At the time of this application, the explorer has indexed 57,054 ecosystem payments on the Stellar ecosystem (not just us):
Mainnet: 2,620 payments, 44 buyers, 28 sellers, 2,616 exact, and 4 upto.
Testnet: 54,434 payments, 2,058 buyers, 4,275 sellers, 54,391 exact, and 43 upto.
See all testnet transactions: https://explorer.rail402.dev/testnet/ecosystem
Rail402 settled 29 of the 43 indexed testnet upto payments and all 4 indexed mainnet upto payments. The explorer provides transaction-level evidence and filtering by network, facilitator, scheme, asset, buyer, and seller.
A critical bug fixed on official x402 repository
x402 Protocol (x402-foundation/x402) — PR #3018, submitted: The current Stellar x402 client cannot complete payments from C... smart-contract accounts because it drops the custom authorizeEntry callback required by Soroban __check_auth. We fixed this backed by 159 passing tests and a successful e2e tests on x402’s repo.
Open-source contributions on official Stellar repositories
Stellar Docs (stellar/stellar-docs) — PR #2718, merged: Fixed outdated links, package references, and protocol headers in the official Stellar x402 quickstart. This gives developers accurate setup instructions.
x402 for Stellar (stellar/x402-stellar) — Issue #71: Provided a practical implementation answer for supporting upto payments on Stellar.
x402 for Stellar (stellar/x402-stellar) — Issue #72: Opened a design discussion explaining how exact and upto payments should work with Stellar authorization and settlement.
Conformance and Maintenance
Rail402 already tracks the upstream x402 specifications on which it depends. A public specification-tracking workflow runs weekly and on demand, comparing nine pinned specification files and two version-tracked paths with their current upstream revisions.
When drift is detected, the workflow updates one public issue with the upstream changes, affected Rail402 modules, and test results, then creates a draft branch with updated pins. For breaking changes, Claude Code is configured to prepare the required code and tests and open a draft pull request for human review; it never merges automatically. Issue #1 demonstrates this process on real upstream changes.
YK Labs commits to maintaining the delivered Rail402 scope for 12 months after mainnet launch. This includes reviewing detected specification changes, updating pinned versions and conformance tests, publishing compatibility fixes for supported x402 v2 behavior, maintaining documentation, and recording cases where an upstream change requires no Rail402 modification.
Measured Search Quality:
Rail402’s shipped hybrid ranker was evaluated on 500 real captured listings and 202 queries using blind-graded relevance judgments. It achieved 0.775 MRR, 0.711 nDCG@10, 0.852 Recall@20, and 0.688 Precision@1. A separate held-out evaluation covering 20 real listings and 20 queries achieved 0.950 MRR, 0.953 nDCG@10, 1.000 Recall@20, and 0.900 Precision@1. All results come from the ranker currently used by Rail402. The methodology, dataset provenance, judgments, and limitations are available in the search-quality report.
Evaluation methodology and results: https://docs.rail402.dev/architecture/evaluation
1. Public testnet facilitator
Brief description: Build and publish an Apache-2.0 testnet facilitator on @x402/stellar, with hosted, Docker self-hosted, and in-process options. Support the standard /supported, /verify, and /settle endpoints.
How to measure completion:
A public Apache-2.0 repository, tagged release, container image, and clean-install instructions are published.
A free testnet facilitator operates without an API key.
/supported returns the correct CAIP-2 network, schemes, and extra.areFeesSponsored: true.
An unmodified canonical x402 client completes an exact payment, with the command, versions, commit, and transaction hash published.
Automated tests cover G... and C... accounts, SEP-41 amounts, missing trustlines, insufficient balances, expiration, tampering, and replay.
Balance and event assertions confirm that the payer is debited, the declared recipient is credited, and Rail402 never holds or supplies the payment funds.
Every rejected verification or settlement returns a stable machine-readable code and non-empty reason.
Budget: $5,000
2. Bazaar catalog and integrity controls
Brief description: Build an off-chain Stellar Bazaar that automatically catalogs HTTP endpoints and MCP tools from successful payment payloads, without requiring separate seller registration or another on-chain transaction.
How to measure completion:
GET /discovery/resources supports type, payTo, network, extensions, limit, and offset with stable pagination.
Discovery metadata is validated against its supplied schema before cataloging.
HTTP resources and MCP tools are cataloged automatically after successful settlement.
MCP tools are identified by resource.url and input.toolName.
Listings are bound to the payTo address proven by settlement. Conflicting sellers cannot create or modify another seller’s listing.
Duplicate settlements do not create duplicate listings, and updates retain a public version history.
Invalid metadata is soft-dropped without failing an otherwise valid payment.
routeTemplate values are percent-decoded before traversal validation.
EXTENSION-RESPONSES returns the cataloging result and a non-empty reason for rejection.
Budget: $12,000
3. Natural-language search and evaluation
Brief description: Build GET /discovery/search using structured filters, BM25, local embeddings, and Reciprocal Rank Fusion. Publish a reproducible evaluation for the same ranker served by Rail402.
How to measure completion:
Search supports natural-language queries, structured filters, cursor pagination, and partialResults.
A public evaluation package contains all publicly retrievable Stellar x402 listings plus clearly labeled sample listings covering additional service types and edge cases, for a total evaluation corpus of 500 listings and 202 queries.
From a fresh repository clone, reviewers can run one documented command to reproduce the published search results.
The report compares BM25 and hybrid retrieval using MRR, nDCG@10, Recall@20, Precision@1, and latency.
Network, asset, scheme, recipient, and price constraints are tested separately and produce zero filter violations.
The hybrid search system must match or outperform the fixed BM25-only benchmark on nDCG@10 and Recall@20.
CI rejects releases where nDCG@10 or Recall@20 falls by more than 0.02 from the tagged baseline.
Budget: $8,000
Tranche #1 Total: $25,000
1. Stellar upto specification and contract
Brief description: Define and implement the Stellar upto scheme on testnet. Publish scheme_upto_stellar.md, a reproducible Soroban settlement contract, and the required client, server, and facilitator integrations.
How to measure completion:
A public upstream pull request contains the specification, implementation, test vectors, and integration instructions.
All CI checks for the upstream pull request pass, and every maintainer request for a code or specification change is resolved by a linked commit or written technical response.
The contract is deployed on testnet with its contract ID, source revision, build instructions, and reproducible WASM hash published.
The authorization binds the payer, recipient, token, spending cap, expiration, nonce, and settlement operation.
Published transaction hashes demonstrate zero, partial, and maximum settlement using both G... and C... payers.
Tests reject changes to the recipient, asset, cap, expiration, nonce, actual amount, or authorization tree.
Submitting the same authorization more than once, including concurrently, results in no more than one on-chain transfer.
A smart-account test proves that payments exceeding either the x402 cap or the account’s independent spending limit fail.
Contract instance and WASM TTL monitoring and restoration procedures are documented and tested.
Budget: $12,500
2. MCP, SDK, CLI, Playground, and examples
Brief description: Build the testnet interfaces used by agents, buyers, sellers, and operators. Provide MCP discovery and payment tools, SDK helpers, CLI commands, and a browser-based Playground.
How to measure completion:
The MCP server provides search_stellar_resources and pay_and_call with structured inputs and outputs.
MCP, SDK, CLI, and Playground payment flows require and enforce a spending cap immediately before signing.
Payments are rejected if the network, asset, recipient, or amount is not permitted, or if the payment would exceed the per-call or total session spending cap.
Agent-selected URLs are protected by SSRF checks, DNS-to-connection IP validation, redirect controls, and request-size limits.
Automated scanning confirms that signing secrets and authorization material do not appear in schemas, logs, traces, or errors.
Seller helpers generate valid discovery metadata for HTTP endpoints and MCP tools.
Buyer helpers support paying a specified resource or searching the Bazaar and paying a selected result.
Installable packages are published under the @rail402.dev namespace.
One paid HTTP API and one MCP tool are cataloged, discovered, paid, and called on testnet. Their transaction hashes open in the Explorer.
Budget: $10,000
3. Testnet conformance, security, and operations
Brief description: Complete the testnet acceptance suite and validate settlement, discovery, MCP, Stellar-specific behavior, concurrency, monitoring, and failure recovery.
How to measure completion:
A public report covers an unmodified canonical client, payload: { transaction }, /supported, areFeesSponsored, exact, upto, discovery, and MCP.
Applicable upstream x402 end-to-end tests pass against the deployed testnet service.
The authorization expiration ledger is calculated from maxTimeoutSeconds, with tests confirming acceptance before expiration and rejection after expiration.
USDC and a second SEP-41 asset with different decimal behavior complete both exact and upto payments.
A channel-account pool is implemented. Three batches of at least 20 concurrent settlements complete without double settlement or sequence-number collision.
Repeated settlement requests return one settlement and the same terminal result.
A fault test interrupts processing after submission; recovery finds the original transaction without submitting a replacement.
Every facilitator, Bazaar, search, and MCP rejection returns a stable machine-readable code and non-empty reason.
/health and /metrics expose settlement results, sponsor balances, channel utilization, sequence conflicts, RPC failures, contract TTL, catalog outcomes, indexing failures, and search latency.
A public threat model and operational test report cover replay, front-running, fee sponsorship, catalog poisoning, SSRF, smart accounts, MCP paid calls, and the upto contract.
Budget: $15,000
Tranche #2 Total: $37,500
1. Mainnet facilitator and upto deployment
Brief description: Deploy the facilitator on stellar:pubnet while continuing testnet support. Provide exact, upto, sponsored fees, USDC by default, configurable SEP-41 assets, and support for classic and custom accounts.
How to measure completion:
Public /supported responses advertise the correct networks, schemes, and areFeesSponsored: true.
An unmodified canonical x402 client completes payments on testnet and pubnet.
Published transaction hashes cover exact and upto on both networks.
The mainnet upto contract ID, WASM hash, source revision, build instructions, and deployment record are published.
Hosted, Docker, and in-process releases support configurable authentication, rate limits, sponsor limits, accepted assets, and service fees.
Startup fails when required credentials, contract addresses, asset configuration, or fee ceilings are missing.
The facilitator remains non-custodial and has no required dependency on Rail402’s hosted service.
The upstream upto contribution has passing CI and a public review history. Every maintainer request for a code or specification change is resolved by a linked commit or written technical response. Final merge remains under upstream maintainer control.
Budget: $17,500
2. Production Bazaar and search
Brief description: Deploy the Bazaar catalog and search services for testnet and pubnet, keeping discovery off-chain and avoiding an additional cataloging transaction.
How to measure completion:
/discovery/resources and /discovery/search serve both networks and pass filter, pagination, cursor, and partialResults tests.
Successful testnet and pubnet payments automatically catalog HTTP endpoints and MCP tools.
Production tests cover ownership, schema validation, duplicates, forged pricing, unsafe URLs, SSRF, and encoded traversal.
Published interoperability fixtures demonstrate that canonical Bazaar records are ingested and returned without changing their payment, resource, extension, filter, or MCP semantics.
The production ranker reproduces the tagged search evaluation within its declared regression limits.
A public load-test package provides the script, dataset hash, concurrency level, service configuration, cache state, raw results, and cached and uncached p50, p95, and p99 latency.
Budget: $15,000
3. Production MCP, Explorer, and Ecosystem Report
Brief description: Deploy the MCP service and transaction-indexing tools for testnet and pubnet. Provide transaction-level payment evidence and network-wide x402 activity reporting.
How to measure completion:
MCP discovery and paid-call flows operate on both networks with spending caps and structured error responses.
Explorer pages show the network, scheme, asset, buyer, seller, facilitator, amount, fee sponsorship, and settlement hash.
CLI and Playground payments return hashes that open directly in the Explorer.
Testnet and mainnet Ecosystem Reports clearly distinguish network-wide x402 activity from Rail402-settled payments.
Explorer and report data can be rebuilt using documented source transactions and indexing rules.
Budget: $7,500
4. Security validation and production operations
Brief description: Publish final security evidence and verify the monitoring, recovery, and operational procedures required for production.
How to measure completion:
A public security report identifies the tested source revision, threat model, tests, findings, and implemented corrections.
Every Critical or High finding is resolved before release. Any unresolved lower-severity finding documents why it is accepted and what measures reduce its risk.
A public status page records at least 99% availability over seven consecutive days.
Recovery exercises cover signer rotation, RPC failure, sequence conflicts, expired authorizations, channel-pool exhaustion, sponsor depletion, and degraded indexing.
The operational runbook identifies alert owners, escalation paths, rollback steps, backup restoration, and recovery procedures.
Budget: $7,500
5. Documentation, integrations, and developer testing
Brief description: Publish role-based documentation, complete the required integrations, and implement corrections identified through documented developer usability testing.
How to measure completion:
Public documentation provides separate seller, buyer/agent, and facilitator-operator paths.
Every path includes a working testnet example and explains network selection, assets, trustlines, authorization, and fee sponsorship.
A clean-environment test demonstrates that a developer can publish a paid, discoverable testnet endpoint using only the published documentation.
A developer-guide pull request is opened against Stellar Developer Docs.
At least two complete examples are publicly runnable: a discoverable paid HTTP API and an MCP agent that discovers and pays without a preconfigured service endpoint.
SDK and CLI documentation covers explicit stellar:testnet and stellar:pubnet selection.
Developer-testing findings, implemented corrections, and verification results are published in a change log.
Budget: $7,500
6. Conformance and specification-maintenance tooling
Brief description: Publish automated tooling that detects upstream x402 specification changes, records affected Rail402 components, and verifies wire-level conformance.
How to measure completion:
A public workflow supports scheduled and manual comparison of pinned x402 specification files and package versions against upstream revisions.
A versioned watch list identifies every monitored upstream file, package, URL, and pinned revision.
A demonstrated upstream change opens or updates one public issue containing the changed files, upstream commits, relevant diffs, and affected Rail402 components.
Automated tests prove that unchanged drift does not create duplicate issues and resolved drift closes the existing issue.
A recorded upstream specification change demonstrates the complete workflow: change detection, issue creation or update, affected-component identification, resolution evidence, and issue closure.
The conformance suite verifies /supported, payload: { transaction }, exact, upto, Bazaar cataloging and search, MCP responses, and non-empty rejection reasons on testnet and pubnet.
A final report identifies the tested Rail402 release, upstream x402 revision, exact commands, passed, failed, and skipped test counts, reasons for skipped tests, and transaction hashes for every network-and-scheme combination.
Budget: $7,500
Tranche #3 Total: $62,500
YK Labs is a two-person software engineering team founded by Tolga Yaycı and Mert Köklü, building blockchain infrastructure, developer tools, and user-facing applications. Together, the founders bring more than five years of blockchain engineering experience across SDKs, backend infrastructure, smart contracts, wallets, protocol integrations, frontend systems, and applied cryptography.
YK Labs has built and shipped projects across Stellar, Arbitrum, NEAR, Cardano, Starknet, Internet Computer, Hedera, and other ecosystems through contracts, ecosystem grants, partnerships, and open-source contributions, with a strong focus on developer and user experience and production-ready delivery.
The team has an established track record with the Stellar Community Fund. Most recently, Mert successfully completed SoroPass, an awarded SCF RFP project that enables passkey-based signing and recovery for Soroban smart accounts.
Website: yk-labs.com
Tolga Yaycı — Co-founder & Software Engineer
Tolga is a software engineer with a Computer Engineering background focused on frontend engineering, product development, and user-facing blockchain applications. For Rail402, he leads the Explorer, Playground, and developer-facing application experience.
GitHub: github.com/tolgayayci
LinkedIn: linkedin.com/in/tolgayayci
Mert Köklü — Co-founder & Software Engineer
Mert is a software engineer with a Computer Engineering background focused on backend systems, SDKs, smart contracts, protocol infrastructure, and applied cryptography. Earlier in his career, he built StarkNet plugins and Cairo-language compiler tooling at ApeWorX, and before that led large-scale computer-vision projects as AI Video Analytics Team Lead at an NVIDIA partner company. For
Rail402, he leads the facilitator, backend and protocol infrastructure, SDK architecture, and Soroban integrations.
GitHub: github.com/justmert
LinkedIn: linkedin.com/in/mertkoklu
Selected Projects
Rail402: Stellar-native x402 infrastructure for paid HTTP resources and agent payments, with facilitator, discovery, agent tooling, and fixed or metered settlement.
SoroPass: Passkey SDK for Stellar smart accounts, enabling non-custodial signing without seed phrases.
Website: https://soropass.dev/
Pocket: Self-custody confidential Stellar wallet. One recovery phrase, two balances: one public, one private that hides your amounts.
Website: https://pocketwallet.app/
Wizard: Browser IDE for building, compiling, and deploying Arbitrum Stylus smart contracts in Rust.
NEARPlay: Browser IDE for writing, compiling, and deploying NEAR smart contracts in Rust.
Sluby: Decentralized video-streaming application with adaptive HLS delivery on the Sia network.
Tolga Yaycı
No other submissions.