> ## Documentation Index
> Fetch the complete documentation index at: https://docs.artstarex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Launchpad Subscription & Tokenization

> ArtStar primary-market module overview: the end-to-end workflow and underlying mechanisms from initial artwork issuance to user subscription

## Overview

Launchpad is ArtStar’s primary-market module. It is responsible for the initial issuance of artwork assets and user subscriptions. Users pay with stablecoins and, once eligibility requirements are met, receive on-chain asset shares.

Tokenization is the underlying representation of this process. It converts high-value, low-liquidity artworks into computable, traceable, and distributable on-chain units of entitlement.

## Core Mechanisms

<AccordionGroup>
  <Accordion title="Launchpad’s Core Responsibilities" icon="rocket">
    In ArtStar, Launchpad is one of the platform’s most critical conversion entry points. It primarily handles:

    * **Information display**: artwork project details, issuance status, price, and remaining allocation
    * **Eligibility checks**: whether the user meets subscription requirements
    * **Transaction execution**: stablecoin approval and purchase transactions
    * **State synchronization**: post-transaction updates to asset status and the user’s holdings
  </Accordion>

  <Accordion title="Why Tokenization Matters" icon="coin">
    Tokenization is not mere presentation or packaging. It is the foundation of
    ArtStar’s product mechanism: \* Shifts art investment from whole-asset
    ownership to fractional participation \* Provides a standardized on-chain
    representation for primary issuance \* Establishes a structured basis for
    holdings queries and state synchronization \* Enables subsequent liquidity
    provisioning and secondary-market trading
  </Accordion>

  <Accordion title="Share Calculation Logic" icon="calculator">
    The number of shares is typically determined by the payment amount and the unit price.

    ```text Share calculation formula theme={null}
    Shares = Payment Amount / Unit Price
    ```

    <Info>
      If there are minimum purchase units, integer-share constraints, or precision differences, the frontend display logic must remain consistent with on-chain rules.
    </Info>
  </Accordion>
</AccordionGroup>

## Subscription Flow Guide

### Prerequisites

Users usually need to meet the following conditions before they can proceed with a valid subscription. If any item is not satisfied, the frontend should clearly block the flow and show an explicit prompt.

<Card title="Checklist" icon="list-check">
  * Wallet connected \* Logged in or account identity recognized \* Switched to
    the target network \* KYC completed \* Whitelist or eligibility requirements met
  * Sufficient stablecoin balance in the wallet \* Stablecoin allowance meets
    requirements
</Card>

### Two-Step Purchase Flow

<Steps>
  <Step title="Step 1: Approve (Authorization)">
    The user first calls the stablecoin contract’s approval method, allowing the
    target contract to deduct the required amount within the approved limit.

    <Warning>
      This step grants spending permission and does not mean the purchase is
      complete.
    </Warning>
  </Step>

  <Step title="Step 2: Mint / Purchase (Subscription/Mint)">
    After approval succeeds, the user calls the target asset contract’s purchase
    or mint method. Based on the payment amount, price, and rules, the contract
    issues the corresponding shares to the user.

    <Check>
      The subscription is only completed after this step, when the user receives
      the tokenized shares.
    </Check>
  </Step>
</Steps>

## Implementation Focus

### Frontend Handling

At minimum, the frontend should handle the following key steps during subscription:

* **Data reads**: current price and remaining allocation, user stablecoin balance, and stablecoin allowance
* **Interaction control**: button text/clickability based on state; sequencing approval and purchase transactions
* **Error handling**: user signature rejection, insufficient balance, network errors, and other exceptions
* **State sync**: refresh holdings and progress state after transactions

### Common Failure Causes

When a user is blocked during subscription, investigate the following common causes:

<AccordionGroup>
  <Accordion title="User / State Causes">
    * KYC not approved \* Whitelist not approved \* The offering is sold out or
      has ended
  </Accordion>

  <Accordion title="Asset / Transaction Causes">
    * Insufficient stablecoin balance \* Insufficient allowance \* Wrong wallet
      network \* User rejected the signature \* Contract execution reverted
  </Accordion>
</AccordionGroup>

## Pitfalls (Common Mistakes)

<Callout type="warning" title="Approval success does not mean purchase success">
  Many users assume that once Approve is done, the purchase is complete. The
  frontend should clearly differentiate “Approval completed” from “Subscription
  completed” and provide corresponding guidance.
</Callout>

<Callout type="danger" title="Decimal handling must be consistent">
  The stablecoin and the target asset may have different `decimals`. If the
  display layer and contract-interaction layer handle decimals inconsistently,
  the UI may look correct while the on-chain transfer amount is wrong.
</Callout>

<Callout type="info" title="Do not rely on local UI state alone">
  After a transaction is broadcast, the final outcome still depends on block
  confirmations and backend synchronization. Do not assume the asset is credited
  based only on local frontend variables; listen for on-chain confirmations or
  refresh via an API.
</Callout>

***

Launchpad subscription and tokenization are the most critical business flows in ArtStar. They unify user eligibility, stablecoin payments, on-chain execution, and asset mapping into one consistent process—where the platform’s value is truly realized.