Scenario: A user on Chain B (e.g., BSC) buys a token that was launched on Chain A (e.g., Ethereum). We assume the bonding curve is still active and both Chain A and B’s TokenFactories are set up as peers.

1. User Action – Buy (Chain B): The user on BSC calls the

   buy

   function on the BSC TokenFactory, targeting the token (which was created on Ethereum). They send BNB as payment. From the user’s perspective this is similar to a local buy.

2. Local Handling on BSC: The BSC TokenFactory recognizes that it is not the “home” factory for this token (perhaps via a mapping of token -> homeChain). Instead of minting immediately, it prepares a cross-chain request. It may lock the user’s payment (BNB) in itself (or mark the amount) and then invoke LayerZero to communicate with Ethereum.

3. Send Message to Ethereum: The BSC TokenFactory calls the LayerZero Endpoint’s

   send

   function to dispatch a message to Ethereum. The message contains: the target TokenFactory address on Ethereum, the details of the buy (token ID, buyer address, amount paid, etc.). BSC TokenFactory likely temporarily stores the buyer’s info and amount until confirmation.

4. Processing on Ethereum: The Ethereum TokenFactory (home) receives the message in

   lzReceive

   . It now executes the price calculation for the buy using the current global supply $S$. It determines that the user’s BNB (converted to an equivalent value in ETH terms, or the contract knows the amount in BNB) corresponds to, say, $\Delta S$ tokens. It then updates $S := S + \Delta S$ for the token’s global supply. The Ethereum TokenFactory does not mint tokens on Ethereum to the user (the user is on BSC). Instead, it prepares a return message. It might also record that $\Delta S$ tokens have been allocated to BSC for this buyer (for accounting).

5. Return Message – Mint on BSC: The Ethereum TokenFactory, after updating state, sends a LayerZero message back to BSC. This message instructs the BSC TokenFactory to mint the $\Delta S$ tokens to the buyer’s address. (If the token’s ERC-20 contract on BSC didn’t exist yet, the Ethereum factory could have included a command to deploy it, but likely all chain contracts are pre-deployed or deployed on first cross interaction.)

6. Mint on BSC: The BSC TokenFactory receives the message and now mints $\Delta S$ tokens on BSC’s instance of the ERC-20 token for the buyer. It finalizes the purchase by releasing the tokens to the user.

7. Finalize and Event: The BSC TokenFactory updates its local record (if it keeps one) of supply or at least knows the operation succeeded. It then emits a

   BoughtCrosschainMemeToken(srcChainId=1 (Ethereum), buyer, token, amount=\Delta S, cost=Y BNB)

   event. This event signals a cross-chain buy was completed.

8. User Receives Tokens: The user now has the tokens in their BSC wallet, even though the sale was coordinated by Ethereum’s contract. The user’s BNB payment remains with the BSC TokenFactory (to be used for BSC liquidity).

This whole flow might take place within the single transaction the user initiated (LayerZero can perform the round trip if configured with an Ultra Light Node return). However, depending on setup, the buy could also be asynchronous – typically, though, it can be near-instant. From the user’s perspective, it’s one action: they receive tokens shortly after confirming the transaction, without needing to know anything happened on Ethereum.

If another user on Ethereum or any other chain concurrently buys, both will be processed in order, and price will adjust accordingly with global supply.

5.4 Cross-Chain Sell Flow

Cross Chain Sell Logic