# Fees
Source: https://docs.star.fun/about/fees



<video />

Star does not take a percentage of your raised funds, and Star does not take a share of your token supply. Every dollar you raise reaches your treasury, and your full supply goes where you allocate it. This is deliberate: the raise exists to give you runway, and the supply exists to carry value for your holders.

Star earns from trading activity instead:

| Stage                    | Star's fee             |
| ------------------------ | ---------------------- |
| During the fundraise     | **1%** on each trade   |
| After a successful raise | **0.5%** on each trade |

Separately, **you earn 0.5% of each secondary trade** of your token after launch. That fee is yours, not Star's - see [Post-launch](/founders/post-launch#trading).

Star wins when your token trades, which happens when your project grows. There is no fee on failure: a round that does not close costs you nothing.


# $STAR
Source: https://docs.star.fun/about/what-is-$star



<video />

\$STAR is a market-governed ownership token. The Star treasury and protocol IP are governed by [decision markets](/founders/decision-markets), created and traded on Star and also available on [combinator.trade](https://www.combinator.trade/).

## Token Info

| Property            | Value                                          |
| ------------------- | ---------------------------------------------- |
| Contract address    | `StargWr5r6r8gZSjmEKGZ1dmvKWkj79r2z1xqjFstar`  |
| Main liquidity pool | `BCHdYBEzzStNGXYNHyf623KheHsBgpZFs4rjLvbE5YtJ` |
| Mint authority      | Assigned to the DAO                            |

All trading and liquidity now occur exclusively on this contract.

## Supply Data

<table>
  <thead>
    <tr>
      <th>Allocation</th>
      <th>Amount</th>
      <th>Percentage</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>Total Supply</td>
      <td>272,762,996 \$STAR</td>
      <td>100%</td>
    </tr>

    <tr>
      <td>Circulating Supply</td>
      <td>272,762,996 \$STAR</td>
      <td>70%</td>
    </tr>

    <tr>
      <td>Team Allocation</td>
      <td>116,910,117 \$STAR</td>
      <td>30%</td>
    </tr>
  </tbody>
</table>

## DAO & Treasury

<table>
  <thead>
    <tr>
      <th>Property</th>
      <th>Value</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>Treasury Address</td>
      <td>`EtdhMR3yYHsUP3cm36X83SpvnL5jB48p5b653pqLC23C`</td>
    </tr>

    <tr>
      <td>Monthly Allowance</td>
      <td>\$35,000 USDC</td>
    </tr>

    <tr>
      <td>DAO Contract</td>
      <td>`6Eykhr9PfnjKFGWxgACCUKo1sy9zRKEBAQV8n94Qo33y`</td>
    </tr>
  </tbody>
</table>

All protocol revenues and assets are held on-chain and governed by the DAO. Any expenditure above the allowance amount requires market approval. The allowance starts on **February 1st**.

### Marshall Islands DAO LLC

A Marshall Islands DAO LLC governs all protocol IP.


# ACE
Source: https://docs.star.fun/founders/ace



<video />

**Status: Available on request.** [Book a call](https://cal.com/adam-bergeman/founder-call) to set it up.

ACE (Asset Conversion to Equity) is an equity conversion framework by [MetaLeX](https://www.metalex.tech/). Eligible token holders convert a part of their tokens into an **ACE SAFE**: a modified Y Combinator SAFE, denominated in your token instead of dollars. Holders keep their unconverted tokens, so a participant holds both an equity position and a token position.

## How a conversion works

1. The holder opens the round through a link that you share.
2. The holder selects an amount, inside the minimum and maximum ticket sizes that you set.
3. The holder passes nationality and sanctions screening, and KYC/AML verification.
4. The holder signs the SAFE and transfers the tokens.
5. The holder receives a **cyberCert**: an ERC-721 certificate of the SAFE position. It is non-transferable by default.

## The ACE SAFE

| Property       | Behavior                                                                |
| -------------- | ----------------------------------------------------------------------- |
| Denomination   | Purchase amount and valuation cap are set in your token, not in dollars |
| Equity type    | Common stock at conversion                                              |
| Certificate    | An ERC-721 cyberCert, with regulatory legends in the metadata           |
| Round duration | Guaranteed by smart contract. Nobody can close the round early          |
| Funding cap    | The only trigger that closes a round before its end                     |

## What happens to converted tokens

Your company receives the tokens as the SAFE purchase price and holds them under treasury covenants:

* The tokens are **locked** for a set period (one year in the MetaLeX pilot; configurable).
* The company cannot sell, loan, or collateralize them during the lock.
* The company can burn them to reduce supply.
* After the lock, the tokens are a corporate asset for the benefit of all equity holders.

## The valuation cap sets the signal

| Cap                                     | Effect                                                  |
| --------------------------------------- | ------------------------------------------------------- |
| High (for example 500% of token supply) | Modest equity per token. Alignment and insurance        |
| Medium (100% of supply)                 | Parity between token value and equity value             |
| Low (50% of supply)                     | Aggressive equity per token. A reward for the community |

## Eligibility

The MetaLeX pilot runs under Regulation S: non-U.S. persons, verified by zero-knowledge passport proof. Outside the pilot, U.S. accredited investors can participate under Regulation D. The token itself does not become a security: the SAFE is the security, and the token is the payment method.

## When to use it

Use ACE when your backers want a path to real equity but the raise and the early ownership should stay liquid. Conversion is optional for each holder and priced by the terms that you set.


# Capital unlocks
Source: https://docs.star.fun/founders/capital-unlocks



<video />

Your raise unlocks more capital automatically as your market cap grows. Portions of tokens are set aside as positions higher on the price curve. When demand moves the price to a position, the position is bought automatically and the proceeds unlock to your team. You do not sell manually and you do not time the market.

## Schedule

| Market cap | Capital unlocked (cumulative) |
| ---------- | ----------------------------- |
| \$2M       | \$10,000                      |
| \$10M      | \$200,000                     |
| \$20M      | \$775,000                     |
| \$40M      | \$1,900,000                   |
| \$80M      | \$4,200,000                   |
| **\$160M** | **\$8,600,000 (maximum)**     |

## Payout

Unlocked capital reaches you in monthly allowances. The allowance arrives in the wallet that created the project. To withdraw:

* Send to another Solana wallet, or
* Open a bank account with [Altitude](https://altitude.xyz), our preferred partner for stablecoin business banking, to send and receive fiat and stablecoins.

Larger expenditures from the treasury are governed by [decision markets](/founders/decision-markets).


# Decision markets
Source: https://docs.star.fun/founders/decision-markets



<video />

Decision markets govern the project treasury on **every launch, in every ownership structure**. The treasury holds the raised funds, the trading fees, and the revenues. Day-to-day operations stay with the founding team; decision markets are scoped to high-impact choices, like treasury allocation and structural changes.

For founders, the markets work like a board: backers get a structured, market-mediated say over major decisions. For backers, the markets replace trust in founder discretion with a mechanism.

## How a proposal works

<Steps>
  <Step title="A holder opens a proposal">
    A token holder with at least **5% of supply** can create a proposal.
  </Step>

  <Step title="The market prices it">
    The proposal runs as a market on Star, on the project's own page. Markets are also available on
    [combinator.trade](https://www.combinator.trade/). Participants put capital behind outcomes. The
    prices are a real-time signal on which decision is expected to maximize long-term value.
  </Step>

  <Step title="The outcome executes">
    The market outcome decides whether the treasury action is carried out.
  </Step>
</Steps>

## What the markets govern

* **The treasury.** Raised funds are released to the team in monthly allowances. Larger expenditures require a proposal.
* **Allowance changes.** The monthly allowance can be increased or decreased through a proposal. A founder proposes an increase; holders can propose a decrease. Both go to the market like any other treasury decision.
* **Structural changes.** A shift to a different funding structure, or a follow-on fundraise, goes to the market.

## What this gives backers

* Founders cannot extract funds or force major decisions unilaterally.
* Treasury usage is visible and governed by predefined mechanisms.
* Backers can react when information changes, not only at governance windows.


# Curves
Source: https://docs.star.fun/founders/fundraising



<video />

A curve round raises USDC through a dynamic market sale: a live, public sale on a bonding curve. The mechanism is optimized for small rounds of **\$10K to \$50K** that want speed, price discovery, and a liquid token from the first buy.

## Presets

Each preset sets the amount that you take home and the **graduation market cap**: the valuation at which the sale completes and the token migrates off the curve into a live trading pool.

| Preset   | Raise target | Graduates at |
| -------- | ------------ | ------------ |
| Micro    | **\$10K**    | \~\$190K     |
| Standard | **\$25K**    | \~\$352K     |
| Pro      | **\$50K**    | \~\$622K     |

To raise more than \$50K, [book a call](https://cal.com/adam-bergeman/founder-call) and we configure a larger round directly.

## How the sale works

* There is no fixed price. The token price rises as more is bought, so earlier backers get a better price.
* The sale is a live market. Backers can buy and sell throughout the raise.
* The sale completes when it reaches the graduation market cap. The token then migrates into a live trading pool.

The sale collects more than the amount that you take home: the round also funds **onchain liquidity**, a reserve paired with tokens, so the market has depth to trade against after graduation.

## What you earn

A curve round pays you from three sources:

1. **The raise**: the preset amount, settled in USDC.
2. **Trading fees**: 0.5% of each secondary trade of your token, for as long as it trades. This is your fee, separate from [Star's](/about/fees).
3. **[Capital unlocks](/founders/capital-unlocks)**: more capital unlocks automatically as your market cap grows, to a maximum of \$8.6M.

## Token distribution

The supply is fixed at **1,000,000,000** tokens (Solana SPL). It splits three ways:

| Allocation  | Share   | Purpose                                                       |
| ----------- | ------- | ------------------------------------------------------------- |
| Public sale | **60%** | Sold to backers during the raise                              |
| Team        | **20%** | Locked - see [Team vesting](/founders/team-vesting)           |
| Liquidity   | **20%** | Seeds the trading pool when the token graduates off the curve |

## After graduation

The token is live and tradable. What follows has its own pages:

* [Capital unlocks](/founders/capital-unlocks): more capital unlocks automatically as the market cap grows.
* [Decision markets](/founders/decision-markets): the treasury and larger expenditures.
* [Post-launch](/founders/post-launch): managing the project, trading, and follow-on fundraising.

To launch a curve round from your terminal or your agent, read the [Quickstart](/quickstart).


# Launch guide
Source: https://docs.star.fun/founders/launch-guide



<video />

A good launch is preparation. The founders that raise fastest have their accounts connected, a demo that people can try, and a launch post that is ready before the round opens. This page lists what to prepare, what to do at launch, and how to keep momentum in the first days.

## Before you launch

### Connect your accounts

Backers check who you are before they commit. Connect **X**, **GitHub**, and **LinkedIn** to your project.

<CardGroup>
  <Card title="X" icon="x-twitter">
    Your public voice. Pin a post that shows what you have shipped.
  </Card>

  <Card title="GitHub" icon="github">
    Your shipping record. Public repositories and recent commits show that the product is real.
  </Card>

  <Card title="LinkedIn" icon="linkedin">
    Your track record. A real work history shows that you have done hard things before.
  </Card>
</CardGroup>

### Link a working demo

Backers fund what they can try. Link a demo, in this order of preference:

1. **A live product URL**. The real product, even in a rough state.
2. **A TestFlight or beta link**, if you are pre-release.
3. **A demo video**: a 60-90 second walkthrough of the product in use.

<Note>Add a demo video URL in the raise flow. Edit it later from your founder dashboard.</Note>

### Write the launch post first

Draft the launch post before the round opens, for each channel where your audience is: X first, then Telegram, Discord, Farcaster, or your newsletter. A complete launch post contains:

* **What you are building**, in one or two plain sentences.
* **Why now**: what you shipped, what works, what the raise unlocks.
* **A visual**: a demo GIF or a screenshot.
* **Your Star project link.** This is the most important element: it is how a reader becomes a backer.

### Prepare your audience

* Announce the launch date and time in the days before.
* Tell your network directly. Direct messages convert better than broadcasts.
* Arrange a small group of supporters to back, reply, and repost in the first hour. Early activity brings in the next backers.

### Pick the moment

Launch when your audience is awake and your day is clear. Attention is highest in the first hours. Plan to spend the launch day in conversation.

## At launch

<Steps>
  <Step title="Publish the launch post">
    Post to X and each other channel within minutes, with your Star link in each post. Pin the X
    post to your profile.
  </Step>

  <Step title="Start a livestream">
    A livestream at launch has the highest impact of any single action. Go live on Star, and connect
    your X account to stream to both at the same time. Demonstrate the product, answer questions,
    and keep the stream open through the first hours.
  </Step>

  <Step title="Answer everything">
    Reply to each comment and question on the launch post. A question answered in public convinces
    more people than the one that asked.
  </Step>
</Steps>

## The first 48 hours

Momentum is visible during a live sale. Feed it:

* Stay responsive on X, in your channels, and on stream.
* Share each milestone: 25% and 50% of the raise, notable backers, product usage.
* Stream again on day two, for the people that missed day one.
* Thank your backers in public. They are your first owners and your first amplifiers.

## After the raise

Keep shipping in public and keep your holders close. The [Post-launch](/founders/post-launch) page covers operations after launch.

## Checklist

* [ ] X, GitHub, and LinkedIn connected
* [ ] Working demo linked
* [ ] Launch post drafted for each channel
* [ ] Network told the date and time
* [ ] Supporters arranged for the first hour
* [ ] Launch day kept clear


# Offshore DAO
Source: https://docs.star.fun/founders/offshore-dao



<video />

**Status: Available on request.** [Book a call](https://cal.com/adam-bergeman/founder-call) to set it up.

In the DAO structure, an offshore foundation holds the company IP and the token is the cap table. Ownership is fully liquid. Governance operates onchain through [decision markets](/founders/decision-markets).

## Properties

| Property     | Behavior                                                           |
| ------------ | ------------------------------------------------------------------ |
| Legal entity | An offshore DAO structure (for example BVI or Cayman) holds the IP |
| Cap table    | The token. There is no traditional equity                          |
| Governance   | Decision markets govern the treasury and major decisions           |
| Trade-off    | You cannot sell conventional equity later                          |

## How it works

1. An offshore foundation (for example a BVI company with a Cayman SPC) is created for the project.
2. The founders assign the project IP to the foundation.
3. The token becomes the ownership of the foundation. There is no separate equity class.
4. [Decision markets](/founders/decision-markets) govern the treasury: raised funds, trading fees, and revenues.

## What holders receive

The holder owns a share of the whole project, not a claim on it. Governance rights and treasury exposure travel with the token. The position is liquid from the first block.

## When to use it

Use this structure when you build fully onchain and do not plan a traditional venture path. The trade is permanent: with the IP in the foundation, there is no conventional equity to sell to a VC later. Teams that want both paths should read [Revenue share](/founders/revenue-share) or [ACE](/founders/ace).


# Overview
Source: https://docs.star.fun/founders/overview



<video />

Star is the platform for programmable ownership. You design a token, raise from the internet against it, and operate the ownership after the raise: revenue share, rewards, governance, and follow-on funding. The [CLI](/quickstart) is the primary interface for all of it.

This page maps everything that is possible on Star, now and in development.

## The token

| Capability                                                | What it does                                                                                               |
| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| [Ownership structures](/founders/structures)              | Four models: revenue share only, offshore DAO, Bedrock equity link, ACE equity conversion                  |
| [Revenue share](/founders/revenue-share) (on request)     | A fixed share of revenue, enforced by smart contract, delivered through buybacks. Works with any structure |
| [Token utility](/founders/token-utility) (in development) | Burn for access, credits, pre-sold usage                                                                   |

## The raise

| Capability                                                                   | What it does                                                                           |
| ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| [Curves](/founders/fundraising)                                              | A dynamic market sale. Liquid from the first buy. Completes at a graduation market cap |
| [Presales](/founders/presales) (on request)                                  | A fixed-price round with a set window and a minimum target                             |
| [Pre-commit campaigns](/founders/presales#pre-commit-campaigns) (on request) | Early commitments against a boost of allocation                                        |
| [Launch guide](/founders/launch-guide)                                       | The assets and the sequence that make raises close                                     |

The curve and the presale are two separate mechanisms. A round uses one or the other.

## After the raise

| Capability                                     | What it does                                                                            |
| ---------------------------------------------- | --------------------------------------------------------------------------------------- |
| [Capital unlocks](/founders/capital-unlocks)   | More capital unlocks automatically as your market cap grows, to a maximum of \$8.6M     |
| [Team vesting](/founders/team-vesting)         | Team tokens vest on a cliff and a schedule, locked and disclosed before the raise       |
| [Rewards campaigns](/founders/rewards)         | Pay ownership to the users that grow your product                                       |
| [Decision markets](/founders/decision-markets) | Markets govern the treasury and larger expenditures                                     |
| Trading fees                                   | You earn 0.5% of each secondary trade. See [Post-launch](/founders/post-launch#trading) |

## Where to start

1. Read [Choosing a structure](/founders/structures) and select an ownership model.
2. Read [Curves](/founders/fundraising) or [Presales](/founders/presales) and select a raise mechanism.
3. Install the [CLI](/quickstart) and launch, or [book a call](https://cal.com/adam-bergeman/founder-call) for a configured raise.


# Bedrock
Source: https://docs.star.fun/founders/ownership



<video />

Bedrock ties the token to real company equity: holders get exposure to the upside through a 1-30% equity backing, held as preference shares. The project treasury is protected separately, by [decision markets](/founders/decision-markets).

<Note>
  The **equity link** - the share of your equity the token is backed by - defaults to **10%** and is
  customizable from **1%** to **30%**. Your graduation market cap prices that slice, so the link
  sets the valuation you raise at: valuation = graduation market cap ÷ equity link. On the Standard
  preset (\~\$352K graduation cap), a 10% link implies a **\~\$3.5M** valuation; a 5% link implies
  **\~\$7M**. See [Curves](/founders/fundraising) for the presets.
</Note>

<CardGroup>
  <Card title="Bedrock" icon="shield-halved">
    Equity-backed tokens. An enforceable, legal claim on real company value.
  </Card>

  <Card title="Decision markets" icon="scale-balanced">
    Market-based treasury governance - backers get a board-like say over how funds are spent.
  </Card>
</CardGroup>

## Bedrock

Bedrock is a standardized legal infrastructure layer that connects tokens to real-world equity. It gives founders a fast path to launch and gives token holders enforceable protections - without taking control away from the founder.

Each project carries an explicit **equity figure** (e.g. *10% equity*) that the token is backed by.

### The structure

<CardGroup>
  <Card title="Project Company (BVI)">
    The founder's company. Holds IP, signs contracts, and runs operations.
  </Card>

  <Card title="Bedrock SPC (Cayman)">
    Holds the project's equity link (1-30%, typically 10%) via preference shares.
  </Card>

  <Card title="Bedrock Foundation">
    An independent entity that enforces token-holder rights when needed.
  </Card>
</CardGroup>

<Note>
  The standard structure is a **BVI** project company paired with a **Cayman SPC**. It can also be
  set up as a **Delaware C Corp** or another structure on request.
</Note>

Bedrock enforces a strict sequence so funds are never at risk before the company legally exists:

<Steps>
  <Step title="Fundraise">Run your raise. Funds are held securely during the raise.</Step>

  <Step title="KYC + incorporation (after a successful raise)">
    Once your raise succeeds, complete the KYC and incorporation form from your founder dashboard.
    The company is then incorporated (a BVI project company with a Cayman SPC). Incorporation costs
    **\~\$7.5K** and is funded by the raise itself, not from your take-home amount. If incorporation
    fails, funds are refunded and the token never goes live.
  </Step>

  <Step title="Token goes live">The equity-backed token goes live and starts trading.</Step>
</Steps>

### Ownership and control

* **Founders keep everything outside the equity link (90% at the standard 10% link) and full operational control.**
* **Bedrock holds minority preference shares** with no day-to-day control.

Bedrock only intervenes in cases of **fraud, misuse of funds, or unauthorized value extraction**. It does *not* intervene in failed startups, token price drops, or normal business decisions.

<AccordionGroup>
  <Accordion title="What token holders get">
    * A real legal counterparty behind the token
    * IP legally owned by the company (not the founder personally)
    * Enforceable protections via the Foundation
    * A funded litigation mechanism, at no cost to holders

    If a founder commits fraud, there is recourse. If the company is acquired, value flows through equity. If the project simply fails, there are no guarantees - it's still a startup.
  </Accordion>

  <Accordion title="The buyout mechanism">
    Bedrock aligns tokens with equity through a built-in acquisition path:

    * Acquire **30%+** of tokens, then buy the remaining supply at a premium, then receive equity.
    * Acquire **100%** of tokens, then receive the full Bedrock equity stake.

    Any acquisition flows through the token, so holders benefit from buyout premiums - and founders can cleanly exit the structure if needed.
  </Accordion>

  <Accordion title="Founder constraints">
    Founders must assign all IP to the company, keep company and personal funds separate, avoid regulated activities (e.g. custody or exchange) without licenses, and stay compliant with local tax obligations.
  </Accordion>
</AccordionGroup>

## Decision markets

Decision markets govern the project treasury on every launch, in every ownership structure. They have their own page: [Decision markets](/founders/decision-markets).


# Post-launch
Source: https://docs.star.fun/founders/post-launch



<video />

The raise is the start. After launch, your holders are your distribution: keep them informed and give them work to do.

## Keep holders informed

* Post progress updates on X.
* Livestream on Star for product updates, AMAs, and milestones.

Informed holders stay engaged, and engaged holders drive the trading volume that pays your 0.5% fee.

## Give holders work

Your holders are aligned owners, not an audience:

* Ship in public and collect their feedback before a wide release.
* Ask them to amplify launches and milestones. Ownership converts into distribution.
* Reward the most active ones through [rewards campaigns](/founders/rewards).

## Time announcements to milestones

Your [capital unlocks](/founders/capital-unlocks) and your [trading fees](/founders/post-launch#trading) both reward growth. Align releases, announcements, and streams with your market-cap milestones.

## Govern with your backers

Larger treasury decisions run through [decision markets](/founders/decision-markets). Bring holders into those decisions. That is what keeps capital and incentives aligned.

## Manage your project

Edit your project from the founder dashboard: description, website and links, hero and banner media, team members, and socials. After the token is live, onchain metadata (name, ticker, links) changes through proposals. Your token's mint address and liquidity pool address are in the **Details** tab of your Star project page.

## Trading

Your token trades on any Solana DEX after graduation. You earn 0.5% of each trade. Star charges its own fee on trades separately - see [Fees](/about/fees).

## Follow-on fundraising

You can raise again later through proposal-approved minting: the token issues additional supply to fund the next stage. The proposal runs through [decision markets](/founders/decision-markets), with the amount and the valuation stated.


# Presales
Source: https://docs.star.fun/founders/presales



<video />

**Status: Available on request.** [Book a call](https://cal.com/adam-bergeman/founder-call) to configure one. CLI support is in development.

A presale is a fixed-price round for participants that you select: your waitlist, your users, your community. The presale and the [curve](/founders/fundraising) are two separate mechanisms. A round uses one or the other, not both.

The curve gives speed and immediate liquidity. The presale gives certainty: one price, a set window, a minimum target.

## Mechanics

| Parameter        | Behavior                                                          |
| ---------------- | ----------------------------------------------------------------- |
| Price            | Fixed. The same for each participant                              |
| Window           | A set deposit period, usually 5 days                              |
| Minimum target   | If the target is not met, all deposits are refunded automatically |
| Oversubscription | Excess deposits are refunded pro rata                             |
| Lock periods     | Configurable for each allocation tier                             |
| Token supply     | Fixed at 1,000,000,000                                            |

Participants deposit USDC during the window. Funds are held until launch. After a successful launch, participants claim their tokens.

## Pre-commit campaigns

You can open a pre-commit campaign before the round. Participants commit early and receive a **boost of allocation**: a larger share of the round. You go live with known demand.

## Parameters you set

| Parameter                | What it sets                                                          |
| ------------------------ | --------------------------------------------------------------------- |
| Minimum raise            | The floor. Below it, all participants are refunded                    |
| Treasury allowance       | Your operating budget, transferred on a schedule after the raise      |
| Public allocation %      | The share of supply sold. A smaller share sets a higher starting FDV  |
| Liquidity allocation     | A part of the raised USDC, reserved for post-launch trading liquidity |
| Team performance package | Team tokens that unlock at market-cap milestones                      |


# Revenue share
Source: https://docs.star.fun/founders/revenue-share



<video />

**Status: Available on request.** [Book a call](https://cal.com/adam-bergeman/founder-call) to configure one. CLI support is in development.

A revenue share is a fixed percentage of your sales. You commit to it before the round opens. A smart contract enforces it. Holders receive the value through onchain buybacks of your token.

## Standalone or combined

A revenue share works with **any ownership structure**:

* **On its own**: the token carries the revenue share and nothing else. Your Delaware C-Corp, your cap table, and your IP are not changed. This is the simplest structure on Star.
* **Next to a structure**: a [Bedrock](/founders/ownership), [DAO](/founders/offshore-dao), or [ACE](/founders/ace) launch can commit a revenue share as well.

## Configuration

| Parameter        | Options                                                               |
| ---------------- | --------------------------------------------------------------------- |
| Share of revenue | A fixed percentage. Set before launch. Not adjustable after launch    |
| Trigger          | Day one, a calendar date, or a revenue milestone (example: \$50K MRR) |
| Delivery         | Onchain buybacks of your token                                        |
| Visibility       | Each execution appears on a public dashboard                          |

## Program design

| Decision    | Options                                              | Note                                                |
| ----------- | ---------------------------------------------------- | --------------------------------------------------- |
| Disposition | Burn the bought tokens, or hold them in the treasury | Set per raise                                       |
| Cadence     | Continuous, or batched on a schedule                 | Batched execution reduces price impact per purchase |
| Venue       | The token's own liquidity pool                       | The same pool that the raise seeds                  |

A stronger commitment from day one catalyzes more distribution early. A trigger at a revenue milestone keeps early cash in the company. Both are valid; the market prices the difference.

## How equity investors see it

The revenue share is a fixed, disclosed obligation. Equity investors price it into your valuation, in the same way that they price a licensing fee or a royalty. Nothing else on the cap table changes, and later venture rounds proceed normally.

## Why buybacks

A buyback delivers the same value as a cash distribution, but through the market. Holders see the buy pressure and decide when to sell. Value accrues to the token. No dividend-type payment occurs.


# Rewards campaigns
Source: https://docs.star.fun/founders/rewards



<video />

A rewards campaign pays your token to the people that grow your product. You allocate a fixed amount of your token to the campaign, define which actions earn it, and Star computes, escrows, and distributes the rewards. Campaigns run in the CLI and the dashboard.

## Two campaign modes

| Mode               | What participants earn                             | Use it for                                                                 |
| ------------------ | -------------------------------------------------- | -------------------------------------------------------------------------- |
| **Points**         | A score and a leaderboard rank                     | Competitions: reward the top referrers or the most active users at the end |
| **Action rewards** | A fixed amount of your token per qualifying action | Direct incentives: every signup, order, or referral earns a set amount     |

A points campaign converts to token payouts at the end, from the campaign budget. An action-reward campaign pays from a funded action pool, at a fixed rate per action, until the pool or the caps are reached.

## How a campaign runs

1. **Fund it.** You allocate an exact amount of your token before earning begins. The tokens sit in a program-controlled campaign vault. You cannot withdraw them after earning starts, and Star cannot transfer them outside committed rewards.
2. **Define the actions.** Each action has a type (`unique`: once per participant, or `count`: repeatable), a reward or point value, a per-participant cap, and a campaign cap.
3. **Participants earn.** Earning is never paused during a campaign.
4. **Participants claim.** A campaign-wide claim window opens. Participants select and verify a Solana wallet at claim time, not before.
5. **Leftovers return.** Unclaimed tokens return to your project treasury after the claim window closes.

One campaign earns at a time per project. An older campaign can remain claimable while a newer one earns.

## What participants need

Nothing. A participant earns without a Star account and without a wallet. They claim later, through your product, with a wallet they verify at that moment. You can also nominate rewards directly to an email address or an X handle, from a separate budget lane; only a user authenticated with that identity can claim them.

## Connecting your product

Actions are verified server-side in your own app, so a reward is paid only when the real action succeeded:

1. Create the campaign in the dashboard and download the integration bundle.
2. Hand the bundle to your coding agent. The [`@star-factory/sdk-launch-rewards`](https://www.npmjs.com/package/@star-factory/sdk-launch-rewards) package ships an agent skill that wires your app: your agent finds the server-side success facts (a new account row, a completed order, an accepted referral) and connects them to the campaign actions.
3. Your server signs and delivers each qualifying event. Duplicate events are rejected by design, and caps are enforced by Star.

Your users' identities stay in your database. Star receives no emails, handles, wallets, or IP addresses from your app. Participant scores and a campaign leaderboard are available to your app through the same SDK.

## Design notes

* Budgets are absolute token amounts, not percentages of supply.
* A campaign that pays more in rewards than the revenue its actions bring in is a marketing cost. One that pays less funds its own growth. Price the action values against the value of the action.
* Fund campaigns from the reward reserve you allocate at launch, or top them up later.


# Choosing a structure
Source: https://docs.star.fun/founders/structures



<video />

A Star token can have one of four ownership structures. The structure sets what the token legally contains, what remains on your cap table, and which investors you can accept later. The structure is fixed before the round opens.

| Model                                                 | What the token contains                                       | Your equity                 |
| ----------------------------------------------------- | ------------------------------------------------------------- | --------------------------- |
| [Revenue share](/founders/revenue-share) (on request) | A revenue share, enforced by smart contract, and nothing else | Not changed                 |
| [Offshore DAO](/founders/offshore-dao) (on request)   | The company. The token is the cap table                       | Replaced by the token       |
| [Bedrock](/founders/ownership)                        | An equity backing of 1-30%                                    | You keep 70-99% and control |
| [ACE](/founders/ace) (on request)                     | Rights that convert tokens into equity                        | Diluted only on conversion  |

## How to choose

* To raise venture capital and issue a token: select **revenue share** on its own, or **Bedrock**. Equity investors price the obligation. The rest of the cap table is not changed.
* To operate fully onchain with no traditional equity: select the **offshore DAO**.
* To let your community convert into equity later: select **ACE**.

A revenue share is not exclusive to one model. A [Bedrock](/founders/ownership), [DAO](/founders/offshore-dao), or [ACE](/founders/ace) launch can commit a revenue share as well - see [Revenue share](/founders/revenue-share).

Each model has its own page with the full mechanics.


# Team vesting
Source: https://docs.star.fun/founders/team-vesting



<video />

Vesting terms are locked and disclosed before anyone buys. The team allocation is 20% of supply on a standard curve round. It vests linearly over 9 months, after a 3-month cliff. Tokens are transfer-locked until they vest.

## Standard schedule

| Parameter       | Value                                |
| --------------- | ------------------------------------ |
| Team allocation | 20% of the 1B supply                 |
| Cliff           | 3 months                             |
| Vesting         | Linear over 9 months after the cliff |
| Transfers       | Locked until vested                  |
| Disclosure      | Public before the raise opens        |

## Performance packages

On curated presales, team tokens can also unlock against market-cap milestones instead of time. The milestones are set before the raise. See [Presales](/founders/presales#parameters-you-set).

## Why vesting is strict

Buyers price team overhang. A locked, disclosed schedule removes the first question every investor asks. A smaller team allocation generally raises better than a larger one.


# Token utility
Source: https://docs.star.fun/founders/token-utility



<video />

**Status: In development.** CLI support is planned. This page shows the patterns it will launch with.

Utility is what the token does inside your product when a user holds it or spends it. A token with utility is a claim on your growth and a method to use your product.

## Patterns

| Pattern         | Behavior                                                                  |
| --------------- | ------------------------------------------------------------------------- |
| Burn for access | A user burns the token to get access to a plan, a feature, or an API call |
| Credits         | The token is your in-product currency. Usage is priced in it              |
| Pre-sold usage  | The raise is also a pre-sale. Buyers hold future usage of the product     |

Burn-based utility does not make your product crypto-only. It can operate next to standard billing as one more payment method.

Configure utility terms before launch, with the rest of the token design. Read [Ownership structures](/founders/structures).


# Quickstart
Source: https://docs.star.fun/quickstart



<video />

The CLI is the primary interface to Star. Use it to design a token, open a round, and operate rewards campaigns. The dashboard shows the same data, but the CLI controls the platform.

## Install

Requires Node.js 22 or 24. Install the exact current release, `0.4.0`:

```bash theme={null}
npm install --global @star-factory/launch-cli@0.4.0
star --version   # prints 0.4.0
```

Or run it without installing:

```bash theme={null}
npx -y @star-factory/launch-cli@0.4.0 --help
```

Pin the version. An unpinned `@star-factory/launch-cli` resolves the npm `latest` tag, which can lag the current release and hand you an older command surface.

## Launch from the terminal

Every launch carries four founder decisions, and the CLI defaults none of them: the raise tier, the equity link percent, whether to create the compensation-band plan, and whether to reserve the Launch Rewards allocation. Start by reading what the deployment requires, then authorize, preview, and launch.

```bash theme={null}
# 1. Read the requirements: the four decisions, Star's prompt for each, and what every tier raises and graduates at
star launch requirements

# 2. Authorize this device (prints a star.fun URL + user code)
star launch login

# 3. Preview exactly what will be sent (no mutation)
star launch create \
  --name "My Startup" --ticker MYSTAR --website https://mystartup.com --icon ./logo.png \
  --tier 25k --equity-link 10 --compensation-bands --launch-rewards \
  --dry-run --json

# 4. Launch for real and wait until the token is live
star launch create \
  --name "My Startup" --ticker MYSTAR --website https://mystartup.com --icon ./logo.png \
  --tier 25k --equity-link 10 --compensation-bands --launch-rewards \
  --yes --wait-until live --timeout 30m --json
```

The tier ids, equity-link bounds, and each tier's economics come from `star launch requirements`, never from the CLI itself. Leave a decision out and `create` asks for it on a terminal; with `--json` it returns `DECISION_REQUIRED` naming the unanswered questions. `--compensation-bands` and `--launch-rewards` each have a `--no-` form.

Production is the default. To target staging, pass `--env staging` on every command.

## Use it from Codex or Claude

The package is three pieces: the `star` CLI, the `launch-token-on-star` skill (the interview that asks the four founder decisions in Star's words), and the local MCP server (the tools). `mcp add` alone registers tools. It does not install the skill. The native plugin that would do both is not listed in the Codex or Claude marketplaces yet, so install all three:

**Claude Code**

```bash theme={null}
npm install --global @star-factory/launch-cli@0.4.0
mkdir -p ~/.claude/skills
cp -R "$(npm root -g)/@star-factory/launch-cli/skills/." ~/.claude/skills/
claude mcp add --scope user star -- npx -y @star-factory/launch-cli@0.4.0 mcp serve
claude mcp list
```

`--scope user` makes the MCP server available in every project. Claude's default is the current project only.

**Codex CLI**

```bash theme={null}
npm install --global @star-factory/launch-cli@0.4.0
mkdir -p ~/.agents/skills
cp -R "$(npm root -g)/@star-factory/launch-cli/skills/." ~/.agents/skills/
codex mcp add star -- npx -y @star-factory/launch-cli@0.4.0 mcp serve
codex mcp list
```

Codex writes the MCP entry to `~/.codex/config.toml`, so it is available in every project.

If the CLI is already installed at `0.4.0`, skip the `npm install` line and keep the skill copy plus `mcp add`.

**Cursor, or any client with an `mcp.json`**

```json theme={null}
{
  "mcpServers": {
    "star": {
      "command": "npx",
      "args": ["-y", "@star-factory/launch-cli@0.4.0", "mcp", "serve"]
    }
  }
}
```

Then copy the skills from the installed package into that host's skill directory the same way. Every MCP tool accepts a per-call `environment` (`production` or `staging`); without one it targets production.

## Launch with your agent

1. Ask the agent to launch. Example: "Launch my token on Star. Name My Startup, ticker MYSTAR, website mystartup.com."
2. The agent reads the launch requirements and asks you the four founder decisions in Star's own words. It never picks them for you.
3. The agent starts a secure sign-in. Open the link, sign in with your Star account, and enter the code.
4. Star derives your launch wallet and reserves a Star vanity mint.
5. Examine the exact payload and approve it. Nothing launches before you approve.

Agents do not have access to wallet secrets or keypairs.

## Capabilities

The CLI launches tokens, opens [curve rounds](/founders/fundraising), and operates [rewards campaigns](/founders/rewards) today. The rest is on its way:

| Capability                                            | Status                                    |
| ----------------------------------------------------- | ----------------------------------------- |
| Presales and pre-commit campaigns                     | On request. CLI support is in development |
| Token utility                                         | In development                            |
| [Revenue share](/founders/revenue-share) and buybacks | On request. CLI support is in development |

**On request**: we configure the feature with you. [Book a call](https://cal.com/adam-bergeman/founder-call).

**In development**: the documentation shows the planned behavior. You can plan your integration now.

## Example session

```text theme={null}
> design a token with 20% revshare and in-app credit utility
> open a round on Star
> reward the top 100 referrers weekly from the rewards pool
```

The CLI validates your configuration. It shows the full plan and waits for your approval before launch. Read [Curves](/founders/fundraising) for the raise mechanics.

## Give these docs to your agent

The docs are agent-readable. Point your agent at [docs.star.fun/llms.txt](https://docs.star.fun/llms.txt) for the index, or [llms-full.txt](https://docs.star.fun/llms-full.txt) for the full text. Append `.md` to any page URL to get that page as plain markdown. The full command surface is in the [CLI reference](/reference/cli).


# CLI reference
Source: https://docs.star.fun/reference/cli



<video />

The command surface of [`@star-factory/launch-cli`](https://www.npmjs.com/package/@star-factory/launch-cli) `0.4.0`. Install with `npm install --global @star-factory/launch-cli@0.4.0`, or run one-off with `npx -y @star-factory/launch-cli@0.4.0 <command>`. Every command accepts `--json` and returns one stable envelope per command (`schemaVersion: star.launch-agent/v2`) carrying `ok`, `command`, the `environment` that answered, `data`, and `error`.

## Environment

Production is the default and needs no selector. `--env staging` targets staging and `--api-url <origin>` targets a custom origin; both are global, may appear before or after the command, and apply to that one invocation only. Nothing is remembered between commands, so a staging session carries `--env staging` on every command (or exports `STAR_ENV=staging`). Tokens are stored per origin, so each environment is authorized separately.

## Launch commands

| Command                         | Purpose                                                                                                                                                   |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `star launch requirements`      | Unauthenticated read of the deployment's launch contract: required fields, the four founder decisions with Star's prompts, and tier economics. Start here |
| `star launch login`             | Authenticate with a scoped Star agent token for the selected environment                                                                                  |
| `star launch whoami`            | Show the current session and launch wallet                                                                                                                |
| `star launch x-verify`          | Prove an X handle. Unverified handles are dropped at launch                                                                                               |
| `star launch validate`          | Validate a launch configuration without a mutation                                                                                                        |
| `star launch create`            | Create the launch. Supports `--file launch.json`, `--dry-run`, `--yes`, `--wait-until live`, `--timeout`, `--idempotency-key`                             |
| `star launch status <launchId>` | Launch status. Supports `--watch`, `--wait-until`, `--timeout`                                                                                            |
| `star launch logout`            | End the session for the selected environment (`--all` for every environment)                                                                              |

### Founder decisions

`star launch create` and `star launch validate` carry four founder decisions. None has a default: on a terminal `create` asks for whatever you left out; with `--json`, off a terminal, or from a file that omits one, it returns `DECISION_REQUIRED` naming the unanswered questions.

| Flag                                               | Decision                                                                      |
| -------------------------------------------------- | ----------------------------------------------------------------------------- |
| `--tier <id>`                                      | Raise tier: one of the ids `star launch requirements` lists. Locked at launch |
| `--equity-link <percent>`                          | Equity link: a whole percent within the published bounds. Locked at launch    |
| `--compensation-bands` / `--no-compensation-bands` | Create the complete, all-or-none compensation-band plan, or none              |
| `--launch-rewards` / `--no-launch-rewards`         | Reserve the Launch Rewards allocation for founder-created campaigns, or none  |

The tier ids, equity-link bounds, and the token amounts each choice reserves are published by `star launch requirements` and returned in the `--dry-run` preview. The CLI ships no economics of its own.

Recommended sequence: `launch requirements` → `launch login` → `launch create … --dry-run --json` → review → `launch create … --yes --json`.

## Rewards commands

| Command                           | Purpose                                                  |
| --------------------------------- | -------------------------------------------------------- |
| `star rewards login`              | Authenticate with rewards-management scope               |
| `star rewards requirements`       | Machine-readable campaign field requirements. Start here |
| `star rewards validate`           | Validate a campaign configuration without a mutation     |
| `star rewards create`             | Create the campaign                                      |
| `star rewards integration-bundle` | Download the partner integration bundle                  |
| `star rewards action-setup`       | Configure an action-reward pool                          |
| `star rewards action-status`      | Pool funding and activation state                        |
| `star rewards action-activate`    | Activate a funded pool                                   |
| `star rewards publish`            | Publish the campaign                                     |
| `star rewards participant-score`  | Read one participant's score                             |
| `star rewards leaderboard`        | Read the campaign leaderboard                            |

## MCP server

```bash theme={null}
star mcp serve
```

Starts the local stdio MCP server. The server is launch-focused; rewards management is CLI-only today. Tools:

| Tool                       | Purpose                                                                                                     |
| -------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `star_auth_begin`          | Start device auth. Returns `authorizeUrl` and `userCode`                                                    |
| `star_auth_poll`           | Poll once. Returns `AUTH_PENDING` until the user approves                                                   |
| `star_auth_status`         | Current session: `environment`, `authenticated`, `launchWallet`, scopes                                     |
| `star_launch_requirements` | The deployment's requirements: decisions with Star's own prompts, tier economics, policies. Unauthenticated |
| `star_launch_validate`     | Validate a configuration without a mutation. Reports `missingDecisions`                                     |
| `star_launch_token`        | Create the launch. Carries the four decisions; requires `confirmed: true` unless `dryRun`                   |
| `star_launch_status`       | Status by `launchId`: `status`, `baseMint`, failure code                                                    |

Every tool that talks to Star accepts a per-call `environment` (`production` or `staging`) or `apiUrl`; without one it uses the environment `star mcp serve` was started with. Every result names the `environment` it answered for. A call that omits a founder decision is answered with `DECISION_REQUIRED` and the unanswered questions in `error.details.questions`, never a default.

Agents should parse `structuredContent`, not scrape text. Invalid arguments return `INVALID_TOOL_INPUT` before any network call.

### Use it from Codex or Claude

`mcp add` registers the tools. It does not install the skill. Until the `star-launch-agent` plugin is listed, install the CLI, copy the skills, then register MCP. The same steps, with host-specific paths, are in the [Quickstart](/quickstart#use-it-from-codex-or-claude).

```bash theme={null}
# Claude Code — CLI + skill + MCP (user scope = every project)
npm install --global @star-factory/launch-cli@0.4.0
mkdir -p ~/.claude/skills
cp -R "$(npm root -g)/@star-factory/launch-cli/skills/." ~/.claude/skills/
claude mcp add --scope user star -- npx -y @star-factory/launch-cli@0.4.0 mcp serve

# Codex CLI — same three steps; skills live in ~/.agents/skills
npm install --global @star-factory/launch-cli@0.4.0
mkdir -p ~/.agents/skills
cp -R "$(npm root -g)/@star-factory/launch-cli/skills/." ~/.agents/skills/
codex mcp add star -- npx -y @star-factory/launch-cli@0.4.0 mcp serve
```

## Errors

| Code                                               | Action                                                                        |
| -------------------------------------------------- | ----------------------------------------------------------------------------- |
| `AUTH_REQUIRED`, `TOKEN_REVOKED`, `SCOPE_REQUIRED` | Run `star launch login` or `star rewards login`, then retry                   |
| `DECISION_REQUIRED`                                | Ask the founder the listed questions, then retry with every decision supplied |
| `CONFIRMATION_REQUIRED`                            | Ask for approval, then retry with `--yes` (CLI) or `confirmed: true` (MCP)    |
| `INVALID_TOOL_INPUT`                               | Fix the arguments. No network call was made                                   |

Security model: agents never hold wallet secrets or keypairs, and nothing launches until you approve the exact payload. See the [Quickstart](/quickstart).


# Glossary
Source: https://docs.star.fun/reference/glossary



<video />

One definition per term, used consistently across these docs.

| Term                  | Definition                                                                                           |
| --------------------- | ---------------------------------------------------------------------------------------------------- |
| Bonding curve         | A sale where the token price rises as more is bought. Liquid from the first buy                      |
| Graduation market cap | The valuation at which a curve sale completes and the token migrates to a live trading pool          |
| Migration             | The move from the bonding curve to a live trading pool, at graduation                                |
| Presale               | A fixed-price round with a set window and a minimum target                                           |
| Pre-commit campaign   | Early commitments before a presale, rewarded with a boost of allocation                              |
| Ownership structure   | The legal model that sets what the token contains: revenue share only, offshore DAO, Bedrock, or ACE |
| Revenue share         | A fixed percentage of sales, enforced by smart contract, delivered through buybacks                  |
| Buyback               | An onchain purchase of the project token, executed by the revenue-share contract                     |
| Equity link           | The share of company equity that backs a Bedrock token, from 1% to 30%                               |
| Decision market       | A market that prices a treasury proposal. The outcome decides whether the action executes            |
| Treasury              | The project account that holds raised funds, fees, and revenues, governed by decision markets        |
| Monthly allowance     | The scheduled release of raised funds from the treasury to the team                                  |
| Capital unlock        | Capital that unlocks automatically when the market cap reaches a milestone                           |
| Team vesting          | The lock and release schedule of the team allocation                                                 |
| Rewards campaign      | A funded program that pays the project token for qualifying user actions                             |
| Action pool           | The funded budget of an action-reward campaign                                                       |
| Claim window          | The period in which campaign participants can claim earned tokens                                    |
| TGE                   | Token generation event: the moment the token goes live                                               |
| Atoms                 | The smallest indivisible unit of a token amount                                                      |