# Getting Rain ready for customers and growth

*1. Driving to completion for Neighbourhoods and Rubies*
- CI complete (Victor)
- Bot for liquidity for Sloshy and Neighbourhoods (Rouz)
- Bot prepared in a way that someone acn take bot, point it at their orders and run it (uptimehabit, fork hithub, update variables, run in a github action - fork repo, put in key, github runs every 5 minutes)
- Want to bot at specific orders and clear against other pools (0x API and clears against 0x)
- Testing bot in testnet/production environment (embed trust model in the bot e.g. point at the orders we trust)
- Basic OrderBook components and UI for Rubies and Love To (Josh)
- Front ends to do sales to their users

*2. Liquidity Pilot is showing the need for dotrain and Foundry*

- https://github.com/rainprotocol/specs/blob/main/dotrain.md
- Swap Hardhat for Foundry https://github.com/SunWeb3Sec/DeFiVulnLabs/blob/main/src/test/Backdoor-assembly.sol

- TBC, everyone read the DOTRain proposal and let's work out who is motivated to build it

*3. Long term culture of agency and intrinsic motivation*

Technology
- Wrapped balancer pools (two years ago)
- RainVM (last year)
- *Stable interpreter (today)*
- Dot.rain for composability and extensibility
- More interpreters and word packs
- I2

Business
- Not taking investment in core, core is open source, license nearly done, clear way of operating, no token
- Will focus bootstrapping through liquidity services that use rainlang + OB & through supporting larger product builds where we have a strength/ dont push us out
- That means all our pay and new ppl come through cash flow so we need to be smart about how we bring in opportunities
- Rain will always evolve as we skate to where the puck is going to be etc

1. Liquidity engine pilot
2. Liquidity customers and product e.g. simulation
3.

## Proposals

?
- Chain ID from Subgraph
- Bot to clear liquidity strategies
- Codemirror / parser
- QA?

### Gaps that are motivating dotrain as the jump straight from raw/individual rainlang strings to the kinds of tooling we want to build is too unstructured imo
- No ability to compose/metaprogram rainlang natively, means ppl need to resort to something like js string interpolation to do real work
- no ability to tell tooling where to find metadata (including context grid info, social comments and interpreter/extern op meta)
- no ability to paramaterise expressions at compile time, such as reusing an ob strategy but with a different token, or mocking out values for testing
- no ability to give things names and reuse/reference them unless they form a full LHS/RHS pairing
- fairly consistent feedback that index based entrypoints is confusing and limits reuse

(it's going to get especially painful when we want to make externs work, which is a fairly immediate concern with our i9r now maxing out code size)

## Ready with what we have now

- Neighbourhoods liquidity strategy (easiest, testing dust protection, price curve)
- Ruby liqidity strategy (loop so better testing needed - e.g. funds upfront, takes 5 years to sell not 18 months; model in these eventualities here's what happens, build playbook, idelaly made visible to token buyers upfront)
- Potential Love To liquidity strategy
- Ruby ideally proper QA - fuzz testing and monte carlo simulations

## Needs new words / some changes to interpreter

- Chronicle oracle / mid-point strategy
-

## Priorities

- Victor CI and Studio features
- Rouz parser, vscode, bot
- Marchus either studio social features and dotrain
- Si QA for rainlang
- Aish QA