GodlRun
Shaft—
Payout—:—:—
Docs

Deterministic verifiability (this is not a "provably fair" RNG page)

There is no randomness in this system

Let's be direct about something before going any further: GodlRun contains no random number generator, no dice roll, no seed, no commit-reveal scheme, and no VRF. There is nothing to "provably" randomize because nothing here is random in the first place. If you came here looking for a fairness proof about a random draw, that is the wrong framing for this game entirely. Read this page instead as an explanation of deterministic verifiability: every single outcome in GodlRun is a pure, calculable function of on-chain state and time, and you can recompute any of it yourself, independently, with public tools.

This is a stronger property than "fair randomness," not a weaker one. A random outcome asks you to trust that the randomness source wasn't manipulated. A deterministic outcome asks you to trust nothing at all: you just do the arithmetic.

Every quantity is a pure function of state and time

The four numbers that define the game at any instant (who holds the slot, the current price, the current deposit, and whatever refund or rebate a settlement produces) are each computed from a small set of stored values plus block.timestamp. Nothing else feeds into them. No off-chain oracle, no external price feed, no keeper decision, no admin input.

Price and deposit curve

if currentBeneficiary == address(0):
    price   = floorPrice
    deposit = floorDeposit

else:
    windowEnd = buyTimestamp + windowDuration

    if now <= windowEnd:
        # still inside the holder's active window: escalated terms
        price   = lastPrice   + priceIncrement
        deposit = lastDeposit + depositIncrement

    else:
        # window has expired: decaying terms
        elapsed = now - windowEnd
        price   = decay(lastPrice,   floorPrice,   elapsed)
        deposit = decay(lastDeposit, floorDeposit, elapsed)

Decay curve

decay(peak, floor, elapsed):
    if peak <= floor or elapsed >= decayDuration:
        return floor

    drop = (peak - floor) * elapsed / decayDuration     # integer division, rounds down
    return peak - drop

This is a straight linear ramp from peak down to floor over exactly decayDuration seconds, saturating at floor and never going below it or overflowing, no matter what elapsed is.

Settlement: refund and rebate

At the exact moment a new claim displaces the current holder, before anything else changes:

inWindow = now <= buyTimestamp + windowDuration    # buyTimestamp is still the OUTGOING holder's

refundEth = inWindow ? (lastPrice * 7500 / 10000) : 0        # 7500/10000 = 75%, fixed constant
protocolEthBalance += lastPrice - refundEth

rebateToken = inWindow ? (lastDeposit * rebateBps / 10000) : 0   # rebateBps currently 5000 = 50%
seasonReserve += lastDeposit - rebateToken

refundEth is credited to the outgoing holder's withdrawable balance. rebateToken is credited to the incoming buyer's withdrawable balance. Both are exactly zero once inWindow is false. There is no partial, decayed, or otherwise fuzzy version of either payout. It is a hard boolean gate evaluated against a single timestamp comparison.

No operator discretion at settlement

Nobody chooses who wins a flip. There is no admin call, no backend process, and no keeper decision anywhere in the path that determines who ends up holding the slot after a transaction lands. The rule is simply: the first transaction that pays at least the current live price and holds at least the current live deposit, and is not blocked by the immunity check, takes the slot. Whoever's transaction lands first, at a price the contract accepts at that moment, wins. That is the entire selection mechanism.

Why gas bribes don't buy you priority here

On many EVM chains, a challenger racing to flip a slot the instant it becomes flippable might try to pay a higher gas price to jump the ordering queue in a public mempool. Robinhood Chain does not have a public mempool for this kind of bidding to work against: transaction ordering is first-come-first-served at the sequencer level, not auctioned by gas price. Overpaying for gas does not buy you a better position in line. The practical implication: the fairest way to win a race for the slot is to simply submit your transaction as early and as correctly (right price, right deposit, right timing relative to immunity) as possible, not to out-bid anyone.

How to independently recompute a payout yourself

Everything below only needs a public RPC endpoint and the cast tool that ships with Foundry. No private infrastructure, no trust in GodlRun's own frontend or backend is required for any of this. You are reading the same chain everyone else reads.

export RPC_URL="https://rpc.mainnet.chain.robinhood.com"   # public Robinhood Chain RPC
export CONTRACT="<FEE_DISTRIBUTOR_ADDRESS>"   # the live contract address, published at launch

1. Read the fixed configuration values

cast call $CONTRACT "floorPrice()(uint256)"        --rpc-url $RPC_URL
cast call $CONTRACT "floorDeposit()(uint256)"      --rpc-url $RPC_URL
cast call $CONTRACT "priceIncrement()(uint256)"    --rpc-url $RPC_URL
cast call $CONTRACT "depositIncrement()(uint256)"  --rpc-url $RPC_URL
cast call $CONTRACT "windowDuration()(uint256)"    --rpc-url $RPC_URL
cast call $CONTRACT "immunityDuration()(uint256)"  --rpc-url $RPC_URL
cast call $CONTRACT "decayDuration()(uint256)"     --rpc-url $RPC_URL
cast call $CONTRACT "rebateBps()(uint256)"         --rpc-url $RPC_URL

2. Read the current slot state

cast call $CONTRACT "currentBeneficiary()(address)" --rpc-url $RPC_URL
cast call $CONTRACT "lastPrice()(uint256)"           --rpc-url $RPC_URL
cast call $CONTRACT "lastDeposit()(uint256)"         --rpc-url $RPC_URL
cast call $CONTRACT "buyTimestamp()(uint256)"        --rpc-url $RPC_URL
cast call $CONTRACT "windowEndsAt()(uint256)"        --rpc-url $RPC_URL

Add --block <blockNumber> to any of the above to read the state as of a specific historical block, rather than the current chain head. This is useful for reconstructing what the price or deposit was at a specific past moment.

3. Compute the current live price/deposit yourself

Plug the values from steps 1 and 2 into the price/deposit curve formula above using any calculator, or just call the view functions directly and compare:

cast call $CONTRACT "currentPrice()(uint256)"   --rpc-url $RPC_URL
cast call $CONTRACT "currentDeposit()(uint256)" --rpc-url $RPC_URL

If your own hand-computed value from step 1 and 2's raw inputs matches what currentPrice()/currentDeposit() return, you've verified the contract is doing exactly the arithmetic described above, not something else.

4. Verify a specific past settlement from its transaction

cast receipt <TX_HASH> --rpc-url $RPC_URL

The receipt's logs contain the SlotClaimed, HolderSettled, and (if applicable) BuyerRebateCredited events for that transaction. Decode them against the contract's ABI to read the exact pricePaid, depositPaid, ethRefunded, tokenAbsorbed, inWindowFlip flag, and rebateAmount that were emitted. You can then independently confirm ethRefunded is exactly 75% of pricePaid if inWindowFlip is true, and exactly zero if it is false, with no partial or in-between value ever possible.

To scan for every settlement event across a range of blocks (useful for building your own independent history of the game, without trusting anyone else's indexer):

cast logs --address $CONTRACT \
  "HolderSettled(address,uint256,uint256,bool)" \
  --from-block <START_BLOCK> --to-block <END_BLOCK> \
  --rpc-url $RPC_URL

Every value above ties back to the same handful of formulas at the top of this page. There is nothing else in the payout logic to verify: no hidden state, no off-chain input, no randomness of any kind.