Skip to main content

Documentation

ElyxS guides, legal rules, smart-contract references, user-created draw rules, prize custody, wallet help, and on-chain verification for Supra Testnet.

Documentation

Smart Contracts

Smart ContractsUpdated: Aug 17, 2026

Smart Contracts

How ElyxS smart contracts handle lotteries, the jackpot, user-created draws, prizes, payouts, and refunds.

Contract on Supratestnet

Contract Address

Contract address shown by ElyxS

0xdbe4051500355f4993c790ac2efef41779557a7add9e2e40ac62f16f715b88f0

Reference scope

A compact reference for contract packages, user-draw rules, prize custody, and result verification.

Contract languageMove
Randomness sourceSupra dVRF
Result checkVia SupraScan

This page explains the ElyxS draw categories, smart-contract packages, Supra dVRF, prize storage, payouts, and result verification.

Smart Contract Address

Within each network, the core ElyxS modules use one address. Mainnet and Testnet may use different addresses. The network, address, and SupraScan link must match the details shown in the ElyxS interface.

The smart contracts use three draw categories: lottery (LOTTERY), jackpot (JACKPOT), and user-created draw (USER_DRAW).

A function can exist in the code without being available to users. Availability depends on the current contract settings and rules.

When a creator requests a user-created draw, the available options can depend on the organizer's current status. Before confirmation, the interface shows the options available for that request.

Once a user-created draw request is accepted, the contract fixes the terms for that draw. A later change to the organizer's status does not alter them.

How the Smart Contracts Are Organized

The smart contracts are organized into Move packages with separate responsibilities:

  • draw_base - Shared draw and organizer data, authorization checks, and binding each Supra dVRF response to the expected request.
  • draw_user_rules - Validation and storage of user-created draw rules, including the options available to the organizer.
  • draw_data - Current draw and round state, cancellations, and refund rights.
  • draw_engine - Ticket sales, moving a draw from one stage to the next, and winner selection.
  • draw_finance_core - Base accounting rules for the jackpot and refunds.
  • draw_finance - SUPRA storage, fees, organizer revenue, prize payouts, and refunds.
  • draw_prize_assets - Storage for prizes in other Supra tokens and NFTs.
  • draw_utils - Calculations, history, metadata, and price-data reads.
  • draw_gateway - Public functions for user transactions and viewing contract data.
  • draw_vrf_gateway - Supra dVRF requests, response verification, and a controlled retry when a response is delayed.
  • SupraVrf and oracle_core - Connections to Supra randomness and price-data services.

For users, there are two prize models. The smart contract can hold SUPRA, another token on Supra, or an NFT.

If the organizer is responsible for the prize, the contract does not hold it. The organizer remains responsible for any promised delivery.

The options shown in the builder depend on the active rules and the organizer's status.

Rules Enforced by the Contracts

The contracts apply these checks to the relevant operations:

  • Each round moves forward through participation, a randomness request, and winner selection. If the prize is held by the contract, the winner can then receive it through the contract. If the organizer is responsible for the prize, the contract records the winner but neither promises nor performs prize delivery. Cancellation and any resulting refunds follow a separate path. A completed user-created draw cannot be restarted or canceled.
  • A pause blocks new sales and new randomness requests, but it does not change the outcome of a request already submitted to Supra dVRF.
  • Every successful purchase adds its stated number of tickets once. Late or duplicate processing of the same purchase cannot increase participation, and each issued ticket enters its round exactly once.
  • A Supra dVRF result is bound to the network, contract address, draw, round, request, and fixed ticket set. A verified response cannot be applied again or used for another draw.
  • A user-created draw request first waits to be processed. The system then creates the draw or rejects the request; the organizer can also cancel it before the draw is created. Once the draw is created, its rule and description fingerprints do not change.
  • Participation is free or paid in SUPRA. Other tokens on Supra and NFTs are not accepted as ticket payment.
  • If the smart contract holds the prize, the organizer transfers SUPRA, another token on Supra, or an NFT to it before the draw. Once the winner is recorded, only that wallet can claim the prize.
  • If the organizer keeps the prize, the contract records the rules, participants, and winner, but it cannot prove that the prize exists or was delivered.
  • The accepted rules, participation method, prize-storage method, and fees are fixed for each draw. Changes to the organizer's status or the platform's general rules do not alter accepted terms.
  • For a paid user-created draw, the amount already paid to create it is deducted from the platform fee calculated from ticket sales. The contract keeps organizer revenue reserved until payout.
  • The contract checks that its SUPRA balance covers every recorded payout: prizes, refunds, fees, and organizer revenue. For another token, it checks the exact amount. For an NFT, it checks the object selected as the prize.
  • Once the winner is recorded, the right to a prize held by the contract does not expire. The prize cannot be returned to the organizer, redirected to someone else, or claimed more than once.
  • Purchases, randomness requests, results, prize claims, and refunds are recorded in on-chain state and events so they can be checked independently.

Verifying a Draw

  1. Open the draw in Hub -> Results and use its verification link.
  2. Open the linked VRF record in SupraScan.
  3. Confirm the network, contract address, category, draw identifier, and the link between the dVRF request and the draw.
  4. Compare the ElyxS result with the on-chain record opened from the interface.

For a user-created draw, also compare the request status, rule fingerprint (rules_hash), description fingerprint (content_hash), who holds the prize, and, where applicable, the event confirming that the contract received it.

Supra dVRF proves the random output, while contract records show how that output selected the winner. If the organizer keeps the prize, this evidence does not prove that it was delivered.

See Verify Draw Results and How to Read SupraScan for ElyxS.

What to check next

After reading the reference, you can walk through the core on-chain verification steps directly in the product and in SupraScan.

  1. Confirm that the contract address shown by ElyxS matches the address opened in SupraScan.
  2. Match the draw category and status. For USER_DRAW, also compare the rules and content hashes.
  3. Open the Supra dVRF response transaction and compare the recorded winner data.
  4. Check the relevant prize escrow, claim, and refund events.

Helpful references

If you need more context around terminology, errors, or end-user flows, open the nearby reference sections.

Open FAQ