Motivation

Benchamrking is necessary to generate the correct weight values for the different Extrinsics, and improve the security of the pallets.

Suggested Solution

Do an extensive benchmarking of the pallet-roles.

Creating pallet-housing-fund

Config

• init accountId initiated at genesis.

extrinsics

• Investors can deposit and withdraw their funds.
• fund registers which accountId, amount, and blocknr the funds were committed.
• if a user withdraws any amount, it has the has_withdrawn bool activated

query

• contribution of an investor keeps up the total per investors and it has withdrawn(bool) their accountId.
• housing_fund needs to have a getter for the total_funds.
  • Show total balance (total transferable + contributed + reserved)
  • Show total transferable ( the available balance spendable)
  • Show contributed balance ( the withdraw able balance by the user and reservable by the housing fund)
  • Show total reserved (the users fund reserved by the housing fund)

Needed Additional Features

- Loose coupling of Litentry NFT pallet
- Add fractional nft function in Fairsquares pallet
- Rewrite FairSquares pallet around Litentry nft pallet, instead of Anmol nft pallet
- Voting system for a proposal approval (https://docs.substrate.io/rustdocs/latest/pallet_collective/index.html).
- Proposal destruction function (proposal not approved, or expired projects)
- Design & Implementation of the logic behind the choice of the contributors for each proposal
- Design & Implementation of the rent payment logic.

The FundInfo, stored in the FundBalance storage, keep track of the amount used to buy houses.
The goal is to have this value computed and not kept in the blockchain.
The field FieldInfo.Contributed has to be removed and the code refactored according to the change.

Remove the all the pallet folders that are not being used for milestone-1

Provide a documentation for the housing fund pallet's code.

1. Currently the node-template uses DEV units, it helps to have already using a stable token such as the EUR, to a something more widely usable token for demo's and end purposes.

2. The token needs to be reservable and/or locked when in fund it stays locked and the locked value can grow by means of interest and when l bid for a house the locked amount needs to be reserved until the tx finalizes.

Ideas:
Implementing token pallet of orml that support multi-currency could give us some edge in the future.

This issue will be described further, needs discussing what , when, how.

We need automated testing for the core of FS. We needs to add into the genesis file of our node so we can test in code instead of running the node and manual inspection.

Scenarios's that need to be ran:

• Bond and Unbond stable-coin from the fund
• Bond (2+ Actors), Mint an Asset, successful buy and successful transfer of ownership.
• Bond (2+ Actors), Mint an Asset, unsuccessful buy and successful destruction of the asset on-chain.
• Testing the selection of the stables provided in the fund with the fs-allocator
• Apply for rent and deposit the rentalDeposit.
• With no recurring payments of rent the rentalDeposit get's distributed to the owners and the contract is destroyed.

The share of investors in the housing_fund is updated each time a contribution or a withdraw is done.
This share should be calculated when needed.

The pallet must not compute anymore the share when a contribution or a withdraw is done.

• Remove the share field from the contribution struct
• Remove the call of update_contribution_share from contribute_to_fund and withdraw_fund
• Remove update_contribution_share from functions.rs
• Update the tests and benchmarking

The rental module focusses on the contract with the renter, recurring payments in time payments. The module for the renter should stay simple for now and can be extended more in the future.

First priority is the recurring payments and assigning a renter.

1. A verified role of a renter registers and deposits a small amount
2. The renter is on-chain registered and can be picked up by a estate agent to match (role)
   2.1 OR the renter can apply to a house herself.
3. The renter signs a contract for minimum 1 year and deposit a fee for 1-2 months in the contract.
4. Once all done the recurring payments work, which the basis is blocktime

Open Questions

• Assignment of a renter, should the investors decide who becomes the renter ?
• How we deal with block-time lengths and real world dates ?

Motivation

The nft pallet uses the type u8 to represent the nft share as a percentage. this is not suitable if we have decimals involved, such as 2.5% for example.

Suggested Solution

Instead of percents, we could use the type permills, which will give us a more precise representation of the NFT share for each contributor.

Fast voting stakeholders
Can't always rely on the housing council, we need help form the FS stakeholders to weigh in on the oppurtunity/risk of managing the onboarding of assets.

Off-chain worker
The fs-allocator is supposed to be off no weight for the system that relies on the blocktimes with dates and needs me be less compute heavy, if a. lot of houses are onboarded. In the future the computation needs to be off-chain, for now simple ruleset for the fs-allocator will work

Wide varierty of roles
FS will rely on real world actors, but for now we are assuming that Alice and Bob are just as trustworthy as credited realtors or estate agents, if not more.

Reputation systems
How to deal with new-entrants and bad performing or sketchy actions, how to make sure that some people can't game to system ? We can't always rely that the community needs to be on their toes when a bid is done on house.

Secondary Market
The fractional shares can always be traded on a secondary market if people wan't to offload their shares, the renter is at all times protected by it's contract.

Interest
When users have bonded their capital, but it's in the fund and no houses getting listed, it's attractive for users to get a return on their bonded capital, by means of channelling their capital to a Defi Savings product.

Motivation

Storage in the context of blockchain is mostly about on-chain state. But it is expensive (as it is populated to each node in the network) and not recommended for historical or user-generated data which grow indefinitely over time.

Suggested Solution

We have offchain storage for this purpose. In addition of being accessible by OCWs, Substrate also includes a feature called "offchain indexing" allowing the runtime to write directly to the offchain storage independently from OCWs. Nodes have to opt-in for persistency of this data via --enable-offchain-indexing flag when starting up the Substrate node.

Additional information

Unlike OCWs, which are not executed during initial blockchain synchronization, offchain indexing is populating the storage every time a block is processed, so the data is always consistent and will be exactly the same for every node with indexing enabled.

A team discussion is needed for this...

use custom benchmark values for pallet-roles

Motivation

Vital feature for FS, is the bonding of the capital. This is the first step for the DAO to go live and that there is a housing fund, where all the capital is pooled in

Suggested Solution

• Create a fund / bank pallet
  • Users can deposit and withdraw their capital if not being utilised already by a house.
  • The fund tracks:
    • Total amount deposited
    • Time of commiting capital
  • The fund is able to invest an agreed amount in a transfer if a deal for an estate is go!

Additional Information
This pallet seems to have a close use of the fund/bank

• https://github.com/sunshine-protocol/sunshine/tree/master/pallets/bank

Motivation

Use a valid admin account for verifiers, when initialising HouseSeller and Servicer roles .

The contribution flow of adding capital to the housing fund

1. Users once verified can contribute stable token to the housing fund.
2. Funding
   2.1. The users fund stays in the fund and is registered in the fund with their contribution amount and blockNr.
   2.2 The users that wan't to take out a full amount or a part of their capital are allowed, the register of totalCapitalBonded will be updated
3. The fs-allocator will define for all contributions when bidding on an asset, whose funds and how much of the funds will be taken along. More on this in future issue
   Bidding succes?
4. If the bid is successful the funds are converted into fractionalized shares of a house.
   Bidding fails?
5. When the bid fails and is not sold to FS investors, then the funds are returned and investors are still first in line when a new asset is listed

open questions:

• How to deal with several contributions for the fs-allocator

Description

Not all traits are not all trait items implemented Getting following errors

error[E0046]: not all trait items implemented, missing: `Currency`, `MinContribution`, `WeightInfo`
  --> pallets/housing_fund/src/mock.rs:52:1
   |
52 | impl pallet_housing_fund::Config for Test {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `Currency`, `MinContribution`, `WeightInfo` in implementation
   |
  ::: pallets/housing_fund/src/lib.rs:40:9
   |
40 |         type Currency: ReservableCurrency<Self::AccountId>;
   |         --------------------------------------------------- `Currency` from trait
41 |         type MinContribution: Get<BalanceOf<Self>>;
   |         ------------------------------------------- `MinContribution` from trait
...
44 |         type WeightInfo: WeightInfo;
   |         ---------------------------- `WeightInfo` from trait

warning: unused import: `Error`
 --> pallets/roles/src/tests.rs:1:22
  |
1 | use crate::{mock::*, Error};
  |                      ^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused imports: `assert_noop`, `assert_ok`
 --> pallets/roles/src/tests.rs:2:21
  |
2 | use frame_support::{assert_noop, assert_ok};
  |                     ^^^^^^^^^^^  ^^^^^^^^^

   Compiling pallet-transaction-payment-rpc-runtime-api v4.0.0-dev (https://github.com/paritytech/substrate.git?branch=polkadot-v0.9.23#76522d79)
error[E0599]: no function or associated item named `do_something` found for struct `pallet::Pallet` in the current scope
  --> pallets/housing_fund/src/tests.rs:8:33
   |
8  |         assert_ok!(HousingFundModule::do_something(Origin::signed(1), 42));
   |                                       ^^^^^^^^^^^^ function or associated item not found in `pallet::Pallet<mock::Test>`
   |
  ::: pallets/housing_fund/src/lib.rs:50:5
   |
50 |     pub struct Pallet<T>(_);
   |     ------------------------ function or associated item `do_something` not found for this

error[E0599]: no function or associated item named `something` found for struct `pallet::Pallet` in the current scope
  --> pallets/housing_fund/src/tests.rs:10:33
   |
10 |         assert_eq!(HousingFundModule::something(), Some(42));
   |                                       ^^^^^^^^^ function or associated item not found in `pallet::Pallet<mock::Test>`
   |
  ::: pallets/housing_fund/src/lib.rs:50:5
   |
50 |     pub struct Pallet<T>(_);
   |     ------------------------ function or associated item `something` not found for this

error[E0599]: no function or associated item named `cause_error` found for struct `pallet::Pallet` in the current scope
  --> pallets/housing_fund/src/tests.rs:18:35
   |
18 |         assert_noop!(HousingFundModule::cause_error(Origin::signed(1)), Error::<Test>::NoneValue);
   |                                         ^^^^^^^^^^^ function or associated item not found in `pallet::Pallet<mock::Test>`
   |
  ::: pallets/housing_fund/src/lib.rs:50:5
   |
50 |     pub struct Pallet<T>(_);
   |     ------------------------ function or associated item `cause_error` not found for this

   Compiling pallet-session v4.0.0-dev (https://github.com/paritytech/substrate.git?branch=polkadot-v0.9.23#76522d79)
error[E0277]: the trait bound `Test: pallet_sudo::Config` is not satisfied
  --> pallets/roles/src/mock.rs:52:6
   |
52 | impl pallet_roles::Config for Test {
   |      ^^^^^^^^^^^^^^^^^^^^ the trait `pallet_sudo::Config` is not implemented for `Test`
   |
note: required by a bound in `pallet::Config`
  --> pallets/roles/src/lib.rs:38:41
   |
38 |     pub trait Config: frame_system::Config+SUDO::Config {
   |                                            ^^^^^^^^^^^^ required by this bound in `pallet::Config`

Steps

in the root of the repo cargo test --release

Expected vs. Actual Behavior

Expecting tests to pass.

Additional Information

This is. requirement for docker images and testing framework.

The roles pallet for now gives users the extrinsic to set their own role. The roles-pallet gives users the following roles to be implemented within M1. [investor, tentant, seller, servicer].

• investor and tenant get the role immediately
• Seller and servicer can set the role themselves, but need judgement from a role verifier.

Requirements:

• An account can only set one role ( defined in w3f grant)
• The role verifier will provide judgement, for now this belongs to a different

Testing scenarios, not excluded to the

• #50
• Getting several roles, unsuccessful
• Getting role (seller, servicer) without verification, unsuccessful

This part uses the treasury pallet of substrate . The main features are what is also defined in the pallet its-self, but customised to the housing market.

We should call it the housing fund instead of treasury, since owners will deposit their capital in the fund, instead of collecting tx-fees, staking inefficiencies or pre-funded as most current PoS systems do.

The main features are

propose_spend - Make a spending proposal and stake the required deposit.
reject_proposal - Reject a proposal, should not slash the deposit (different then current treasury)
approve_proposal - Accept the proposal, returning the deposit.

• The deposit parameter might need tweaking as we cannot expect, everyone that onboards a house to have 10% of the housing value in their wallet, but still expensive enough to not be spammed.
• The time period of the proposal being approved also needs to be fast-forwarded. We need to carefully design here the speeds vs. security spectrum.

The deposit for a house should be in line with the housing price, when proposal is rejected the NFT is burned. When proposal is approved the data is extended in the NFT.

Motivation

_Houses will be an NFT that will be fractions of the investors shares. We chose to make them NFT's as these standard of fractions could also be for other cross-chain applications. _

Suggested Solution

Integrated

• NFT Pallet
• Functions: Mint, Burn, Freeze, Thaw
• The NFT should have one class which is real-estate asset, in further issues we can explore how we streamline the minting.
• Make it the NFT's divisible / fractional

Alternatives

Instead of implementing the NFT pallet, we can also work with shares of houses that would essentially be the same

Additional Information

• https://github.com/danforbes/pallet-nft
• https://github.com/open-web3-stack/open-runtime-module-library/tree/master/nft
• https://github.com/paritytech/substrate/tree/master/frame/assets
• A good ERC-1155 standard in rust is still to be found: https://github.com/enjin/erc-1155

• Check if account is already in waiting list
• Add corresponding failure test

Rewrite the FS pallet functions to make them work with Litentry pallet

Final Steps for the pallet_role:

• Delete commented code, unless it's documentation.
• Test Account_Creation
• Test Account_rejection
• Additionnal testing where necessary

Motivation

The FS stakeholders arrive should a bid price based on the value of the house. Before an offer can be made on a house, it must be known with which investors and how much money per investor together the total bid is formed. The intention is that an offer must be made quickly and then it is up to the seller or authorised representative to make a choice.

For the purpose of this hackathon we are going to keep it light and not make it hard as explained in the Wiki, which would be the ideal implementation for better price and competitive markets

Suggested Solution

• Checking if there is enough $/€ in the housing fund, for a house that has the status listed
• Define which stakeholders/investors get selected for the house.
  • If so, continue placing a bid with a +3% margin ( just a assumption)
  • If bid is successful and get's accepted by the seller:
    • The house get the status onboarded
    • The investors get their part of the house as an fractionalized NFT
  • if bid is unsuccessful
    • The house get's the status rejected
    • The investors selection returns to normal

Additional Information

This is the most novel part of the of the FS platform, willling to discuss. The above implementation is the most simple one, if we can implement this, we can always improve the realness of it. At the moment it might feel like abracadabra but this is the flow in simple steps.

On old dependency since the hackathon, that is outdated and not maintained, needs to be removed and dependencies in the code that touch upon the fractionalisation.

As for now , it is permissioned investing, and this issue is a research issue and it will also interfere with the initial ROI planned for FS project.
So we have a minimum amount for investor to be in the storage. But We can lower the barrier by introducing Pools. An investor can open account as a solo or a pool, and this can enable more investors to be onboarded in.

We want FS to be permission-less, but still trustworthy. Therefore we want to use specific standard and identification ways that are being standardised by industry. Before getting there we need to have.

For now we would assume that the roles are honest players and verified we will make use for this role will be integrated with the #19 an estate agent or house owner, that can onboard a house. The inputs required:

• Unique ID generated by the system for the object [increasing assetId]
• House owners [accountId]
• When you want the sale to happen[ blockNr]
• Province ( something about the location ? )
• Square meters [Tied to a global parameter to pricePerSqm]
• Deposit for onboarding onboardingDeposit

This generates/mint's an NFT with the current representative the estate agent and the owner the estate owner. The value of the house will be generated based onsqm*pricePerSqm.

The lifecycle of the NFT could be a maximum duration [lifetimeNft] that is a configurable constant, e.g. 2 weeks. If nothing happens with the onboarded asset, the nft get's burned and the deposit is transferred to the treasury.

Simplified sequence diagram

sequenceDiagram
    participant houseOwner
    participant onboarder
    participant registry
    participant house
    Note over houseOwner,onboarder: can be same person
    onboarder->>registry: enters [ 'Sqm', 'locationData`, 'owner' ]
    registry->>house: generates a NFT with the data entered * Constants
    Note over registry,house: pricePerSqm=5000
    Note right of house: There will be an unique assert that has a base-price and it can be bid on by the housing fund

Complete the benchmarking for pallet-roles

The Nick Pallet tutorial on substrate.dev can be used as a guideline for this task. ==> this is not correct: the Nick Pallet shows only how to add a Pallet to the runtime...
Also decouple the Anmol nft pallet

deliverable milestone 1 - W3F grant

• pallets
  • #64
    • code
    • #69
    • documentation. --> guidelines
  • #65
    • code
    • unit-testing
    • documentation
• #66
• Article milestone-1 Mahir & Ilhan
• #67
• Dockerfile. + Instructions
• Licensing
• #68
• place to publish ? Medium? Subsocial? Github ?
• grants delivery repo:
  • https://github.com/Fair-Squares/Grant-Milestone-Delivery/blob/fs-m1/deliveries/fair_squares-milestone-1.md
• Update how to run all the tests.

• change docker paths and names
• change node-template to node-fs

The Housing council exist of public figures, founders etc. People that strive for a more fair housing market and represent the mission by taking a seat in the council.

Currently there is no voting mechanism yet in place with a native token, so these roles in the current POC will be entered in the genesisConfig, these can be Alice, Bob and Charlie, or other keys can be entered with sudo.

We want FS to be as much as automated and in a testing version, we don't want to wait for a council approval to experiment, which are extra steps. So as a current measure maybe the council can object against a purchase and rental agreement.

The housing council for now has the ultimate say whether a house is acquired, this is still a big subject for research but with an early implementation we can showcase the usage of governance.

Also the council can propose changes to the protocol-wide parameters such as Return on Rent etc.

Motivation

Step away from the Litentry pallet which is still in development, and use the features of the more complete uniques pallet through a customised FairNft pallet.

Motivation

With the NFT pallet and the housing fund in place, we want to onboard estates on-chain. In real-world there would be many more checks but in this case Alice and Bob suffice. Built on the NFT pallet, we have a pallet that utilizes the NFT pallet and turns the estates in NFT's. The NFT has the features of the homes.

Suggested Solution

This function uses the NFT pallet of choice and wrap around the logic to onboard a house. This means that we need to have some constants to make the process smooth. Such as we can set a square meter price (Sqm. price) as a constant and start from there

• Unique ID ( start with the number 1.)
• Constant price for a square meter price * Square meters of the property define the price
• Status ( listed, in_auction, rejected, onboarded)
  • When the status is rejected the NFT is burned @dabaojian1992

Alternatives

This seems to be the easiest way to go, if there are any alternatives, glad to hear. Once this is created, we can see what else we can add to this.

Additional Information

• For the unique ID: https://docs.substrate.io/tutorials/v3/kitties/pt1/#write-the-create_kitty-dispatchable
• Constants in Runtime: https://docs.substrate.io/how-to-guides/v3/basics/configurable-constants/
  • Also check if with Governance we can change this constant.
• For status and errors also check the Kitty tutorial for more info : https://docs.substrate.io/tutorials/v3/kitties/pt1/

Right now, tight coupling with the Anmol NFT pallet is used.
the Litentry NFT pallet not having the fractional function, we need to:

• Identify this part of the code in the Anmol NFT pallet
• Implement it in FS pallet as a function that takes as input an NFT minted by the Litentry pallet

The goal is to separate main.rs into several files. For example, one file roles.rs for all the different roles (see the pallet diagram) and their implementation.
The Branch structure_template is used for this activity and is already loosely coupled with the Litentry pallet.