Priority Downgrade

Why downgrade?

Some Users may want extra yield in exchange for taking more risk. By downgrading CT-tokens from Middle to Low they forfeit first-loss protection, but become eligible for a share of the fees paid by others who upgraded to High.

Basic rules

Rule	Detail
Capacity cap	Low tokens may never exceed ⅔ of total CT supply (because High is capped at ⅓).
Only Middle ➜ Low	You can’t jump straight from High.
Cut-off date	Downgrade must be recorded ≥ 1 day before the loan’s maturity date printed on the CT.
No default	Downgrades are frozen once the Project is declared in default.
Free action	Unlike upgrades, downgrading carries no upfront fee.

Payout Logic

Low-priority CTs are paid once per loan, at whichever event happens first:

• the loan is fully repaid, or

• the Project defaults.

The payout pool comes from the upgrade fees collected earlier:

Payout Logic (Advanced Users)

1. Aggregate the fees

where:

• S: total middle to high upgrade fees collected.

• u ∊ U↑​: set of CTs upgraded to High

• P_u: fee paid for each upgrade.

2. Platform comission

where:

• c: commission rate (burned by the platform).

• F: funds left for Low-priority holders.

3. Weight each Low CT

• d_i​: days from downgrade date to loan maturity. Earlier downgrades → larger did_idi​ → higher weight.

• r: annual interest rate of the loan (APR).

• k: (e.g., 3x).

4. Distribute the pool

Here, each Low-priority CT iii is assigned a weight wiw_iwi​ (from Step 3) that reflects both how early it was downgraded and the loan’s APR. The denominator sums all weights of Low CTs, giving the total “weighted pool.”

By dividing an individual weight wiw_iwi​ by this total, we calculate the fractional share of the pool FFF that belongs to CT iii. Finally, multiplying by F converts that fraction into a token amount—so CT-holders who downgraded earlier (larger d_i​) or on higher-rate loans (larger r) receive a correspondingly larger piece of the fees collected from High upgrades.