The x402 Global Challenge is live! How to build & submit your entry

ALGO ·

The x402 Global Challenge is live, and there is $100K USD plus 500K ALGO in prizes on the line. To compete, launch a paid API endpoint on Algorand MainNet, drive real usage through the GoPlausible x402 Facilitator , and climb the leaderboard . Ten finalists will be selected to present live at Devcon 8 in India. This checklist will guide you from a working endpoint to a live, ranked entry. Your project isn't competition-ready until at least one real Mainnet payment has settled through GoPlausible Facilitator, the paid response is returned, USDC lands in your payTo address, your endpoint appears in the Bazaar catalog under x402-global-challenge tag, and it is driving real usage and volume visible on the leaderboard. That's the finish line that everything below is working toward. The right setup depends on what kind of project you're building, so we'll start there before getting into the steps. Before you start, it helps to know the shape your project can take. We've seen three kinds of approaches to participating in the x402 Global Competition. A Standard Entry is what most teams are building: one project , one endpoint , one price . Example: A team builds an endpoint that returns a verified credit score check for a given wallet or entity. Every call costs three cents, settles instantly, and returns a pass or fail plus a confidence score. There's no login, no subscription, no second endpoint behind it. One clearly priced capability is the whole product, and that's exactly what this entry type is for. A Composite Entry is for a team that has built its own product out of several atomic endpoints instead of one . Example: a document-processing product replaces a monthly subscription with a handful of small, honestly priced actions instead of one flat fee. Extracting text from a scanned file costs three cents. Summarizing that text costs another four cents, only triggered if the user actually asks for a summary. Translating the result into a second language costs five cents, only triggered on request. None of those three actions could honestly be folded into one bundled price, they happen independently, sometimes not at all, so the product exposes three atomic endpoints instead of faking one. Because the same team operates all three and the same operating wallet funds them, they roll up into a single Composite entry. One document might generate one, two, or three of these settlements depending on what the user needed, all of it real, all of it now visible on the leaderboard instead of being flattened into whichever one endpoint the team happened to register. An Orchestrator Entry is for a team whose product's real value is calling into other people's endpoints, not exposing one of its own . Example: an agent built for financial analysts doesn't run an endpoint at all. Given a question about a market segment, it calls a pricing endpoint, a macroeconomic conditions endpoint, and a regulatory filings endpoint, three other teams' products, pays each one individually on the analyst's behalf, and hands back one synthesized answer. The agent never touches the underlying data itself; its entire value is in knowing which endpoints to call and how to assemble what comes back. Registered as an Orchestrator entry, every payment its wallet makes into those other teams' endpoints counts toward its own leaderboard total, and also toward the total of whichever endpoint received it, since both sides of a real transaction are real activity. For a Standard Entry , nothing changes: your leaderboard number is the USDC settled to your endpoint. For a Composite Entry , this is handled automatically. If your endpoints share the same receiving address, the facilitator groups them under a single merchant, and their combined volume and transaction count appear as one entry on the dashboard and leaderboard. There's no separate registration step and nothing extra to prove, it's simply how settlement already works. Each endpoint can still be listed and described separately in the Bazaar, so people can discover and call them individually, only the leaderboard total rolls up. For an Orchestrator Entry , the requirement is straightforward: you have to actually be part of the payment flow. Your own endpoint, the one a client pays to request the finished result, is what gets tracked, the same as any Standard Entry. If your product then pays other teams' endpoints on the back end to fulfill that request, that's simply how you deliver the service, and that spend is recorded as real activity for whichever teams received it. What doesn't count is pointing a client toward other endpoints and letting them pay those directly, without your own endpoint ever settling a transaction. If you're never actually in the payment flow, there's nothing on-chain to attribute to you. Now that you know which shape your entry takes, this is the hands-on part. Work through the steps below in order, each one builds on the last, to go from a working endpoint to a live, ranked entry. Whichever entry type you picked above, you'll find its specific setup in step 4. You have a paid API endpoint built with x402 on Algorand. It's a real service someone would pay for (data, compute, an AI call, a verification, an action, etc.). It returns HTTP 402 Payment Required when called without payment. You've run the endpoint on Algorand Testnet and confirmed the full flow works (x402 request → pay → settle → paid response) without spending real funds. Testnet config used: network ALGORAND_Testnet_CAIP2 , USDC ASA 10458941 , and a Testnet payTo account opted in to USDC and funded with test ALGO + USDC (from the dispensers). Payments settle through the same GoPlausible facilitator on Testnet, so the only thing that changes for launch is the network and asset values. Testnet is for validation only; it does not count toward the leaderboard. You've flipped the config to Mainnet: network ALGORAND_Mainnet_CAIP2 and USDC ASA 31566704 (facilitator URL stays the same). The endpoint runs on Algorand Mainnet (not Testnet). It's deployed to a public host and reachable over HTTPS . Your receiving ( payTo ) address is a Mainnet account. That address is opted in to USDC (ASA 31566704 ). You'll keep using the same payTo address for the whole competition (that's how the leaderboard attributes your entry). Payments are verified and settled through the GoPlausible facilitator (not any other or local facilitator). Make sure your resource server is deployed to a domain and not running on localhost. The Bazaar discovery extension is enabled on your endpoint. Add the required challenge tag: x402-global-challenge . This helps identify your endpoint as part of the x402 Global Challenge and ensures your activity is properly tracked and attributed. Simply add a field named ‘tag’ to your extra field in your resource server x402 config so it looks this way: Important note: the facilitator Bazaar gets the metadata to enrich merchant and resources records from your domain and merchant account NFD if exists, so it is recommended you make sure your website metadata, logo, title, description, agentic files, and well-known structures are updated and correct if you want your merchant page to look shiny, data-enriched, and informative. The route's description field (in paymentMiddleware ) is what shows up in the Bazaar catalog API, so make it specific and concrete, name what the caller actually gets, not just the topic (e.g. "Real-time weather: temperature, conditions, and forecast for a given city" rather than "weather data access"). This is the human-readable summary both users and agents see when browsing. You've made one real Mainnet payment against your endpoint end-to-end. You received the paid response, and the USDC landed in your payTo address. Your endpoint shows up on the competition leaderboard (with global hackathon filter ON). After that first real settlement, your endpoint appears automatically in the Bazaar resource catalog and your merchant catalog entry (keyed by your payTo address). If you see those with the global hackathon filter ON, then you are done and did well. Also, feel free to check the correctness of your web implementation for endpoints and merchant domain by checking the completeness of your data records there. If your project is made up of several endpoints, you can group them all under a single merchant and still have each one listed in the Bazaar: The endpoints must run on Algorand Mainnet (not Testnet). They’re deployed to a public host and reachable over HTTPS . Share one payTo between endpoints . Point every endpoint route at the same payTo address . The facilitator groups every endpoint that shares a payTo under one merchant entry keyed by that address, so their USDC volume and transaction counts add up together on the dashboard and leaderboard instead of being split across separate rows. Never use different domains under one merchant account. Add endpoints as routes. Each endpoint is just another route in your paymentMiddleware configuration with its own price, network, payTo , and asset, backed by a handler that returns the paid response. Adding a capability means adding one route-and-handler pair while keeping the payTo unchanged. Enable discovery once. Register the Bazaar resource-server extension on the server a single time to turn on discovery for the whole product. Describe each endpoint. Attach a declared discovery extension to each route and give each a clear, specific description of what the caller receives. Result: every endpoint is listed individually in the Bazaar catalog with its own description and domains metadata, while all of them roll up to the one merchant entry , giving you separate discoverability per endpoint and consolidated volume under a single payTo . IMPORTANT: On MAINNET, never use the same payTo address for different domain endpoints because it is against regulations. Use endpoints to differentiate between different resources, not different domains! If your project's value is in calling into other teams' endpoints rather than exposing one of its own, you still enter through a single endpoint of your own, and every payment your agent makes downstream counts as real activity: IMPORTANT: Do not place different domain endpoints under the same merchant account! Each merchant account should be connected to only one root domain! Expose your own paid endpoint. Your product exposes one endpoint that the client pays to request the finished result, set up and discovered exactly like a Standard endpoint above (GoPlausible facilitator, Bazaar discovery extension, x402-global-challenge tag, clear description ). Settle the client's payment first. That own endpoint is what settles the client's payment before your backend pays anyone else, so you are genuinely in the payment flow, not merely redirecting the client to pay other endpoints directly. Pay downstream from your wallet. Your backend then pays the other teams' endpoints it depends on to fulfill the request. Each of those payments is recorded as real activity for the endpoint that received it, and counts toward your own leaderboard total as well, since both sides of a real transaction are real activity. Prove the full round-trip. Complete one real Mainnet round-trip end-to-end: client pays your endpoint, your backend pays the downstream endpoints, and the synthesized paid response is returned. Result: your endpoint is listed in the Bazaar catalog and merchant catalog like any Standard entry, while every downstream payment your wallet makes shows up as real volume, both toward your own leaderboard total and toward the endpoints you called. If you have a plan to get real users , transactions , and volume , then shipping is just the start. Keep promoting and growing paid calls: the leaderboard is measured over an unannounced window in October , and ranking is based on real on-chain usage. The submission is where you'll share more details about your project with us and formalize your participation in the competition. We'll use the information you submit, together with your leaderboard activity, to select the 10 finalists. When the submission period opens in September, submit your project for review. We’ll share the submission form closer to the deadline, so please keep an eye on your inbox. Start with the x402 developer guide for an overview of x402 and agentic commerce on Algorand, then follow the official x402 on Algorand example on the Algorand Developer Portal, and the step-by-step walkthrough for building x402 endpoints. To get started faster, use the Algorand Foundation demo server as a reference. It includes a complete x402 resource server with Bazaar discovery plus a matching client to call and test it, both of which you can review and adapt for your own endpoint: (Note: the demo ships with Testnet values, switch to Mainnet for your competition entry: network ALGORAND_Mainnet_CAIP2 , USDC ASA 31566704 ) Building with an AI coding assistant? Install the Algorand agent skills , a set of skills (including x402 for TypeScript and Python) that give your assistant the up-to-date patterns for building x402 endpoints, smart contracts, and dApps on Algorand. You can also use Algorand Agent plugins for OpenClaw , Claude code or Codex by GoPlausible to access all Algorand operations, development, skills and more all in one plugin with expertise on development and operations on Algorand and x402. Do you need technical support? Reach out on the Algorand Discord .

AI 시장 분석

The Algorand Foundation has announced the 'x402 Global Challenge' featuring a total prize pool of $100,000 in cash and 500,000 ALGO. Developers will build paid API endpoints on the Algorand mainnet, drive real-world usage, and compete on a leaderboard. The top 10 finalists will have the opportunity to present their projects live at Devcon 8 in India.

상승 영향

AI가 생성한 분석으로 투자 자문이 아닙니다.

DYAX Investor Sentiment

Bullish (Long) 52% · Bearish (Short) 48%

355 participants

Related News

원문 보기 — ALGO