The Rain Protocol

A Framework for Verifiable Promises


Introducing Rain.

1. The Vision: An Economy of Strangers

Imagine a global, decentralized economy where strangers can seamlessly and safely interact. An economy that facilitates:

  • Loans: Without traditional banks or credit scores.
  • Insurance: Pools created and managed by their members.
  • Collaboration: DAOs where voting power is tied to merit, not just wealth.
  • Offline Trade: Commerce in areas with intermittent or no internet connectivity.

Building these powerful financial instruments requires solving one fundamental problem: trust. But what do we truly mean by “trust” in a decentralized system? The blockchain solved part of this puzzle, but several critical layers remain.

2. Deconstructing Trust: A Layered Model

To build a robust system, we must understand that trust is not a single challenge, but a hierarchy of four distinct problems.

  • Layer 1: Trust in the Machine (Foundational Trust): This is the trust that the fundamental rules of the digital universe will be upheld. It is provided by the underlying blockchain, such as Ethereum. We trust that its distributed consensus mechanism guarantees atomic execution and immutability. A transaction will either execute completely as coded or fail entirely, and its outcome will be recorded on a final, censorship-resistant public ledger. Rain relies entirely on this layer as its bedrock.

  • Layer 2: Trust in the Actor (Identity Trust): This is the trust that an actor is a unique person and the same person they were yesterday. This layer addresses the “Sybil attack,” where one entity creates countless fake identities. Rain provides identity persistence natively by minting a non-transferable Soulbound Token (SBT) to each user. For uniqueness, Rain does not attempt to solve the “proof of unique humanity” problem itself. Instead, it is designed to compose with best-in-class external solutions like WorldCoin or BrightID, making the system modular and focused.

  • Layer 3: Trust in the Application (Code Trust): This is the trust that a specific application or “script” built on the protocol does what it claims to do. The core protocol cannot technically enforce “good code” without becoming a centralized censor. Instead, Rain fosters a free market for trust. It provides radical transparency, allowing signals of code quality—like public audits, formal verification, and community consensus—to emerge organically, empowering users to verify the code they interact with.

  • Layer 4: Trust in the Human (Counterparty Trust): This is the highest and most complex layer: trust that a person will choose to keep their promise, even if the code allows them not to. This is the primary problem Rain is designed to solve.

3. The Solution: A Language for Verifiable Promises

Rain solves the problem of Counterparty Trust by creating a system to incentivize promise-keeping.

A Formal Definition of a Promise

In a computational system, a promise is a discrete, verifiable data structure. We define a Promise (P) as a tuple: P = (Promisor, Promisee, Content, Deadline, State), where State can be Pending, Fulfilled, or Defaulted.

The Design Space of Enforcement

To incentivize a promisor, one can apply four types of economic pressure: Forfeiture-of-Present-Value (a bond), Gain-of-Future-Value (a reward), Shared-Fate (a co-signer), and Exclusionary (banishment). A protocol that relies on only one of these is fragile. Rain’s strength is its hybrid nature; it provides the tools for developers to combine these mechanisms.

The Free Market of Scripts: Good, Bad, and Transparent

It is crucial to understand that Rain’s goal is not to ensure every agreement is a “good deal.” The goal of Rain’s mechanism design is to create a set of incentives and consequences so clear and unavoidable that the economic outcome of a Promisor’s choice—to fulfill or to default—is perfectly predictable.

Anyone can write a script on Rain. You could write:

  • A “Bad” Loan Script: A script that offers a loan but forgets to call stake(). The CalculusEngine will happily record the promises. A savvy lender will read the script, see the lack of collateral, and refuse to use it.
  • An “Instant Default” Trap: A script where the loan deadline is one second after it’s funded. The CalculusEngine will record this deadline perfectly. A user’s wallet can read this data, warn them of the impossible term, and they will refuse the loan.

Rain does not protect users from bad decisions. It provides them with perfect, immutable information so they are empowered to protect themselves. In this ecosystem, transparency is the security model.

4. The CalculusEngine: An Economic State Machine

