How Tramplin Guarantees Randomness in Reward Distribution

Tramplin is an innovative Solana validator that introduces premium staking — a proven real world savings model rebuilt for crypto.

Instead of distributing staking rewards in proportion to stake size, Tramplin collects and redistributes them among participants in a randomized, verifiable way. This model preserves the security and capital protection of Solana’s native staking, while introducing the chance for outsized rewards even for small holders.

Randomness is not an add-on at Tramplin — it is one of the protocol’s foundations. Making sure that it is fair, transparent, and impossible to manipulate is essential to the system’s integrity.

This post below explains how Tramplin generates this randomness, how it is verified onchain, and why no participant—including Tramplin itself—can influence the outcome.

TDLR: Tramplin uses a Commit–Reveal scheme combined with ORAO VRF (Verifiable Random Function) to generate random outcomes that no single party can predict or influence.

Tech terms alert: This post gets pretty technical. If that’s not your thing, there’s a short glossary at the bottom to make it easier to follow.*

Step 1: Taking a snapshot

At the start of every new epoch (2-3 days on Solana), Tramplin’s Stake Watcher takes a snapshot of the validator.

The snapshot includes all active staking accounts eligible for reward redistribution in that epoch, and is published so anyone can verify its accuracy.

The snapshot data is structured as a Merkle tree* for efficient onchain verification. You can view an example snapshot here.

Key snapshot metadata is also written directly to the smart contract, including:

• The epoch of the snapshot
• The total eligible stake
• The snapshot’s Merkle root

This data is publicly visible in the Solana explorer’s Program Logs, so users can check eligibility on their own.

Any participant can verify that their address is included in a snapshot by checking it against the published Merkle root* using a Merkle proof* — a small set of hashes that proves inclusion without exposing the full dataset.

Once a snapshot is published, the participant set is fixed. Any attempt to alter it would change the Merkle root and be immediately detectable, which ensures immutability and transparency.

Step 2: Commit phase

Once the snapshot is finalized and the reward pools are funded, the redistribution process begins.

Contract execution is handled by the Operator* service, which runs two onchain transactions every 10 minutes: Commit* and Reveal*.

During Commit phase:

1. The Operator generates a secret value and computes its hash.
2. The hash of this secret (the commit) is submitted to the smart contract via a draw instruction (for example, draw_regular).
3. This creates a draw account and triggers a request to ORAO VRF (Verifiable Random Function).

The VRF seed is derived from:

• The snapshot’s Merkle root hash
• The secret hash

ORAO VRF then generates and returns a verifiable random value.

This process ensures two critical properties:

• Binding: Once the hash is published, the secret cannot be changed. Any modification would produce a different hash and be publicly detectable.
• Hiding: The secret itself remains unknown until the reveal phase. Because hashes are one-way, no party (including the VRF provider) can predict or manipulate the outcome.

Attempting to manipulate results would require either:

• Changing the secret after committing (impossible without breaking the hash), or
• Refusing to reveal the secret (which would result in public failure and economic and reputational penalties).

Step 3: Reveal Phase

1. The Operator reveals the secret and computes the final randomness:

FINAL_RANDOMNESS = VRF_output XOR off_chain_secret

By combining two independent entropy sources (the VRF output and the off-chain secret) using XOR, the final randomness remains unpredictable as long as at least one source is honest.

2. This final randomness is passed into the KISS (Keep It Simple Stupid) algorithm to select the reward recipient:

• Learn more on Wikipedia
• Read documentation

3. The result is finalized onchain, recording the winner’s identifier and the reward amount

Daily and monthly redistributions

The same mechanism works for two types of reward redistributions on Tramplin:

1. Regular pool (every 10 minutes)

• 1 randomly selected user receives a reward
• ~144 winners per day
• ~4,320 winners per month

2. Big pool (once every 12 epochs (~30 days))

• 1 user receives a significantly larger reward

The reward amount in each redistribution depends on the total SOL delegated and staking yield generated during that period, but the verifiable randomness model always stays the same.

Randomness you can verify

To sum it up, every redistribution follows a clear, auditable process that anyone can verify onchain. The participant set is fixed, key values are locked in before the process begins, and the final outcome can’t be predicted or influenced by anyone, including Tramplin.

That’s what makes premium staking possible: native Solana security, cryptographic fairness, and resistance to manipulation.

Still got questions? Join the conversation on our Discord server and follow Tramplin on X.

Glossary

Commit–Reveal — A two-step process that locks in a value first (Commit) and reveals it later (Reveal), preventing prediction or manipulation.

Epoch — A fixed time period on Solana (about 2–3 days) during which staking activity is measured and rewards are processed.

Merkle Proof — A lightweight check that lets you confirm your address is included in the snapshot, without revealing the full list.

Merkle Root — A single cryptographic fingerprint that represents the entire snapshot. If anything in the snapshot changes, the root changes too.

Merkle Tree — A structured way to bundle a large list of data into a single, verifiable format that makes changes easy to detect.

Operator — An off-chain service that submits the required transactions to the smart contract to run the redistribution process.

Snapshot — A saved record of all accounts actively staking at a specific moment, used to determine who is eligible for reward redistribution.

VRF (Verifiable Random Function) — A system that generates random values together with proof that the result was fair and untampered.