2.2 TokenFactory Contract Copied

The TokenFactory contract is the heart of the system on each chain. Its responsibilities include:

• Token Deployment: It has a function (e.g.

  createToken(name, symbol)) that deploys a new ERC-20 Meme Token contract. The TokenFactory is typically set as the owner/minter of the token. Each TokenFactory can manage many tokens (each token corresponds to one bonding curve sale). The newly created token’s address is emitted in a CreatedMemeToken

  event for indexing.

• Bonding Curve State: The TokenFactory tracks the state of the bonding curve for each token. This includes the total token supply sold so far (across all chains), and whether the sale is still ongoing or has finalized. It may maintain an internal mapping of token -> saleState

  (with fields like current supply, maybe a boolean for active/ended). The TokenFactory uses this state to compute prices and ensure the bonding curve rules are enforced for each buy or sell.

• Buy/Sell Functions (Single-Chain): The contract exposes functions for users to buy and sell tokens during the bonding curve phase. For example,

  buy(tokenAddress, amountDesired)

  and

  sell(tokenAddress, amount)

  (the exact function signatures may vary). When a user buys:

  1. The user sends the required payment (in the base currency for that chain, e.g. ETH on Ethereum, BNB on BSC, AVAX on Avalanche, etc., or possibly a stablecoin depending on configuration).

  2. The TokenFactory calculates how many tokens can be minted for the given payment using the bonding curve formula (see Section 4). Alternatively, the user might specify an amount of tokens to buy, and the contract calculates the cost and ensures the sent value is sufficient.

  3. It then mints the appropriate number of tokens in the ERC-20 contract and transfers them to the buyer’s address.

  4. It updates the token’s total sold supply and emits a

     BoughtMemeToken(buyer, token, amount, cost)

     event.

  For a sell, the user must first approve the TokenFactory to spend their tokens. The TokenFactory will:

  5. Calculate the refund amount based on the bonding curve (essentially the inverse of the buy calculation).

  6. Burn the specified number of tokens from the user (reducing supply in the ERC-20 contract).

  7. Transfer the refund payout in the base currency from its reserves to the user.

  8. Update the total supply and emit a

     SoldMemeToken(seller, token, amount, payout)

     event.

• Cross-Chain Operations: Each TokenFactory can also handle cross-chain buy and sell requests via LayerZero. If a user on a different chain wants to buy a token, their local TokenFactory will forward the request to the TokenFactory on the token’s home chain (the chain where the token was originally created) – see Section 3 for details. The home chain factory will execute the price calculation and minting, then instruct the remote factory to deliver tokens to the user. Similarly, sell orders for tokens held on a non-origin chain may involve cross-chain messages to synchronize burning and payouts. The TokenFactory contract implements LayerZero’s

  lzReceive

  interface to receive messages from other chains and act on them.

• Liquidity Finalization: The TokenFactory monitors when the token’s market cap or supply threshold is reached (the predefined cap that ends the bonding curve phase). Once the threshold is hit, it marks the sale as completed (no further buys allowed). It then triggers the initial liquidity provisioning:

  • The contract calculates pool parameters and calls the Uniswap V2 Router to create a pair (if not already) between the meme token and the base asset. It supplies liquidity using the funds collected from buyers and an equivalent amount of the minted tokens. Typically, it will use a portion of the collected base currency and a portion of tokens such that the pool starts at the final bonding curve price. For example, it might contribute all remaining base currency and the equivalent token amount, leaving no surplus.

  • It then locks liquidity by sending the liquidity provider (LP) tokens to a burn or dead address (or otherwise disabling their removal). This ensures the pool’s liquidity cannot be rug-pulled. (In Pump.fun’s Solana version, they deposit to Raydium and burn a portion of liquidity; here the Uniswap V2 LP tokens can be burned to achieve a similar lock.)

  • After this, the token becomes freely tradable on the DEX, and the bonding curve functions in the TokenFactory are typically disabled for that token (trading is handed off to the DEX).

• Internal References: On deployment, each TokenFactory is configured with references to external addresses it needs:

  • The LayerZero endpoint contract for its chain (for message sending/receiving).

  • The local UniswapV2 (or equivalent) Factory and Router addresses, so it can create pairs and add liquidity. These are stored in the TokenFactory (passed in via constructor or set during initialization).

  • A mapping of LayerZero chain IDs to the address of the TokenFactory on that chain (the peer mapping, set via the

    setPeer

    function). This mapping is critical for security: the TokenFactory will only accept cross-chain messages from known peer contract addresses. It also uses this mapping to direct messages to the correct contract on the destination chain.

In summary, the TokenFactory acts as a minter, treasurer, and controller for the token during its initial launch phase. There is one TokenFactory instance per chain, all of which work together to give a unified experience.

2.3 Meme Token (ERC-20) Contract

EVM Contract