Catalyst · How it works

How Catalyst works

A Catalyst startup goes through four distinct phases: registration, funding, active operation, and settlement. At each phase, specific contracts are called, specific actors have specific permissions, and specific guarantees apply. This page walks through the complete lifecycle so you can understand exactly what happens, when, and why.

Phase 1: Registration

A founder (or an AI agent acting as founder) starts a startup by calling CatalystRegistry.registerStartup(). The registration transaction does several things atomically:

1. 1

   ERC-20 token is deployed

   A fresh token contract is created for this startup. The token is completely owned by the registry and initially minted according to the tokenomics schedule (see Tokenomics).
2. 2

   Collateral is locked

   The founder deposits ETH into the CollateralVault, which creates a JobAssurance record following ERC-8210. If the startup fails its commitment at settlement, this collateral is claimable by investors.
3. 3

   Commitment terms are recorded

   The registration stores the minimum token price target, the commitment deadline (typically 30-180 days), and the token allocation percentage reserved for investors.
4. 4

   Two Uniswap v4 pools are initialized

   Pool 1 (USDx/USDy with the Catalyst hook) and Pool 2 (USDx/TOKEN). Both pools use the same hook contract, which enforces custom logic on every swap. See Pools for details.
5. 5

   Startup enters Funding state

   Status is now FUNDING. Investors can deposit liquidity into Pool 1. The adoption oracle starts watching but has no verdict yet (status PENDING).

Phase 2: Funding

Investors call CatalystHook.fundStartup() (or use the frontend form which wraps it) to deposit stablecoins into Pool 1. The hook does three things in one transaction:

1. 1

   Takes the USDx and USDy from the investor

   Pulls both stablecoins using permit2 allowances, converts them into a Uniswap v4 liquidity position in Pool 1.
2. 2

   Registers the investor position

   Stores a mapping of investor address to liquidity position, so the investor can later withdraw principal or claim token allocation.
3. 3

   Mints the token allocation

   Mints the investor's share of the startup token (proportional to their funding contribution) directly to their wallet. The investor now holds both LP position and tokens.

Funding can continue until either the founder closes it manually or the commitment deadline arrives, whichever happens first.

Phase 3: Active operation

This is the longest and most important phase. The startup is live, Pool 1 is generating fees from stablecoin swaps, and three parallel processes are happening:

Fee distribution

Every swap in Pool 1 generates a fee (typically 0.05% or 0.3% depending on tier). The Catalyst hook intercepts these fees via the v4 hook delta mechanism and distributes them automatically:

• • 70% to the founder as operational funding. Flows directly to the founder address recorded at registration.
• • 30% to token buyback. The hook uses these fees to execute a swap in Pool 2, buying the startup's token with USDx. The bought tokens are burned (or distributed to investors pro-rata, depending on configuration).

This is the buyback flywheel: more volume in Pool 1 means more founder funding and more token buy pressure in Pool 2. It aligns investor upside with founder success.

Oracle monitoring

In parallel, the off-chain scorer-oracle daemon is continuously reading adoption metrics from the startup's token and pools. It looks at holder count, unique swappers, wash-trading indicators, and 7-day retention. When any of these cross a threshold, it publishes a signed verdict on-chain by calling CatalystAdoptionScorer.postScore().

Verdicts have three possible states: PENDING (not enough data yet), APPROVE (metrics look legit), or DENY (metrics look manufactured). The verdict and its confidence level are stored on-chain and used at settlement time. For a full walkthrough of how the oracle reasons, see Adoption oracle.

Price discovery in Pool 2

Pool 2 (USDx/TOKEN) is where the token's market price is determined. Anyone can trade here, not just investors from the initial funding round. Arbitrageurs, speculators, and real users of the product can all buy or sell the token. The combination of organic trading plus the automated buyback from Pool 1 fees creates the price trajectory that the performance evaluator will read at settlement.

Phase 4: Settlement

When the commitment deadline passes, anyone can call PerformanceEvaluator.evaluate(startupId). The evaluator is a smart contract — no human in the loop — and it makes a binary decision based on two inputs:

• • Token price from Pool 2.Read from Uniswap v4's StateView at the evaluation block. Compared against the minimum price target set at registration.
• • Adoption verdict. Read from CatalystAdoptionScorer.getVerdict(startupId). Used as a veto: even if the price is above target, a DENY verdict means the evaluation fails (because the price gain is likely wash-traded).

Claims and the upstream field

When an investor files a claim, the claim transaction includes an upstreamfield — an optional reference to another job or actor that caused the failure. This is part of the ERC-8210 standard and was specifically designed for multi-agent workflows where one agent's failure cascades into another.

For a simple Catalyst startup, upstreamis usually empty — the founder is solely responsible. But if a startup depends on another service (e.g. an oracle, a data provider, a third-party AI model) and that dependency caused the failure, the claim can reference it, enabling chained claims and attribution. This is a structural feature of the standard, not a Catalyst-specific addition.

State machine summary

Where to go next

• Adoption oracle — deep dive into how verdicts are produced
• Roles — who can call which functions
• Architecture — on-chain contracts and off-chain services
• Pools — the two-pool design in detail