> For the complete documentation index, see [llms.txt](https://takes.gitbook.io/takes-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://takes.gitbook.io/takes-docs/creators/review-and-launch.md). # Review and launch Publishing saves your basket as a public idea. Deploying creates a public pool and deposits its seed USDC. ## Publish your basket New basket publication requires 10,000 USDC in lifetime completed buy and sell volume for your wallet, across all baskets and supported chains. Volume counts gross settled requests before fees; pending and cancelled requests do not count. Create shows your completed and remaining volume, with **Refresh eligibility** to check again. Recent settlements may take time to appear. If you have not reached the minimum, you can instead **Apply for creator whitelist** with your X profile and a short reason. Applications are reviewed by hand; Create shows the pending, approved or rejected decision and any reviewer note. Approval unlocks publication; after a rejection you can apply again. Testnet, development environments and approved wallets are exempt. This requirement applies to publishing a new basket. You can deploy a pool from an existing public basket or edit a basket you already authored without meeting it. Connect your wallet, open Create, and sign in. The sign-in signature moves no funds. Complete your [basket design](/takes-docs/creators/design-a-token.md#design-a-basket), including the thesis and icon, then choose Publish basket. Publication needs no deposit or on-chain transaction. Edits stay only in the open form until you publish. Leaving or reloading discards them; returning to Create starts blank. A failed publication keeps the form available for retry. Your baskets lists published baskets only. To update a published basket, choose Edit basket and Publish changes. This creates one new version. Existing pools keep their original version and icon. ## Review and deploy 1. Choose **Create pool** in Your baskets, or **Create your own pool** on a public basket page. 2. Choose the network, each asset’s leverage, and initial funding in USDC. 3. Check generated names, inherited icon, estimated exposure, fees, and minimum funding. Keep enough balance for funding and network gas. 4. Choose **Deploy pool**. Preparation and funding checks run automatically before wallet confirmation. 5. Confirm the required wallet prompts. If fees change, check the updated visible amounts and choose Deploy pool again. Initial funding, fees, net funding and estimated trading equity stay visible; expand **Estimated exposure** for the strategy breakdown. If USDC approval is required, the app waits for its confirmation, refreshes allowance and fees, then opens deployment automatically while the operation is unchanged. Approval and deployment remain separate wallet transactions. Rejecting a prompt or leaving the page stops continuation. Funding approval and pool deployment have separate transaction records. Expand **Transaction details** to inspect a hash or explorer link. Known transactions resume tracking after reload; a restored unsent workflow requires an explicit Deploy action. An unknown wallet outcome remains paused until it can be determined, preventing duplicate deployment. On Arc, the creation transaction includes the seed as native USDC. On HyperEVM, Ethereum, Base, Arbitrum, and Monad, the factory takes approved USDC. Keep the network's [gas token](/takes-docs/reference/supported-networks.md#networks) as well as your seed balance. The app prepares the transaction for your selected network. The exposure preview uses the current mint fees and a 1 USDC activation reserve. Launch requires sufficient seed for the current fee and lot estimate. A later market move or execution cost can still leave a small leg below the trade floor. Creation fixes the chain, name, symbol, weight model, basket, and initial seed. Wallet approval submits the transaction; wait for successful chain confirmation before treating the token as created. ## Activation After creation, Takes sets up the trading account and its trading permissions. The activation card shows **Waiting for activation**, **Activating your pool**, **Open for investment**, or **Activation needs attention**. Choose **Refresh status** to check again or **View pool** to open the pool page. Once deployment is confirmed and saved, you can leave while activation continues. Creation, activation, seed settlement and delivery are separate steps. Creator seeds include a signed settlement fee with activation gas. Tokens are delivered automatically after settlement, with a [manual claim fallback](/takes-docs/holders/claim-tokens-or-usdc.md#claim-tokens-or-usdc). “Live” means account setup is complete. It does not guarantee that every target trade has filled. ## If launch does not finish If creation succeeded but connecting the pool page failed, choose **Retry connection** using the existing creation transaction. Do not deploy again. If activation fails, keep the creation hash and error. Cancelling an accepted seed buy request before execution starts returns its USDC but prevents the normal activation flow from continuing. Seed mint fees and account costs apply. See [Fees and limits](/takes-docs/reference/fees-and-limits.md#fees-and-limits). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://takes.gitbook.io/takes-docs/creators/review-and-launch.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.