2.4 LogExpMath & TokenFactoryHelper Libraries

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

• 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 $P(S) = a \cdot e^{b S}$).

  • 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: $$ ∫SS+ΔS​P(x)dx $$ For an exponential curve $P = a e^{b x}$, this resolves to: $$ cost=ba​(eb(S+ΔS)−ebS) $$

  • 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.)2.3 Meme Token (ERC-20) Contract

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).