Disentangle X-P-C-chains. Inspired by ACP-77 #88
Adventuremonkey
started this conversation in
Brainstorming
Replies: 1 comment 1 reply
-
Obviously support the idea of disentangling 😊 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Here’s a new paradigm to consider that solves multiple issues. Imagine the following:
X-P-C-chains are separated and their functions are disentangled.(Breath deep.)
C-chain: It builds itself to be the Avalanche ecosystem hub as a Layer One EVM, the same as it is now.
AVAX holders are air-dropped 1:1 a new native token($SNOW) to pay fees, stake, and govern.
This doesn't have to happen at the outset. It could keep AVAX for governance/fees until P-chain use is more established.
X-chain: It doesn’t seem to serve much purpose(I may be missing something here.). I suggest we just drop it or convert it to something useful like a native oracle service. If it sticks around, it gets it’s own token.
P-chain: It’s sole purpose is to operate as the Validator Registry and closely related services for AWM enabled chains. AVAX remains it's native token.
The Continuous Fee Mechanism is implemented with a minimum time metered balance.
P-chain is designed to be added to a chain like a browser extension.(This might not be the perfect computer science analogy, but hopefully you get my drift.)
Building P-chain like an extension creates a fault separation between P-chain and the Subnet validators. (The same way an extension adds functionality to a browser w/o breaking it.)
Adding the extension adds them to the registry. This requires a balance to pay fees. It also requires subnet validators to stake/validate the P-chain.
Validating the P-chain is reasonable now that X-P-C-chain are separated.
P-chain extension is easily bolted on to any Avalanche Subnet who wishes to have the interoperability of AWM.
P-chain extension adapters can eventually be fashioned to operate with external chains.
If an Avalanche Subnet validator does not wish to be part of AWM, it just turns off the P-chain extension after they enter an exit validator set transaction. They then become a Subnet Only Validator. Subnet implementations however, can make the use of P-chain extension a network requirement.
All subnets who wish to have AWM through the P-chain must require their validators to validate it and stake 50 AVAX(actual amount set by governance) or use a PAYG staking service to make it affordable for the masses.
An option for additional P-chain rewards is splitting fees between P-chain validators and burning. This advantages staking AVAX over just holding AVAX, which burning benefits.
Reasons: This requires P-chain/AWM beneficiaries to have skin in the game. It simplifies the token functions for X-P-C, allowing them to align token holders based on the chain's function. It aligns subnets with AVAX governance of P-chain.(Currently alignment is skewed towards C-chain) It makes staking cheap enough for mass adoption of P-chain. If these changes are to ever be made, it will be much easier to implement earlier in the design process.
Beta Was this translation helpful? Give feedback.
All reactions