Protected Tokens: Guaranteed Fee Capture for AI Agent Tokens on Stacks
Every trade of a protected token generates fees — by design. Discover how LAUNKR's restricted token architecture solves the revenue problem for AI agent native tokens on Stacks.
The Problem With AI Agent Tokens
AI agent tokens are having a moment. Platforms like Virtuals Protocol on Base have demonstrated that the market is hungry for tradable, co-owned AI agents — with protocols generating millions in fees at peak and ecosystems hosting tens of thousands of tokenized agents. On Stacks, that same wave is building, with the network's 2026 roadmap explicitly targeting 10,000 active AI agents as a key milestone.
But there's a fundamental tension in how these tokens are typically designed: the protocol that created the token has no guarantee it will ever capture fees from secondary trading.
On most launchpads, once a token graduates from its bonding curve and starts trading on open AMMs, the creator loses control over where liquidity lives. Traders migrate to forks, pools get deployed without fee switches, and the protocol that did all the work of launching and maintaining the agent ends up with no revenue stream from the asset it created.
LAUNKR, built on Stacks, takes a different approach — one that enforces fee capture at the token level rather than relying on traders to use the "right" pool.
What Are Protected Tokens?
A protected token is a fungible token whose transfer logic is restricted to a set of authorized liquidity pools. If a pool isn't on the whitelist, the token simply can't trade there. No workarounds, no forks, no drain.
This is possible on Stacks because of Clarity, the language used to write smart contracts on the network. Unlike EVM smart contracts, where token transfers are permissive by default, Clarity allows a token to enforce arbitrary conditions at transfer time — including checking whether the counterparty is an approved contract.
The result: every swap of a protected token must go through an LP that charges fees, and those fees are routed to the addresses defined at pool creation. The fee capture isn't a suggestion or a soft convention — it's enforced on-chain, unconditionally.
End-to-End Demo on Stacks Mainnet
Try it yourself at launkr.io — the LAUNKR front-end is live on Stacks mainnet.
On June 9, 2026, we ran a complete end-to-end demo of LAUNKR on Stacks mainnet using two wallets:
- Token deployer + fee receiver (Leather):
SP2YDHYCVP0QG1ARVBRPJ8ZW8N7AQVR39GJWK5AE - Swapper / buyer (Xverse):
SP34NMB9KGY9RHK2KKMDTZ7FCW8XA9K3SJJ3GJFGT
Step 1 — Deploy the Protocol Stack
Three contracts form the protocol layer, deployed by SP2GF0C5YV1HFVGVF7GK9FFVD8FANPVFP8R4BYDP5:
| Contract | Transaction |
|---|---|
restricted-ft-trait-v6-mn-demo | View on Explorer |
lp-singleton-v6-mn-demo | View on Explorer |
restricted-token-template-v6-mn-demo | View on Explorer |
Step 2 — Clone and Deploy a Token
From the LAUNKR front-end, the deployer clones the token template and names it helloai. This single transaction deploys the token contract at:
SP2YDHYCVP0QG1ARVBRPJ8ZW8N7AQVR39GJWK5AE.helloai
View token deploy transaction →
Step 3 — Create the Pool
With the token deployed, the deployer calls create-pool-bonding on the singleton. This registers the pool and sets the fee receiver to the deployer's address — meaning every future trade will route fees back to this wallet.
View pool creation transaction →
Step 4 — Swap (from a different wallet)
The buyer, using Xverse, executes a swap-exact-stx-for-tokens call for 0.5 STX:
The on-chain print event for the swap shows exactly how the fees are routed:
(tuple
(caller 'SP34NMB9KGY9RHK2KKMDTZ7FCW8XA9K3SJJ3GJFGT)
(direction "buy")
(event "swap")
(protocol-fee u500)
(recipient 'SP34NMB9KGY9RHK2KKMDTZ7FCW8XA9K3SJJ3GJFGT)
(stx-in u500000)
(token 'SP2YDHYCVP0QG1ARVBRPJ8ZW8N7AQVR39GJWK5AE.helloai)
(tokens-out u494755096227)
(treasury-fee u4500)
)
Breaking down the numbers for this 500,000 uSTX buy:
| Amount | |
|---|---|
| STX in (buyer) | 500,000 uSTX (0.5 STX) |
| Tokens out (buyer) | 494,755,096,227 helloai |
| Treasury fee (pool creator) | 4,500 uSTX — 90 bps |
| Protocol fee (LAUNKR) | 500 uSTX — 10 bps |
| Total fee | 5,000 uSTX — 100 bps |
The treasury:protocol ratio is exactly 9:1, as defined at pool creation. No slippage on the fee split, no way to route around it.
How It Works: The Architecture
LAUNKR's protected token system is built around three composable components:
1. The Restricted FT Trait
The restricted-ft-trait defines the interface that all protected tokens implement. It extends the standard Stacks fungible token trait (sip-010) with transfer logic that gates movement through an approved-pools registry. Any token cloned from the template automatically inherits this behavior.
2. The LP Singleton
The lp-singleton contract manages the pool registry and implements the bonding curve and swap logic. When a token is created, a pool is registered in the singleton with the fee receiver address specified by the deployer. From that point forward, all trades route through this contract — and all fees are captured.
Fee routing follows a fixed split:
- 90 bps → Treasury (the pool creator's fee receiver address)
- 10 bps → Protocol (LAUNKR's protocol fee receiver)
- Total: 100 bps (1%) during the bonding curve phase
Once a token graduates from bonding to a full liquidity pool, the fee schedule increases:
- 450 bps → Treasury
- 50 bps → Protocol
- Total: 500 bps (5%) in the graduated pool
The treasury:protocol ratio stays constant at 9:1 across both phases.
3. The Token Template
The restricted-token-template is the base contract that teams clone when deploying a new agent token. It ships preconfigured with the trait implementation and hooks into the singleton for pool registration. Deploying a new protected token is a single transaction.
Why This Matters for AI Agent Tokens
The AI agent token meta has a monetization problem. Most tokens launched on bonding curves generate fees during the initial price discovery phase, but once liquidity migrates post-graduation, the protocol loses its handle on where trades happen. Forks appear. Liquidity fragments. The team that built and maintained the agent earns nothing from secondary volume.
Protected tokens invert this dynamic: the token itself enforces that all trading happens in fee-generating pools. It doesn't matter which interface the trader uses — Leather, Xverse, or any future wallet that supports Stacks contract calls. As long as they're buying or selling the token, the fee receiver gets paid.
For teams building AI agents on Stacks, this means:
- Predictable revenue from the moment of launch, not just during the bonding window
- No liquidity fragmentation — there's one authorized pool, and all volume flows through it
- Treasury sustainability — agent teams can fund ongoing development from swap fees rather than relying on token sales
This is particularly relevant in the Stacks context, where the 2026 roadmap's push toward a fee-driven Bitcoin economy aligns well with a primitive that makes fee capture enforceable rather than aspirational.
Deployment Guide
This section is for teams on Stacks that want to deploy a protected token using the LAUNKR protocol.
Prerequisites
- A Stacks wallet with mainnet STX for contract deployment (Leather recommended for deploys)
- Access to the LAUNKR front-end at launkr.io
- Basic familiarity with Clarity contract calls
Deployer Addresses (Mainnet)
| Role | Address |
|---|---|
| Protocol deployer | SP2GF0C5YV1HFVGVF7GK9FFVD8FANPVFP8R4BYDP5 |
Protocol Contracts (Mainnet)
| Contract | Address |
|---|---|
| Restricted FT Trait | SP2GF0C5YV1HFVGVF7GK9FFVD8FANPVFP8R4BYDP5.restricted-ft-trait-v6-mn-demo |
| LP Singleton | SP2GF0C5YV1HFVGVF7GK9FFVD8FANPVFP8R4BYDP5.lp-singleton-v6-mn-demo |
| Token Template | SP2GF0C5YV1HFVGVF7GK9FFVD8FANPVFP8R4BYDP5.restricted-token-template-v6-mn-demo |
Step-by-Step
1. Connect your wallet
Open the LAUNKR front-end and connect your Leather wallet. This wallet will be set as the fee-receiver for the pool, meaning all treasury fees from swaps will route here.
2. Deploy your token
Fill in your token's name, symbol, and supply parameters. LAUNKR calls clone on the token template — this deploys a new contract at your wallet address, e.g. <YOUR_ADDRESS>.<your-token-name>.
The contract inherits the restricted-ft-trait automatically, so transfer restrictions are active from block 1.
3. Create your pool
After token deployment, LAUNKR prompts you to call create-pool-bonding on the LP singleton. This transaction:
- Registers your token in the authorized pool registry
- Sets your wallet as the fee receiver (90 bps on all buys/sells)
- Initializes the bonding curve parameters
4. Share your token
Your token is now live on Stacks mainnet. Share the contract address (<YOUR_ADDRESS>.<token-name>) with your community. Buyers can swap from any Stacks-compatible wallet using swap-exact-stx-for-tokens on the singleton.
5. Monitor fees
All treasury-fee events are emitted on-chain and filterable by your fee receiver address. You can track revenue in real time via the Hiro Explorer or any Stacks indexer.
Fee Schedule Reference
| Phase | Treasury | Protocol | Total |
|---|---|---|---|
| Bonding curve | 90 bps | 10 bps | 100 bps |
| Graduated pool | 450 bps | 50 bps | 500 bps |
| Treasury:Protocol ratio | 9:1 | — | — |
Built by Rather Labs on Stacks
LAUNKR is a Rather Labs product, built natively on the Stacks blockchain. Stacks' use of Clarity — a decidable, non-Turing-complete language — is what makes the restricted transfer logic both possible and auditable. Unlike EVM hooks or off-chain enforcement, Clarity's design means that the restrictions can be statically verified: there's no execution path where a protected token trades outside an authorized pool.
If your team is building AI agents on Stacks and wants to explore protected token deployment, visit launkr.io or reach out to the Rather Labs team to get started on mainnet today.
Demo conducted on Stacks mainnet, June 9, 2026. Contract calls verified via Hiro Explorer. Both Leather and Xverse wallets are compatible with all protocol interactions; token deployment is currently Leather-only.