Why an AI agent is a productive asset, what tokenization solves for builders in attention, ownership, and revenue, why people invest in tokenized agents, and every decision in the Swarms Launchpad flow from connection type to Frenzy Mode, USDC, and Vault Mode.
This guide has two halves. The first is the argument: why an AI agent is a productive asset, and what tokenizing one actually changes for a builder. The second is the mechanics: every decision in the launch flow, in the order you meet it, from how you connect your agent to which of the three toggles you enable.
If you already know why you want to do this, skip to Part 2. If you are not sure tokenizing is right for what you built, Part 1 is the part that matters, and it includes the cases where the answer is no.
Most software is a cost center that occasionally produces revenue.
You build it, you host it, you maintain it, you market it, and if all of that goes well you collect a subscription. The moment you stop doing any of those things, the revenue stops too. The software does not accumulate value on its own. It depreciates the second you look away from it.
AI agents are different in a way that has not been fully priced in yet. An agent does work. Not "enables work" the way a spreadsheet does, but performs it: reads the document, writes the code, makes the calls, produces the output. That distinction matters more than it first appears, because something that performs work repeatedly, without your involvement, and whose output has a market price, is not a file. It is a productive asset.
Three properties have to hold before something is an asset rather than a possession. An agent has all three.
It produces value repeatedly. A good agent does not get consumed by use. It runs a thousand times as easily as once, and each run has a value the user could have paid a human for. The unit economics of that are strange and new: near-zero marginal cost against a marginal value set by human labor rates.
It has a definable claim attached. You can say who owns an agent, who is entitled to its output, and who is entitled to the revenue it generates. That is what turns a capability into property.
It can be transferred without being destroyed. Ownership can change hands. A stake can be divided. Someone who believes in an agent can take a position in it, and someone who no longer does can exit.
Traditional software distribution gives you the first property and mangles the other two. You own the code, but nobody else can hold a stake in it. There is no way for a user who loves your tool to own part of its success, and no way for you to raise anything against its future output short of selling the company. The asset exists and there is no market for it.
Tokenization is not a marketing layer on top of an agent. It is the missing mechanism that lets the second and third properties actually function.
Talk to people building agents and you will hear the same thing. Their agent works. It genuinely does something useful. And almost nobody knows it exists.
This is the actual bottleneck in the agent economy right now, and it is worth being precise about it. The constraint is not model quality, and it has not been for a while. The constraint is that thousands of capable agents are being built by people with no distribution, no audience, and no budget, and there is no mechanism that reliably connects a good agent to the people who would use it.
The traditional answers are all expensive. Content marketing takes months. Paid acquisition takes money you do not have before you have revenue. Launching on aggregator sites gives you one day of traffic and then silence. Every one of these asks the builder to become a marketer, which is a different job that most builders are not good at and did not sign up for.
Tokenization attacks this differently. It does not ask you to buy attention. It creates a reason for other people to supply it.
When someone holds a stake in your agent, their incentives change. They are no longer a passive user who might mention you if they remember. They now have a reason to want more people to know about your project, because the value of what they hold depends on it.
This is the part that sounds cynical if you describe it badly and is genuinely powerful if you describe it accurately. It is not about manufacturing hype. It is about the difference between a user base and a stakeholder base. A user base is a group of people who benefit from your work. A stakeholder base is a group of people who benefit from your work succeeding. Those are different, and the second one distributes for you.
There is a mechanical version of this too. A tokenized agent has a live price, a live market cap, a live volume figure, and a public leaderboard position. Those are all surfaces where a project can be discovered by people who were not looking for it. A traditional listing has one surface: someone searches for exactly what you built and finds you. A tokenized listing generates ongoing signals in a place where people are actively looking for things that are moving.
Attention is the scarce input in the agent economy. Tokenization is a way to source it without buying it.
The second thing tokenization changes is what the relationship between a builder and a user can be.
By default, a token attached to an agent is a claim on the project's success rather than on the agent itself. Vault Mode changes that. With Vault Mode enabled, only holders of your agent's token can use the agent. Holding is not a bet alongside the product, it is the mechanism by which you get the product.
That inverts the usual subscription relationship in an interesting way. Under a subscription, money flows out of the user and into the builder, permanently, and what the user accumulates is a series of receipts. Under a holder-gated model, the user acquires something they retain, that has a price, and that they can exit if the agent stops being worth it to them. Access stops being an expense and becomes a position.
For the builder, this converts customers into aligned holders. The people using your agent most heavily are the people holding the most of it, and they are the people who most want it to succeed. That is a much stronger community structure than a list of email addresses attached to recurring card charges.
The third change is the shape of the earnings.
A normal paid listing pays you once per buyer. You get a fixed amount, and then that customer is monetized and you need another one. Revenue scales with acquisition, which means it scales with marketing, which is the thing you are least equipped to do.
A tokenized listing pays you a fee on every trade of your token, in both directions, for as long as people keep trading it.
Two things about that are structurally different from a subscription.
The first is that you earn on sells as well as buys. Someone exiting your project pays you a fee on the way out. Revenue is tied to turnover rather than to net inflows, which means a project with an active, engaged market earns even when sentiment is mixed.
The second is that it does not require you to keep acquiring customers to keep earning. It requires the market in your project to stay active. Those are related but not the same, and the second one is something your holders participate in rather than something you carry alone.
You also do not have to fund any of it. A tokenized launch creates a bonding curve rather than a liquidity pool you provide capital for. You bring the agent. You do not bring money.
That is the builder's side. The other half of the question is why someone on the other side of the trade would participate at all, and it deserves a straight answer rather than an assumption.
Because it is early exposure to a productive asset. If you believe agents will do a meaningful share of economic work, then the agents that get built now are the seed inventory of that economy. Most will fail. Some will become infrastructure that thousands of businesses depend on. Historically, the only people who could take a position in software that early were venture investors with access to private rounds. A tokenized agent is the first structure that makes that position available to anyone, at the point where it is actually early.
Because access has value, and holding is how you get it. For a vaulted agent, the calculation is not purely speculative. If the agent is useful to you, the token is worth at least what that usefulness is worth, and unlike a subscription payment you retain something at the end. A holder of a genuinely productive agent is buying utility with an exit option attached.
Because it is a claim on attention in a market where attention is the constraint. Volume and market cap on an agent token are measures of how much interest a project commands. In an economy where thousands of agents compete for a limited amount of notice, taking a position in the ones that are winning attention is a coherent thesis in its own right.
Because there is liquidity from the first day. The reason early-stage software equity is illiquid is that there is no market for it until an acquisition or an IPO, which may be a decade away or never. A bonding curve makes a position tradeable immediately. That is not a small structural difference. It changes the risk profile of participating early, because being wrong does not mean being stuck.
Because the fundamentals are legible. An agent produces output you can evaluate. You can use it, judge whether it is good, and see the volume it trades and the holders it has. Compared to most early-stage assets, where you are buying a pitch deck and a founder's confidence, the thing itself is available for inspection before you take a position.
A guide that only lists upsides is a pitch, not an argument, and it is worth being direct about the limits.
Tokenization does not make a bad agent valuable. It creates a market, and markets are quite good at pricing things at approximately zero. An agent nobody wants, with a token attached, is an agent nobody wants with a token attached.
It is not the right structure for every project. A steady, unglamorous tool that fifty companies quietly pay for every month may well earn more as a straightforward paid listing than as a token nobody trades. Tokenization rewards projects that attract turnover and attention. If your project's virtue is that it is boring and reliable, be honest about that and price it accordingly.
It does not remove the need to build something good. It changes who helps you distribute it, not whether it deserves distributing.
And from the investor's side, these are early-stage positions in a young market. Most early-stage anything fails. Prices move, sometimes sharply, and the fact that an agent works well is not a guarantee that its token appreciates. Anyone participating should size accordingly.
Some rough heuristics, drawn from what actually gets traded.
Agents with a visible, demonstrable output are stronger candidates than agents whose value is invisible. If someone can watch it work and immediately understand why it is good, that legibility compounds.
Agents serving a defined community are stronger than general-purpose agents. A community has a reason to coordinate, care, and hold. "Anyone might find this useful" is a weaker basis for a stakeholder base than "this is essential for a specific group of people."
Agents where recurring access is the value are strong candidates for Vault Mode. Agents where one-time use is the value are usually better as a straightforward paid listing.
Agents you intend to keep improving are better than finished ones. A stakeholder base is a relationship over time, and a project that is visibly still being built gives people a reason to stay.
The first choice in the flow is the listing type, and it constrains everything after it.
Agents are runnable systems. An agent has an implementation behind it, whether that is code, a hosted API, or an MCP server. Agents can be tokenized, can use Frenzy Mode, and can use Vault Mode.
Prompts are text assets: a system prompt, a jailbreak-resistant instruction set, a carefully tuned template that produces a specific behaviour. Prompts are simpler to publish because there is no implementation to connect, just content. Prompts can be tokenized, can use Frenzy Mode, and can use Vault Mode, exactly like agents. If you have a prompt that reliably does something valuable, it is a first-class listing, not a lesser one.
Tools are utilities and integrations. Tools cannot be tokenized. There is no token, no bonding curve, no Frenzy Mode, and no Vault Mode for a tool. If you want a tradeable token attached to what you are publishing, publish it as an agent or a prompt.
Bundles group several listings into one package and use a separate form of their own.
The practical takeaway: if tokenization is part of your plan, you are launching an agent or a prompt.
If you chose Agent, the Agent Implementation section asks how your agent actually works. There are four tabs, and they are genuinely different products rather than four routes to the same place. Pick based on where your agent lives and what you want buyers to be able to do with it.
You paste the implementation directly, choose the language, and list its requirements.
This is the right choice when your agent is self-contained and you want people to read, run, and adapt it. The buyer gets the actual source. There is no endpoint to keep alive, no uptime to maintain, and no infrastructure cost to you after publishing. Once it is sold, it works forever, independent of whether you are still running anything.
Choose Code when the value is in the logic itself: a well-designed prompt chain, an unusual orchestration pattern, a scraper with hard-won selectors, a workflow someone would otherwise spend a week building. Choose something else if the value depends on infrastructure you operate, or on data only you can reach.
You provide the URL of an x402-compatible API endpoint.
x402 is a machine-readable catalog for API endpoints. When you supply an x402 URL, Swarms discovers the API schema from the facilitator and displays integration instructions automatically. You do not write the documentation; the endpoint describes itself and the listing renders that description.
This is the right choice when your agent is a service you host. The logic stays on your infrastructure, which means you can update it without republishing, keep proprietary methods private, and reach data or models the buyer could not access on their own. The tradeoff is real: your endpoint has to stay up, and your listing is only as good as your uptime.
Choose x402 when you are running a real service and want it discoverable and callable by other agents, not just readable by humans.
You provide the base URL of an MCP server.
MCP, the Model Context Protocol, is the emerging standard for how agents discover and interact with services. When you supply an MCP server URL, Swarms connects to it, fetches the schema, and generates Python code examples using the MCP client. Buyers get working integration code rather than a description of what the integration would look like.
The difference between this and x402 is the audience. x402 describes an API endpoint. MCP describes a set of tools designed for an agent to call, with a standard for discovery built into the protocol. If you have built something that other people's agents should be able to pick up and use, MCP is the format that makes that automatic.
Choose MCP when your agent is a capability for other agents rather than a destination for humans.
You point at a URL.
This is the lightest option and the least structured. No schema is fetched, no code is generated, and nothing is verified. The listing is a pointer to something that exists elsewhere.
Choose Website when your agent is a product with its own front door, when you want a marketplace presence and a token without exposing an API surface, or when you are establishing a listing now and will connect a real implementation later.
The GitHub import field near the top of the form is often mistaken for a fifth implementation type. It is not. It is an accelerator.
Paste a repository URL and Swarms fetches the repo and prefills your listing from it: the name, the description, the main code, the detected language, suggested categories, suggested tags, and the repository avatar as your listing image. Everything it fills in is editable afterwards.
So GitHub import is a fast path to a Code listing, not a connection type of its own. It is the fastest way to go from an existing repository to a published agent, and it is worth using even if you plan to rewrite every field, because it handles the image and the boilerplate for you.
| Your situation | Connection type |
|---|---|
| Self-contained code others should run and modify | Code |
| Already on GitHub | GitHub import, then Code |
| A hosted API you operate | x402 URL |
| A capability other agents should call | MCP URL |
| A product with its own site | Website |
If you are launching a prompt, there is no implementation section. You provide the prompt content itself, plus the usual name, description, image, categories, and tags.
That simplicity is worth taking seriously rather than treating as a lesser path. A prompt that reliably produces a specific outcome is often more immediately useful to a buyer than an agent they have to wire up, and it carries none of the maintenance burden. Prompts tokenize on exactly the same terms as agents, with the same fee structure, the same Frenzy and Vault options, and the same eligibility for competitions.
If you have been sitting on a system prompt that works unusually well, it is a legitimate launch.
Tokenizing attaches a live, tradeable token on Solana to your listing, and it does so through a bonding curve rather than a liquidity pool you have to fund.
The curve prices the token algorithmically: early buys are cheaper, later buys cost more, and you do not need to provide any capital to get started.
The curve has two checkpoints. It opens at a default initial market cap of about $3,246 and migrates at about $46,468. Those are USD targets. For a SOL-quoted pool they are converted to SOL at the current spot price at launch time; for a USDC-quoted pool they are used directly. Reaching the migration checkpoint means the token has graduated out of the launch curve, which is the moment most projects are aiming at.
Every bonding curve is denominated in something. That is the quote currency, and Swarms supports two.
SOL is the default and the crypto-native choice. Your token has a SOL price and a SOL market cap, your fees accrue in SOL, and your chart moves with the Solana ecosystem.
USDC denominates everything in dollars. Your token has a dollar price, your market cap is a dollar figure, and your fees accrue in USDC.
The distinction that matters is the denominator. On a SOL-quoted curve, your dollar market cap moves when SOL moves, which means a day with no trading in your token at all can still show your project up fifteen percent or down twelve percent. On a USDC-quoted curve, the number only changes when someone actually buys or sells your token. The noise is gone, and what is left is a clean signal about your project.
There are three practical consequences:
Choose SOL if your audience is crypto-native and comfortable holding it. Choose USDC if you are building for people who want the agent and have no interest in taking a position on a layer-one token as a side effect.
One note on timing: the quote currency is set when the curve is created and is not something you switch later. Decide before you launch.
Frenzy Mode is a toggle at launch time, available for agents and prompts, that changes the fee tier your token runs on.
By default, a tokenized listing charges a total trading fee of 1.0% per trade, split evenly: 0.5% to you and 0.5% to the platform. Frenzy Mode routes the token through a different fee tier entirely, doubling the total fee to 2.0%, with 1.0% going to you and 1.0% to the platform.
| Standard | Frenzy Mode | |
|---|---|---|
| Total trading fee per trade | 1.0% | 2.0% |
| Your share | 0.5% | 1.0% |
| Platform share | 0.5% | 1.0% |
The precise thing to understand is that Frenzy does not redistribute the existing 1.0% in your favour. It doubles what every trade costs. You earn twice as much per unit of volume, and traders pay twice as much per trade.
That is a real tradeoff, not a free upgrade. Higher fees are friction, and friction reduces turnover, particularly for tokens people trade actively. Frenzy Mode makes sense when you expect meaningful volume and want to maximise what you capture from it. It makes less sense if your token is likely to trade thinly, where the higher cost per trade may suppress the very activity you are trying to earn from.
Frenzy launches also appear on the Frenzy leaderboard, which is its own source of visibility.
Vault Mode turns your token into an access key. Only holders of your agent's token can use the agent.
Part 1 covered why this changes the builder and user relationship. The mechanical points to know at launch time are shorter.
The most important structural point: Vault Mode and pricing are mutually exclusive. A vaulted listing does not have a purchase price, because holding the token is the access mechanism. You are choosing between selling access and gating access, and you cannot do both on the same listing.
Vault Mode suits agents where ongoing access is the value and where you would rather align a community around ownership than convert one-time buyers. It does not suit anything where a straightforward one-time purchase serves the buyer better, and it does not suit an agent nobody wants to use repeatedly, because gating access to something with no recurring demand gates nothing.
The three toggles are independent, which produces a useful set of combinations.
USDC plus Frenzy Mode. Dollar-denominated pricing with the doubled fee tier. Your revenue is both maximised per unit of volume and stable in value once earned. This is the most revenue-focused configuration for a project expecting real turnover.
USDC plus Vault Mode. A dollar-priced access token. Buyers see a stable, comprehensible price for what access costs, which is the most legible configuration for business buyers evaluating a tool against a budget.
SOL plus Frenzy Mode. The crypto-native, volume-maximising configuration. Best suited to a trader audience where SOL denomination is expected and higher fees are tolerated.
Neither, on a SOL curve. The plain default. Lowest friction for traders at 1.0% total fees, no access gating, no dollar denomination. A reasonable starting point if you are unsure.
Vault Mode is the only one of the three that removes an option elsewhere, since it rules out setting a price.
Publishing and tokenizing are two steps under the surface: the listing is created first, then the token is minted on chain. If the second step fails, for example because you rejected the signature request, the listing still exists and you can tokenize it later from its page. You will not lose the work.
Can I change the quote currency after launching? No. The quote currency is written into the bonding curve configuration when the curve is created and cannot be changed afterwards. Decide before you publish.
Can I add Vault Mode later? Vault Mode is a launch-time decision, and it is incompatible with having set a price. Plan for it up front.
Can I tokenize a tool? No. Tools do not support tokenization in any configuration. Publish as an agent or a prompt if you want a token.
Do prompts really earn the same as agents? Yes. The fee structure, Frenzy Mode, Vault Mode, and competition eligibility are identical.
What if my endpoint goes down? For x402 and MCP listings, the implementation lives on your infrastructure, and a listing that points at a dead endpoint is a dead listing. If you are not confident about keeping something running, publish as Code instead.
Does tokenizing stop me selling normally? A tokenized listing can still carry a price, unless it uses Vault Mode. Tokenization adds a revenue stream rather than replacing one.
The reason to care about any of this is not the mechanics of bonding curves. It is that a category of work is being created faster than the structures to own it.
There will be millions of agents. They will do real work with real economic value. Right now, almost all of that value is captured either by the platform hosting the agent or by the model provider underneath it, and very little by the person who actually built the thing. That is a distribution problem, and distribution problems get solved by giving people a way to own what they make and a way for others to own part of it with them.
An agent is a productive asset. It should be possible to own one, to hold a stake in one, and to earn from one continuously rather than once. That is the whole argument.
If you have built something that works, it is worth finding out what the market thinks it is worth.
The shortest useful path: pick an agent or prompt you have already built, run it through GitHub import if it is in a repository, choose the connection type that matches where it actually lives, and decide the three toggles deliberately rather than by default.
Launch at swarms.world/launch.
The new Swarms Launchpad competition is live. Launch an agent or prompt with USDC as the quote currency between August 26 and September 2 UTC and compete for a share of a $1,000 USDC prize pool, ranked by total trading volume.
![Swarms Weekly Ecosystem Update [August 17 - August 24]: The Swarms MCP Server, MCP Scribe, and Encrypted Skills Storage](/_next/image?url=%2Fswarms_weekly_ecosystem_update_aug.png&w=3840&q=75)
This week across the Swarms ecosystem: the hosted Swarms MCP server went live with 23 tools behind a single endpoint, the MCP Portal shipped on Swarms Cloud with live status and connection diagnostics, MCP Scribe turned OpenAPI specifications into production MCP servers, Swarms Cloud added encrypted prompt and skills storage with native SKILL.md support, and the Marketplace changelog covered more than 200 improvements shipped between July 21 and August 21.
Swarms Cloud now has a dedicated MCP page at cloud.swarms.world/mcp for the hosted Model Context Protocol server at mcp.swarms.world/mcp. Point any MCP client at one URL to give it agents, swarms, batch execution, and account telemetry as callable tools. The page carries live endpoint status, connection snippets for Python and TypeScript, swarm completion examples, and client tutorials.