Request Random Numbers

Ready to get random? Follow these four simple steps to integrate Supra dVRF into your Move module and start requesting verifiable random numbers.

Prerequisites

  • ✅ Whitelisted wallet address with configured gas parameters

  • ✅ Deposited sufficient funds in the Deposit Contract

  • ✅ Whitelisted your consumer contract address

Before requesting random numbers, ensure you have:

Step 1: Import the Supra dVRF Interface

Add the Supra dVRF framework dependency to your module's Move.toml file.

For Testnet:

[dependencies]
supra_vrf = { 
    git = "https://github.com/Entropy-Foundation/vrf-interface", 
    subdir = "supra/testnet", 
    rev = "testnet" 
}

For Mainnet:

Import in Your Module:

Step 2: Define Your Module Structure

Create the necessary structs to store your VRF permit and manage random numbers.

Initialize Module:

The init_module function is called automatically when your module is published. Use it to set up VRF access:

Step 3: Request Random Numbers

Use the rng_request_v2 function to request random numbers. This function returns a nonce that you can use to track your request.

Parameters:

  • permit_cap: Reference to your VRF permit capability (proves authorization)

  • callback_function: Name of your callback function that will receive the random numbers (e.g., "distribute")

  • rng_count: Number of random numbers to generate (maximum 255)

  • client_seed: Your custom seed for additional entropy (can be 0 for default)

  • num_confirmations: Number of block confirmations to wait before generating random numbers (minimum 1)

Returns:

  • u64 nonce: A unique identifier to track your request and link the callback

Example Request Function:

Request with a Custom Seed:

Step 4: Implement Callback Function

Create a callback function to receive and verify the random numbers. The callback must be a public entry function with a specific signature.

Callback Validation:

CRITICAL: Always call supra_vrf::verify_callback to ensure the random numbers are legitimate and from Supra's VRF service. This prevents malicious actors from calling your callback with fake data.

Complete Callback Example:

Complete Working Example

Here's a full implementation showing all components together:

Best Practices

✅ Always Verify Callbacks: Never skip verify_callback() - it's your security layer

✅ Handle Nonce Collisions: Use unique storage per nonce to avoid overwriting

✅ Set Appropriate Confirmations: Higher confirmations = more security but slower delivery

✅ Store Request Context: Link nonces to requesters or application state for proper handling

✅ Use Client Seeds Wisely: Add entropy from user input, timestamps, or external data

✅ Monitor Your Balance: Ensure sufficient funds for callback transaction fees

✅ Error Handling: Implement proper error codes and assertions.

Troubleshooting

Request fails with "module not whitelisted":

  • Ensure you called init_vrf_module<T>() in init_module()

  • Verify your wallet is whitelisted first.

Callback never arrives:

  • Check your balance is above minimum.

  • Verify callback function name matches exactly.

  • Ensure module is enabled: deposit::is_module_enabled<T>()

Verification fails:

  • Don't modify the callback parameters.

  • Pass all parameters exactly as received.

  • Ensure you're using correct module type. <T>

"Nonce already exists" error:

  • Don't reuse nonces - each request gets a unique nonce.

  • Clear old nonce data before making new requests.

The random numbers generated are cryptographically secure and verifiable, making them suitable for gaming, NFT minting, and other blockchain applications requiring true randomness.

Last updated