Back to Externals
Mint reserved funds for Phala crowdloan unlock - motion #119
1mo ago
1 Comments
Tabled

This proposal will mint 44M PHA token to the SubBridge reservation account.

SubBridge connects Khala and Ethereum and allows to transfer PHA between. It maintains the reservation on the both side to ensure there's enough liquidity to allow PHA to move freely between the chains. Theoretically Khala should have 1B PHA supply, where part of the supply is in circulation, and others are locked in the bridge reservation account. However practically, there are still 463.2 M PHA locked for mining subsidy and 38M locked for crowdloan
crowdloan reward. So the final equation should be:

[PHA in Khala supply] + [PHA locked on Ethereum] = 1B

Therefore Khala's total supply (bridge reservation + other tokens in circulation) is supposed to be (1B - 463.2 M - 38M) = 498.8M PHA. Once we have unlocked the crowdloan reward, we should add 38M to the reservation to make sure the equation still holds, which means it has sufficient liquidity accept all the cross-chain transfer.

However, the situation is more complex. It turns out in the past, Khala was always imbalanced. The sum of PHA supply on Khala and locked PHA on Ethereum adds up to 994M. There's still 6M missing. It turns out an imbalance in the supply was due to the miscalculation in the initial bridge launch. It's supposed to have 27M PHA for StakeDrop event, but we only used 21M. Another 6M was used for crowdloan reward instead. It made the total crowdloan budget increased from 63M to 69M.

Another part is the 38M crowdloan reward. In the Polkadot crowdloan event, Phala is going to reward the participants with ~20M PHA. With Phala launched, it's easiest to unlock the full 38M and keep the remaining PHA locked on Phala.

So in this proposal, we are going to fix the 6M PHA imbalance add the 38M crowdloan funds to the reservation.

Edited
Reply
Up
Share
Business
Hash
0x78b0395a972c69912d6c144cec2dcc8721fc16a3b3f0e2c5883e09041c469e5d
Metadata
hash
0xd55c826574461e4727a853b4f8dc857f0d7d2d0f978dd38d778b5c90a24dc1f2
voteThreshould
SimpleMajority
Call
Table
Json
callIndex0x0302
sectionutility
methodbatchAll
args
calls
0
callIndex0x2801
sectionbalances
methodsetBalance
args
who
id436H4jaqWqZmap587RfJaRkPjNmD7tJacZgVAfsZF5PbA1CB
newFree44000000000000000000
newReserved0
1
callIndex0x2802
sectionbalances
methodforceTransfer
args
source
id436H4jaqWqZmap587RfJaRkPjNmD7tJacZgVAfsZF5PbA1CB
dest
id436H4jat7TobTbNX4RCH5p7qgErHbGTo1MyZhLVaSX4FkKyz
value44000000000000000000
TimelineLatest activity 1mo ago
2022-08-11 11:01:54
externalProposeMajority
proposalHash
0xd55c826574461e4727a853b4f8dc857f0d7d2d0f978dd38d778b5c90a24dc1f2
2022-08-11 11:02:48
fastTrack
proposalHash
0xd55c826574461e4727a853b4f8dc857f0d7d2d0f978dd38d778b5c90a24dc1f2
votingPeriod
900 blocks
delay
1 blocks
Comments
1mo ago

Additional comments.

The "StakeDrop" was on Ethereum?

There are two separate things. First, StakeDrop was partially send on Ethereum, but there were still many people not claimed before the Khala launch. So when Khala launched, we distributed all the remaining reward to their KSM address. The second is that, no matter where the StakeDrop is distributed, the funds were not "locked" on Ethereum anymore. So where it lives in, Ethereum or Khala, it MAY be bridged to Khala. So the full amount should be minted on Khala (as PHA in circulation for our final reward distribution, and PHA in reservation for the part distributed on Ethereum)

The 6m that were not used by the StakeDrop were used for the crowdloan, so why are they missing in the equation?

In the initial tokenomic paper, there's 63M reserved for crowdloan and 27M reserved for StakeDrop. However in the reality, only 21M is used for StakeDrop, leaving 6M. We decided to use that for Crowdloan.

Here's the problem. When we initially set up the bridge, we mistakenly thought the bridge reservation for the corresponding part should be (21M stakedrop + 63M crowdloan). But actually it should be (21M stakedrop + 69M crowdloan). That's why there's 6M missing.

Finally, the bridge reservation on Khala is a way for protection. Suppose the bridge is 100% secure, we can safely put 1B in the bridge reservation. That will be sufficient for all the future birdge liquidity. Or we can just adopt the "mint & burn" approach without caring about the reservation.

A precise reservation amount is the best, because even if the bridge is compromised, there's a upper limit of the damage. A less reservation may cause trouble in extreme situation, but there's no immediate damage.

The timeline is StakeDrop > Khala Crowdloan > Win > Distribute reward on Khala > Enable bridge

Reply
Up