[ACP-253] X-Chain Removal

[michaelkaplan13]

Proposes the deprecation and end-of-life of the X-Chain. All AVAX held on the X-Chain would be made available to its existing owners as UTXOs on the P-Chain.

[aphexmunky]

I think this is a shame tbh. There's no demand to put state sync and dynamic fees into the X-Chain so the overall maintenance overhead is low. State growth minimal. I'm guessing usage dropped a lot when the web wallet was deprecated. The chain had a lot more potential, particularly with the feature extensions and gave a very Bitcoin like experience to those that cared for that.

I'll accept there's likely no valuable assets other than the AVAX on X-Chain, personally I did have transactions recorded in there that used the memo field as a proof of existence to other content and I was hoping that would preserve for a long time.

The low usage is purely due to EVM + C-Chain focus. Instant finality UTXO experience is valuable if it's curated. Education remains a problem.

I'm against this but realise it's likely a battle already lost

[aphexmunky]

I would rather see it converted to a plugin with the option to turn it off via config frankly.

What's the plan with exchange integrations? I think binance and coinex had x-chain integration - ask them to move all their funds from X to C chain before the transition? Might mess with their internal accounting.

[michaelkaplan13]

I'm against this but realise it's likely a battle already lost

That's definitely not the case...this ACP hasn't even been officially "proposed" yet. The ACP process is meant for this discussion

[michaelkaplan13]

There's no demand to put state sync and dynamic fees into the X-Chain so the overall maintenance overhead is low.

That's not quite true. There is a definitely demand for state sync because otherwise the length of time it takes to spin up a primary network node will continue to increase despite the total state size remaining relatively small.

[aphexmunky]

Bootstrapping X-Chain time scales purely on number of X-Chain transactions/blocks? Or is there a co-dependency between X and P?

We shouldn't have an infinite growth feature sitting in technical debt, but feels very low priority considering the current low usage. I've never found the X-Chain portion of bootstrapping to be painful but i'm more than happy to have discussions around bootstrapping speed. Does that grow into a conversation about the implementation cost to payoff of implementing additional features like ICM, State Sync et al.

[michaelkaplan13]

Does that grow into a conversation about the implementation cost to payoff of implementing additional features like ICM, State Sync et al.

Yeah, to me that's the core of the question here. If it is the case that:

• barely anyone is using it
• it is not serving as a differentiator in its current form
• there aren't strong proposals to make it a key differentiator

Then what is the cost & lift size of removing it vs the cost and lift size of adding the future functionality that will eventually be needed to properly maintain it.

Removing the X-Chain in its current form also does not exclude the development of new UTXO-based chains for unique use cases.

[aphexmunky]

Agree

In an unlimited resources hypothetical, I would like to see the X-Chain develop features and grow more of its own identity. Become all the things that Bitcoin wanted to be before it had its OP_RETURN legs chopped off. Add privacy features. Add stablecoins. Add new signature mechanisms. Become a fast paced innovation chain. It's incredibly light and the codebase is clean. Just be a far better Bitcoin and familiar to that userbase but have a bunch of extra cool stuff developed over time. Then when that userbase wants to try defi we can point to an easy instant bridge they can try the more intimidating EVM experience.

I'd be interested in hearing some pitches for what cool things could be done with it before it's canned in any case. If it's marked for death, we could try have some fun with it before the lights go out.

[gonzaloetjo]

Agreed with the privacy features. Maybe the X chain could be repurposed as a ZK Privacy Layer.

Currently there's a lack of a native shielded pool / private layer. The C-Chain is a poor fit as account + sequential nonces model are not optimal (Aztec doc) + MEV risks are high. From checking Noir, most EVM privacy designs end up pushing state off-chain to hide access patterns, which hurts composability and takes security assumptions off of consensus. On the other side, projects like Aztec use eUTXOs to allow parallel processing of private notes, giving access to a shared private state. Meaning one could build actual private apps (not just simple mixers/transfers) without the off-chain data hell.

I'm not aware of what the path would look like, and if it's viable. I’d expect it to require a new VM with zk-friendly libraries (and probably opcodes/precompiles for BN254/BLS12-381 or similar curves), plus note/nullifier trees, on-chain encrypted logs, etc.

Conceptually though, "P-chain as global registry, C-Chain as public execution/accounting logic, and X-Chain as UTXO privacy layer" sounds clean.

[iJaack]

I second this. X-Chain is dead, had barely any usage ever and as far as I know it was supposed to be a way to show the capabilities of Avalanche as a multi-VM platform.

Avalanche needs to be leaner to be better understood widely from the whole industry.

This ACP would be the first step, and then I would propose a rename of the P-Chain and the C-Chain to better highlight their use.

[jzu]

I wonder what would be the costs of making the X-chain an L1, as is. No ICM, no privacy, no nothing, just the chain and its UTXOs. This would be the first step. Next, further development would be outsourced to members of the community who could have fun with ICM and other niceties.

As a bonus, it would simplify the architecture, and the elevator pitch as well: see, there's the C-chain for the usual EVM activity, a whole lot of various L1s for a whole lot of various stuff, and the P-chain, the backbone which orchestrates the whole network.

[yacovm]

I wonder what would be the costs of making the X-chain an L1, as is. No ICM, no privacy, no nothing, just the chain and its UTXOs. This would be the first step. Next, further development would be outsourced to members of the community who could have fun with ICM and other niceties.

I guess the question is how do you ensure that the X-chain is secured by enough stake compared to the assets it holds.

[jzu]

I guess the question is how do you ensure that the X-chain is secured by enough stake compared to the assets it holds.

By the way, I couldn't find the total value in avax the X-chain holds, nor could I find a practical way to get it by myself.

[iJaack]

I wonder what would be the costs of making the X-chain an L1, as is. No ICM, no privacy, no nothing, just the chain and its UTXOs.

It's already an L1, I don't know what you mean. It's an L1 validated by the Primary Network. If you make it an L1 outside the Primary Network, it will probably have a subnet of 0 validators, hence won't be maintained by anyone.

[joshua-kim]

The X-Chain has almost zero maintenance cost associated with it (other than the cost of security) since there isn't active development on it, so I don't think that should be a major concern.

Deprecation however, is a one-way door so we should be very deliberate for our rationale on deprecation. We can also consider some lower risk (and also two-way door) ideas:

Currently the X-Chain is "functionally" deprecated, in that there is no active development and it's not exposed from the user in Core. The X-Chain is gradually being referenced less in our docs, so we could argue that doing a final pass over our documentation and removing references to it would be the last barrier to removing it from the mental model of the user to get the same benefit of simplifying the network architecture.

We're currently in a fork in the road where the development in state sync is blocked on this decision (to deprecate or not to deprecate), but proceeding with state sync would put us in a spot where we no longer have to worry about unbounded sync time (X-Chain has close to zero usage, so it's not an immediate concern) and we could continue with the idea to functionally deprecate the X-Chain as it would no longer be on a scaling cliff and it can be omitted from docs. Additionally the P-Chain which also needs state sync will be sharing some implementation with the X-Chain so it would still move us towards a position we would want to be in.