2. Contract Architecture Breakdown

The system consists of several smart contracts and libraries working together:

• TokenFactory (Core Contract): The TokenFactory is the primary contract that orchestrates token creation, the bonding curve buy/sell logic, cross-chain messaging, and liquidity deployment.

• Meme Token (ERC-20): For each token launched, an ERC-20 contract is deployed (often called the MemeToken). This contract represents the token itself on a given chain. It is minted and burned exclusively by the TokenFactory to adjust supply.

• LogExpMath Library: A math utility library that provides high-precision fixed-point implementations of natural logarithm and exponential functions. TokenFactory uses this for calculating the exponential bonding curve pricing.

• TokenFactoryHelper Library: An auxiliary library that contains helper functions for price and cost calculations (using LogExpMath), and possibly utility functions for integrating with Uniswap V2 (e.g. computing liquidity amounts).

Below we breakdown each major component and its role:

2.1 Solana-EVM Cross-Chain Integration Copied

One of the most technically innovative aspects of the TokenFactory architecture is its seamless interoperability between the Ethereum Virtual Machine (EVM) and Solana's runtime via LayerZero's cross-chain messaging protocol. This cross-domain capability enables native token minting and swapping between Solana-based SPL tokens and Ethereum-based ERC-20 tokens without relying on traditional wrapped token mechanics.

Architecture Overview

The Solana-EVM integration involves the following core components:

1. Solana Program (Rust)
   A Solana program listens for cross-chain messages originating from Ethereum. This program is responsible for:

   • Locking or unlocking SPL tokens.

   • Verifying LayerZero message authenticity via its Solana endpoint.

   • Executing CPI (Cross-Program Invocation) calls to the SPL Token Program for minting/burning.

2. Ethereum Smart Contract (Solidity)
   A mirrored ERC-20 contract allows Ethereum users to:

   • Mint equivalent ERC-20 tokens when SPL tokens are locked on Solana.

   • Burn ERC-20 tokens to unlock their corresponding SPL tokens on Solana.

   • Relay encoded LayerZero payloads to LayerZero’s endpoint for routing.

3. LayerZero Endpoint (V2)
   The LayerZero endpoint enables atomic messaging between heterogeneous blockchains. For Solana-EVM communication:

   • Messages are encoded with

     msgType, token address, recipient, and quantity.

   • The destination chain verifies authenticity and processes instructions deterministically.

   • Payloads are processed either via CPI (Solana) or direct contract calls (EVM).

Payload Encoding Format

(uint8 msgType, bytes32 tokenAddress, bytes32 recipient, uint128 ethAmount, uint256 tokenQty)

This format ensures deterministic decoding on both platforms (Solana via Borsh / manual unpacking, Ethereum via ABI).

Message Flow

• User burns ERC-20 tokens on Ethereum.

• Solidity contract sends LayerZero message to Solana endpoint.

• Solana program decodes message, verifies endpoint origin, and mints SPL tokens.

• User receives native Solana tokens (and vice versa in reverse flow).

Novelty and Technical Significance

This Solana-EVM bridge bypasses legacy bridges and avoids liquidity fragmentation by:

• Utilizing native token contracts on both chains.

• Encoding messages in a custom format understood by both Rust and Solidity environments.

• Leveraging LayerZero’s Ultra Light Node (ULN) security guarantees.

The bridge is not a synthetic token bridge but a true inter-chain mint/burn relay system, contributing to a universal liquidity layer across chains.

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 Copied

Each token launched by the TokenFactory is an ERC-20 smart contract (often a simple implementation with a name, symbol, and 18 decimals). The TokenFactory deploys this contract (e.g. via

new ERC20Token(...)

) when a user creates a new token. Important aspects of the token contract:

• Mint/Burn Control: The token’s minting and burning is controlled by the TokenFactory. Typically, the token contract might use an Ownable or MINTER role pattern where the TokenFactory contract is the only address allowed to mint or burn tokens. This ensures that all supply changes happen through the bonding curve logic in the TokenFactory.

