L1 Stages Classification Framework

[iJaack]

🎯 Proposal Overview

I'm proposing the L1 Stages Classification Framework (SCF) — a standardized way to evaluate and communicate the trust characteristics of Avalanche L1 blockchains.

As the L1 ecosystem grows, participants need clear information about:

• Who controls validator participation?
• How concentrated is validator operation?
• What bridges exist and who operates them?
• How transparent is the governance process?

This framework answers these questions in a neutral way, recognizing that different trust models serve different purposes.

🔍 How It Works

Four Simple Dimensions

Each L1 is scored on four dimensions using a five-level scale: Minimal, Low, Moderate, High, or Maximum trust required.

1. Validator Control — Who decides validator entry and exit?
2. Validator Operator Diversity — How concentrated is validator operation?
3. Bridge Trust — Who do users trust to move assets?
4. Governance Transparency — How predictable is the upgrade process?

Four Stages

The combination of dimension scores produces one of four stages:

• Stage A: Single-Entity Trust — One entity controls the L1
• Stage B: Multi-Party Trust — Multiple known parties govern collectively
• Stage C: Distributed Community Trust — Community governance with multiple participants
• Stage D: Algorithmic/Permissionless Trust — Cryptographic and economic mechanisms, no single authority

No stage is "better"—they serve different use cases and risk preferences.

📊 Example

L1	Validator Control	Operator Diversity	Bridge Trust	Governance	Stage
COQnet	Minimal	Low	Low	Minimal	D
Animalia	Moderate	Moderate	Low	Moderate	C
Dexalot L1	Moderate	Moderate	Moderate	Moderate	B
AppL1	Maximum	High	High	High	A

✅ Why This Matters

For Validators:

• Make informed decisions about which L1s to operate
• Understand trust assumptions before committing resources

For Builders:

• See where your L1 fits compared to others
• Understand what trust model is right for your use case

For Users:

• Know what assumptions underlie the L1s they interact with
• Choose L1s aligned with their risk tolerance

For the Ecosystem:

• Standardized language for communicating L1 characteristics
• Better comparisons across analytics platforms

🤔 Open Questions

We'd love community input on:

1. Are the four dimensions right? Should we add/remove dimensions or change their focus?

2. Is the five-level scale appropriate? Too granular? Not granular enough?

3. Bridge trust priority: What's the ideal weight we should give it?

4. Mixed L1s: How should we handle L1s with very different scores across dimensions? Should we create intermediate stages?

5. Fee tracking: Should L1s disclose monthly validator fees to the Primary Network? How detailed should this be?

6. Governance emphasis: Are we treating different governance models (DAO, multi-sig, permissionless) fairly? Does the framework over/under-emphasize DAOs?

7. Implementation: Which analytics platforms might implement this? What support would they need?

🎤 Next Steps

This discussion will help refine the L1 Stages Classification Framework before formal submission. Your feedback should address:

• Conceptual clarity: Are the dimensions clear and useful?
• Practical implementation: Can platforms realistically score L1s this way?
• Fairness: Does the framework treat different L1 models neutrally?
• Completeness: Are there trust factors we're missing?

Please share:

• ✅ What works well about this framework
• ⚠️ What concerns you
• 💡 What's missing or should be changed
• 📝 Examples of how this framework would help you

---

Looking forward to building a better way to understand L1 trust together.

[erwindassen]

I like the idea of having such a standardized evaluation process for trust. But I see a few improvements needed:

• One is more aesthetic but it is important to transmit information easily and correctly:

  • Drop the "Stage" monicker: it gives the idea that there is a natural progression among them which there is not as this is purely a decision of requirements and different use cases. Perhaps just call "Trust level".
  • In accordance with the previous I would change A, B, C, D to something more self-explanatory. In addition A, B, C, D again give the sense of progression which there isn't. Perhaps call it SP (single-party), MP (multi-party), CG (community governance), P (permissionless).

• The next is more fundamental. I think that either:

  • We should have explicit criteria to identify what is Minimal vs Low vs Moderate etc... as it now stands is it quire subjective.
  • Or we flip it around (my preference): for each of the "scorable" (this should be a word!) segments we assign SP, MP, CG, P as above. This makes it absolutely clear how to score and how to interpret as an end user. If needed we can assign an overall score as well with simple majority or weighted majority but always making the individual scores available.

Again I like the idea but we should also clarify where such a "standard" and its scores would live and who would vote/decide on the scores.

[Nuttymoon]

Thanks @iJaack, for starting this very important conversation. Sorry in advance for the lengthy comment, but, as an L1 tooling builder for some time, this is something I have been thinking about for quite a while!

While I do get the idea in the message that No stage is "better"—they serve different use cases and risk preferences, we cannot ignore that most Avalanche L1s start with a very small concentrated validator set, making them vulnerable to a single entity's failure.

This is why I think that we SHOULD have proper stages for Avalanche L1s, very similar to what we can find on L2BEAT for Ethereum L2s, to (i) clearly inform users of the risks they are taking and (ii) guide L1s on the road to improving security through decentralization. That being said, we can of course also envision a classification like you proposed in parallel.

