SSI driven consensus with RWA (Invoice) staking

Background and motivation

Invoices are assets that do not create yield. We want to change that.

Design perimeter and assumptions

There are the native staking bonding_denom that is DT. To avoid creating another token which complicates the system and divert values from DT, which should represent the security of the network, we have decided to translate invoices into DT for the purpose of staking.

However, there are very distinct differences between staking DT and staking invoices. This is because the expected risk and reward are different.

Considerations specific to invoice staking

Invoice value are in fiat (Euro) and must be paid in fiat via the banking system of choice
Suppliers and Buyers are not necessarily DT holders
Suppliers are expected to take risk on the yield derived from invoice staking, which would have been zero if not staked anyway

Distinction between DT and invoice staking

	DT staking	Invoice staking	Rationale
Holdings	Already holds DT	Notarising invoices which are translated into staked DT, cannot transfer invoice derived DT	invoices -> DT is allowed for the purpose of providing security service to the network, it is not an exchange between assets
Delegate	Delegate desired amount of DT to validator	Notarise invoice and all minted DT are by default staked	We cannot allow partially staking of invoices, the full face value of the invoices must be fully staked, but it can be delegated to different validators
Expected Risks	DT rewards rates vs Slashing of validator	No slashing of invoice face value, only on rewards	Suppliers is providing their invoices as a service for the security of the chain, their risk is on the potential yield (i.e. service fee) and not the actual invoice value
Rewards	Reward rate depends on the inflation and desired bonding ratio minus validator commission	Rewards are shared between supplier and validator node (and therefore the delegators)	Since there is no unbonding period or slashing of the face value, rewards are shared between the validator and the supplier
Reward distribution & collection	Reward distributed and collectable at every block	Reward distribution and collection on invoice payment only	This prevents invoice default or fraudulant invoices minting DT rewards
Unbonding Period	Chain unbonding period	staked DT can have unbonding period, rewards will be distributed following unbonding decision	Security of the network is reflected by the value of the assets staked, if the invoice has been paid, the staked DT must at least be unbonded then burnt or burnt immediate, see section below for details
Undelegate	Can undelegate DT and withdraw after unbonding period	Cannot undelegate invoice derived DT, only exit when buyer pays	DT derived from notarised invoices are not transferable, they are minted on staking and burnt on payment, reflecting the ownership and asset value of the invoices on chain

* This point must be carefully analysed, unbonding period is there to:

prevent short range attacks (double spending) where validators can be slashed during the unbonding period

ensure the stability of the network (prevent sudden changes in the validator set)

ensure "skin in the game" for validators and delegators (prevent vote and exit, quickly unbond to validate another network) scenarios

Economic model and financial incentives

Suppliers (Invoice issuer)

On completion of the goods or services delievered to the Buyer, the invoices become an asset on the balance sheet of the suppliers - account recievable. However, there are no ways to derive any yield from this asset.

There are a few incentives for the suppliers to stake their invoices:

Service Fee: By providing the option for staking the invoice, the supplier is able to derive service fees (yield in DT). It must be designed such that suppliers do not put their assets at risk (Buyers are still liable to pay the invoice via traditional banking services or in the near future - regulated stable coins). The yield the network provides compensates for the the service the supplier provides to the network - security.
Speed of payments: D Chain should be encouraging buyers to pay early in order to attract suppliers. A early payment bonus (defined by params) is a feasible solution
Other services: Notarised invoices are a proof of the transaction between the supplier and the buyer. This can be used for other services - discounting via Platform-D DApp
DT rewards: Suppliers invoice staking service fees are paid in DT which will supplement their future transaction on D Chain, also allowing them to also stake their DT for additional yield

Buyers (Invoice payer)

Buyers are not directly involved in the staking process however, there are benefits for them to be involved:

