RAIN is designed to monetize prediction-market throughput, then turn that throughput into token demand and token scarcity

Rain is a decentralized prediction markets protocol built on Arbitrum, with cross-chain deposits intended to make the product feel chain-agnostic at the UX layer, as described in its protocol whitepaper.

The token design is opinionated. $RAIN is positioned as (1) a usage gate for trading capacity inside the app and (2) a governance token, with (3) a protocol-level buyback-and-burn funded by trading fees.

From an emissions sustainability lens, the best thing here is the linkage between protocol activity and token sink. The weakest thing is the degree of discretionary control over inflation and the treasury, especially given the system’s reliance on continued volume to justify both unlocks and any ongoing minting. This is a “prove you have product-market fit every day” token economy. It can work. It can also fall apart quickly if volume quality is weak. For the framework behind these critiques, see our tokenomics methodology.

What the project is, and what $RAIN does inside the product

At the product layer, Rain supports public and private markets, with outcomes resolved either by the market creator or by an AI oracle called Delphi for public markets.

Markets require a minimum of $10 liquidity to open.

The token’s most concrete utility is access control through “Trading Power.” The whitepaper states users must hold $RAIN to participate, and that “Trading Power” determines how much of a user’s deposited funds can be actively traded. If you’re new to these mechanics, our tokenomics FAQ covers common terms.

The example given is explicit: holding $1 worth of $RAIN allows trading up to $100 of deposited balance, and $2 worth allows $200, and so on.

Two implications matter for long-horizon analysis:

First, token demand is intended to be tied to active traders rather than passive staking. That is directionally healthier than inflationary “pay people to park capital” designs, if the product really does generate durable flow.

Second, the demand is proportional to usage in dollar terms, not token units. If the gate is enforced as “$X worth of $RAIN,” token price rises reduce the number of tokens required to maintain the same trading capacity. The mechanism still creates a baseline of structural demand, but it does not mechanically compound demand with price.

$RAIN also sits inside governance. The whitepaper frames $RAIN holders as governing key operational parameters including “market structure and fee logic,” oracle and dispute resolution frameworks, allocation of development funds, and protocol upgrades.

Supply, allocations, and unlock schedule (as documented)

The token contract (proxy) on Arbitrum is at 0x25118290e6A5f4139381D072181157035864099d.

The contract creation transaction on Arbitrum is dated August 26, 2025.

That creation transaction shows a transfer of 1,150,000,000,000 RAIN, which matches the token contract’s INITIAL_SUPPLY constant of 1.15 trillion.

The whitepaper states “the $RAIN token’s initial total supply is 1.15 trillion tokens,” and also notes that this is not necessarily the maximum supply due to inflationary mechanics.

The token distribution categories, percentages, and vesting notes are defined in the whitepaper as follows.

The whitepaper also defines an in-app credits system intended to reward actions like deposits, trading, liquidity provision, and referrals, with credits later convertible into $RAIN.

It specifies that 2% (23 billion tokens) of the Ecosystem Growth & Staking allocation is designated for this credits system, released via a 12-month linear vesting schedule.

Emissions over time: fee-funded burns, and a burn-linked mint that routes to the treasury

Rain’s fee model is straightforward at the headline. The protocol charges a 5% fee on each market’s trading volume.

That 5% is split as follows: 1.2% to the market creator, 1.2% to liquidity providers, 0.1% to the resolver, and 2.5% allocated to $RAIN buyback-and-burn.

The whitepaper mirrors this split and explicitly states that 2.5% of trading volume is used to buy back and burn $RAIN, positioning this as the core deflationary mechanism.

That deflationary leg is paired with an inflationary leg. The whitepaper states that 10% of the tokens burned by the buyback-and-burn mechanism are automatically minted as “dynamic inflation,” which the team manually claims as needed and allocates to the foundation.

On-chain, the current implementation contract makes this burn-linked mint concrete. It defines MINT_RATE_PPM as 100,000 and PPM as 1,000,000, which is a 10% mint rate.

The function dailyMinting() computes newMinting = (dailyBurned * MINT_RATE_PPM) / PPM, mints that amount to the treasury address, and resets dailyBurned to zero.

Minting is permissioned. dailyMinting() is onlyOwner and rate-limited by a 1-day cooldown (MINT_COOLDOWN_PERIOD = 86400).

