Understand
the journey.

Genesis helps projects plan a move from Solana to Robinhood Chain. A project chooses its destination identity, a permanent migration or a two-way bridge, and a liquidity plan. Holders participate through the reviewed route using their own wallets. The project decision sets the route; individual holders do not choose different return rights for the same destination token.

Moving a token and creating a market are separate jobs. Migration determines what happens to the original tokens and how matching destination tokens arrive. Liquidity determines whether people can buy and sell those destination tokens at a useful price. A successful migration receipt does not, by itself, prove that a pool is funded or ready for meaningful trades.

1. 01

   Identify the original token

   Provide the Solana mint, project details, developer wallet and contact email. Review the available source metadata and choose the proposed destination identity.

2. 02

   Choose the route

   Select permanent migration or a two-way bridge. Read and acknowledge the specific return terms; changing the route requires reviewing its terms again.

3. 03

   Describe the market funding

   Explain who supplies destination tokens and ETH, the intended opening price and whether you are requesting partial Genesis support. A proposed contribution is not a funded pool.

4. 04

   Review and submit

   Check the full proposal. The saved private receipt records the route, identity choice and liquidity plan. Keep access to the original browser used to submit.

Review states are Received, In review, More information needed, Shortlisted for planning and Not proceeding. Review notes appear in the private receipt. If information is requested, the applicant can reply from the original receipt browser. Genesis does not send those notes as an automatic email or chat message.

Submissions are private and are not automatically added to the public migration board. Receipt access is tied to the submitting browser session; a receipt URL alone is not a public project page. Avoid clearing that browser’s site data while an application is active.

The application offers Keep original identity and Create a new identity. The source lookup verifies the Solana mint and reads available matching metadata. You can retain that identity or propose a different name, symbol, artwork, description, website, X profile and Telegram link. Side-by-side previews keep the original and destination identities distinct.

Missing metadata stays missing; Genesis does not invent an image or name. A lookup failure still allows a manually entered custom proposal. Unavailable artwork uses an initials fallback. Review the destination again after changing the mint, editing metadata or restoring a draft. Keeping the original identity preserves the selected available fields, not an automatic live mirror of every future source edit.

Your receipt includes the choice and a downloadable identity proposal with a content fingerprint. The proposal is not a deployed token. Broader campaigns still need that exact identity bound to the deployment review, verified token precision, durable artwork publishing and destination registry or token-list integration. The current receiver path requires a verified six-decimal source. Other precision needs a separately implemented and reviewed route.

A two-way bridge suits a community that wants access to another market while retaining redemption into its original token. Permanent migration suits a community that intends participating balances to leave Solana. In both cases, holders must understand the configured authorities, delivery process, costs and trading conditions.

1. 01

   Verify the route and wallets

   The commissioned source route and destination receiver must match the reviewed token, networks and recipient. The holder proves control of the required wallets and supplies the needed token inventory and network fees.

2. 02

   Review the exact burn

   Genesis checks the configured amount and live readiness, then shows a time-limited transaction review. The holder approves the exact source-token amount, destination address and cost bounds in their wallet.

3. 03

   Confirm the source transaction

   The source transaction burns the participating originals and emits the cross-chain message. Its successful finalized receipt identifies the message and amount. If the source transaction fails atomically, that failed transaction does not leave a completed burn.

4. 04

   Authenticate and deliver

   The configured LayerZero verifiers authenticate the source message. Destination execution credits the reviewed recipient. Genesis checks the message identity, receipt and actual token movements before reporting delivered.

5. 05

   Check the new balance

   The holder uses the destination token on Robinhood Chain. Trading requires a separately funded pool. A delayed destination execution is resolved using the original message, without another source burn.

On the outbound journey, the holder approves a Solana transaction that locks original tokens in the reviewed Adapter’s escrow. After authenticated delivery, the destination contract issues the matching representation. The original Solana supply is not reduced by that lock: the participating balance has moved into reserved custody.

To return, a holder separately reviews and approves a destination transaction that burns the representation. Its authenticated return message authorizes the source route to unlock matching originals to the reviewed Solana recipient. Each direction has its own fees, confirmations and delivery receipt. Merely sending a token to an arbitrary address is not a supported return.

