RAIN

Rain (RAIN): Prediction Markets Built Around Pools, Oracles and Arbitrum

Rain is an Arbitrum-based prediction-market protocol where users can create event markets, trade outcome shares and provide liquidity. RAIN connects the system’s incentives and planned governance, but the project’s own documentation presents unresolved differences about when token-based access and DAO control are active.

What Rain is designed to do

Rain provides infrastructure for markets tied to real-world or digital events. Users can create public markets that anyone can join or private markets that require an access code. A market creator defines the question, possible outcomes, timing and initial liquidity, then chooses manual or AI-assisted resolution. The project documentation says a market can contain up to 26 outcome options and requires at least $10 of initial liquidity.

The practical audience is broader than a conventional sports-betting interface. Market creators can publish questions, traders can buy or sell outcome shares, and liquidity providers fund the pool used for trading. Builders can also use Rain’s SDK to create applications that query markets, construct transactions, read positions and stream events on Arbitrum One.

How markets and liquidity work

Rain’s standard market design combines an automated market maker with outcome shares. Users trade against a market liquidity pool rather than directly matching every trade with another participant. The project’s documentation also describes market and limit orders, allowing users either to trade immediately at the available price or wait for an order-book match at a chosen price. Prices therefore represent the market’s changing assessment of an outcome, but they are not guaranteed probabilities or redemption values until resolution is complete.

Liquidity providers fund the whole market rather than taking a single Yes or No position. Rain says providers collectively receive 1.2% of market trading volume, while the wider fee schedule allocates 1% to the creator, 0.3% to the resolver and 2.5% to RAIN buybacks and burns. These are protocol-design statements, not evidence that every market has deep liquidity or that providing liquidity is profitable.

Resolution, disputes and the oracle dependency

Resolution is a central dependency because a market’s final outcome determines which shares receive value. Rain supports manual resolution and an AI-assisted path. Its dispute documentation describes a one-hour challenge window after an outcome is announced, with collateral set at 0.1% of market volume or $1,000, whichever is lower. A dispute is first reviewed by an AI judge called Lex; an appeal can escalate the case to human oracles whose decision is described as binding.

For developers seeking faster settlement, Rain separately documents an Entropy Layer using Chainlink VRF for randomly generated scenarios. This layer does not resolve real-world questions; it is intended for applications where outcomes are determined by verifiable randomness. It also uses a limited shared liquidity pool rather than a separate pool for every market, creating a different risk and liquidity model from Rain’s event-based markets.

What RAIN does

RAIN is an ERC-20 token deployed on Arbitrum One at 0x25118290e6A5f4139381D072181157035864099d. Arbiscan shows the token contract as source-code verified and identifies it as an upgradeable ERC-1967 proxy; that means the token address delegates calls to an implementation contract, so contract administration and upgrade controls deserve separate review from the token balance and transfer history.

Rain’s current help pages describe RAIN as connected to Trading Power, contributor rewards, governance and the buyback-and-burn mechanism. A separate token page says the initial supply was 1.15 trillion and that 10% of tokens burned through buybacks may be minted for Foundation purposes. The white paper, however, states that governance rights are not yet exercisable until the Rain DAO is activated and that the token does not provide ownership, profit or rights to goods and services. Readers should therefore treat the exact live utility and governance status as an open verification item rather than a settled feature.

Governance and technical dependencies

Rain’s help-center governance page says users do not need RAIN to use the app or participate in markets and describes governance as the token’s primary utility at launch. The newer white paper presents a different control model: DAO governance is planned for a later phase, with timing and scope not finalized, while the Foundation and team retain control before activation. This difference matters because token ownership, protocol control and application access are separate questions.

The developer repository describes Rain’s architecture as smart-contract pools and automated market makers on Arbitrum One, with a separate API and optional account-abstraction layer for transaction execution. The SDK can read some information from on-chain contracts, while other functions depend on Rain’s API or a configured subgraph. That creates practical dependencies beyond the contracts themselves, including RPC providers, indexers, API availability, wallet security and Arbitrum’s continued operation.

Limitations to weigh

Rain’s own white paper identifies market volatility, smart-contract bugs, oracle errors, governance transition risk, vesting-related supply changes, bridge failures and reliance on Arbitrum, Ethereum and third-party infrastructure. It also says the buyback-and-burn mechanism does not guarantee price support or token value and may be modified, suspended or discontinued. Those disclosures are consistent with the main analytical limitation: RAIN’s value depends on the relationship between actual market usage, fee flows, token issuance, governance control and the security of multiple technical components.

Key takeaways

• Rain combines event-based prediction markets with pooled liquidity, outcome shares and manual or AI-assisted resolution.
• Liquidity providers fund entire markets and receive a stated share of trading fees, but returns depend on volume, market design and smart-contract performance.
• RAIN is used in the project’s incentive and token-economics design, while the exact activation status of Trading Power and DAO governance is not fully consistent across official materials.
• The Entropy Layer is a separate developer-oriented system for randomly resolved, fast-settlement applications using Chainlink VRF and shared liquidity.
• The token contract is deployed on Arbitrum One and is presented on Arbiscan as an upgradeable proxy, making administrative controls relevant to contract risk.

Risks and open questions

• Official Rain pages differ on whether holding RAIN is required for Trading Power and prediction-market participation.
• The white paper says DAO governance is planned and not yet exercisable, while help-center pages describe token-holder governance more directly.
• Market outcomes depend on manual resolvers, AI judging, human-oracle appeals or randomness infrastructure, depending on the product path.
• The documented buyback-and-burn design includes a Foundation mint equal to 10% of burned tokens, so deflation is not the only supply-side mechanism.
• Liquidity, API, subgraph, RPC, bridge and Arbitrum dependencies may affect market access, execution and withdrawals.
• The Arbiscan token page identifies an ERC-1967 proxy, so users should verify who controls implementation upgrades and related administrative functions.