Burn tracking is also explicit. When a burn occurs (transfer to address(0)), the contract increments both lifetimeBurned and dailyBurned.

Mechanically, this means the system is attempting to run a net-deflation loop where the treasury “rebate” is 10% of whatever is burned. In token units, the net change from a burn-and-mint cycle is a 90% net burn relative to the amount burned, assuming minting is executed.

From a sustainability standpoint, this is closer to “inflation justified by activity” than most DeFi emissions schedules. The project is not minting tokens because time passed. It is minting tokens because tokens were burned, and those burns are intended to be funded by usage fees.

But it is still inflation. It still routes to a treasury. And it is still a governance risk because the owner chooses whether to execute minting and where the treasury points.

History: the November 2025 inflation redesign is a meaningful tokenomics change

The token contract is proxy-based and has been upgraded at least once. The token tracker shows an inactive implementation and a later active implementation.

The earlier (inactive) implementation includes a minting policy framed as “daily inflation in USD,” with DAILY_INFLATION_USD = 50,000, and exposes an admin function setOraclePriceFeed.

The later (active) implementation replaces oracle-based daily USD minting with a burn-tracked “mint 10% of tokens burned” policy via parts-per-million parameters.

The upgrade transaction is dated November 4, 2025 and shows a Safe-style execTransaction call targeting the proxy contract.

As an analyst, I treat this kind of change as structurally important. Moving from “time-based USD inflation” to “burn-linked inflation” shifts the macro behavior of supply. It makes supply reflexive to activity. It also makes supply reflexive to policy execution, because minting is still permissioned.

Fiscal flows and incentive gradients: this is a high-rebate, high-fee market design

Rain’s economic loop has two distinct legs that pull in different directions.

One leg is “revenue recycling” into participants. Of the 5% fee, 2.5% of market volume is routed to creators, liquidity providers, and resolvers as explicit rewards.

This is designed to bootstrap market creation and liquidity depth. The help center states that liquidity providers “collectively earn 1.2% of the total trading volume generated by that market.”

The other leg is “revenue recycling” into token scarcity. The remaining 2.5% of market volume is allocated to buyback-and-burn.

Put bluntly, Rain is paying supply-side actors to manufacture markets and liquidity, and paying token holders by shrinking supply. It is trying to subsidize growth while also building a credible long-run sink. For a comparison, see our Hyperliquid tokenomics.

The trade-off is that this exact structure can support unhealthy volume if the system does not have strong anti-manipulation norms and enforcement. When creators and LPs are paid as a fixed percentage of volume, actors can attempt to generate volume for the sake of rebates. The design does impose a real cost because a portion of the fee is permanently routed to buyback-and-burn, which is not recoverable by the same actors through rebates.

If participation rewards are eventually “paid in $RAIN,” as the whitepaper signals for the future, the system becomes more reflexive. The same volume that triggers buybacks could also trigger token-denominated distributions, which increases the need for strict controls and transparent reporting around reward calculation.

The dispute system also has a specific incentive shape. To open a dispute, the user posts collateral equal to 0.1% of market volume or $1,000, whichever is less, and disputes must be opened within a 1-hour dispute window after the winner is announced.

That cap matters. On very large markets, a $1,000 cap can be small relative to the potential incentive to contest outcomes. If the oracle and arbitration design is strong, the cap mainly limits spam. If it is weak, the cap can become an attack surface because it bounds the cost of nuisance disputes. The tokenomics angle is simple: if resolution trust degrades, volume decays, and the whole buyback loop loses its funding.

Governance and parameter control: the whitepaper describes a DAO, the contracts show privileged roles

The whitepaper frames governance broadly, listing operational domains that token holders can propose and vote on, including fee logic and oracle frameworks.

On-chain, the token uses OpenZeppelin’s vote-enabled extensions (ERC20VotesUpgradeable), which supports delegated voting power at the token layer.

But the token’s monetary policy execution is not DAO-controlled in the implementation contract. The function that mints inflation (dailyMinting()) is gated by onlyOwner.

The destination for minted tokens is also mutable by the owner via updateTreasury().

Upgrade history shows that a Safe-style transaction executed an action against the proxy contract on November 4, 2025, which is consistent with a multisig operational control plane at least at that time.

The earlier implementation explicitly included setOraclePriceFeed and UUPS upgrade authorization logic, emphasizing that the token contract’s policy surface has, historically, been admin-configurable.

