Skip to main content

· 2 min read
David Meister

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?

· 3 min read
Josh Hardy

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.

· 16 min read
David Meister

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.

· 4 min read
David Atkinson

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.

· 21 min read
David Meister

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.

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.

· 20 min read
David Meister


  • 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

· 13 min read
David Meister


  • 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.