Early Payment Bonus: the system encourages faster payments by introducing an Early Payment Bonus to the buyers with a set params of invoice notarisation date
Better offers: suppliers knowing that the buyers can provide track record (of payments) and that are willing to allow them to use their invoices (on DChain or other services) will be more likely to provide better offers (e.g. discounts, better payment terms, etc.
Other services: Buyers can may use other services, such as be investors on Platform-D DApp, which supplies their treasury with high quality short term assets

Validators

Validators are not directly incentivised or involved by invoice staking, however, they may benefit from:

invoice notarisation transactions bringing more fees to the network
self-delegation (see next section)

Delegators of DTs

Delegators of DT has more risk than invoice stakers:

has to wait for unbonding period
can be slashed

However, they are also able to be more flexible in their stakin:

deciding on unbonding date
collecting rewards at every block

They must be rewarded better than the invoice staking of the same amount of DT

Immediate or unbonding period of invoices?

Given that the unbonding period is actually introduced for security measures, we can keep that for invoices.

Pros:

gives a chance for the reward to be slashed (so that other delegators are not as affected)
delays reward distribution to supplier
follows the protocol of normal DT staking
no extra voting power when unbonding
no need to discount total voting power because it follows the same protocol as normal DT

Cons:

delays reward distribution to supplier (from supplier point of view)
the invoice no longer exist, we are just delaying the burn (which can be a good thing)

Point of Considerations:

when tokens unbond, the voting power of the validator decreases but everyone elses increases
during unbonding period, the unbonded tokens can still be slashed
during unbonding periods, the tokens are already inactive, removed from total active staked
during unbonding period, voting not allowed
the rewards are not distributed to the unbonded tokens

Non-Slashable invoice face value staking

Regardless on unbonding or not The problem of Non-Slashable invoices causes an inbalance in the system, where native DT stakers will have to pay for the slashed amount.

Example

Let's consider an example without yield for now.

Block H: Total active staked = 100, 000 - Buyer pays, invoice DT tokens are unbonds (10,000) (this is fine because it will just be burnt after unbonding period)
Block H + 1 : Total active staked = 90,000, unbonding is 10,000
Block H + 10 - Validator gets slashed for double sign at Block H - 10 (when invoice DT were still actively staked), penalty is 5%. Total active staked at validator is now 90,000*0.95 = 85,500 and total unbonding is 10,000*0.95 = 9,500
Block H + unbonding-ends - 10,000 tokens must be burnt but only 9,500 tokens are available, the remaining 500 tokens comes from the actively staked pool, i.e. remaining is 85,000. The remaining delegators has additional stash of 500/85500 = 0.58% of their tokens.

In this case, the reward pool must lock in the potential reward on the invoice DT portion because it might not be distributed if the invoice is not paid. Once it is paid, then the reward is split between the supplier and the shares in the validator (delegators)

This scenario breaks down when the validator does not have sufficient total active staked DT from normal staked DTs (NOT invoice derived DTs). Imagine the scenario that (if there are zero rewards, or rewards is less that 405/10000 = 4.05% of the total staked DTs)

Block H: Total active staked = 10, 100 - Buyer pays, invoice DT tokens are unbonds (10,000) (this is fine because it will just be burnt after unbonding period)
Block H + 1 : Total active staked = 100, unbonding is 10,000
Block H + 10 - Validator gets slashed for double sign at Block H - 10 (when invoice DT were still actively staked), penalty is 5%. Total active staked at validator is now 100*0.95 = 95 and total unbonding is 10,000*0.95 = 9,500
Block H + unbonding-ends - 10,000 tokens must be burnt but only 9,500 tokens are available, the remaining 500 tokens comes from the actively staked pool, but only 95 are remaining.

The following graph shows the yield of a specific case where

100,000 DT are staked, 10% yield applied, 5% slashing, 0% commission
ratio of those DTs are invoice derived (x axis)
yield of the delegators relative to the total staked invoice DTs (y axis)
part of the yield is split between the supplier and the validator (delegators)

See data here

Keyboard shortcuts

Platform-D Technical Design Document