• The locked backing must remain reserved for redemptions; it cannot also be counted as free liquidity capital.
• Matching token units do not guarantee matching exchange prices, immediate delivery or continuous route availability.
• A source lock and a destination credit can occur at different times; accounting must include messages still in flight.
• Completed public-testnet round-trip evidence is separate from the permanent mainnet pilot and from broader mainnet availability.

An administrator and a holder can be different people. Receiving tokens does not make a wallet an administrator, and proving wallet control does not appoint a new route owner. The current HANTAHOUSE workflows recognize their specifically configured participants; connecting an unrelated wallet does not grant pilot access.

Wallet verification uses a purpose-specific message signature. It establishes control for the relevant session and does not itself authorize spending. A transaction review is a different step: inspect the network, account, token amount, recipient and maximum costs before approving the wallet transaction.

• Use a supported Solana wallet such as Phantom for the source side and an EVM wallet such as Rabby or MetaMask for Robinhood Chain.
• Confirm the EVM network is Robinhood Chain, chain ID 4663, and connect the account required by the current step.
• Holder testing does not require sharing an administrator wallet or importing administrator deployment files.
• Keep private keys and recovery phrases in your wallet. Public addresses identify accounts; they are not secrets or signing permission.

A program deployment can require substantially more SOL than an ordinary holder transfer because it creates and funds program accounts and uploads code. Historical pilot estimates are not current quotes. The exact review must refresh account state, rent requirements, gas and balances before signing.

Rent-exempt balances are not an automatic rebate at the end of a migration. Only the appropriate authority can close an account when the account type and program rules permit it. Accounts supporting an active route may need to remain open. Closing a program or required route account could disable service; it is a separate administrative action, not a holder refund button.

1. 01

   Read the current checkpoint

   Approval saved means the review was recorded. A transaction hash identifies an attempted submission. Source confirmed means the source action succeeded. Delivered requires verified destination evidence; these states are not interchangeable.

2. 02

   Check the existing transaction

   Use Check confirmations after a wallet approval, timeout or uncertain response. If the wallet sent an EVM transaction but the page lost its hash, recover the original hash from wallet activity and use the matching recovery field.

3. 03

   Keep the same source message

   After a permanent burn confirms, use Check delivery and retain the message GUID. Recovery checks or a destination execution retry concern that same message. Do not burn another token to make the first delivery arrive.

4. 04

   Refresh only when the original is resolved

   An unsigned expired review can be replaced through the available cancel or refresh action. If signing or submission may have occurred, expiry and an unchanged balance alone do not prove that nothing was sent.

Solana reviews expire because their recent blockhash has a limited lifetime. Prepare when ready to sign and respond to the wallet promptly. If the wallet reports changes to the transaction, Genesis checks those changes against supported safety assertions and the approved migration. Unsupported changes are rejected rather than silently accepted.

The current HANTAHOUSE market uses a direct Uniswap v4 pool with the destination token and native ETH. A liquidity provider supplies separately owned assets under an exact pool review. The position records the provider’s liquidity and rights; a migration receipt alone does not deposit either asset into that position.

Why the old tokens cannot pay for both sides

In a two-way route, locked originals are backing owed to redeeming holders. Spending that backing as liquidity would undermine redemptions. In a permanent route, the migrated originals are burned. Their destruction creates the right to matching destination tokens through the route, not a reserve of ETH.

A project can contribute its own successfully migrated tokens to the token side. ETH must come from the project, participating providers or separately approved support. Selling separately owned assets to raise ETH is an additional market transaction that can affect price; a developer cannot assume control of other providers’ Solana pool assets.

• Review the exact token, quote asset, pool identity, fee configuration and liquidity range.
• Publish who owns the position, who can withdraw, whether a lock exists and how fees are distributed.
• Verify both the confirmed deposit and the position’s surviving liquidity; an old funding receipt is not proof that capital remains today.
• A pool can exist and show a price while offering very little depth. The present HANTAHOUSE position is holder-owned and unlocked.

