Autolaunch

June 18, 2026 · View on GitHub

Autolaunch helps an agent with a real edge turn that edge into runway. It gives the agent a market to raise aligned capital, fund compute and distribution, and keep supporters active after launch.

If you already have an agent, use regents-cli and start with:

regents run
regents run --fold autoresearch
regents auth login --audience autolaunch
regents identity ensure
regents autolaunch prelaunch wizard

Start with Techtree evidence before preparing a launch. If you do not have an agent yet, use regents.sh to make one.

The sale model is a Continuous Clearing Auction: buyers choose a budget and a max price, the auction clears block by block, and launch capital goes toward liquidity and the agent Safe.

Product Direction

Autolaunch centers on a cleaner market and launch workspace:

  • a modern public site for agent launches, auctions, positions, and subject pages
  • command-first launch planning through regents-cli
  • search and filters for live markets, positions, and returns
  • shareable filtered market views
  • real Regent status and staking reads for the connected wallet
  • cleaner subject pages with staking, claims, revenue, ingress, and next actions in one place
  • one action panel pattern for wallet actions and prepared operator actions
  • faster subject reads backed by local Cachex for hot display state
  • a slimmer Elixir/Phoenix structure with product areas split by launch, lifecycle, contracts, trust, revenue, staking, and AgentBook

Autolaunch is built for agents that can earn but need capital before revenue catches up. The product should make three things obvious: what is live, what the agent needs next, and what a backer can do now.

A prelaunch plan can link a Techtree evidence packet. Readiness shows that packet as supporting evidence only; it does not make a launch automatic, and an operator still approves the launch.

For Agents

Use regents-cli for launch work:

regents auth login --audience autolaunch
regents identity ensure
regents autolaunch safe wizard
regents autolaunch safe create
regents autolaunch prelaunch wizard
regents autolaunch prelaunch validate
regents autolaunch prelaunch publish
regents autolaunch launch run
regents autolaunch launch monitor
regents autolaunch launch finalize
regents autolaunch vesting status

Use the website for market discovery, auction participation, subject pages, staking, claims, trust follow-up, and AgentBook.

For an operator-facing deployment and launch sequence, use docs/operator_runbook.md. For launch, subject, revenue, and next-action wording, use docs/operator-status.md. The canonical product rules live in docs/product_invariants.md, and the hardening tracker lives in docs/mainnet_readiness_checklist.md.

Humans

Quick Start

cp .env.local.example .env.local
direnv allow
mix setup
mix phx.server

For day-to-day validation and asset work:

mix test
mix precommit
mix assets.build
mix assets.deploy
mix autolaunch.doctor
mix autolaunch.beta_check
AUTOLAUNCH_MOCK_DEPLOY=true mix autolaunch.smoke
mix autolaunch.verify_deploy --job <job-id>

If you need the launch docs that explain the public auction flow, start with AUTOLAUNCH_AUCTIONS_GUIDE.md.

Why CCA Auctions

Autolaunch uses Continuous Clearing Auctions because we think they are the right launch model for quality projects and teams that need to bootstrap liquidity without turning launch day into a race for advanced users and bots.

The simple buyer mental model is:

  • choose a total budget
  • choose the highest token price you are willing to pay
  • let the order run across the remaining blocks like a TWAP
  • receive tokens only in blocks where the clearing price stays below your max price
  • stop automatically once the clearing price moves above your cap

The intended game theory is simple too:

  • bid early with your real budget and your real max price
  • your max price protects you from paying above what you actually believe is fair
  • waiting only shortens your participation window and usually worsens your average price
  • with sane auction timing, there is far less room for sniping, bundling, sandwiching, or other timing games
  • everyone gets access to the same block clearing price instead of specialized speed advantages

That is the core product claim: less timing game, more real price discovery.

The current live launch economics are:

  • 10% of the 100 billion supply is sold in the auction
  • 5% of the supply is reserved for the Uniswap v4 LP position
  • half of auction $REGENT is used for that LP position
  • the other half of auction $REGENT is swept to the agent Safe for business operations
  • the remaining 85% of tokens vest to the agent treasury over 1 year

The current fixed fee rules are:

  • the launch-pool fee is fixed at 2% on swaps in the official pool
  • that 2% split is fixed at 1% to Regent and 1% to the agent treasury
  • subject USDC received first sends a fixed 1% skim into the shared $REGENT staking contract
  • 10% of the remaining 99% buys $REGENT for the agent treasury
  • the remaining 89.1% stays in the subject lane, where stakers earn their formula share and the rest accrues to the agent treasury

What Runs Where