The CalculusEngine.sol contract is an Economic State Machine Interpreter whose sole purpose is to manage the lifecycle of promises. The “state” in this machine is the Promise data structure itself. The engine’s functions are the only valid “state transitions.”

  1. Creation: monitoredPromise(...) creates a new promise object and sets its state to Pending.
  2. State Transition (Success): monitoredFulfillment(promiseId) transitions the state from Pending to Fulfilled.
  3. State Transition (Failure): monitoredDefault(promiseId) transitions the state from Pending to Defaulted.

This interpreter model is a critical security feature. A bug in a third-party script cannot corrupt the system. The script can only request a state transition; the engine itself enforces the rules, guaranteeing the integrity of the promise log.

5. Making Promises Matter: The Quantifiable Value of Reputation

For the threat of a reputation slash to be a meaningful deterrent, reputation must have clear, quantifiable value. Rain achieves this through a symbiotic, dual-component model.

1. Direct Value: The Reputation Dividend This component provides a direct, passive cash flow, giving every reputation point a tangible “floor price.”

  • The Mechanism: All economic sessions begin with a monitoredAction(), which charges a protocolFee. These fees are collected in the TreasuryV2.sol contract. The Treasury, governed by the RainDAO, invests this capital into a whitelist of secure, external DeFi protocols (e.g., Aave) to generate yield. This yield is then periodically distributed to all users as a Reputation Dividend, proportional to their score, via a gas-efficient Merkle drop.
  • The Impact: The primary purpose is to make the threat of loss economically painful. A reputation slash means the permanent loss of a claim on this future cash flow, representing a direct and measurable financial penalty.

2. Indirect Value: Utility & “Superpowers” While the dividend provides a stable floor, the most significant portion of reputation’s value comes from the powerful, exclusive economic actions it unlocks in third-party applications.

  • Example: Undercollateralized Lending. This is the quintessential superpower. A standard DeFi protocol might require 12,500 of collateral for a 10,000 loan. A Rain-based script, trusting a user’s high reputation, might require only 5,000 of collateral, with the remaining risk secured by their reputation stake. The economic surplus is the 7,500 of freed-up capital the user can now deploy elsewhere. The annual return on that capital is the direct utility value of their reputation.
  • Example: Access to Trusted Roles. Other applications, like decentralized marketplaces or arbitration services, can use reputation as a prerequisite for lucrative roles like juror or escrow agent—roles unavailable to low-reputation participants.

These two value streams create a powerful economic flywheel: Utility drives activity -> Activity generates fees -> Fees fund the Treasury -> The Treasury pays dividends -> Dividends give reputation tangible value -> This tangible value makes losing access to Utility a credible threat -> This reinforces trustworthy behavior, which enables even more valuable Utility.

6. From Theory to Practice: Building the Vision

This framework of verifiable promises, backed by valuable reputation, directly enables the applications we envisioned.

  • Loans & Insurance: A borrower stakes their reputation as a bond. A default leads to a slash, the loss of the bond, and the loss of future dividends.
  • Collaboration: A DAO can require members to stake reputation to vote, ensuring participants have skin-in-the-game.
  • Trustless Offline Trade: A user stakes reputation to get a “credit line,” allowing them to issue signed promises offline (e.g., via QR code) that can be settled on-chain later. The Rainfall Pool, a dedicated lending market, can fully collateralize this credit with real capital, ensuring the system is always solvent while the price of risk is discovered by the market.

7. Future Directions

  • Richer eDSL Primitives: Introducing conditionalPromise to enable more complex financial agreements.
  • The RainDAO: Establishing a DAO to govern the protocol, manage risk parameters, and direct treasury investments.
  • Formalizing Offline Systems: Building out the agent software for the offline-to-online settlement market.

8. Conclusion

By deconstructing the problem of trust, we have designed a protocol that addresses each layer with the right tool. Rain provides a new foundation for the decentralized economy, built not on blind faith, but on verifiable promises and rational incentives. It is a transparent, expressive, and economically robust toolkit that empowers developers to build the next generation of trustworthy financial applications.