How Aether works.

01 / The model

Aether is a proposed dual-market launchpad. Each launch starts with a Solana market. A dedicated share of application trading revenue funds a second market paired with HYPE on Elysium. After opening, both markets remain active.

This is not a single atomic pool shared by both chains. Combined liquidity is the sum of actual local positions, counted once. It is not the amount independently available on each chain.

02 / Use the connected app

1. Open Connect wallet and sign a message with Phantom or Solflare to prove wallet ownership. This is not a transaction.
2. The Markets board reads the API. It shows no tokens until verified deployments and market adapters are connected.
3. Open Trade & move → Launch status to inspect the backend's requirements and last integration evidence.
4. Trading and bridging stay unavailable when quotes, contracts, gas and delivery routes cannot be verified.

Prices, balances, pool depth and USD totals are unavailable until backed by real data. The interface never substitutes sample tokens or assumed liquidity. Existing sandbox database records are excluded from production reads without deleting history.

03 / Intended production workflow

Meteora graduation remains on Solana. The Elysium launch uses a separate fee-funding route. Permanently locked Solana liquidity cannot simultaneously be promised as removable bridge funding.

04 / Tokenomics and supply

The current model starts with 1 billion tokens, with 9 token decimals. The same token decimals are used on both sides of the sandbox. This allocation is a design proposal; a production Meteora curve still needs reserve and graduation modelling.

No separate Aether platform token is implemented. Reserved tokens do not create the HYPE needed for a pool. That quote asset must be funded independently.

Backing, not a second billion

Solana → Elysium locks source tokens and issues their counterpart. The return direction burns that counterpart before releasing the original. In the current sandbox:

For example, bridging 1,000 tokens does not give a holder 1,000 freely spendable tokens on each side. It changes where their 1,000-token entitlement can be spent. Pool inventory and reserved allocations are part of this accounting, too; this metric is not a circulating-supply measurement. Market-cap calculations must not add backed representations on top of the original supply.

05 / Proposed fees

Buy and sell fees are symmetric. There is no token-transfer tax or percentage bridge tax in the model. Actual network, delivery and routing costs would be quoted separately.

Net means the fees Aether actually controls after the venue's deduction. The sandbox assumes the venue takes 20% of the trading fee. This is not confirmation of the fee rights or deductions on every Solana or Elysium venue. Independent LP fees cannot be redirected without entitlement.

At the proposed funding rate, a 1,000-unit trade accrues 11.20 units to the Elysium fund. A 25,000-unit target would therefore require roughly 2.23 million units of cumulative trading volume, before conversion and bridge costs. Trading volume is not market cap, user deposits or a promise of demand.

The intended fee reduction needs verified second-market activation, a compatible venue mechanism and a published deadline/failure policy. The sandbox changes model state; it does not change a deployed pool.

06 / The continual bridge

Development reference: The simulator described below remains in automated tests only and is disabled on the public production service. These database transitions do not implement a live bridge.

There are two separate systems: the holder token bridge preserves supply as tokens move, and the liquidity funding route deploys application revenue into new local liquidity. Keeping both active does not require bridging every individual fee.

1. RequestedThe intent is queued. In this sandbox, a source-wallet cancellation is still possible.
2. Source confirmedThe sandbox debits the source balance, locking or burning as appropriate.
3. AttestedA simulated message-verification stage.
4. CompletedThe destination credit and backing checks commit atomically in the sandbox database.

Wallet users sign in with Solana. Linking an EVM EOA through a session-bound ownership signature enables Elysium-source sandbox requests and private balances on both chains. Contract-wallet authentication and real transaction execution are not implemented.

Cancellation and recovery

Cancel only while a request is still requested. Once source debit occurs, an API timeout is not permission to refund. A live bridge must use its verified delivery or cancellation mechanism to avoid releasing the source and crediting the destination twice. Failed source debits produce no destination credit.

07 / Liquidity, pricing and market differences

Both pools need real quote-side capital. SOL and HYPE also fluctuate against dollars, so matching local token/quote ratios is not the same as matching token prices in dollars. Opening the Elysium market should use its actual HYPE reserve and token inventory to establish its price, with a verified cross-asset conversion when comparing it with Solana.

• Prices can diverge during bridge delays, volatility and inventory shortages. There is no guaranteed peg between the two pool prices.
• Arbitrage narrows gaps only when the difference exceeds trading fees, slippage, bridge costs and execution risk.
• A large blanket sell tax can impede corrective arbitrage and allow wider gaps. No divergence-based surcharge is implemented.
• Deeper local liquidity reduces price impact. Fee-funded additions require both sides of the position or an explicitly supported single-sided mechanism.
• Permanent liquidity locks allow claimable fees but prevent withdrawal of the locked principal. Active principal rebalancing needs a separately disclosed managed-vault design.

No holder yield, guaranteed buyback, minimum liquidity value or token price outcome is promised by this release.

08 / Security and permissions

Sessions identify a wallet, not a transaction approval. No private keys are held by the application. A wallet cannot choose another launch owner or debit another source address. The guided scenario is owner-only and works only in sandbox mode.

The database is currently the authority for test balances only. A production database must be an index: minting authority, replay protection and supply limits must also be enforced by verified contracts.