• Cross-Chain Deployment: In a cross-chain scenario, the same token may exist on multiple chains. The system can deploy identical ERC-20 contracts for the token on each chain, or use a single canonical contract and represent ownership on other chains via messaging. A common pattern (used here) is to deploy a token contract on each chain and have the TokenFactories coordinate minting so that the total supply across all chains is consistent. For example, if a token is created on Ethereum, an ERC-20 is deployed on Ethereum (with initial supply 0). If users on BSC also buy the token, an ERC-20 for that token will be deployed on BSC as well (by the BSC TokenFactory when needed), and some of the total supply will be minted on BSC. The TokenFactories ensure the sum of supplies on all chains follows the bonding curve’s supply count.

• Standard ERC-20 Behavior: Aside from controlled minting, these Meme Token contracts behave like standard ERC-20 tokens. Users can transfer them, add them to liquidity pools, etc. Once the bonding curve phase is over, the token contract doesn’t restrict transfers (it’s fully liquid). During the bonding curve phase, transfers might be allowed as well (users could technically trade OTC by sending tokens, though that’s outside the intended flow).

• No Special Governance or Taxes: Typically, these meme token contracts are kept simple (no fee on transfer, no complex governance logic). They exist solely to track balances. All pricing and purchase logic is kept in the TokenFactory instead of the token contract.

Because the token contracts are minimal, developers forking this system can easily reuse the same ERC-20 implementation or swap in a custom one if needed (as long as it allows the TokenFactory to mint/burn).

2.4 LogExpMath & TokenFactoryHelper Libraries Copied

The LogExpMath and TokenFactoryHelper libraries implement the mathematical logic for the bonding curve and assist with other calculations:

• LogExpMath: This library provides functions to compute natural exponentials and logarithms in Solidity with high precision. Since the bonding curve uses an exponential formula (which involves powers and logs), this library is crucial. It likely originates from the Balancer V2 utility libraries (which include a LogExpMath.exp(unit256 x)

  might return $e^x$ (with x given in 18-decimal fixed point format) and similarly for log.4

• TokenFactoryHelper: This library likely builds on LogExpMath to provide higher-level bonding curve calculations. Key functions might include:

  • Price Function: Compute the current price of the token given the current supply (using the formula

  • Buy Cost Calculation: Given a current supply S and a number of tokens Delta S to mint, compute the cost in base currency. This is essentially the integral of the price function: For an exponential curve P, this resolves to: cost:

    $\text{cost} = \frac{a}{b} \left( e^{b(S+\Delta S)} - e^{bS} \right)$

  • Sell Reward Calculation: Similarly, for a sell of $\Delta S$ tokens (reducing supply from $S$ to $S-\Delta S$), compute the payout (integral in reverse, or use the same formula to find the value difference).

  • Inverse Calculation: Given an amount of base currency a user wants to spend, determine how many tokens $\Delta S$ that would buy. This may involve using

    log

    to invert the cost integral formula.

  • Threshold checks: Possibly functions to check if adding a certain supply would exceed the cap or to compute the remaining supply until the cap is reached.

These functions allow the TokenFactory to focus on business logic while offloading math to the library. For example, a pseudo-code for buy might be:

uint256 currentS = totalSupply[token];
uint256 cost = TokenFactoryHelper.getCost(currentS, amount);
require(msg.value >= cost, "Insufficient payment");
totalSupply[token] = currentS + amount;
ERC20(token).mint(msg.sender, amount);

where

getCost

internally uses

LogExpMath

to compute the exponential differences.

Using these libraries, the TokenFactory can handle the exponential bonding curve pricing precisely. This avoids issues with overflow or lack of precision in computing $e^x$ for large x. The choice of an exponential curve ensures the price starts very low and then grows faster as supply increases, preventing the supply from growing infinitely. (Early buyers might pay virtually nothing per token, but as more tokens are minted, the price per token rises exponentially.)