Community Update #22 - First Look at Habitat V2

A primer about what's to come with Habitat V2

Hi everyone, it’s been some time! 👋🏽 With today’s update we reach a small milestone for Habitat - it’s been 100 days since the Habitat Mainnet Launch at end of June.

Since then, the rollup is close to producing Block #250 and the first diverse communities launched on the Habitat platform. Soon there will be our first ecosystem update, outlining the first settlers on the Habitat Rollup, their mission, and unique spirit.

Last week finished the GR11 Hackathon and winners were chosen and awarded in fast fashion. Submissions gave great ideas for the platform and displayed room and feedback for improvements around Habitat V2. The Habitat keeps building, growing and pollinating. 🐝

See the full update below, where we unveil the first details of our V2 which is coming very soon 👇🏼

---

⭐ GR11 Hackathon - Habitat Bounty Winners

Gitcoin grants Round 11 ended last week, 29th of September 2021. This was the first time attending and sponsoring a major Hackathon for Habitat, certainly not the last time.

It has been a great experience with the Gitcoin team and ambitious hackers - thank you all! A total of 15k USD in HBT have been awarded to the winners. #

Here is the Top 3:

Bounty: “Build a dApp on the Habitat Rollup”

🥇 - @tjvs - https://github.com/hominids/app

Bounty: “Launch a Community on Habitat & document feedback”

🥈 - @hadzija - https://github.com/hadzija7/Habitat-testing

🥉 - @abhinavmir & @catplotlib - https://github.com/AbhinavMir/CharityDAO

You can see all winners and the full review over here

---

👀 First Look on Habitat V2

This first overview jumps straight into the technicals, but we will take more time to introduce the concept with glorious examples in future updates. Most of the changes relate to the initial design and builds on top of the feedback and learnings we received since the Mainnet launch.

Most features and improvements aim to extend the capabilities of users and treasuries within the Habitat platform. Also, the infrastructure becomes more generalized, so that DAOs and developers can bring their existing setup with a minimum of changes onto Habitat.

Interfaces get another tweak, based on UX/UI research and community feedback. As mentioned, treasuries and communities become more flexible and customizable, not only for voting but changing the design or description will be easier in the future version.

These are the first details of the internal specs, enjoy the first bites 🦟

Modules V2 🦾

Habitat V1 Voting modules are strictly limited to voting algorithms for treasury management.

Version 2 will add a new transaction types that allows calling arbitrary contracts within a static context.

Functionalities like token transfers, token locks and storage will have a custom calling convention to accomplish state transitions without compromising the rollup security. Modules like token swaps, NFT minting, reputation and many more things are now possible.

Modules may also initiate direct withdraws to a benificiary. Modules can also print execution permits - the same functionality used to approve L1 executions.

Changes

• Introduce a new transaction type that creates a treasury (a new address on the rollup) with a target module address and a initialize function that serves as a constructor.

• Introduce a second transaction type that wraps to, data and handles state transitioning, token transfers, storage cells.

• Add migration functions to upgrade V1 treasuries to work with V2 modules.

• TBD

Module Bytecode 🧮

A V2 module will have the same bytecode constraints as V1 voting modules. Thus, they need to be deployed on Ethereum and registered on the Rollup via an Ethereum transaction that validates the bytecode of that contract.

The contract address will be the same on the rollup and is needed to construct new treasuries with that bytecode.

Treasury Mechanics 🏦

V1 Treasury (vaults) need to be migratable to Treasuries V2.

V2 Treasuries introduces the following new features:

• the ability to have a multitude of v2 modules attached to a single treasury

• appending and deleting modules to a treasury must happen via the treasury’s voting module

• the ability to change the treasurie’s voting module via a vote

• allows invoking v2 modules on the rollup via a proposal (encoded in internalActions)

• allows to call other modules on the rollup

• implements token withdrawals from the treasury for a beneficiary address

  • background: it’s not possible to directly withdraw assets from a treasury without locking the tokens up

• allows replacing the governance token of a treasury

Storage Cells 💽

Each V2 treasury has the ability to use & store 10 EVM words (32 bytes) worth of data. Storage mappings and alike are therefore out of reach and need to be implemented via the use of merkle trees in the module itself.

Token Transfers 💸

An invocation returns both the new storage cells and a list of actions. In this case, a token transfer. Tokens can be transferred from the transaction sender and the treasury itself.

Token Locks 🔓

Token locks allow to lock & unlock tokens from the transaction sender or the treasury itself. This is useful for voting and general lockup/vesting mechanisms

Pro-rata token transfers 🤝

Allows a module to transfer tokens given a numerator and denominator to transfer tokens, e.g. amount = (balanceOf(token, account)) * numerator / denominator. This becomes useful for tokenized shares.

Triage

• decoupling would lead to the totalMembers property to be removed

Decoupling

A community is a real entity on V1 that is the envelope for treasuries.

This entity is removed from V2 and is to be handled entirely by frontends.

Changes

• Remove all Community related smart contract features

• Each treasury gets a new governanceToken property

• Add migration function(s) to allow transitioning existing treasuries

• Add support for a topic-like transaction type that sole purpose is to relay metadata intended to be used by frontends.

  • This can act as a data-source for Community Metadata; intended for frontends

To support frontends in the task…

• Add a new transaction type that sole purpose is to publish metadata for a specific topic on the rollup.

Removing Staking Pool functionality 💔

Action

Remove TributeForOperator / Staking Reward Pools from the native habitat functionality and replace them.

Migration

Ever-changing Reward Programs are best suited for governance proposals. As a matter of fact, reward pools are currently funded via governance and could be replaced with another habitat tool like the Liquidity Rewards process and payout people directly via governance votes.

It may make sense to create a secondary Liquidity Rewards Treasury with shorter governance decision-windows that receives the operating budget from the Community Reserve.

---

That’s it for the current state of affairs and the ongoing development. Habitat keeps testing, onboarding and tweaking the platform. Quick & minor updates will arrive in Discord or Telegram - big steps are announced here and also on mirror.xyz (we are migrating soon).

See you soon! 🌞