This backend is not an audited bridge. Before real assets: independent review, proven source finality, destination message verification, restricted issuance, route limits, pause procedures, tested recovery and external backups are required.

09 / How the build is organised

Disk-backed storage currently means a single service instance and deployment interruptions. A live system should move the ledger and queue to managed Postgres before separating relayers or scaling horizontally. Disk persistence is not an off-site backup policy.

SOL has 9 decimals and USDC 6. Native HYPE on Elysium uses 18. The Solana HYPE model assumes 9 until its exact mint is verified. The launch token uses 9. Funding totals remain grouped by asset; the API does not add SOL, USDC and HYPE together without a conversion policy.

10 / API reference

The route list below is loaded from the running backend. Open raw API reference ↗

Wallet mutations

Require a valid session cookie, exact application Origin, X-CSRF-Token, JSON content type and Idempotency-Key. Retry a network-failed mutation with the same key and identical body. A changed body with the same key returns a conflict.

{
  "name": "Horizon",
  "symbol": "HRZN",
  "description": "A saved sandbox launch",
  "quoteAsset": "USDC",
  "fundingTargetUnits": "25000000000"
}

This target is 25,000 USDC. The server derives the launch owner from the session. Current wallet launch limit: 20.

11 / Integration status

This is the actual release boundary, not a list of completed chain integrations.

Support for a chain's core messaging does not prove a compatible token-transfer product, relayer, quote route or pool integration. No bridge provider or deployed token/program address is asserted by this application.

12 / FAQ and glossary

Quote asset

The asset used to buy/sell the launch token in a particular pool.

Unlock vault

The separately accounted share of fees intended to fund the HYPE market.

Net application fee

The collectible fee entitlement after venue deductions.

LP position

A claim on a pool's reserves and potentially trading fees, subject to its lock and ownership rules.

Escrow

Source tokens held as backing for destination representations or pending delivery.

Idempotency

A retry returns the original committed result instead of repeating the mutation.

Finality

The chain-specific assurance that a source event will not be reversed; not implemented by a submitted transaction hash alone.

13 / Contract development and requirements

What is being built

The production workflow

1. Simulate and verify the exact Meteora configuration, fixed supply, reserve inventory and fee rights.
2. Launch the Solana market; index finalized trades and collect actual net fee entitlements.
3. Convert and route capital under explicit amount, cost, deadline and minimum-output limits.
4. Lock reserved tokens and deliver their backed representation through an authenticated transport.
5. Verify the HYPE pool, opening reserves, price bounds and LP custody before activating both markets.
6. Continue two-way holder transfers and separately accounted recurring liquidity batches.

The source lock or burn must be final before destination credit. Every source nonce can settle once. Failed delivery is retried without another source debit. No elapsed timer authorizes a refund after source commitment.

Before contract confirmation

The review packet must include the exact source commit, reproducible artifacts, network and peer bindings, constructor parameters, authority powers, venue configuration, verified transport, LP custody, exposure limits, end-to-end receipts, supply reconciliation, recovery drill and independent review findings. The current manifest leaves deployment disabled and route identities unset; it is a development checklist, not an on-chain safety lock.

Official Elysium documentation confirms standard EVM tooling, native HYPE and HyperEVM bridge architecture. Still open: chain-level contract verification, the exact supported Solana token-transfer route, Meteora reserve mechanics, fee-transition support, liquidity custody, rate limits and governance. No addresses from third-party search results have been wired into the application.

14 / Connected product

The public board reads GET /api/v1/launches and GET /api/v1/overview. The terminal reads configuration, launch requirements and saved RPC evidence from the backend. These calls use same-origin requests with no admin credentials in the browser.

No sample fallback

Browser-local trading, synthetic activity, starter balances, sample tokens and fixed price charts are removed. An empty market response shows an empty board. A failed API call shows an error and Refresh. Unknown dollar totals display a dash rather than an invented valuation.

Real authentication

Solana wallet sign-in uses signed ownership messages and secure, exact-origin sessions. Connecting a wallet grants no transaction approval. There is no live balance, quote or execution adapter configured yet.

The visual link

The infinity animation uses only Solana and Elysium marks. The Elysium mark remains grey until verified market activation. The brand animation is not evidence of route availability.

Launch requirements

Deploy reviewed contracts and validate network identities, token authorities, peer configuration, finality and bridge delivery. Integrate actual Meteora/Elysium pools, live reserves, quote building, wallet transaction signing and confirmed receipt indexing. Add destination gas, idempotent live jobs, custody checks, monitoring and tested recovery. Deployment alone does not complete these requirements.

15 / Route verification

The backend now checks real RPC observations separately from sandbox balances. The token page’s Launch status tab shows the last saved evidence, remaining blockers and freshness. A public refresh reads stored evidence; only an authenticated operator can start new checks.

Matching these parameters does not prove bridge peer configuration, backing, finality, executable liquidity or an independent review. Unknown mint layouts and unsupported proxy types need further adapters. No check enables real trading or bridging.

RPC credentials stay on the server. Deployment-specific public pins must come from reviewed sources; token names and addresses copied from an issue are insufficient. Unconfigured instances make no RPC calls. The CLI and operator endpoint use read-only methods, bounded responses, timeouts and a cooldown.