Receiving one destination token for one original token preserves the reviewed token quantity. It does not fix the destination’s dollar price. The new market must be initialized near a credible Solana reference and funded deeply enough that a normal buy or sell does not immediately move far away from it.

These examples concern a new pool with balanced full-range funding at an illustrative initialization price. Uniswap v4 supports concentrated ranges, so deposited token balances alone are not a universal formula for every v4 pool’s price. Actual preparation must account for initialization, token ordering, decimals, ticks, range and current pool state. Convert the dollar budget into ETH using a fresh quote.

For an existing v4 pool, adding liquidity does not reset its initialized price. The current price and selected range determine the required asset mix. Genesis’s owner workflow uses a separately approved swap for price alignment, then a separately approved liquidity increase for depth. More liquidity reduces the effect of a given trade; it does not stop future market movement or make every holder able to cash out at the opening price.

A market can fail because its price differs, its pool is too shallow, its source reference is unreliable or fresh evidence is unavailable. The report distinguishes passing, blocked and unavailable conditions. A missing response is not interpreted as a zero price or permission to proceed.

For the reviewed HANTAHOUSE position, the owner can separately review a price-alignment swap and an increase to the existing liquidity position. These actions require their own wallet approvals and verified receipts. An allowance grants bounded spending permission; it is not the swap or liquidity deposit itself. A small affordable addition may help without satisfying the full depth requirement.

The two-way token needs its own verified pool; the permanent token’s pool cannot substitute for it. Current new two-way forwards therefore remain blocked. Market checks do not erase completed migrations or prevent existing delivery or return recovery. The live launch screen supplies current evidence; historical screenshots and this policy description cannot establish that the market passes right now.

Genesis plans to launch its main coin on Robinhood Chain through Pons. The proposed treasury policy allocates creator-fee revenue actually received by Genesis: 60% for migration liquidity, 25% for building and security, and 15% for reserves. This is a planned allocation of collected revenue, not a 60% trading fee charged to users.

1. 01

   Revenue is received

   Only the share actually collected by Genesis can enter the available budget. A projected trading volume or an unclaimed estimate is not funded liquidity.

2. 02

   A project proposes its contribution

   The project supplies a token inventory and quote-asset plan. Both migration routes can request support, subject to readiness and approval.

3. 03

   An award has explicit terms

   A capped contribution needs an approved project and pool, available funds, ownership checks, contributor rights and published withdrawal or lock terms.

4. 04

   Funding is verified onchain

   A promised allocation and a confirmed pool deposit are separate milestones. Verified deposits should identify the position and the assets actually contributed.

The route relies on source-chain execution, destination-chain execution and LayerZero’s configured message verification and delivery. The reviewed setup explicitly selects peers and required verifiers. It does not treat an arbitrary incoming message as a valid migration. Receipt checks bind delivery to the intended route, amount and recipient.

Administrator powers remain part of the trust model. Configuration owners can control route settings, and a Solana program can have an upgrade authority. Genesis verifies identities and configuration against reviewed expectations, but those checks are not equivalent to removing authority or completing an independent audit.

The permanent HANTAHOUSE pilot completed a one-token canary and a separate 10,000,000-token migration with verified mainnet burn and delivery receipts. Its replacement token and funded direct Uniswap v4 pool are live. These completed transfers are separate from whether the pool currently satisfies price and depth checks.

Use the live migration board and launch console to inspect receipt links and current market checks. A milestone percentage describes progress through the displayed checklist; it is not the percentage of total supply migrated, the probability of success or a promised financial return. A historical funded milestone can remain true while a fresh price check fails.

Does a developer’s application move all holders?

No. It proposes a project route. Holders must separately approve their own participating balances, and unparticipating Solana tokens can remain in circulation.

Can each holder choose a different name or a different return route?

No. Destination identity and migration mode are project-level choices for a reviewed token campaign. Holders choose whether to participate in those published terms.

If my wallet shows no token image, did delivery fail?

Not necessarily. Token delivery is established through the correct contract, recipient balance and verified receipts. Artwork display depends on separate metadata indexing. Check delivery evidence before assuming that an empty image means an empty balance.