Three ways to earn here, and all three end at the same Stripe account.
Route one: sell on the Marketplace. A buyer pays for your listing, Xuda takes a cut read off your seller tier at charge time, and the remainder is routed to your connected account (cpi/stripe_module/index.mjs:3064-3070). Route two: earn a partner commission on xuda.network. An ambassador accrues 15 percent and a mentor 20 percent, the only two rates that exist in code, at cpi/stripe_module/index.mjs:6480-6488. Route three: invoice your own clients through Xuda Finance, raising quotes and invoices on your own Stripe account so you remain the merchant of record. That third route is built and live on dev, dated 2026-08-02, and it is deliberately not on prod. What the three share is the destination. A purchase is refused outright when the seller has no connected Stripe account id, with the message "the seller is not set up to receive payments" (stripe_module:3047-3053), and a partner payout is blocked with "the partner has no active Stripe account to be paid into" until a chargeable connect account exists (stripe_module:9186-9218). The gate to LIST is looser than the gate to be PAID: is_marketplace_pro returns true for an account merely flagged is_xuda_network_ambassador (marketplace_module:90-96), so it is possible to be a visible seller and structurally unpayable at the same time.
Three different mechanisms, one account they all settle into.
A sale, a commission and an invoice are not variations of one feature: they are three separate code paths, written at different times, with different owners of the money. They meet at exactly one object. Every one of them needs a connected Stripe account that is actually chargeable before a single dollar can reach you, and each of them refuses in its own words when that account is missing.
Declared listing types that have a provisioner
The cut Xuda keeps, Free tier down to Scale
Ambassador and mentor rates, the only two in code
Floor price of a paid listing, ceiling $100000
Four tiers, and the row that matters is the last one.
Read any column top to bottom and the offer is plain: a monthly price, the percentage Xuda keeps, how many listings you may have live, and which of the four declared listing types you are allowed to create. Then read the last row, which is the one no tier page tells you. LISTING_TYPES declares project, ai_agent, instance and managed_vps (marketplace_module:2640), and PROVISIONERS implements two of them, project and managed_vps (marketplace_module:3099, 3291). Anything else records provision_stat failed with provision_error nothing knows how to provision a "<type>" listing yet, and the caller gets no provisioner for listing_type. The Free tier permits ai_agent by name, which is one of the two with nothing behind it. Managed VPS is the strictest of the two that do work: a listing cannot go live at all without a captured, restorable image, checked at marketplace_module:2652-2672. One caveat on the paid rows: the repo copy of config.json carries placeholder Stripe price ids on Starter, Grow and Scale (TODO_marketplace_starter and its siblings), so this table states the ladder as declared and claims nothing about buying into it.
Free | Starter | Grow | Scale | |
|---|---|---|---|---|
| Monthly price | $0 | $19 | $49 | $149 |
| Xuda keeps | 20% | 15% | 10% | 5% |
| Live listings | 1 | 5 | 20 | Unlimited, the flag reads 0 |
| Types you may create | project, ai_agent | plus instance | plus managed_vps, the first tier that can sell a VPS | all four declared types |
| Of those, types that actually provision | 1 of 2, project only | 1 of 3, project only | 2 of 4, project and managed_vps | 2 of 4, project and managed_vps |
A purchase that took the money and delivered nothing, in its own fields.
A marketplace purchase is PAID FIRST and provisioned afterwards. stripe_module captures the charge, writes the marketplace_purchase doc, then dispatches provisioning without awaiting it: cloning a project copies the database, studio docs, plugins and disk assets and runs npm install, far too slow to hold a checkout open. For a type with no provisioner, that ordering produces the record below. PROVISIONERS has exactly two entries, project and managed_vps, LISTING_TYPES declares four, and the default seller tier permits an ai_agent listing by name. The dispatcher looks up the type, finds nothing, and stamps the failure onto a purchase that has already cleared.
Two roles per city, and only two of the four rates exist in code.
The marketplace sells artifacts. The partner program pays people, per city, with two roles in it. PARTNERSHIP_PROGRAM.md is specific about what each role owes monthly, what each line pays, and the guardrail on the total. The commission code is narrower than that document on purpose, and says so in a comment. The panel is two solid bars and two aspirational ones.
- The ambassador is the front of a city: events, university and bootcamp lectures, at least 2 native-language videos a month, sourcing prospects. Three pay lines: a 5 percent regional override on net new city subscription revenue for 12 months, a 15 percent direct referral on first-year revenue from customers they sourced, and fixed stipends per qualified activity.
- The mentor is the technical half: implementation, code-review pairing, 1 technical video a month, a quarterly reference project. A 20 percent implementation share on services they deliver, a 3 percent regional technical override on accounts they enabled, paid hourly mentoring. Total payout per city is capped at 25 percent of city net revenue.
- FINANCE_COMMISSION_BPS_BY_ROLE holds two entries and no others: ambassador 1500 bps, mentor 2000 bps. The comment above it names what is deliberately absent and why. The regional overrides are attribution by region code over 12 months, the stipends need proof and pre-approval, and the per-city cap and the month-12 taper are ledger questions. A per-invoice percentage expresses none of them, so none are pretended.
- The gap that matters to a partner: an account flagged is_xuda_network_ambassador passes the seller gate outright, with no Stripe account attached. A partner can list and quote while being structurally unpayable, and payout is operator-only, refusing with the message that the partner has no active Stripe account to be paid into. Xuda Finance is live on dev and explicitly not on prod.
Seven stages from create to live, and six of them can refuse you.
Creating a listing and publishing one are different methods with different gates, and the order is not the obvious one. The type your tier may sell is checked at CREATE, so a Full Stack VPS is refused before its creation side effects run: the backup access grant, and the image capture the seller starts next. The cap and the image gate are publish-time, and account standing sits in front of the AI as a deterministic override.
Three moves, and the last one is reading.
Being permitted to list and being able to receive money are two checks in two different modules, and passing the first is not evidence of the second.
- 01
Become payable, not just permitted
The seller gate takes any of three signals: the is_xuda_network_ambassador flag, finance_active true, or stripe_connect_account_status.status active. Only the last is money. Checkout refuses outright when the seller has no connected Stripe account id, saying the seller is not set up to receive payments, and the buyer needs a stored Stripe customer too.
- 02
Pick the route, and price it
Selling an artifact: project and managed_vps are the two types with a provisioner today. A paid listing runs $5 to $100000, so it is never free, and Xuda's cut defaults to 20 percent, read off your tier at charge time and stamped onto the record. The ladder: Free at $0 for 20 percent and 1 listing, Starter at $19 for 15 percent and 5, Grow at $49 for 10 percent and 20, Scale at $149 for 5 percent uncapped. Selling services goes through Xuda Finance instead: a connect account makes you merchant of record, a delegate seat is quote-only with stripe_account_id deliberately null and Xuda staying merchant of record. Finance is dev-stage, dated 2026-08-02.
- 03
Read the two status fields, not one
publish_stat says whether a listing is visible, and mirrors into stat. On a purchase, stat says the money moved and provision_stat says whether anything was delivered. Read provision_stat, provision_attempts against the ceiling of 3, and provisioned_ref for what was created. commission_percent is the rate applied, kept there so a later refund uses it. Once provision_stat reads done the refund route refuses: billing stops only by deleting what was provisioned.
Nine things to read before you list, starting with the one that charges and delivers nothing.
- Four listing types are declared for the paid surface, project, ai_agent, instance and managed_vps, and PROVISIONERS implements two of them, project and managed_vps. An ai_agent or an instance listing can be published, bought and CHARGED, and then records provision_stat failed with the error nothing knows how to provision a "<type>" listing yet, returning no provisioner for listing_type. The default Free seller tier lists ai_agent by name in its listing_types flag, so the cheapest path into the marketplace is also the one with no delivery behind it. cpi/marketplace_module/index.mjs, LISTING_TYPES at 2640 and the dispatch at 3291 to 3301.
- Money is taken first and provisioning runs afterwards. Payment settles in stripe_module.purchase_marketplace_listing, then provisioning is dispatched asynchronously off the back of it and deliberately not awaited, because a project clone copies the database, the studio docs and the disk assets and then runs npm install. The comment in the source says it in those words: a purchase is PAID FIRST, then provisioning runs async.
- There is never an automatic refund. A failed provision records an attempt count capped at 3 by MAX_PROVISION_ATTEMPTS, and past it the buyer is told the purchase has used all of its automatic retries and to contact support or cancel it for a refund. Once provision_stat reads done the refund route refuses outright with this purchase is set up and running, and the only way to stop billing is to delete what was provisioned.
- The seller gate is a payability check, not a plan check. is_marketplace_pro returns true for an account flagged is_xuda_network_ambassador, or with finance_active true, or with stripe_connect_account_status.status active, at lines 90 to 96. An ambassador therefore clears the gate with no Stripe account at all, which is how a partner can list and quote while being structurally unpayable.
- The repo copy of config.json carries placeholder Stripe price ids on the three paid seller tiers, TODO_marketplace_starter, TODO_marketplace_growth and TODO_marketplace_scale, at lines 3249, 3274 and 3300. The ladder is real as a set of rates and caps. Nothing on this page proves those tiers are purchasable today, and we are not claiming it.
- Xuda Finance is built and live on dev, dated 2026-08-02 in its design doc, which then says Not on prod. Invoicing, quotes and the delegate seat are dev stage. Payout is operator only, there is no self-service withdrawal, and it blocks with the partner has no active Stripe account to be paid into until a chargeable connect account exists.
- Only two commission rates exist in code, ambassador 1500 bps and mentor 2000 bps in FINANCE_COMMISSION_BPS_BY_ROLE. The 5 percent and 3 percent regional overrides, the activity stipends, the 25 percent per-city payout cap, the taper after month 12 and the monthly statement cycle live in a markdown plan with no ledger behind them. The comment above that constant states why: they are attribution over a window rather than a per-invoice percentage, and pretending otherwise would quietly pay the wrong number.
- The finance plan flag documents_per_month, 25 on the Free tier, appears in config.json and in config_dev.json and is read by no code anywhere in the repo. It is an advertised cap with nothing enforcing it, so nothing stops you at 25 today.
- The publish gate promises no turnaround. Nothing records a review outcome time, there is no SLA anywhere in the code, and there is no rating, no review and no seller reputation field anywhere in cpi/marketplace_module/index.mjs. Trust in a listing today comes from what the gate refused, not from what other buyers said.
The seller screens, and the finance screens behind them.
A walkthrough of the surface this page describes: creating a listing and picking its type, the publish state moving from pending review to published, and the finance side where a connected account is attached and a quote is raised. The finance screens are recorded on the development environment, which is where that half of the product currently runs.
The four questions that decide whether this is for you
Answered against the shipped code, including where the code does less than the interface around it suggests.
Two doors, and the second one is the one that gets you paid.
Applying to the xuda.network partner program is a real application: city, role, your public work, and a short motivation, reviewed by a person. An ambassador runs events and university lectures, publishes at least 2 native-language videos a month and sources prospects. A mentor does implementation, code-review pairing, 1 technical video a month and a quarterly reference project. The second door matters more than it looks: whether you sell a listing or earn commission as a partner, money moves through a connected Stripe account, and until that account exists and is active the platform has nowhere to send it. Set it up in billing before you list anything, not after your first sale.