A new DeFi native language for EVM (Rainlang at EthCC)

Lindy effect means the longer a technology is used without issues, the more likely it will continue to be used, but there's a problem

There's a problem with smart contracts

Very few people can read and write them

This leads to issues like more "rugs", less innovation, one-size-fits-all protocols, and a scarcity of expensive developers.

Solidity, while powerful, is not designed specifically for DeFi and has concepts that are difficult for non-developers to understand.

One way to solve this problem is to create a language specifically designed for DeFi, with a simple syntax, intuitive financial operations, and common DeFi interfaces built-in.

Thanks to this language, we maintain the key properties of Ethereum smart contracts: 100% on-chain, trustless, permissively extensible, permissively auditable, verifiable, and gas-efficient.

Introducing Rainlang (3:40)

Rainlang features:

• Simple syntax, likened to spreadsheet formulas
• Stack-based, with an assignment of the right-hand side to the left-hand side
• Numbers can have fractional components
• Token amounts represented intuitively, e.g. 1 WETH to 100 USDC is 0.01
• Built-in ERC-20 interface to get token balances
• Built-in access to Oracle prices (e.g. Chainlink)
• Ability to easily inverse ratios

How Rainlang works:

• On-chain parser and interpreter, acting as a "VM in a VM"
• Parses RainLang string input into bytecode
• Interpreter executes the bytecode to produce a result
• Designed to work best with an underlying contract

Rainlang isn't a replacement for Solidity, but it has several benefits like a single immutable entry point for parsing, evaluation, and formatting, one-to-one parsing and formatting, no need for third-party verifiers

Furthermore, it is more gas-efficient than equivalent Solidity due to Yul implementation.

One thing we can build with Rainlang: Raindex (10:30)

Raindex allows users to create perpetual dynamic limit orders in RainLang.

In Raindex, each strategy evaluates to a maximum amount and a price, and users connect their strategies to input and output vaults

1. Users deploy their RainLang strategies and fund the vaults
2. Solvers/fillers clear the trades by borrowing the output tokens, executing the swap, and keeping the arbitrage difference
3. Settlement is trustless and solving is permissionless

In other words, each order on Raindex is like its own AMM, with a personalized constraint defined in Rainlang.

Users don't need to care about the source of liquidity or how the trade is executed, only their specified constraint

Write a rainlang trading strategy (14:15)

Raindex is an alpha version of a DeFi app, still in development.

It provides a base-level application with features like orders, vaults, and charting. More specific user experiences could be built on top of Raindex.

On the screen above, we can see a streaming DCA (Dollar-Cost Averaging) Strategy

The strategy automatically executes small, regular purchases of an asset (Wrapped Flare) based on a fixed budget. It keeps track of the amount spent so far and adjusts the purchase amount accordingly.

The strategy utilizes Flare's native oracles to get the current price and sets a stale time to ensure fresh pricing data.

Josh (the speaker) mentions intentionally offering a slightly worse price than the market to ensure the trades clear quickly.

Raindex Features:

• Charting and simulation capabilities. Raindex allows visualizing and analyzing the performance of the deployed strategy.
• Onchain composability. There are discussions about reusable Rainlang snippets that can be referenced and composed by others.
• Privacy experiments. Josh acknowledges the need for privacy features and mentions exploring the use of privacy-focused EVM implementations.

Future Plans:

• Improving the user experience of Raindex.
• Experiment with more specific applications built on top of Raindex, such as a file caster, walk caster, and frames trading tool.
• Creating an onchain registry for easily referencing tokens, contracts, and Rainlang snippets.

Questions & Answers (27:30)

Do you need to deploy your strategy, or do you simply create a signature, and then the solver handles it?

Previously, the actual bytecode was deployed on-chain into storage. Now, only a hash of the bytecode is stored, and the bytecode is emitted. The solver has to fetch the emitted bytecode and match the hash.

In the end, this is a smaller transaction compared to deploying the full bytecode.

As a user, would it be better to have the best execution over the fastest execution, for example, to mitigate MEV concerns on Ethereum?

It makes sense to have a reverse auction within the output price to achieve the best execution.

Josh suggests starting the auction above the market price and letting it come down until there's an opportunity for a solver to take it.

Josh believes this approach should sufficiently solve the problem. Because as long as enough solvers are looking for the opportunity, it should clear as soon asthe price iss favorablee, but is open to other ideas.

Is there any minimization of the on-chain process between the time you send your Rainlang code and the actual deployment?

Raindex has built some off-chain composing features to allow you to set entry points and contain multiple Rainlang snippets in a single file.

However, once you have the Rainlang, there are no additional steps. You just go to the parser, get the bytecode, and add it as your strategy.

The parsing itself is a read-only operation and not a write transaction, so it's gasless. Comments in the Rainlang code are ignored and do not affect the cost.

Is there a way to include a native approach to have more randomness in the system?

Josh suggests that if there is a randomness protocol available on-chain, you can create a custom word for it and add it to the Rainlang interpreter.

Rainlang has a modular design, where you can have different sub-parsers for specific functionality, such as the order book or oracles.

So if you had a VRF protocol, you could create a sub-parser with a single word for it, and users could then add that sub-parser to their Rainlang code to use the randomness feature.