The current implementation contains a hard revert message “UUPS upgrades disabled” inside _authorizeUpgrade, signaling a desire to reduce upgradeability going forward.

Still, the governance delta between “token holders govern” and “owner executes inflation and treasury routing” is real. For an informed audience, this is not a moral critique. It is a modelability critique. Token monetary policy is easier to underwrite when execution is credibly constrained.

Risk analysis: dominant risk is discretionary control over monetary policy and treasury flows, not the headline inflation rate

Rain’s tokenomics has a coherent long-horizon story: usage produces fees, fees fund buybacks, buybacks burn supply, and the token gate creates baseline demand from active traders.

But a coherent story is not the same thing as a stable equilibrium. The equilibrium here depends on two fragile inputs: (1) volume quality and (2) credible constraints on the entities that can route value from the protocol to themselves.

Dominant risk: Monetary policy discretion plus treasury routing creates a governance premium that the market will eventually price in.

The inflation mechanism is marketed as “dynamic,” but the on-chain implementation makes it an executed policy, not an automatic one. Minting requires the owner to call dailyMinting(), which is onlyOwner.

That matters because “optional inflation” is a powerful tool. The owner can choose to delay minting, batch it, or execute it opportunistically. The contract enforces a 1-day cooldown, but it does not enforce that minting must occur at a given cadence.

The treasury destination is also updateable by the owner. That means the final recipient of inflation can change without token-holder consent at the contract level.

Even if the team’s intent is benign, the market typically prices these surfaces as risk. The premium shows up as lower valuation multiples on fee streams, and a higher discount rate on future buyback narratives. Why. Because the same volume that funds buybacks also funds the story that justifies unlocks and treasury spending. If the treasury becomes a net seller into thin liquidity, the deflation loop can be overwhelmed socially even if it is not overwhelmed mechanically.

This risk is amplified by the fact that the contract has already experienced at least one meaningful implementation change affecting inflation policy. The system has precedent for changing monetary policy behavior.

The fix is not “no admin keys.” The fix is narrower and more practical: explicit governance constraints. Time-delayed execution. Transparent treasury policy. Explicit reporting on buyback execution and burn totals. And if the DAO is real, a credible path for the DAO to control the parameters that currently sit behind privileged roles.

Top 3 risks

  1. Centralized execution risk around minting and treasury routing. Trigger: the owner (or controlling multisig) changes treasury routing or changes how consistently inflation is minted. Mechanism: dailyMinting() and updateTreasury() are onlyOwner, enabling discretionary execution and destination control. Who bears it: $RAIN holders via dilution risk and credibility discount, and active traders via reduced confidence in the token gate’s long-run fairness. Measurable indicators: frequency and size of Minted events, changes to the treasury address, and observable net outflows from known treasury wallets to exchanges.

  2. Volume quality risk from fee rebates to creators and LPs. Trigger: actors discover profitable ways to recycle volume primarily to harvest creator and LP rebates. Mechanism: fixed-percentage rewards to creators (1.2%) and LPs (1.2%) scale with volume, potentially encouraging behavior that optimizes for fee routing rather than genuine information markets. Who bears it: token holders (buybacks funded by low-quality volume can create unstable price reflexivity) and legitimate users (worse market integrity). Measurable indicators: anomalous concentration of volume in a small set of markets, repeated self-referential markets by the same creators, and unusually high creator/LP reward capture relative to unique user growth.

  3. Resolution and dispute-system trust risk. Trigger: disputed outcomes, oracle errors, or perceived unfair resolution in high-stakes markets. Mechanism: a capped dispute collateral requirement and a defined 1-hour dispute window can concentrate contention into a short period, and any systemic failure reduces user willingness to trade, which directly reduces fee volume that funds buybacks. Who bears it: traders and LPs first (lower activity), then token holders (weaker buyback funding). Measurable indicators: rising dispute frequency, repeated appeals to human oracles, and sustained drops in market creation and trading volume following resolution controversies.

If you’re building a similar design, a good token economy design review is less about “adding more utility” and more about stress-testing who can extract value under adversarial behavior. In tokenomics consulting, I would focus on emission governance constraints and measurable triggers for changing fee splits, rather than cosmetic staking features.



This article is part of our Tokenomics Deep Dive series.