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:

• stellar-contract/
  • contracts/
    • factory/
    • bonding-curve/
    • reputation/
  • packages/
    • launchpad-types/
    • reputation-types/
• evm-contract/
  • src/
    • Factory.sol
    • BondingCurve.sol

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.

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.