What is the biggest risk? And to what extent?

In short, bridged TVL via ICM can be entirely lost.

In detail:

Since we are rating L1s in the context of the Avalanche ecosystem, the assumption is that they are communicating with other chains (esp. the C-Chain for access to liquidity and integrations) using ICM (InterChain Messaging), and paying their rent to the P-Chain for that. While very efficient, ICM has known weaknesses that impact specifically chains with a low number of validators, and more importantly low number of operators (= independent entities running validators).

ICM relies on BLS signatures to verify messages on destination chains, requiring a signature of at least 67% of the L1 weight to be considered valid. A typical message would be the bridging of assets to the Avalanche C-Chain.

If an attacker gets access to BLS keys corresponding to 67+% of the total weight, they can basically bridge all assets without corresponding transactions on the L1 itself.

Other properties to optimize for

On top of bridged TVL security, which is IMO the most important one, critical properties of a chain like liveness and censorship resistance could also be taken into account for L1s stages.

Proposed requirements per stage

Stage 1

• Bridged TVL Security
  • Validator set management is not controlled by a single EOA (otherwise, a breach of this EOA could lead to validator set changes and potential loss of funds bridged to the L1). This can be enforced by setting up multisignature wallet ownership or governance-based security.
  • Each operator controls strictly less than 67% of the L1 total weight (otherwise, a single operator's breach could lead to a loss of all funds bridged to the L1)
• Liveness
  • The L1 has at least 5 validators (otherwise, any validator failure would halt the chain)

Stage 2

• Bridged TVL Security
  • No single entity has the power to arbitrarily add/remove operators/validators on more than 67% of the total weight (otherwise, other assumptions about validators/operators can easily be changed). This can be enforced through PoS security or governance.
• Liveness
  • No more than 20% of the L1 total weight is controlled by a single operator (otherwise, a single operator failure would halt the chain)
  • No more than 20% of the L1 total weight is hosted on a single data center
  • All validators are hosted in OFAC-compliant jurisdictions
• Censorship resistance
  • The L1 has multiple RPC endpoints operated by different entities (otherwise, a single operator’s outage could lead to censorship of user transactions)
• Verifiability
  • Validator ownership of more than 67% of the L1 total weight is verified at the social layer

Stage 3

• Liveness
  • No more than 20% of the L1 total weight is hosted on a single cloud provider
  • No more than 20% of the L1 total weight is hosted on a single geographical jurisdiction
• Verifiability
  • Validator ownership of more than 67% of the L1 total weight is tracked onchain and verified at the social layer

Other rating criteria

I do agree that other criteria for rating L1s, like the degree of permissionlessness re: validators’ onboarding, are more subjective, and I think that a framework like proposed initially would work better for those.

[QuadSigma]

This addresses an important attribute of validator sets, and is in line with a draft Im producing centered around the broader need for more granular attributes (or the validation of asserted ones) being supported at the protocol level. The thoughts below borrow from some that are still in draft, but to roughly summarize...

I generally like the framework above. I think it may have room to be much more granular across a lot of dimensions of validator set attributes. (More to come.) But as long as that extensibility of the attribute set becomes part of this proposal set, I think these particular attributes you're proposing are a good start.

The question arises as to who classifies them into the proposed categories (for easy info discovery) .. and more importantly to decentralization, how is it verified/trusted. What I am be proposing would be to consider an extension of this, which is that certain properties are asserted and validated, either via polling amongst the validators, as is done for some current "proof of..." metrics, or by incorporating (and incentivizing reserved compute for amongst the v set) some ZK-proof mechanisms within the protocol, that allows these and other "properties" to be asserted and proved in a decentralized manner. For some properties, polling is suffient to establish trust. Other properties may require a zK-based mechanism, which th v-set can handle "in-house" in most cases. Again, this is more of a comment on extension, not contradiction/alternative of the proposal above.

L1s looking to "recruit" niche validation from the main chain v-set (or incentivize "private" / exclusive or partially / "softly" exclusive L1 validators to meet its niche needs, can use these attributes as a market discovery/ information communication mechanism. I've term it a "RFV" (Request For Validation). One such parameter (or set of them) could be desired Stage, as proposed here. The end goal is a "market", with granular, verifiable information about both the L1s, and their requests (complete with incentivization offers / participant requirements) for niche validators, but also allowing validators themselves to "advertise", in this more efficient validation market, which attributes they offer. One of which is whether it is willing to restrict itself to a particular Stage, as proposed above.

Im proposing combining that concept of parameterized request/offer/advertise market dynamics with a concept of advertising/requiring additional reserved AVAX stake, the handling of which is subject to negotiate between L1 and a candidate validation, that can effectively ensure SLA-like (smart contract enforced) characteristics.

One dimension I'm proposing be added to those you specify is along the lines of what I'm calling "soft vs hard exclusivity". This will reflect, for me example, whether the L1s v set allows/has ANY overlap with validation of the main chains. Hard exclusivity means it can not. It's "private" to that L1 (or disjoint to main chains). Soft exclusivity may be a better of degree. The strictist being "yes you can validate main chain, but we want ours to be the only other L1 you validate" (Note this is niche and may require incentivization). Continuing along that spectrum may be partial exclusively. Yes validate other L1, but not our competitors or only if they're in this jurisdiction. It's granular, so it can loosen along several parameters, but on the other end is completely unrestricted decentralized validation. This is a long way of saying "exclusivity" could be another dimension to add in your stages/ratings.
Thanks for getting these ACPs out there. The community needs this. Looking forward to helping refine.

[0xJohnnyGault]

The only reason L2Beat exists, is because Ethereum L2s are a horrendous pile of complexity and risk that no one understands. They try valiantly, bless them, but IMO it has not helped because let's face it, ain't nobody got time for that.

The beauty of Avalanche L1s are their simplicity. Everyone knows how an L1 works -- you must trust the validator set. We are doing ourselves a disservice if we try to complexify things too much.

I see there being only 2 types of L1s (from a user's perspective):

• AppChain: Things like Dexalot or Hyperliquid -- an app (or suite of apps), run by a single entity or group that must be trusted by the end users. It really doesn't matter how "decentralized" the validator set is in this case, it is just one of many things you must trust in order to use the system.

• PlatformChain: Things like gaming chains, where the goal is to create a platform with specialized features that make it an attractive place to build for a specific type of dApp. In this case, the users relationship will probably be with the dApp (like a specific game), NOT the L1, so asking them to care about the underlying L1's "Stage" or whatever is unrealistic.

For AppChains or dApps, the industry as a whole should adopt some kind of SOC-type audit that considers many aspects of their security posture -- opsec, contract audits, pen testing, validators, economic security, multisigs, key mgmt, insurance, physical security, etc etc. A/B/C/D/F rating. Easy for users to understand.

I guess my main point is that the Avalanche C-Chain is an honest-to-God permissionless L1, with a validator set that is now large enough, Lindy enough, with enough stake, to be beyond reproach. All of the "L1" chains built on top of Avalanche will never match this, nor should they try. And their validator set is but one of many trust points -- by focusing on just validator security you are giving a false sense of security due to all the things that are left out.

[iJaack]

@0xJohnnyGault thank you for your feedback.

Everyone knows how an L1 works -- you must trust the validator set.

That's not true. As @Nuttymoon clarified in his comment, the validator set is only the first component that you have to trust. This is similar to tokens. A token can be native, bridged, bridged again, and the trust and security assumptions change at any node of the graph.

In the same way, an L1 can have all his tokens natively issued, or bridged via AVM, or via a third-party liquidity bridge, or via a third-party BMLR (burn/mint+lock/release) bridge, or even via a solver network now.

The goal of this Framework is not to frighten users, but to help developers make thoughtful decisions over which L1 to deploy on, and for users to simply know what degree of security they're trusting their money with.

If we were a regulated industry, we didn't even need to discuss about this - we just had to do it. And yes, SOC-2 compliance (I think you're referring to that) is underway for most of us because we need that to support institutions, but SOC only covers part of the issue, and we can only discuss it when we now how it fully applies to the blockchain industry in production.

[Nuttymoon]

*Edit: my answers are more related to my comment, not sure you read it @0xJohnnyGault

Agree with Jaack. Adding some comments:

Everyone knows how an L1 works

This is not necessarily true. Not all users are aware of the risks involved when using a centralized L1.

you must trust the validator set

The validator set can have many forms. Some validator sets are more resilient than others, and I described what metrics can be used to minimize risk.

All of the "L1" chains built on top of Avalanche will never match this, nor should they try.

This is true. The purpose is not to ask chains to grow their validator set to 100s of validators, but to diversify the validator set enough to drastically reduce the biggest security threats.

If we're ok with 5-validator chains operated by a single entity, why bother putting that onchain?

And their validator set is but one of many trust points -- by focusing on just validator security, you are giving a false sense of security due to all the things that are left out.

I don't buy this argument. Just because you have to trust the whole stack (chain > app > front-end) doesn't mean that you have to disregard the security of each piece. The beauty of blockchain is that you can actually gauge the security of the bottom of the stack: chain + app.

[iJaack]

Agree with @Nuttymoon on this, security assumptions must be clear to everyone. One can choose not to check them, but there needs to be a way of checking it if one so chooses.

[iJaack]

I wanted to add that this Framework is just a piece of a bigger project that I think is due for delivery on Avalanche:

• Establish a Community Review Board which goal is to independently review each L1 (=peer review) like it happens on L2Beat, for the sake of keeping the Avalanche network as integrated and connected as possible
• This Board would get funding from different players in the ecosystem that have vested interest in seeing the network grow and accrue value back to AVAX and to them and their tokens
• It would be a very concrete effort to bring a sense of continuous progress on the technical innovation and a tool to get an 'official' second feedback to Ava Labs and the Avalanche Foundation, which both act in the interest of the network but are also just one party, Ava Labs kinda being the 'operative' arm of the Foundation.

I know that this is likely going to be very hard to do, but it's definitely a way to increase investors' confidence and present a stronger community effort overall.