# Lumen Rise documentation LumenRise is live on Base with bonding curves, presales, and auctions. The Base app is audited and has done more than $10k in volume. Stellar is the expansion network; its factory, vault, and reputation contracts are documented here. Copy the Base factory from /deployments/base. Stellar Mainnet factory and registry addresses are on /deployments/mainnet. Historical Stellar Testnet fixtures must not be used as current addresses. # Introduction Route: / LumenRise is live on Base. The launchpad supports bonding curves, presales, and auctions. The Base app is in production, the contracts are audited, and the launchpad has done more than $10k in volume. We are expanding to Stellar next. Same product, same launch formats, second network. :::info[Where to launch] Base is the live network. Use it for production launches. Stellar is the expansion: factory and reputation contracts are documented here, and that network is still being brought up to the Base feature set. ::: ## How Launchpad works A creator picks a network, a launch format, the token, supply split, quote asset, opening time, pricing, and vesting. The factory deploys a dedicated vault and locks the launch supply there. Participants then trade, bid, or join the presale under the published terms. Intended flow: issue an ERC-20 on Base or a Stellar asset, lock launch supply in a dedicated vault, then open a bonding curve, auction, or presale. Team tokens follow their own vesting schedule. On Base the launch token is an ERC-20 and the quote asset is USDC. On Stellar the launch token is a Stellar asset, reached from contracts through the Stellar Asset Contract, with XLM or USDC as the quote. ## Three ways to launch | Format | Pricing and participation | Status | | --- | --- | --- | | [Bonding curve](/launches/bonding-curves) | A reserve formula changes the price as tokens are bought and sold. Trading opens at the start date and continues until graduation. | Live on Base | | [Auction](/launches/auctions) | Participants submit bids. Higher-priced bids get allocation priority. Bid during the window, settle, then claim. | Live on Base | | [Presale](/launches/presales) | The creator sets a fixed price. Commit quote tokens, take a final allocation, and claim under the published vesting terms. | Live on Base | Stellar launches use the same three formats as that network comes online. The Stellar factory source is farthest along on bonding curves. ## Reputation that travels On Stellar, connect a Stellar account, X, and GitHub to build **onchain**, **social**, and **GitHub** reputation. Projects can use those signals for access rules or allocation priority. Other apps can reuse the same registry. This is part of the Stellar expansion. Base launches can still use the access rules you publish on the launch page. [Understand reputation](/reputation/overview) or [define custom criteria](/reputation/criteria). ## Find your starting point | I want to… | Start here | | --- | --- | | Launch a token | [Create a launch](/creators/create-launch) | | Buy, bid, or join a presale | [Participant guide](/participants/getting-started) | | Build reputation on Stellar | [Connect accounts](/reputation/connect-accounts) | | Integrate the factory or a launch | [Developer overview](/developers/overview) | | Copy Base factory addresses | [Base deployments](/deployments/base) | | Copy Stellar contract addresses | [Stellar Mainnet](/deployments/mainnet) | ## Build with LumenRise Start with the live Base factory, then the Stellar contract references if you are integrating that network. - [Base factory](/deployments/base): Factory and quote-asset addresses on Base. - [Developer overview](/developers/overview): Base factory, Stellar contracts, and integration boundaries. # Fees and proceeds Route: /concepts/fees The current curve separates trading fees from the quote reserve. Amounts are recorded in the launch's quote asset. Network transaction costs are separate. On Base that quote is USDC, and gas is paid in ETH. On Stellar the quote is XLM or USDC, and network fees are paid in XLM. ## Creator trading fee `creator_fee_bps` is applied on each buy and sell. The creator chooses it at launch, up to 1,000 basis points, or 10%. - A buy pays the gross curve cost **plus** the fee. - A sell receives the gross curve proceeds **minus** the fee. - Fees are rounded up to the smallest quote-asset unit. For example, a 100 USDC gross buy with a 100 bps fee costs 101 USDC before network fees. A 100 USDC gross sell with the same fee returns 99 USDC. The owner withdraws accrued fees with the vault's fee-claim method. This does not withdraw trading reserves, direct donations, or a graduation payout. Keeping fee withdrawals separate lets trading continue even when the owner's receiving account needs attention. ## Graduation accounting `creator_payout_bps` describes the share of recorded quote reserves earmarked for the creator at graduation. The factory's `platform_fee_bps` describes the platform share. The remaining recorded quote reserve is shown as the planned pool quote amount. The platform fee is capped at 1,000 bps. Creator payout plus platform fee cannot exceed 10,000 bps. The creator cannot override the factory's platform fee for an individual launch. On Stellar these amounts are exposed through `graduation_preview()`. The current Stellar contract does not pay them out or create a pool. A preview is not withdrawable proceeds. On Base, follow the live launch for settlement. ## Basis points `100 bps = 1%` and `10,000 bps = 100%`. Allocation percentages and fee percentages are different parameters and should be reviewed separately. ## Network fees Base transactions consume ETH for gas. Stellar transactions consume XLM for network fees, and accounts also need sufficient reserves for entries such as trustlines. Resource costs depend on the transaction and network conditions; use simulation rather than a fixed fee promise. Auction and presale fee schedules are published on the live Base launch. A Stellar sale must disclose fees and proceeds-release rules before accepting commitments. # Launch lifecycle Route: /concepts/lifecycle A launch has a project profile, a configured token and supply, a participation phase, and distribution rules. Those product stages do not all map to the same onchain state machine. Base is the live network for bonding curves, auctions, and presales. Stellar uses the same product flow, with bonding-curve states already in the factory and vault source. ## Shared product flow **Configure → issue and deposit → schedule → participate → distribute or settle → claim.** The creator prepares the profile, allocation, quote asset, prices, dates, and eligibility before signing. The intended issuance flow creates the token and deposits the supply. Once the format opens, participants trade, bid, or commit. The format's settlement and vesting terms determine what happens next. ## Current bonding-curve states | State | Condition | Trading | | --- | --- | --- | | `Scheduled` | Chain time is before `starts_at` | No buys or sells | | `Open` | Chain time is at or after `starts_at`, before graduation | Eligible buys and recorded-position sell-backs | | `Graduated` | A successful buy reaches or exceeds the net reserve target | Buys and sells permanently stop | There is no `ends_at` field and no `Failed` state in the current curve. A launch that has not graduated remains open, even if its target takes years to reach. A start time in the past opens the curve immediately on creation. ## Graduation is a boundary Graduation is triggered inside the buy that reaches the target. No keeper or separate finalization call is needed to change that state. The whole purchase is accepted, subject to the buyer's payment limit, so the reserve can exceed the target. On Base, follow the live launch for how graduation settles. On the Stellar prototype, graduation stops trading without releasing the quote reserve or creating a pool. `graduation_preview` is accounting only. Future settlement must also reconcile the final curve price with pool funding and allocation. ## Vesting runs on its own clock Team vesting uses the configured launch start as its reference. It does not wait for graduation. Team claims and fee claims remain available under their own rules after trading stops. ## Auction and presale phases Auctions need bidding, close, settlement, and claim phases. Presales need commitments, allocation, proceeds/refund settlement, and participant claims. Those stages are live on Base. On Stellar they are part of the expansion, not existing contract enum values. See [auctions](/launches/auctions), [presales](/launches/presales), and [vesting](/concepts/vesting) for their different timing rules. # USDC, ETH gas, and XLM Route: /concepts/quote-assets The quote asset is what participants pay and what the launch collects. The project token is the separate token being sold. On **Base**, every launch quotes in **USDC**. Participants also need ETH for gas. On **Stellar**, the product quote choices are **XLM** and **USDC on Stellar**. | | Base USDC | Stellar XLM | Stellar USDC | | --- | --- | --- | --- | | Asset type | Native Circle USDC on Base | Stellar native asset | Issued Stellar asset | | Price expression | USDC per launch token | XLM per project asset | USDC per project asset | | Participant setup | USDC balance plus ETH for gas | XLM balance | USDC balance and a valid trustline | | Transaction fees | Paid in ETH | Paid in XLM | Still paid in XLM | | Identity check | Chain ID 8453 and USDC address | Network and native SAC | Network, issuer, and USDC SAC | ## What the choice changes Prices, commitments, trading fees, the curve's graduation target, and eventual proceeds are denominated in the selected quote asset. A target of 50,000 USDC on Base is not a target of 50,000 XLM on Stellar. A launch uses one quote asset. The contracts do not perform currency conversion or accept arbitrary payment tokens for a single launch. ## Network-specific identity Use the deployed token for the selected network. On Base, native Circle USDC is [`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`](https://basescan.org/token/0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913). The Base factory is constructed with that pair and rejects a different quote. On Stellar, Testnet balances and contract addresses are separate from Mainnet. An arbitrary asset named `USDC` is not sufficient proof of the issuer. The [Circle contract directory](https://developers.circle.com/stablecoins/usdc-contract-addresses) is an external source for USDC identity. ## Contract behavior The Base factory stores one pair token at construction. The Stellar factory accepts a `pair` SAC address and validates its executable and decimals. It does **not** enforce an XLM/USDC allowlist. The two-choice product interface therefore needs its own reviewed network configuration. Keep amounts as integers in the token's base units. Base USDC uses 6 decimals. Stellar assets used by the current factory use 7 decimals. Use decimal-string parsing or integer arithmetic rather than JavaScript floating-point multiplication. ## Price is format-specific On a curve, the initial price comes from the virtual-reserve ratio and changes with trades. In an auction, bids determine the result under the settlement rules. In a presale, the creator's fixed price determines how accepted quote funds convert into allocation. # Tokens and locked supply Route: /concepts/stellar-assets Launchpad locks launch supply in a dedicated vault. The token type depends on the network. On **Base**, the launch token is an ERC-20. The factory reads the creator's token balance, deploys a vault, and pulls that balance in. USDC on Base is the quote. On **Stellar**, the launch token is a Stellar asset, identified by an **asset code and issuer account**, such as a project code paired with its issuer's `G...` address. A code by itself does not identify an asset. XLM is Stellar's native asset and has no issuer. The [Stellar Asset Contract](https://developers.stellar.org/docs/tokens/stellar-asset-contract) lets Soroban contracts hold and transfer both native and issued Stellar assets. Its `C...` address is a contract interface to the same underlying asset. ## Intended issuance flow The complete launch flow is designed to: 1. Create the token. On Base, deploy or reuse an ERC-20. On Stellar, create the issuer and distribution arrangement. 2. Issue the configured supply to the distribution account or creator wallet. 3. Establish and publish the token's administrative controls. 4. On Stellar, deploy or locate its SAC on the selected network. On Base, confirm the ERC-20 address and decimals. 5. Transfer the launch supply from the distribution account into the dedicated vault. :::note[Current factory] The Stellar factory begins at this step. It does not create an issuer, issue an asset, or disable future issuance. The Base factory likewise expects an existing ERC-20 and an approval for the deposited balance. ::: ## What the vault receives The factory reads the launch owner's full token balance, creates a new vault, transfers that balance, and verifies that the owner's balance became zero. The vault records the amount deposited as its launch supply. That transfer cannot prove that other accounts hold no tokens or that the issuer or admin cannot mint more. A fixed-supply claim needs separate evidence about issuance, distribution, and remaining administrative authority. ## What is locked The vault accounts for the pool reserve, sale inventory, and team allocation. These buckets have different permitted uses. Team tokens follow vesting; curve inventory is distributed through trades; pool tokens are reserved for future settlement. A contract lock does not neutralize token-level admin powers. On Stellar, authorization and clawback settings can affect balances held in a vault. On Base, review mint, pause, and blacklist controls on the ERC-20. Review those controls as well as contract code. ## Network setup and precision On Base, approve the factory (or the sale contract) to spend the launch token, and hold USDC plus ETH for gas. On Stellar, classic accounts need the required trustlines for issued assets they receive. XLM does not need a trustline. These launch contracts do not create trustlines for users. The current Stellar factory accepts only host-verified Stellar Asset Contracts with seven decimals for both the project asset and quote asset. A custom contract implementing a similar token interface is rejected. [Configure supply allocations](/creators/tokenomics) or [choose the quote asset](/concepts/quote-assets). # Cliffs, vesting, and claims Route: /concepts/vesting Vesting makes an allocation claimable over time. A **cliff** delays the start of release. A **claim** transfers tokens that have already unlocked; time passing does not automatically send them to an account. ## Team vesting in the current curve The team allocation remains inside the launch vault. The owner configures: | Field | Meaning | | --- | --- | | `cliff_seconds` | Delay from `starts_at` before vesting begins | | `duration_seconds` | Length of vesting after the cliff | | `schedule` | `Daily`, `Weekly`, or `Monthly` release steps | Daily means 86,400 seconds, weekly means 604,800 seconds, and monthly means a fixed 2,592,000 seconds, or 30 days. Monthly does not mean calendar-month boundaries. With a nonzero duration, nothing is claimable at or before the cliff boundary. After it, elapsed time is rounded down to complete release intervals. At the exact vesting end, the full remaining allocation unlocks, including rounding dust. ## Worked example A launch allocates 300,000 tokens to the team, with a 30-day cliff and 300-day duration using 30-day steps. | Time from launch start | Total vested | | --- | --- | | Day 30, at the cliff | 0 | | Day 59 | 0 | | Day 60, first complete step | 30,000 | | Day 180 | 150,000 | | Day 330, vesting complete | 300,000 | The cliff is followed by the vesting duration. This example takes 330 days from launch start to full release. ## Claiming The vault reports unlocked team tokens minus tokens already claimed. The owner authorizes the claim and receives the unlocked amount. The current contract has one team bucket and one owner recipient; it does not split vesting among multiple team members. A failed token transfer rolls the transaction back. On Stellar, a missing, frozen, or full recipient trustline must be resolved before an issued-asset claim can succeed. On Base, the owner needs to be able to receive the ERC-20. ## Immediate release Setting both cliff and duration to zero makes the whole team allocation immediately claimable, including before the trading start. This is not a team lock. A nonzero cliff with a zero duration is invalid. ## Participant vesting Current curve buyers receive their purchased token during the buy. They do not receive a participant vesting entitlement. Auctions and presales support their own published participant schedules on Base. Those schedules must be kept separate from the current team-vesting implementation. On Stellar they are part of the expansion. # Create a launch Route: /creators/create-launch The creation flow turns a complete project configuration into a scheduled launch. Prepare the economic terms before authorizing any token issuance or transfer. Base is the live network. Bonding curves, presales, and auctions all run there. Stellar is the expansion; its factory currently exposes bonding-curve creation. ## Prepare your project Choose the project name, token symbol, supply, description, logo, website, team members, and relevant links. Explain the product, the use of raised funds, and the purpose of the token. See [project profiles](/creators/project-profile). Use a distinct distribution wallet to hold the supply intended for the vault. The current factory's `owner` is the distribution account and the recipient for team claims. ## Select the format Choose a [bonding curve](/launches/bonding-curves), [auction](/launches/auctions), or [presale](/launches/presales). Format-specific pricing and settlement fields should only appear for the selected format. On Base, all three formats are live. On Stellar, the factory exposes `create_bonding_curve`. ## Set supply percentages Define what percentage belongs to the sale, future liquidity, and team. The current curve requires all three percentages to add up to 100%, with nonzero pool and sale allocations. The team share can be zero. Other tokenomics categories can be explained in the project profile, but the current vault does not create extra treasury, campaign, or advisor buckets. ## Choose the quote asset On Base, the quote is USDC. On Stellar, pick XLM or USDC and verify its network-specific identity. Every price, contribution, target, and quote-denominated fee for this launch uses that asset. ## Set prices and dates For a curve, choose the initial price, reserve shape, graduation target, creator fee, and intended creator payout share. The initial price and target must correspond to a valid reserve configuration; they are not unconstrained independent numbers. For an auction, the configuration includes the bidding window and price constraints. For a presale, it includes the fixed price, funding goal, commitment window, and allocation policy. Use UTC timestamps when reviewing final terms. Current curve trading opens at `starts_at` and has no end date. ## Configure vesting and eligibility Choose the team's cliff, duration, and release interval. Review the actual first release and final release dates. With both durations set to zero, the team allocation is immediately claimable. Choose open participation or, on Stellar, an existing [reputation label](/reputation/criteria). A nonzero label must exist in the factory's registry. Presales also need participant vesting and an oversubscription policy. ## Review and launch The review should identify the token, selected network, full supply plan, vault deposit, allocation percentages, quote asset, prices, fees, dates, vesting, and access rules. It should also distinguish onchain terms from profile information. The **Launch** action coordinates token setup and vault deployment. Confirm you are signing on Base for a production launch, and copy the factory from [Base factory](/deployments/base). The Stellar path still requires an already-issued asset and a direct factory invocation. After creation, verify the returned vault, its recorded configuration, and its deposit. The current Stellar contracts do not expose a launch-parameter editor or cancellation method. Do not assume a mistaken start date, price, or vesting schedule can be changed later. # Set participation rules Route: /creators/eligibility A launch can accept any eligible buyer who signs and pays, or require extra access rules. On Base, publish those rules on the launch page. On Stellar, a launch can require the buyer to pass a reputation label from the factory's registry. ## Open participation On Stellar, set `reputation_label` to `0`. This disables the curve's reputation check. Time, balance, trustline, inventory, and slippage rules still apply. Label `0` is a reserved sentinel. Real labels begin at `1`. ## Gate by reputation This path is part of the Stellar expansion. Choose an existing label or create one with the desired thresholds. Inspect its registry, ID, creator, and criteria before attaching it to a launch. Names can repeat; the ID is the actual reference. For example: | Goal | Current representation | | --- | --- | | Require a stronger social profile | `social_above: 200` | | Require developer and Stellar activity | `github_above: 100` and `onchain_above: 50` | | Require a combined score | `total_above: 600` | Every configured threshold uses strict **greater than** comparison. A social score of 200 fails a `social_above: 200` requirement. All supplied conditions must pass. ## What “verified only” means The product intends to let creators select verified participants. The current Stellar registry has scores and thresholds, but no dedicated identity-verification or KYC flag. A positive-score threshold proves only that a registered score passes the rule. An actual verified-only policy needs a defined verification process and an enforceable representation. Do not equate an X or GitHub connection, a score, or a public wallet address with legal identity verification. ## When checks happen A gated Stellar curve evaluates current scores on **every buy**. The label is immutable, but score updates can change whether the buyer passes. The creator does not need to pass the label to create the launch. Quotes do not enforce eligibility. Use `is_eligible(address)` for a preliminary check, then simulate the signed purchase. That preliminary result is not a reservation. ## Exit rights Reputation gates purchases. It does not gate an existing buyer's sell-back before graduation, creator fee claims, or team claims. It also does not restrict ordinary later transfers of the token. Presale ranking is a separate use of reputation, live on Base where the sale publishes it. A threshold label answers a boolean access question; it does not sort participants or allocate oversubscribed commitments. # Manage a launch Route: /creators/manage-launch After creation, the vault's recorded configuration is the source for onchain terms. The contracts expose read methods and claims, rather than a general launch-management editor. On Base, start from the live launch page and the [Base factory](/deployments/base). The method names below are the Stellar vault ABI. ## Verify the launch Record the factory, vault address, network, creation transaction, token identity, and quote asset. Read `get_config()` to check allocation buckets, start time, fee settings, virtual reserves, target, team vesting, and reputation label. Use `get_state()` for sold inventory, recorded quote reserves, accrued creator fees, claimed team tokens, buyer count, and graduation state. `status()` provides the scheduled/open/graduated interpretation. The factory enumerates registered launches with `launch_count()` and `launch_at(index)`. Current registered indexes begin at **1**. ## Withdraw trading fees Read `get_state().creator_fees`. The owner can call `claim_creator_fees(recipient)` for a receiving address that can hold the quote token. A failed transfer preserves the fee balance through transaction rollback. Trading-fee claims do not change the recorded curve reserve and do not collect future graduation proceeds. ## Claim team tokens Read `claimable_team()` before calling `claim_team()`. The owner authorizes the claim and receives the unlocked token. Review [vesting](/concepts/vesting) for the exact release schedule and zero-duration behavior. ## Follow graduation Check the net reserve against the target. Creator fees and direct donations do not count. Once graduated, the current Stellar prototype permanently stops buys and sells while pool tokens, unsold curve inventory, and the graduation reserve remain in the vault. `graduation_preview()` shows intended accounting. On Base, follow the live launch for settlement. ## Configuration changes There is no current Stellar method to update launch parameters, change its attached label, cancel the launch, or upgrade an existing vault. Creating a new factory with a rebuilt vault hash does not change existing vaults. A future project-profile editor would change profile content, not automatically change signed contract terms. ## Long periods of inactivity Soroban data has a time-to-live. Relevant writes renew active launch storage and positions, but long-idle entries may need restoration. An unavailable entry should not be interpreted as an empty balance or a completed claim. No recovery method exists for unsolicited tokens sent directly to a predicted vault address. Direct transfers do not create purchases or claim entitlements. # Project profile and team Route: /creators/project-profile A project profile explains who is launching, what the token is for, and how the raise will be used. The profile and the launch terms should tell the same story. ## Project information Include a clear project name, short summary, full description, logo, website, and official social and repository links. Describe the product, current stage, intended users, roadmap, and concrete use of raised capital. Avoid presenting a future milestone as a completed result. Link to working products, code, or published material when those support a claim. ## Team Describe each public team member's name or handle, role, relevant experience, and official profile links. Explain who controls the token admin, distribution wallet, project proceeds, and team allocation. The current curve sends team claims to a single owner address. A list of team members on a profile does not create separate onchain vesting recipients. ## Token and tokenomics Show the token identity, supply, allocation table, quote asset, and vesting terms. On Base that identity is the ERC-20 address. On Stellar it is the asset code, issuer, and SAC address. Explain any supply held outside the vault and any remaining admin powers. The [tokenomics guide](/creators/tokenomics) explains how to keep the supply allocation internally consistent. A tokenomics narrative does not create additional contract-enforced allocation buckets. ## Launch terms Publish the selected format, pricing mechanism, opening date, fees, access rules, and claim schedule. Auctions and presales also need their close and settlement terms. Participants should be able to distinguish a submitted commitment, an accepted allocation, a claimable amount, and a token already received. ## Stored metadata today The current Stellar contract stores only these display fields: | Field | Limit | | --- | --- | | `name` | Nonempty, at most 64 bytes | | `description` | At most 512 bytes | | `logo` | URL string, at most 256 bytes | | `symbol` | Nonempty, at most 12 bytes and matching the asset SAC | Byte limits are not character counts for all languages. Stellar asset-code validity is also determined during asset issuance; the contract's string-length check does not issue an asset. Rich descriptions, team biographies, documents, and extended tokenomics belong to the project-profile data layer. The current `logo` field stores a string; it does not upload or pin media. # Supply and tokenomics Route: /creators/tokenomics Creators choose the percentage of the launch supply assigned to public participation, future liquidity, and the team. The allocation plan should account for the entire intended supply. ## Current curve buckets | Bucket | Purpose | Contract rule | | --- | --- | --- | | Curve | Inventory available for direct purchases | Must be greater than zero | | Pool | Token reserve intended for future liquidity | Must be greater than zero | | Team | Tokens released under team vesting | May be zero | The three percentages must sum to **100%**, represented as 10,000 basis points. For a 1,000,000-token launch with 40% sale, 30% pool, and 30% team: | Allocation | Basis points | Token amount | | --- | --- | --- | | Curve sale | 4,000 | 400,000 | | Pool reserve | 3,000 | 300,000 | | Team vesting | 3,000 | 300,000 | | Total | 10,000 | 1,000,000 | Curve and team amounts round down to whole base units. The pool bucket receives the remainder, preserving the deposited total. A nonzero percentage that rounds to zero can invalidate the launch. ## Deposited supply versus issued supply The factory deposits the owner's **entire balance of this token**. Its recorded `total_supply` is that deposit. It cannot query the total amount issued across the network and cannot enforce that future minting is disabled. If the public supply claim is 1,000,000 tokens, the issuance and distribution records need to support it. Moving only 700,000 into the vault does not prove the remaining 300,000 does not exist. On Stellar this also means issuer controls sit outside the vault. On Base, review the ERC-20's mint and admin roles the same way. ## Price and valuation Explain whether the published initial price is a curve marginal price, auction reference price, or fixed presale price. Multiplying a supply figure by that price is a valuation illustration. It does not describe available exit liquidity or guarantee the same price for the full supply. For the current curve, virtual base reserves must exceed the sale bucket. The graduation target must be reachable by selling the available curve inventory under the configured formula. ## Additional allocations Treasury, ecosystem, advisor, marketing, or community allocations can be described in a project plan. The current curve has only three enforced buckets and one team recipient. Do not label additional profile categories as independently locked unless the corresponding custody and vesting mechanism actually exists. Auction and presale supply accounting, including unsold tokens and participant vesting, follows the live Base sale terms. On Stellar those formats are part of the expansion. # Base factory Route: /deployments/base Base is the live LumenRise network. Put the deployed factory address in the table below. Use these values in the app, scripts, and any integration that talks to Base. Network: **Base**. Chain ID: **8453**. Explorer: [Basescan](https://basescan.org). ## Contract directory | Component | Base address | | --- | --- | | Launch factory | Paste the deployed factory address here | | Quote asset (USDC) | [`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`](https://basescan.org/token/0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) | | Individual launch vaults | Created by the factory per launch | | Auction contracts | Published with the live Base app | | Presale contracts | Published with the live Base app | The factory deploys a dedicated vault for each bonding-curve launch. Auction and presale launches on Base use the launchpad's live sale contracts. Do not paste a Stellar `C...` address into a Base client. When the factory address is public, add it to the table and link it to Basescan: `https://basescan.org/address/` ## Factory settings The Base factory is constructed with a platform recipient, a platform fee in basis points, and a quote token. On Base mainnet that quote token is native Circle USDC (`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`). Every bonding-curve launch created through this factory uses that same pair. | Setting | Live value | | --- | --- | | Platform recipient | Paste the platform address here | | Platform fee (bps) | Paste the live fee here | | Pair token | USDC on Base | Fill the empty cells when you publish the deployment. The deploy script defaults the platform fee to 100 bps (1%) and caps it at 1,000 bps. ## What to record with a new factory Keep the factory address together with: - Chain ID `8453` - Deployer and platform addresses - Platform fee in basis points - Pair token address (USDC) - Deployment transaction hash - Verified source on Basescan A new factory does not upgrade vaults created by an older factory. Existing launches stay on the factory that deployed them. ## Base Sepolia Base Sepolia (chain ID `84532`) is for rehearsal. That path deploys a fresh TestUSDC rather than Circle USDC. Do not treat Sepolia addresses as the production factory. ## Related records - [Deployment directory](/deployments/overview) - [Stellar Mainnet](/deployments/mainnet) - [Launch contract reference](/developers/launch-contracts) for the Stellar factory ABI # Stellar Mainnet Route: /deployments/mainnet The reputation registry and launch factory are deployed on Stellar Mainnet. This is the Stellar expansion record, not the live Base production factory. Network passphrase: `Public Global Stellar Network ; September 2015`. For the live launchpad, use [Base factory](/deployments/base). ## Contract directory | Component | Mainnet address | | --- | --- | | Reputation registry | `CCTQOJ4TQNRTKA7QDS7V5VLYXZKKEDZPGMEJB5PILYZQHOJXCPQZB4ZV` | | Launch factory | `CDGRLH3NCIKOTRFW3NJCWAGFYTQALAR7G6KCEZD7X23665WU2XAECLA6` | | Bonding-curve release hash | Not published | | Official launch vaults | Not published | | Auction contracts | Part of the Stellar expansion | | Presale contracts | Part of the Stellar expansion | No production API origin, SDK release, or installable launch CLI is published in the supplied repositories. ## Current Stellar release notes The Stellar curve can reach graduation and stop trading. Graduation proceeds and liquidity-pool creation on that network still need a published settlement path. Check the deployed configuration and contract specification before integrating. The vault code hash, deployment transactions, release revision, and factory configuration are not yet listed here. Issued-asset entries should include code, issuer, and SAC address. Links must point to the public network rather than Testnet. Historical deployments should remain clearly separated from the current supported release. # Deployment directory Route: /deployments/overview Use this directory to pick a network and copy the right factory. An address is only useful together with its chain. ## Networks | Network | Current record | Details | | --- | --- | --- | | Base | Live production launchpad. Factory address lives on its own page so you can drop it in. | [Base factory](/deployments/base) | | Stellar Mainnet | Reputation registry and launch factory addresses published | [Stellar Mainnet](/deployments/mainnet) | | Stellar Testnet | Historical 8 October 2026 fixtures; not a current-source deployment | [Stellar Testnet](/deployments/testnet) | Base is where the app runs today: bonding curves, presales, auctions, audited contracts, and more than $10k in volume. Stellar is the expansion network. ## Components to record | Component | Current release record | | --- | --- | | Base launch factory | [Address page ready](/deployments/base) | | Base quote asset | USDC on Base: `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` | | Stellar reputation registry | [Mainnet address published](/deployments/mainnet) | | Stellar launch factory | [Mainnet factory address published](/deployments/mainnet) | | Stellar bonding-curve code hash | Historical Testnet hash only | | Individual launch vaults | Created per launch. Historical Stellar Testnet examples only | | Auction and presale contracts | Live on Base. Stellar sale contracts are part of the expansion | | Production API, SDK, and launch CLI | Not published in the supplied repositories | ## Network identifiers ### Base ```text title="Base" Chain ID: 8453 Explorer: https://basescan.org Native gas token: ETH Quote asset: USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) ``` ### Stellar Mainnet ```text title="Stellar Mainnet network passphrase" Public Global Stellar Network ; September 2015 ``` ### Stellar Testnet ```text title="Stellar Testnet network passphrase" Test SDF Network ; September 2015 ``` A Base `0x` factory is not a Stellar `C...` contract. Do not mix the two in a client. Stellar Testnet assets and funds have no Mainnet equivalence. Testnet resets can remove old contracts and data. Base Sepolia is a separate rehearsal chain and is not the production factory. ## Verify a deployment A deployment record should include the network, chain ID or passphrase, deployment time, source revision, factory settings, quote asset, and a confirmed transaction. Read the factory's stored settings before you integrate. Do not assume a known factory has been updated just because local source changed. Existing vaults are not upgraded by a new factory deployment. A published address alone does not establish that settlement, liquidity, or claim behavior is complete. Review [implementation status](/getting-started/status) alongside the release record. # Stellar Testnet Route: /deployments/testnet **Current-source deployment: not verified.** The supplied repository records a successful smoke test on **8 October 2026 at 08:49 UTC**, using an earlier version with a deadline/failure lifecycle and without reputation gating. These addresses are Stellar Testnet fixtures. They are not the [Base factory](/deployments/base). The recorded run used fresh in-memory keys, Friendbot funds, and 18 confirmed transactions across ledgers 5,085,124 to 5,085,161. These are disposable fixtures. Their current availability has not been rechecked, and Testnet resets can remove them. ## Historical contract addresses | Component | Recorded Testnet address | | --- | --- | | Factory | [`CDG76JM6I67SGIV5ZN4WK6DW54ZUWPL6BMXD234ULWIERXRRYJ5QVDZC`](https://stellar.expert/explorer/testnet/contract/CDG76JM6I67SGIV5ZN4WK6DW54ZUWPL6BMXD234ULWIERXRRYJ5QVDZC) | | Earlier failed-launch fixture | [`CBSVA5KKJKA5TB46W2PCVNXL4PKONVTGKOPOBORGVHJXHXX2YMVGBBVW`](https://stellar.expert/explorer/testnet/contract/CBSVA5KKJKA5TB46W2PCVNXL4PKONVTGKOPOBORGVHJXHXX2YMVGBBVW) | | Graduated-launch fixture | [`CAR447PXSTWJUK55L3DZFIHFLC2K5YFHXPYMWBLVSZXINEPJXFHMO5EV`](https://stellar.expert/explorer/testnet/contract/CAR447PXSTWJUK55L3DZFIHFLC2K5YFHXPYMWBLVSZXINEPJXFHMO5EV) | There is no reputation-registry address in that older report. “Failed” identifies a historical fixture, not a state in the current curve ABI. ## Historical artifact hashes ```text Bonding curve SHA-256: 8c101cee5ef05021859d5acc74505f8a94f3b860ec9d2dcc528adbfb49bc51d1 Factory SHA-256: 4ecd23fe781124c97baaf2880079fb0ea4299e223887c01039fa29a37f00772d ``` These hashes belong to the recorded artifacts, not the current source build. ## Recorded transaction evidence - [Factory deployment](https://stellar.expert/explorer/testnet/tx/c08c7cb62f99ae0c3179180c955949c49188de9a3b7445086d1e2e6444c15867). - [Buy reaching graduation](https://stellar.expert/explorer/testnet/tx/3dc0cc6b8ff41ef2cb046ab38818ddf017ee63b2b33afb5805cff7e89b7464fc). - [Earlier fixture buyer exit](https://stellar.expert/explorer/testnet/tx/5d07d9f8dcf3f9bd67db7a9fc9724aabba2e36f344d3fde10b9d48b0fd7ead39). The report verified XLM trades, slippage rejection, fee claims, team claims, and graduation. It also exercised the older deadline-based exit behavior. It does not verify the current reputation integration or perpetual open lifecycle. ## Current-version verification The Stellar contract repository's `scripts/test.sh` builds the three WASMs and runs its local checks. Its opt-in `scripts/testnet-smoke.mjs` now includes reputation and no-deadline checks, but the supplied recorded result is still the older run. A current Stellar release needs a fresh registry, a factory pinned to that registry and the rebuilt vault hash, confirmed smoke-test transactions, and a published record of the new addresses and artifacts. Do not reuse the old addresses as current configuration. This documentation task did not deploy contracts or execute the network smoke test. The original record is `launchpad-contract/TESTNET.md` and `target/testnet-smoke.json` in the sibling contract repository. # HTTP API Route: /developers/api **Planned. Not implemented in the current contracts or published as a service.** The HTTP API is intended to let applications use Launchpad reputation and launch data without implementing direct chain reads for every interaction. No production API base URL, OpenAPI specification, endpoint contract, or authentication scheme is supplied in the current repositories. ## Intended capabilities | Area | Intended use | | --- | --- | | Reputation | Retrieve the separate social, GitHub, and onchain scores for a Stellar account | | Criteria | Inspect labels and evaluate access rules | | Launches | Read project information, format, token identity, terms, and deployment references | | Preparation | Validate configuration and prepare unsigned actions for user authorization | | Allocation | Expose settled auction or presale outcomes | These are product capabilities to implement, not callable routes. An API consumer should not assume paths such as `/scores` or `/launches` exist. A launch record needs to name its network. Base and Stellar identities are not interchangeable. ## Identity and numeric representation A future API needs to distinguish network, registry, participant address, label ID, and token identity. A token symbol without its contract or issuer, or a label ID without its registry, is ambiguous. Monetary base units and large identifiers should be represented without JavaScript number precision loss. Final serialization, pagination, and error formats remain unpublished. ## Trust and consistency If an API serves cached registry data, consumers need to know its observation point and freshness. A cached eligibility result is not proof that a transaction will pass the current onchain check. A score response should distinguish missing data, provider failure, stale evidence, and an actual numerical score. A service error must not be reported as a verified zero or as automatic eligibility. ## Direct integration today On Base, use the [Base factory](/deployments/base) and the live app. On Stellar, use the [reputation contract](/developers/reputation-contract) through a Soroban client or the local Rust package, and the [launch ABI](/developers/launch-contracts) for launch state and trading. A published API reference should replace this page only when the service has a real base URL, versioned schema, authentication model, limits, and examples verified against its implementation. # Architecture Route: /developers/architecture The contract architecture keeps launch custody separate from the shared reputation registry. The factory deploys a dedicated vault for each curve launch. Base is the live production stack. The workspace diagram below is the Stellar contract layout; the EVM factory in `evm-contract/` is the Base counterpart. ## Components The Stellar contract workspace separates deployed contracts from shared types: Contract workspace: evm-contract Factory and BondingCurve on Base; stellar-contract factory, bonding-curve, reputation, and shared type packages. | Component | Responsibility | | --- | --- | | Interface | Public discovery, authentication, and launch flows. Live on Base. | | Token issuer / admin | Issue the ERC-20 or Stellar asset and hold the supply before deposit | | Token interface | ERC-20 on Base; Stellar Asset Contracts on Stellar | | Launch factory | Validate parameters, deploy a vault, transfer the owner's balance, and register the launch | | Bonding-curve vault | Hold allocated tokens, price trades, track positions, and process team and fee claims | | Reputation registry | Stellar only. Store administered scores and public immutable labels; evaluate criteria | | Planned backend | Identity linking, evidence collection, score calculation, and project-profile services | | Planned API, SDK, and CLI | Application integrations and launch orchestration | ## Creation boundary The owner authorizes bonding-curve creation. The factory verifies both tokens, reads the owner's token balance, validates the allocation and curve, and deploys a vault. On Stellar it also checks a nonzero reputation label and deploys with its stored WASM hash. The newly created vault receives the owner's entire token balance. The factory checks both the zero owner balance and the exact vault balance increase. A failed invocation rolls back the deployment and transfer effects. Existing unsolicited balances at a predictable vault address do not increase the recorded launch supply. They have no implemented recovery path. ## Trading boundary Buyers pay the quote token and receive the project token through the vault. The vault records net reserve, creator fees, and address-specific sell-back positions. Its checks and transfers occur in one transaction. A quote reads curve state but does not prove eligibility. On Stellar, a gated buy calls the registry selected by the factory. A sell does not call the registry. ## Reputation trust boundary A Stellar factory pins one reputation registry address. Launch creators cannot replace it per launch. Registry administrators can change scores and rotate the admin. Public label creators define immutable thresholds. The registry's authorization protects score writes. It does not establish that the offchain evidence or scoring model is correct. This registry is not part of the live Base factory. ## Upgrades and storage The Stellar factory stores a vault WASM hash at construction. Rebuilding local code does not change that hash, and the current contracts have no upgrade method. A new factory or vault version requires a separate deployment and record. The Base factory is the same in spirit: a new factory does not upgrade vaults created by an older one. Record the live address on [Base factory](/deployments/base). **Storage lifetimes and archived data** On Stellar, relevant operations extend storage lifetimes. Long inactivity can still require restoration of archived data. Integrations must distinguish an invocation failure from an absent score or zero position. # CLI and agents Route: /developers/cli **Planned. Not implemented in the current contracts or published as a service.** The launch CLI is intended to let a creator or agent describe a launch, review the resulting configuration, and authorize the transactions. No Launchpad CLI package, installer, or executable is present in the supplied repositories. ## One-command creation The planned interface includes both a natural-language prompt and a structured configuration file. The following commands are **design examples, not runnable commands**: ```bash title="Proposed commands · not runnable" # Proposed: describe the launch and inspect a plan. launchpad create \ --prompt "Create a bonding curve for ORBIT with 1 million tokens, 40% sale, 30% liquidity, 30% team, USDC quotes, initial price 0.10 USDC, a 30-day team cliff and 300-day vesting" \ --network base \ --dry-run # Proposed: create from an explicitly reviewed file. launchpad create --config ./launch.json --network base ``` There is no installation command yet. Do not install an unrelated package merely because it uses the name `launchpad`. ## From a prompt to an executable plan The intended CLI translates the request into a structured configuration and validates it before signing. It must surface missing decisions rather than invent a supply, issuer, fee, vesting rule, or payout address. It must also name the network. Base and Stellar are not interchangeable. A dry run should identify the project and token, issuance controls, distribution account, allocations, quote asset identity, format parameters, dates, vesting, reputation label, and the intended sequence of transactions. For a curve, a requested initial price must be reconciled with reserve shape, inventory, and the target. For auctions and presales, follow the live Base sale contracts. Stellar sale contracts are part of the expansion. ## Agent-friendly behavior The intended automation interface needs explicit network and signer selection, machine-readable plans and results, a validation-only path, and final transaction receipts. Retrying after an uncertain submission must first reconcile the previous transaction; a repeated command must not accidentally issue the token or purchase twice. Natural language is an input method. It does not bypass review of token issuance, transfers, fees, or wallet authorization. The exact flags, config schema, package name, and output format remain open. ## Available tooling today The Stellar contract repository includes `scripts/deploy.example.sh` for deploying the registry and factory with the Stellar CLI, plus `scripts/testnet-smoke.mjs` for an opt-in Testnet check. The EVM repository includes `deploy.sh` for Base and Base Sepolia. These deploy or test infrastructure; they are not the planned creator CLI. The documentation itself exposes [llms.txt](/llms.txt) and [plain-text documentation](/llms-full.txt) so agents can read the current product and implementation boundaries. # Events and errors Route: /developers/events-and-errors Decode an error using the selected contract's specification. Numeric codes are local to a contract's error enum and can overlap across contracts. This table is the Stellar ABI. The live Base factory uses Solidity errors and events from `evm-contract/`. ## Launch errors | Code | Variant | Meaning | | --- | --- | --- | | 1 | `InvalidConfig` | Invalid metadata, allocations, timing, fees, or curve settings | | 2 | `InvalidSupply` | Invalid deposit or asset-accounting invariant | | 3 | `Overflow` | Arithmetic or counter limit exceeded | | 4 | `NotOpen` | Trading unavailable for the current state, or a guarded action is busy | | 5 | `InvalidTrade` | Invalid amount, position, or trade input | | 6 | `SoldOut` | Requested buy exceeds curve inventory | | 7 | `Slippage` | Payment cap or receipt floor is violated | | 8 | `NoReserve` | Sell has zero gross value or insufficient recorded reserve | | 9 | `NoClaim` | No positive amount is available to claim | | 10 | `WrongAsset` | Asset is not an accepted SAC or its metadata/decimals mismatch | | 11 | `UnknownLabel` | Nonzero label does not exist at launch creation | | 12 | `ReputationRequired` | Buyer does not pass the launch label | Asset transfers, missing authorization, archived data, and failed cross-contract calls can also cause host or nested-contract errors. Not every failure maps to this enum. ## Reputation errors | Code | Variant | Meaning | | --- | --- | --- | | 1 | `InvalidLabel` | Invalid name or empty criteria | | 2 | `Overflow` | Next label ID cannot be represented | Unknown labels and missing scores return `false` from checks rather than one of these label-creation errors. ## Reputation events | Event | Indexed field | Payload | | --- | --- | --- | | `scores_updated` | `address` | Replacement `Scores` | | `label_created` | `label_id` | Full `Label` | | `admin_changed` | None | `old_admin` and `new_admin` | The source defines these with `#[contractevent]`. Use the deployed specification to decode exact topics and data. A score update replaces the complete three-field record. ## Launch indexing The current Stellar factory and curve do not declare custom application-level creation or trade events. Do not invent event names such as `launch_created` or `presale_allocated` in a Stellar indexer. The Base factory emits `FactoryConfigured` and `LaunchCreated`. Index those from the live factory on chain ID 8453. Use factory enumeration, confirmed invocation results, vault reads, and token transfer events as appropriate. Token transfers alone do not prove that a transfer was a registered purchase: unsolicited direct transfers are possible. For Stellar event-query mechanics, see the [Stellar RPC reference](https://developers.stellar.org/docs/data/apis/rpc/api-reference). Store network, contract identity, transaction references, and an ingestion cursor when building an indexer. # Launch contract reference Route: /developers/launch-contracts This page is the **Stellar** factory and vault ABI. For the live production factory, start at [Base factory](/deployments/base). The current Stellar workspace exposes `LaunchpadFactory` and `BondingCurve`. This reference describes the source ABI, not the older Testnet fixtures. ## Factory configuration `__constructor(settings: FactorySettings)` stores: - `platform` (`Address`, required): Platform recipient used by graduation preview. - `platform_fee_bps` (`u32`, required): Platform fee, at most 1,000 basis points. - `curve_wasm_hash` (`BytesN<32>`, required): Uploaded vault code to deploy. - `reputation` (`Address`, required): Fixed registry; its interface is checked at construction. The Base factory is constructed with `platform`, `platformFeeBps`, and a `pair` token. On Base mainnet that pair is Circle USDC. It does not take a WASM hash or a reputation registry. ## Launch parameters `create_bonding_curve(params: LaunchParams) -> Result` requires the owner's authorization and returns the new vault address. | Field | Type | Constraints or purpose | | --- | --- | --- | | `owner` | `Address` | Supplies the deposited asset and receives team claims | | `asset` | `Address` | Project asset SAC | | `pair` | `Address` | Quote asset SAC; must differ from `asset` | | `metadata` | `Metadata` | `name`, `description`, `logo`, `symbol` | | `allocations` | `Allocations` | `pool_bps`, `curve_bps`, `team_bps`; sum to 10,000 | | `vesting` | `Vesting` | `cliff_seconds`, `duration_seconds`, `schedule` | | `curve` | `CurveSettings` | Reserve, target, and fee fields below | | `starts_at` | `u64` | Unix seconds; no end timestamp | | `reputation_label` | `u64` | `0` for no gate; otherwise an existing label ID | Both assets must be host-verified seven-decimal SACs. The deposited balance must be positive and no greater than `i64::MAX` base units. Pool and curve buckets must be nonzero; a nonzero team share must produce a nonzero amount. | `CurveSettings` field | Constraint | | --- | --- | | `virtual_base_reserve: i128` | Positive, at most `i64::MAX`, and greater than the curve bucket | | `virtual_quote_reserve: i128` | Positive and at most `i64::MAX` | | `graduation_target: i128` | Positive and no greater than cumulative gross cost at full sale | | `creator_fee_bps: u32` | At most 1,000 | | `creator_payout_bps: u32` | Sum with platform fee cannot exceed 10,000 | Use the contract's validation and quotes. Derived reserve settings must remain valid after integer rounding and at the maximum sold amount. ## Curve formula Let `Vb` be virtual base reserves, `Vq` virtual quote reserves, and `s` the sold asset amount, all in base units. Define: ```text F(s) = ceil(Vq × s / (Vb - s)) buy gross(a) = F(s + a) - F(s) sell gross(a) = F(s) - F(s - a) current_price = ceil(Vq × Vb × 10^7 / (Vb - s)^2) ``` `current_price` is quote base units per whole project asset. Buy payment adds `ceil(gross × creator_fee_bps / 10,000)`; sell receipt subtracts it. Zero-gross trades are rejected. Round the cumulative function as implemented rather than rounding each increment independently. ## Factory reads | Method | Returns | | --- | --- | | `settings()` | `FactorySettings` | | `launch_count()` | `u32` | | `launch_at(index: u32)` | `Option
`; stored indexes start at 1 | ## Vault reads | Method | Result | | --- | --- | | `get_config()` | Factory, platform, registry, launch parameters, deposited supply, buckets | | `get_state()` | Sold amount, quote reserve, creator fees, team claimed, buyer count, graduated flag, busy flag | | `status()` | `Scheduled`, `Open`, or `Graduated` | | `current_price()` | Marginal price, including before open and after graduation | | `quote_buy(amount)` / `quote_sell(amount)` | `Quote { gross, creator_fee, user_amount }`; trading state required | | `buyer_count()` | Number of distinct direct buyers | | `sellable_balance(buyer)` | Recorded remaining direct-buy position | | `is_eligible(address)` | Reputation result only | | `claimable_team()` | Unlocked team amount minus previous claims | | `graduation_preview()` | Intended creator, platform, pool quote, pool asset, and unsold curve amounts | ## Vault writes | Method | Authorization and effect | | --- | --- | | `buy(buyer, amount, max_payment)` | Buyer authorizes; exact asset amount; total payment cap; current reputation check | | `sell(seller, amount, min_receipt)` | Seller authorizes; position-limited sell-back; net receipt floor | | `claim_creator_fees(recipient)` | Owner authorizes; withdraws accrued fees to chosen recipient | | `claim_team()` | Owner authorizes; transfers claimable team assets to owner | Methods returning monetary results use `Result<..., Error>`. Monetary amounts are `i128` base units. Timestamps and durations use `u64` seconds. The busy flag protects state during external transfers; it is not a user-controlled pause function. There is no auction, presale, graduation settlement, pool creation, parameter update, cancellation, or upgrade method in the current Stellar ABI. Those sale formats are live on Base. # Developer overview Route: /developers/overview Launchpad has two integration surfaces: launching and interacting with tokens, and consuming reputation. Start on **Base**. That is the live factory, the audited production app, and the network with more than $10k in volume. **Stellar** is the expansion: factory, vault, and reputation contracts are documented here so you can integrate that network as it comes up. ## Live on Base Copy the factory from [Base factory](/deployments/base). Bonding curves, auctions, and presales all run through the live app. The Base factory deploys a dedicated vault per bonding-curve launch and is constructed with Circle USDC as the pair token. | Task | Reference | | --- | --- | | Copy the Base factory | [Base factory](/deployments/base) | | Understand custody and dependencies | [Architecture](/developers/architecture) | | Choose a network and address | [Deployments](/deployments/overview) | ## Stellar contracts in source The Rust workspace contains a launch factory, bonding-curve vault, reputation registry, and shared type packages. The interface is a separate React application with prototype launch and reputation data. | Task | Reference | | --- | --- | | Create or trade a Stellar curve launch | [Launch contracts](/developers/launch-contracts) | | Read scores or enforce a label | [Reputation contract](/developers/reputation-contract) | | Interpret failures and registry events | [Events and errors](/developers/events-and-errors) | | Stellar Mainnet addresses | [Stellar Mainnet](/deployments/mainnet) | The shared Rust `ReputationClient` is implemented. It is not a published JavaScript SDK or an HTTP service. ## Planned integrations The [HTTP API](/developers/api) and [SDK](/developers/sdk) are intended to expose reputation, eligibility, launch information, and transaction preparation. Their endpoints, package names, and authentication contracts are not published. The [CLI and agent guide](/developers/cli) describes configuration-driven and natural-language launch creation. ## Integration principles Use network-specific token and contract identities. A Base `0x` factory is not a Stellar `C...` contract. Read configuration from the selected factory and vault rather than assuming every deployment uses the latest source. Keep amounts as integers in the token's base units. Base USDC uses 6 decimals. Stellar assets used by the current factory use 7. Serialize large integers without losing precision. Simulate invocations before signing and submitting. Verify final transaction results before reporting a launch, allocation, or claim as completed. ## Reuse reputation independently A consuming Stellar contract can call the registry directly and apply custom criteria. It need not create a Launchpad launch. Decide which registry and admin you trust, what the rule means for your product, and how you handle invocation failures or stale evidence. Check the deployed contract specification and [implementation status](/getting-started/status) before integrating. # Reputation contract reference Route: /developers/reputation-contract The Stellar registry stores `Scores`, immutable `Label` records, and an admin address. Shared definitions and the generated Rust client live in `packages/reputation-types`. This contract is part of the Stellar expansion. It is not the live Base factory. ## Types ```rust title="reputation-types · shared types" showLineNumbers pub struct Scores { pub github: u32, pub social: u32, pub onchain: u32, } pub struct Criteria { pub github_above: Option, pub social_above: Option, pub onchain_above: Option, pub total_above: Option, } ``` A `Label` contains `creator: Address`, `name: String`, and `criteria: Criteria`. The total score is the three-field sum in `u64`. Every supplied threshold is strict and all supplied conditions must pass. ## Read and check methods | Method | Returns | | --- | --- | | `admin()` | Current admin address | | `get_scores(address)` | `Option` | | `check(address, criteria)` | Boolean; missing records or empty criteria fail | | `get_label(label_id)` | `Option