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
Uh oh!
There was an error while loading. Please reload this page.
-
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