ElyxS currently runs on Supra testnet. All tickets, prizes, payouts, and jackpot values in the current public environment use testnet SUPRA, which has no real monetary value.

The public beta is not only for user access. It is also used to validate the full platform lifecycle: ticket sales, sales-window closure, randomness requests, winner settlement, refunds, and supporting automation around those flows.

You need StarKey Wallet connected to Supra testnet.

Before you buy tickets, make sure that:

1. the wallet is connected to Supra testnet;
2. you have enough testnet SUPRA for both the ticket and gas;
3. you are using the testnet flow only and not sending real assets into the test environment.

You can top up the wallet with test tokens through the official Supra faucet: supra.com/faucet.

Practical flow:

1. Open the official faucet.
2. Enter or confirm your testnet wallet address.
3. Request test tokens.
4. Refresh the wallet and ElyxS if the balance does not appear immediately.

If the faucet does not respond immediately, wait and try again later. Temporary external limits from the testnet infrastructure are possible during public beta.

Before important actions, you should verify the ElyxS smart contract address.

Check that:

1. the ElyxS interface shows the expected contract address;
2. the SupraScan link points to that exact address;
3. the purchase, result, or payout belongs to the expected draw id and contract.

If the contract address, explorer link, or draw data looks unexpected, do not sign the transaction until you re-check the information through the Smart Contracts reference and the official support channels.

The source of truth for any specific draw is its live status and timer inside ElyxS.

If an older screenshot, post, message, or unofficial description conflicts with the active draw card, trust the current Hub status and timer.

In the current beta runtime, the main lottery series runs almost continuously: once one round finishes, the platform may prepare the next one.

The baseline beta template uses short sales windows so the full lifecycle moves quickly through purchase -> close -> VRF -> result -> history.

Some bootstrap rounds may use a sales window around 5 minutes, but the actual start/end timestamps always come from the live round.

If a test scenario requires it, the team may restart the cycle, pause the series, or adjust the next-round parameters.

The jackpot is a separate draw, not a payout inside every regular lottery round.

The current beta cadence may open a jackpot round after a configured number of completed lottery draws. In the active bootstrap configuration this is usually 10 completed draws, but the interface remains the source of truth for the next jackpot cycle.

If the beta runtime is paused, the previous jackpot cycle is still unfinished, or infrastructure checks are in progress, the next jackpot opening can shift.

This rule applies only to the public beta in Supra testnet. Mainnet rules will be published separately.

During the public beta, automated platform test accounts may participate in visible draw activity.

They are used to:

1. keep test traffic flowing instead of leaving a cycle without participants;
2. validate automatic closing, VRF flow, history updates, and related backend processes;
3. observe how the UI and indexer behave under regular on-chain purchases.

These accounts use the same test runtime and the same on-chain purchase paths as regular participants.

That means they can affect participant counts, round momentum, and even the result of a testnet draw. In testnet public beta, that is an expected part of product validation.

Current public testnet addresses of the automated test accounts:

• player1 — 0x553fd40012531ebe3bf92c5eff9b8a11cd64add9f339e75b728652041cf21762
• player2 — 0x0a8658ac7bd47fc754f7f4be8dce53a5fca5febb11e1d1ec634d19768756184a
• player3 — 0x8a7be3bf99dd30503fa55e71508230cd23c782c8435fe69d3a48941fbe864729
• player4 — 0x82ec5deb788ca7e02948800ed2f4baf81b0317164e9c8bfeaa1020e0dc8954d6
• player5 — 0x86a58977804013bb93dea0cd56a0066ee6572d698cf8232add978d6cb3ed0aac

• Short sales windows and fast status transitions.
• A round appearing or disappearing soon after the previous cycle finishes.
• Temporary delay between an on-chain transaction and the UI update.
• Draw cancellation or a technical pause when the team validates recovery or refund paths.
• Adjustments to the next beta cycle parameters.

Before confirming any transaction, check:

1. the wallet network;
2. the wallet address;
3. the contract address;
4. the ticket price;
5. the final amount.

Never share your seed phrase, private key, or any other secret data with anyone, including support.

If you see an error, a disputed outcome, or suspicious interface behavior, keep:

1. the draw id;
2. the transaction hash;
3. the operation time;
4. the error text or a screenshot.

Then use the official ElyxS support channels:

• Support inside the product
• support@elyxs.com
• official X (Twitter): @elyxs_draw

If the issue looks like a possible address substitution, unexpected contract, suspicious link, or data mismatch, do not sign new transactions until support replies.

If you want the fastest practical entry point after this guide, continue with Getting Started with ElyxS.