Payment pallet

[ndkazu]

Suggested items:

• Needed double map storage: (Tenant_id, month, payment).
• Guaranty deposit: is sent to the virtual account and reserved:
  1. In the case of a tenant's foul play, it's unreserved and distributed to the owners.
  2. Unreserved and returned to the tenant at the end of the asset occupation period.

Payment pallet

[ilhanu]

Guaranty deposit: is sent to the virtual account and reserved

agreed

---

If the rental price is set from the (return_on_rent * sale_price) this should be set once the sale is finalized.

Regarding the payment mechanism I was proposing during our call that the payment should not be classic monthly upfront payment, think we can do better than that.

So based on the contract the tenant agrees, let's say the rental contract is 1 year, in a calandar year this is 31536000 seconds. Our blocktime is 6 seconds. If the blocktime changes for what every reason we have a lag in block production or anything else this calculation falls apart, not sure how we could recover from that.

31536000 / 6 = 5.256.000 blocks

If the rental payment is set to 15000USD annually, we can calculate the rental price per block. 15000 / 5.256.000 = 0,002853881278539 rent per block If anything happens for the tenancy we have registered the amount owed on the blockchain without manual calculation.

We would have to come up with period in which we expect this rent to be deposited and claimed. It's a bit the opposite of a vesting contract

[ndkazu]

So we need to identify the following:

• Length of the rent deposit period
• Amount of the guaranty deposit
• Timing and conditions of the guaranty deposit slashing.

[ilhanu]

• Yes the length of the rent deposit is essentially the contract that the tenant signs.
• The amount we can do 2* or 3* the rent that is the set rent.
• I think regarding the slashing we should currently not implement something, think it's good to think about stuff, but i think we can put the focus in the payment mechanism instead of devoting it to slashing mechanisms.

[ilhanu]

In the above discussion we didn't really agree on a design for the recurring rent payment pallet. We have some inspiration for the payment-pallet and the vesting-pallet

We have two parts of the recurring payments we need to work on, 1. is the mechanism of requesting payment & paying it, 2. Is distribution of the payment to the fractional owners.

1. Payment mechanism

We need to set some structs in for the payment lifetime that is required and this information comes from the rental contract schedule. This is a template more or less the same for each contract that is created, but it might be different. If we agree the standard rental contract is 24 Months. The struct below is inspired by the vesting pallet.

pub struct ContractSchedule<BlockNumber, Balance: MaxEncodedLen + HasCompact> {
	/// Rental contract starting block
	pub start: BlockNumber,
	/// Number of blocks between vest
	pub period: BlockNumber,  // fixed amount blocknumber for a month, based on our blocktime.
	/// Number of payment period. If the contract is 1 year, this is 12. This is also taken along from the contract
	pub period_count: u32,
	/// Amount of rent that needs to be payed.
	#[codec(compact)]
	pub per_period: Balance,
    /// The amount of rent that is already payed.
    pub payed: Balance, // This is taken along for the payment pallet part. 
}

The above struct will help the payment pallet to know when to request payment after it publishes an event(New Period) using the on_idle frame_support::traits that we are in a new period. We expect that the runtime schedules the payment pallet to request payment every period. The tenant will have the fullfil the payment with accept_and_pay.

• We are missing some parts about where does the payment need to go to?
  • If it's the virtual account of the Asset how can we ensure it doesn't get entangled with the rest of the funds in the treasury?
  • We can generate a new account for each contract, so users can claim their funds from the contract for a long time to come.
• How do we deal with all of the periods changing at the same time ?

2. Distribution of the payment to the fractional owners

We are using the automatic runtime actions a lot in our chain, a great feature. But most substrate based chains are doing lazy-payouts. This is simply because they want to keep the chain as light as possible. In Polkadot PayoutStakers anyone can call this function. In Polkadot nomination pools you can claim your own stake, think this is more valid for our use-case. Looking at the code. This would give users the ability to claim their share based on their shares within the period.

[ndkazu]

Looked into it today:

• Only Virto & Acala use the payment pallet (Acala version is also using the latest Polkadot Library so this leaves us with Virto for an implementation model).
• All primitives in runtime need to be corrected to be compatible with ORML
  I personally think that this is not a job for M5 as it is the same as re-writing the runtime and all existing pallets to fit in one pallet. It would be faster to make our own minimal payment pallet inspired by orml_payments, and compatible with the substrate frame primitives from the start.
  After M5, we can then come back to orml_payment implementation and its implications.
  Too big of a gamble for M5.