I don't think it is immediately clear at all what it means or why it is good to have a "rain interpreter".

The EVM already has general purpose set of opcodes for smart contracts, why do we want to reinvent that wheel?

How is a Rain interpreter different to the myriad of languages like solidity, vyper, etc. that are high level, battle tested and compile to the EVM?

How can this possibly be gas efficient, useful, secure, etc.?

Everything that Rain can possibly do could be coded in Solidity (the Rain interpreter itself is Solidity) so what's the point?

As the Flow contracts progress through the QA process and test coverage improves, we can start to talk about things to do with Flow.

Yes there's all the marketplace, escrow, sale, mint type stuff you'd expect.

Maybe we can do something a little different and fun too?

One of the ongoing experiments we've been working on in our collective is a Rain-powered asset designer and marketplace. At the moment it's a "game designer" but in reality this could be applied to any kind of marketplace-as-gamified-economy.

Due to popular demand, I've recorded a demo of how you could use the Game Designer POC to quickly create a system of game assets, where the economy itself could be considered a game.

This week I spent some time on a general purpose struct that defines token movements. In the near future this struct and associated logic will replace the EmissionsERC20 contract.

This is all a leadup to "adminless upgrades" for interpreters (previously known as VMs) that I'll try to get working "soon".

In short, this is the crux of the flow code in Solidity from this week.

This post is synthesised from conversations with the Game7 DAO during their grants process.

Describe the problem that your potential users are facing today.​

Game economies are struggling to break the 1-2 token paradigm and so the ‘play-to-earn’ movement is being revisited with people not sure what will drive the next waves of adoption from web2 to web3 gaming.

This week I experimented with our new 32 bit VM to create a viable implementation of 16 bit external calls. This is a really big deal imo, so I'll explain what's happening and why you should care.

Disclaimer: This post is about unaudited code under active development. Implementation details, names, security features, gas costs, etc. may change significantly.

Much of the recent work has been consolidation of the "VM" code to take it to where the Rain ecosystem needs it to be.

The v1.0 VM is everything you see in the latest audit.

https://omniscia.io/beehive-rain-protocol-round-2/

The v1.0 system works fine as far as we know, there's no urgent need to stop using it if you are, but it is showing early signs of running into limits on several fronts.

This is just a blog post so here's only a high level summary, not comprehensive. Highly encourage you to checkout the latest branches in github and look around if you're interested.

Goals​

• Simple design to be understood by many people
• Native support for historical tier logic
• 1:N support for a single staking contract to have many different tier views on the same historical data
• Non-interactive rewards, users should passively accrue value until they exit the system
• Gas efficiency for both reads and writes
• No admin keys required to manage or rescale rewards over time
• Support third party tokens (but not necessarily "exotic" tokens, can be interactive)
• Support "same token" rewards as "revenue share" style distributions

Goals​

• Mechanism by which users can trade tokens with each other
• Optimised for long term distributions as well as general trading
• Be very clear why this isn't just another curve based AMM
• Works for ERC20 but has a clear path to NFT trading as a future upgrade

Current situation​

We have a finite Sale contract where a sale can start, facilitating one-way buys where the seller defines a curve and a buyer accepts it. The sale ends and at this point is judged "success" or "fail". In the failure case all the purchases can be rolled back by buyers, in the success case all the proceeds are forwarded to the seller in a single transaction.