The main product routes are:

  • / and /docs for the public home and auction explainer
  • /launch for the guided launch flow
  • /contracts for the operator contract console
  • /auctions, /auctions/:id, and /positions for auction search, shareable filters, and position views
  • /subjects/:id for subject status, staking, claims, revenue routing, ingress, and available actions
  • /agentbook for the human proof flow
  • /health for readiness checks
  • /v1/agent/* for commands signed by a saved Autolaunch sign-in
  • /v1/auth/privy/session for browser session exchange
  • /v1/app/prelaunch/* for saved launch drafts, hosted metadata, and upload-backed launch assets
  • /v1/app/lifecycle/* for launch monitoring, finalize guidance, and vesting status
  • /v1/app/regent/staking/* for the Autolaunch web surface on the Platform-owned REGENT staking rail
  • /v1/app/agents, /v1/app/launch/*, /v1/app/auctions/*, /v1/app/bids/*, /v1/app/subjects/*, /v1/app/contracts/*, /v1/app/agentbook/*, and /v1/app/ens/link/* for the supporting JSON flows

/v1/app/agents is the agent inventory. /v1/app/agents/:id/readiness checks whether an agent is ready to launch.

Public writes and heavier account reads return a standard rate_limited error with a retry-after header when a client sends too many requests.

Contract Console

/contracts is the operator-facing contract surface. It accepts job_id and subject_id query parameters and reads the current launch stack or subject stack directly from the backend.

What it shows:

  • launch deployment provenance and the returned stack addresses
  • live strategy, vesting, fee-registry, fee-vault, splitter, ingress, and subject-registry state
  • prepared transaction payloads for advanced contract actions

Action modes are intentionally split:

  • wallet actions stay on auction and subject pages for bid, stake, unstake, claim, and ingress sweep
  • confirmed wallet actions are registered after the transaction hash exists
  • prepared operator actions live in /contracts for multisig or operator submission

Configuration

Fly environment names live in .env.example. Local development and operator rehearsal names live in .env.local.example; copy that file to .env.local and run direnv allow. The important groups are:

  • App runtime: DATABASE_URL or LOCAL_DATABASE_URL, SECRET_KEY_BASE, PHX_HOST, PORT
  • Privy auth: PRIVY_APP_ID, PRIVY_VERIFICATION_KEY
  • SIWA sidecar: SIWA_INTERNAL_URL, SIWA_HTTP_CONNECT_TIMEOUT_MS, SIWA_HTTP_RECEIVE_TIMEOUT_MS
  • Upload storage: AUTOLAUNCH_UPLOAD_DIR
  • Launch deployment: AUTOLAUNCH_RPC_URL, AUTOLAUNCH_CCA_FACTORY_ADDRESS, AUTOLAUNCH_UNISWAP_V4_POOL_MANAGER, AUTOLAUNCH_UNISWAP_V4_POSITION_MANAGER, AUTOLAUNCH_DEPLOY_WORKDIR, AUTOLAUNCH_DEPLOY_BINARY, AUTOLAUNCH_DEPLOY_SCRIPT_TARGET, AUTOLAUNCH_DEPLOY_ACCOUNT, AUTOLAUNCH_DEPLOY_SENDER, AUTOLAUNCH_FACTORY_OWNER_ADDRESS
  • Launch contracts: AUTOLAUNCH_REVENUE_SHARE_FACTORY_ADDRESS, AUTOLAUNCH_REVENUE_INGRESS_FACTORY_ADDRESS, AUTOLAUNCH_LBP_STRATEGY_FACTORY_ADDRESS, AUTOLAUNCH_TOKEN_FACTORY_ADDRESS from UERC20_FACTORY_RESULT_JSON.factoryAddress, AUTOLAUNCH_ERC8004_SUBGRAPH_URL
  • Base identity lookups: AUTOLAUNCH_BASE_MAINNET_RPC_URL, AUTOLAUNCH_BASE_MAINNET_ERC8004_SUBGRAPH_URL, AUTOLAUNCH_BASE_MAINNET_IDENTITY_REGISTRY_ADDRESS
  • Base verifier address books: AUTOLAUNCH_BASE_MAINNET_UNISWAP_V4_POOL_MANAGER, AUTOLAUNCH_BASE_MAINNET_REVENUE_SHARE_FACTORY_ADDRESS, AUTOLAUNCH_BASE_MAINNET_REVENUE_INGRESS_FACTORY_ADDRESS, AUTOLAUNCH_BASE_MAINNET_LBP_STRATEGY_FACTORY_ADDRESS
  • Launch-script settings: AUTOLAUNCH_FACTORY_OWNER_ADDRESS, STRATEGY_OPERATOR, OFFICIAL_POOL_FEE, OFFICIAL_POOL_TICK_SPACING, CCA_FLOOR_PRICE_Q96, CCA_TICK_SPACING_Q96, AUCTION_DURATION_BLOCKS, CCA_PREBID_BLOCKS, CCA_FINAL_BLOCK_BPS, CCA_START_BLOCK_OFFSET, CCA_CLAIM_BLOCK_OFFSET, LBP_MIGRATION_BLOCK_OFFSET, LBP_SWEEP_BLOCK_OFFSET, optional UERC20 metadata fields, optional AUTOLAUNCH_IDENTITY_REGISTRY_ADDRESS, optional CCA_VALIDATION_HOOK. AUCTION_DURATION_BLOCKS=86400 gives a 48-hour Base convex sale window, then the script appends the final one-block release. CCA_PREBID_BLOCKS=0 and CCA_FINAL_BLOCK_BPS=3000 are the default schedule settings. CCA_START_BLOCK_OFFSET=300 leaves about ten minutes for the staged broadcast to finish before bidding opens. The default REGENT auction grid uses a 0.1 REGENT floor with 0.001 REGENT ticks, which maps to about \0.000001 per agent token at a $0.00001 REGENT reference and keeps bids aligned through the $0.10 range. Autolaunch supplies CCA_REQUIRED_CURRENCY_RAISED from the launch job when it runs the deploy script.
  • Regent staking rail: REGENT_STAKING_RPC_URL, ETHEREUM_RPC_URL, REGENT_STAKING_CHAIN_ID, REGENT_STAKING_CHAIN_LABEL, REGENT_REVENUE_STAKING_ADDRESS, REGENT_STAKING_OPERATOR_WALLETS
  • Contract admin operators: AUTOLAUNCH_CONTRACT_ADMIN_OPERATOR_WALLETS
  • AgentBook and World ID: WORLD_ID_APP_ID, WORLD_ID_ACTION, WORLD_ID_RP_ID, WORLD_ID_SIGNING_KEY, WORLDCHAIN_RPC_URL, WORLDCHAIN_AGENTBOOK_ADDRESS, WORLDCHAIN_AGENTBOOK_RELAY_URL, BASE_MAINNET_RPC_URL, BASE_AGENTBOOK_ADDRESS, BASE_AGENTBOOK_RELAY_URL

The v1 production launch path is Base mainnet. Use local and fork tests for launch rehearsal.

For the current promotion path, use the root launch guide at /Users/sean/Documents/regent/docs/regent-local-and-fly-launch-testing.md. It treats Regent staking and Autolaunch production launches as Base mainnet rails, and the guided CLI lifecycle as the main operator path.

If product copy, launch docs, or contract docs disagree about the active rules, use docs/product_invariants.md as the source of truth and update the other surface.

REGENT Staking Rail

Autolaunch exposes a separate Regent staking rail for Regent Labs itself.

  • It is not part of the launch flow itself.
  • Its production target is Base mainnet.
  • It uses the existing $REGENT token on the configured Base network as the stake token.
  • It accepts USDC deposits manually on the configured Base network.
  • Each USDC deposit is accounted against the fixed $REGENT revenue-share supply denominator. Staked $REGENT earns its proportional amount, and the rest accrues for the Regent treasury.
  • Other-chain Regent income still lands in Treasury A first, then gets bridged manually to Base USDC and deposited into the staking contract.

This rail is separate from agent subject splitters:

  • agent subject splitters are per-agent revenue-rights contracts on the active Base launch network
  • REGENT staking is one singleton company-token rewards rail on the configured Base network
  • subject splitters send 1% of recognized subject USDC into REGENT staking, set aside 10% of the remaining 99% as pending $REGENT buyback settlement for the agent treasury, and leave 89.1% in the subject revenue lane

For a detailed human-readable walkthrough, see docs/stake-split-payment-receiver-flow.md.

Launch Flow

Autolaunch expects the current CCA_RESULT_JSON payload from the configured deployment script. The contract source of truth lives in the local Foundry workspace under contracts/.

The operator flow is CLI-first:

  1. save a prelaunch plan
  2. validate and publish the hosted metadata draft
  3. run the launch from that saved plan
  4. monitor the auction lifecycle
  5. finalize post-auction actions
  6. release vested tokens later

The launch controller returns the strategy, vesting wallet, fee registry, fee vault, fee hook, subject registry, revsplit, and default ingress addresses. The app stores that output and uses it for post-launch tracking.

Launch responses also carry a reputation_prompt when the user should do follow-up trust steps. That prompt links into /ens-link for ENS and /agentbook for the human proof flow. The launch page uses those same links after the token exists.

Important launch rules:

  • Each auction sells 10% of a 100 billion supply
  • The launch strategy holds another 5% for LP migration and sends 85% into the vesting wallet
  • Every Base mainnet auction clears in $REGENT
  • Buyers set a total budget and a max price, and the order runs across the remaining blocks like a TWAP
  • Each block clears at the highest price where demand exceeds supply, and no one pays above their stated max price
  • Launch buyers must stake the claimed tokens to earn Base USDC once it reaches the subject revenue contract
  • Mock deploy is opt-in through AUTOLAUNCH_MOCK_DEPLOY=true
  • Subject USDC is counted once Base USDC reaches the revsplit
  • Funds waiting in an ingress account have not reached the revsplit yet; they can be swept before a pending share change takes effect, and anything swept later uses the live share at that time
  • The fee hook is the $REGENT launch-side fee lane, while the revsplit is the ongoing Base USDC revenue-rights lane
  • AUTOLAUNCH_DEPLOY_SCRIPT_TARGET is required at runtime
  • config/runtime.exs is the runtime environment path; config/dev.exs stays limited to dev-only browser tooling and reload support

The CLI is the first stop for launch planning, launch execution, monitoring, finalize guidance, and vesting follow-up.

Contributor Rules

  • API and CLI changes start in the YAML source-of-truth files, then the app and CLI are updated to match.
  • Autolaunch HTTP behavior lives in docs/api-contract.openapiv3.yaml.
  • Autolaunch CLI behavior lives in docs/cli-contract.yaml.
  • Agent-signed Regent staking behavior is Platform-owned and lives in ../platform/api-contract.openapiv3.yaml. Autolaunch hosts its own browser route surface for the same staking rail.
  • Keep one current contract shape. Remove obsolete handling instead of documenting or preserving it.
  • Use Foundry for EVM contract development and testing.
  • Use plain public copy: say what a person can do, what happens next, and why it matters.

Before including Autolaunch in a cross-repo release, use the shared Regent release spine in ../docs/release-spine.md and the Autolaunch operator status checks in docs/operator-status.md.

Commands

Run these from the repository root:

mix setup
mix test
mix precommit
mix assets.build
mix assets.deploy
mix autolaunch.doctor
mix autolaunch.beta_check
AUTOLAUNCH_MOCK_DEPLOY=true mix autolaunch.smoke
mix autolaunch.verify_deploy --job <job-id>

mix autolaunch.doctor is the blocking release gate for database reachability, launch-chain config, SIWA, and deploy dependencies. mix autolaunch.beta_check is the read-only public beta gate for database reachability, required Base addresses, route exposure, and the Regent staking plus launch read paths. mix autolaunch.smoke is the synthetic in-repo launch-to-subject smoke. mix autolaunch.verify_deploy --job <job-id> is the post-deploy live-chain check for ownership acceptance, factory authorization cleanup, fee-vault canonical tokens, migration, pool and position recording, hook state, and subject wiring.

Doctor checks map directly to product breakage:

  • database failure means launch jobs, bids, sessions, and subject action registrations cannot be stored
  • Privy failure means browser and CLI session exchange cannot start authenticated flows
  • SIWA failure means launch creation cannot verify the wallet signature
  • deploy binary, workdir, or script-target failure means launches cannot be executed on that node
  • launch-chain RPC failure means launch reads, quote reads, and transaction verification become unreliable
  • upload storage failure means hosted prelaunch images cannot be saved or served
  • launch-script input failure means a real deploy is missing a value the Foundry launch script requires
  • trust-network warnings only affect trust follow-up surfaces; launch and auction flows should still work

What Must Be Alive

Autolaunch is not a static frontend. A working environment needs:

  • a live Phoenix node This handles Privy session exchange, SIWA verification, launch preview, launch creation, in-process launch job execution, queue polling, quote computation, transaction registration, and the contract-read models used by the web app and CLI.
  • a live Postgres database Jobs, auctions, bids, human sessions, and subject action registrations are all persisted there.
  • a live launch-chain RPC The app uses it for launch status reads, auction reads, quote checks, and transaction verification.
  • a reachable SIWA sidecar Launch creation depends on it for signature verification.
  • the Foundry deploy binary plus the configured deploy workdir and script target on the launch node Without those, the backend cannot run the launch deployment at all.

The Phoenix aliases in mix.exs also include ecto.reset and the usual asset setup flow.

Repo Map

  • lib/ - Phoenix app code, LiveView screens, launch logic, AgentBook logic, and SIWA support
  • config/ - runtime, development, test, and release configuration
  • priv/ - migrations, seed data, static assets, and gettext files
  • test/ - unit, controller, and LiveView coverage
  • contracts/ - local Foundry workspace for launch, revsplit, and ingress contracts
  • AUTOLAUNCH_AUCTIONS_GUIDE.md - public auction guide
  • SKILL.md - repo-level autolaunch onboarding skill
  • docs/autolaunch_examples.json - canonical machine-readable payload examples
  • AUTOLAUNCH_PORT.md - port and process notes
  • PRODUCT_SURFACE_PROPOSAL.md - product surface direction

External Dependencies

The CLI namespace, routing flags, and CLI-side trust follow-up commands are tracked in regents-cli. This repo documents the shared launch contract and the web surfaces only.