Astar dApp Staking | Entry Requirements Reinforcement

Astar
1

I. Introduction

The Astar Community Council presents this proposal to strengthen dApp Staking entry and continuity requirements. Currently, dApp Staking operates with approximately 60 available slots, enabling broad participation across the ecosystem.

With the program transitioning to a strictly capped model of 16 slots, each position represents a significantly higher ecosystem commitment. These guidelines aim to ensure that the limited slots are allocated to projects delivering sustained and meaningful value to Astar.

We invite the Astar Collective to review, discuss, and help refine these criteria. Your input is essential to building a framework that is both rigorous and fair.

II. Context

dApp Staking is transitioning from broad participation to focused quality. With 16 available slots, the program must prioritize projects that actively strengthen the Astar ecosystem rather than passively occupy positions.

The ACC proposes the following entry and continuity framework. This is a starting point for community discussion, not a final decision.

III. Proposed Entry Requirements

Given the limited slots available, we propose the following baseline requirements for all applicants:

3.1. Deployed and Operational Product

A live, functional product on Astar Network (Native or EVM) with verifiable onchain activity. Products in development or testnet-only do not qualify.

3.2. Minimum Operational History

At least 6 months of continuous operation with documented onchain activity. This demonstrates commitment and reduces risk of early abandonment.

3.3. Verified ASTR Integration

Active ASTR utility within the product: fees, staking, incentives, governance, or treasury operations. Planned integrations are insufficient. ASTR alignment must be live and verifiable at time of application.

3.4. Quantifiable Ecosystem Contribution

Applicants must provide metrics appropriate to their category:

Category Required Evidence
DeFi TVL trend, transaction volume, active wallets
Infrastructure Consuming dApps, API/RPC usage, uptime records
NFT/Creator Mint/trade volume, unique users, ASTR usage
Gaming/Consumer DAU/MAU data, onchain interactions, retention metrics

Minimum thresholds will be defined per category. Projects below threshold are not eligible regardless of other qualifications.

3.5. Team Accountability

Core contributors identified with verifiable public presence (GitHub, LinkedIn, X, or equivalent). Anonymous teams must demonstrate equivalent credibility through audits, established reputation, or ecosystem vouching.

3.6. Astar Collective Engagement

Prior participation in Astar governance, community discussions, or ecosystem initiatives. Projects with no prior Astar engagement face higher scrutiny.

IV. Proposed Evaluation Process

With limited slots, evaluation must be thorough and transparent. We propose a structured three-phase process:

Phase 1: Community Introduction (Minimum 14 Days)

  • Applicant creates Forum topic with structured application

  • Mandatory sections: product overview, ASTR integration details, team information, metrics evidence, reward usage plan

  • Open community Q&A period

  • Applicant must respond to all substantive questions within 7 days

Phase 2: ACC Technical Review (14 Days)

  • Minimum 3 ACC members review each application independently

  • Standardized scoring matrix evaluates: ecosystem fit, ASTR alignment, team credibility, metrics quality, community engagement

  • Each criterion scored 1-5 with defined rubrics

  • Minimum composite score required for advancement (threshold to be defined)

  • Written evaluation summary published for transparency

Phase 3: Governance Approval

  • Applications meeting score threshold proceed to governance vote

  • Main Council, ACC, or public referendum depending on applicant preference

  • If slots are full, approved applicants enter priority queue

Queue System

When all 16 slots are occupied, qualified applicants enter a ranked queue. Queue position determined by evaluation score. When a slot opens, the highest-ranked queued project receives first consideration.

V. Continuity Requirements

Slot retention is earned, not guaranteed. Listed projects must maintain:

5.1. Onchain Activity

Sustained transaction volume, active wallets, or verifiable usage signals appropriate to project category. Seasonal variation is acceptable; sustained decline triggers review.

5.2. Product Functionality

Accessible, operational product. Broken or abandoned products trigger immediate review.

5.3. Ecosystem Engagement

Responsiveness to ACC communication within 14 days. Participation in governance discussions when relevant to project category.

The ACC monitors listed projects through onchain signals and public product availability. Routine manual reporting is not required for projects in good standing.

VI. Review Triggers

A project enters formal review when any of the following occur:

  • Onchain activity declines by more than 50% over 60 consecutive days without communicated cause

  • Product becomes non-functional or inaccessible for more than 7 days

  • No response to ACC outreach within 30 days

  • Verified community complaints regarding project conduct or reliability

  • ASTR integration removed or significantly reduced without prior communication

Projects under review receive written notification with specific concerns identified.

VII. Removal Criteria and Process

Removal from dApp Staking is a significant action. The following framework ensures decisions are fair, documented, and transparent.

7.1. Grounds for Removal

A project may be removed if it meets one or more of the following criteria:

Criterion Definition Grace Period
Sustained Inactivity Onchain activity below minimum threshold for 90+ consecutive days 30 days to demonstrate recovery plan
Product Abandonment Core product non-functional or inaccessible for 30+ days 14 days to restore functionality
ASTR Disengagement ASTR integration removed or reduced to negligible levels 30 days to restore integration
Communication Failure No response to ACC outreach for 45+ days Final 14-day notice before removal
Bad Actor Behavior Verified malicious conduct, fraud, or ecosystem harm Immediate removal, no grace period
Value Misrepresentation Material false statements in application or reporting Immediate removal, no grace period

7.2. Removal Process

  1. Warning Notice: ACC issues written notice identifying specific deficiency and required remediation

  2. Grace Period: Project has defined period to address concerns (see table above)

  3. Review Hearing: If concerns persist, project may present case to full ACC

  4. Decision: ACC votes on removal. Requires majority approval.

  5. Publication: Removal decision and rationale published on Forum for transparency

  6. Slot Reallocation: Vacated slot offered to highest-ranked project in queue

7.3. Appeal Process

Removed projects may appeal through public referendum within 30 days of removal. Appeal requires community support to proceed to vote.

7.4. Reapplication

Projects removed for inactivity, abandonment, or communication failure may reapply after 6 months if deficiencies are resolved. Projects removed for bad actor behavior or misrepresentation are permanently ineligible.

VIII. Invitation to Participate

This proposal represents the ACC’s initial framework. We recognize that good governance requires community input.

We invite the Astar Collective to discuss:

  • Are the proposed entry requirements appropriately calibrated for 16 slots?

  • Should minimum thresholds differ by project category?

  • Is the evaluation scoring approach fair and transparent?

  • Are the removal criteria and grace periods reasonable?

  • What additional safeguards would strengthen the program?

Your feedback will directly shape the final framework. Please share your thoughts in this thread or contact ACC members directly.

Together, we can ensure dApp Staking rewards the builders who make Astar stronger.

Pit :astr:

Astar Community Council

6 Likes
Comet Swap - dApp Staking Proposal
Large-Scale dApp Staking Cleanup Initiative
Large-Scale dApp Staking Cleanup Initiative
2

Thank you for the proposed criteria. Overall, I believe the content is largely appropriate. However, there are a few points that may require further consideration.

Until now, projects utilizing ASTR on Soneium have also been eligible. Does this mean the intention is to exclude them going forward?

This aligns well with the objective of “maximizing activity on Astar Network (L1),” but it creates some inconsistency with the goal of “maximizing ASTR utility.” Originally, part of the rationale was also to expand ASTR usage outside of Astar itself, which is why activities on external chains were included. If that is no longer the case, it represents a clear shift in direction.

This is not necessarily a bad change. However, if we are pivoting policy, I believe it is important to explicitly acknowledge that shift.

Personally, I do not see an issue with this change in direction, but it should be aligned with the Astar Foundation’s broader strategy going forward. Based on the current roadmap and available information, it appears that the policy is indeed to refocus on Astar L1, so I assume this is consistent — but I would like to confirm.

It might be worth considering exceptions here. For example, in cases like CometSwap — where there is strong intent to contribute and the potential for significant impact — requiring a full six months of operational history could inadvertently slow down valuable initiatives.

It may therefore make sense to introduce a governance-based exception process, such as allowing on-chain governance to determine whether an exception should be granted.

Previously, submitting reports was treated as a best-effort obligation. Is that no longer included?

Given that the number of slots is now limited, and if the ACC plans to regularly monitor activity, that may be sufficient.

In the case of DeFi projects, audits are typically one of the core criteria. However, formal audits are extremely expensive. As a baseline requirement, it might be reasonable to introduce AI-based SaaS audit tools or automated security analysis services as a minimum standard.

3 Likes
3

Hi @pitcoin777

Appreciate the direction shared in this post, aligned on increasing requirements and conditions for dApp Staking. With only 16 slots available, we want dApps that are both high-quality and serious about long-term contribution.

That said, I agree with you425’s point. Astar operates as a collective across multiple blockchains, Astar Network, Soneium, Polkadot, Ethereum, and others. Criteria for dApp Staking shouldn’t be tied to Astar Network alone.

For example, I see Kyo Finance and Sake Finance as pillars of ASTR expansion to Soneium. In my view, they’re eligible for dApp Staking even though they currently operate only on Soneium, that’s part of the broader Astar ecosystem.

To clarify Astar Foundation’s policy: our focus is on developing products that create or bring value to ASTR tokens. These products are not restricted to Astar Network, they can launch on any network within the ecosystem.

For Q1 2026, we’re prioritizing L1 development to reinforce the foundation of the ecosystem with Tokenomics 3.0, dApp Staking improvements, and DeFi enhancements. But this doesn’t mean all future products will launch exclusively on Astar Network. Products will launch and integrate across networks in the Astar ecosystem based on strategic opportunity and user adoption.

Gaius_sama :astr:

Astar Foundation & Community Council

4 Likes
4

Thank you for the clarification.
In that case, it seems there is no need to limit it strictly to Astar L1.

Under the previous criteria, stricter requirements were applied to dApps outside of Astar L1, so I believe it would make sense to follow a similar approach here as well.

3 Likes
5

Excellent observation, @Gaius_sama and @you425. At the end of the thread, the Council will publish the final proposal with the discussed updates incorporated.

That said, based on the suggestions received, The ACC have decided to adjust the referenced point as follows:

3.1. Deployed and Operational Product
A live and fully functional product with verifiable on-chain activity, deployed on Astar Network (Native or EVM) or within the broader Astar ecosystem. Products that are still in development or operating exclusively on testnet do not qualify.

Eligibility should be determined based on the product’s measurable contribution to ASTR and the Astar Collective. As Astar operates across multiple networks — including Astar Network, Soneium, Polkadot, and Ethereum — the dApp Staking criteria should reflect this multi-chain structure rather than being limited solely to Astar Network.

–

Regarding the second observation on the six-month requirement, internal discussions within the Council have reached a consensus to adjust the following statement:

3.2. Minimum Operational History

A minimum operational period is required to demonstrate commitment and reduce the risk of early abandonment. However, the originally proposed six months of continuous operation with documented on-chain activity may be excessive, particularly for high-impact projects with which we intend to establish a strategic relationship.

For example, if the Astar Foundation or the ACC were to onboard a major project into the Astar ecosystem, and one of the core value propositions offered is dApp Staking, requiring a six-month waiting period could be unreasonable.

Therefore, the adjusted criteria are:

  • Three months of continuous operation with documented on-chain activity for new projects where the team is not yet known to the ecosystem and has no prior contributions.
  • One to one and a half months of continuous operation for projects with which we have already established a working relationship and a foundation of trust.
3 Likes
6

I think this document is very comprehensive in terms of the selection requirements. I am a little concerned that projects may inflate their on-chain metrics, but this can be remedied by thorough research. Otherwise, I think the delisting process is fair and accurate, and it also makes use of due process, as it invites projects to appeal within the specified time frame, which is very fair. Good work.

7

ACC Final Version.

I. Introduction

The Astar Community Council presents this proposal to strengthen dApp Staking entry and continuity requirements. Currently, dApp Staking operates with approximately 60 available slots, enabling broad participation across the ecosystem.

With the program transitioning to a strictly capped model of 16 slots, each position represents a significantly higher ecosystem commitment. These guidelines aim to ensure that the limited slots are allocated to projects delivering sustained and meaningful value to Astar.

We invite the Astar Collective to review, discuss, and help refine these criteria. Your input is essential to building a framework that is both rigorous and fair.

II. Context

dApp Staking is transitioning from broad participation to focused quality. With 16 available slots, the program must prioritize projects that actively strengthen the Astar ecosystem rather than passively occupy positions.

The ACC proposes the following entry and continuity framework. This is a starting point for community discussion, not a final decision.

III. Proposed Entry Requirements

Given the limited slots available, we propose the following baseline requirements for all applicants:

3.1. Deployed and Operational Product

A live and fully functional product with verifiable on-chain activity, deployed on Astar Network (Native or EVM) or within the broader Astar ecosystem. Products that are still in development or operating exclusively on testnet do not qualify.

Eligibility should be determined based on the product’s measurable contribution to ASTR and the Astar Collective. As Astar operates across multiple networks — including Astar Network, Soneium, Polkadot, and Ethereum — the dApp Staking criteria should reflect this multi-chain structure rather than being limited solely to Astar Network.

3.2. Minimum Operational History

At least 6 months of continuous operation with documented onchain activity. This demonstrates commitment and reduces risk of early abandonment.

3.3. Verified ASTR Integration

A minimum operational period is required to demonstrate commitment and reduce the risk of early abandonment.

  • Three months of continuous operation with documented on-chain activity for new projects where the team is not yet known to the ecosystem and has no prior contributions.
  • One to one and a half months of continuous operation for projects with which we have already established a working relationship and a foundation of trust.

3.4. Quantifiable Ecosystem Contribution

Applicants must provide metrics appropriate to their category:

Category Required Evidence
DeFi TVL trend, transaction volume, active wallets
Infrastructure Consuming dApps, API/RPC usage, uptime records
NFT/Creator Mint/trade volume, unique users, ASTR usage
Gaming/Consumer DAU/MAU data, onchain interactions, retention metrics

Minimum thresholds will be defined per category. Projects below threshold are not eligible regardless of other qualifications.

3.5. Team Accountability

Core contributors identified with verifiable public presence (GitHub, LinkedIn, X, or equivalent). Anonymous teams must demonstrate equivalent credibility through audits, established reputation, or ecosystem vouching.

3.6. Astar Collective Engagement

Prior participation in Astar governance, community discussions, or ecosystem initiatives. Projects with no prior Astar engagement face higher scrutiny.

IV. Proposed Evaluation Process

With limited slots, evaluation must be thorough and transparent. We propose a structured three-phase process:

Phase 1: Community Introduction (Minimum 14 Days)

  • Applicant creates Forum topic with structured application
  • Mandatory sections: product overview, ASTR integration details, team information, metrics evidence, reward usage plan
  • Open community Q&A period
  • Applicant must respond to all substantive questions within 7 days

Phase 2: ACC Technical Review (14 Days)

  • Minimum 3 ACC members review each application independently
  • Standardized scoring matrix evaluates: ecosystem fit, ASTR alignment, team credibility, metrics quality, community engagement
  • Each criterion scored 1-5 with defined rubrics
  • Minimum composite score required for advancement (threshold to be defined)
  • Written evaluation summary published for transparency

Phase 3: Governance Approval

  • Applications meeting score threshold proceed to governance vote
  • Main Council, ACC, or public referendum depending on applicant preference
  • If slots are full, approved applicants enter priority queue

Queue System

When all 16 slots are occupied, qualified applicants enter a ranked queue. Queue position determined by evaluation score. When a slot opens, the highest-ranked queued project receives first consideration.

V. Continuity Requirements

Slot retention is earned, not guaranteed. Listed projects must maintain:

5.1. Onchain Activity

Sustained transaction volume, active wallets, or verifiable usage signals appropriate to project category. Seasonal variation is acceptable; sustained decline triggers review.

5.2. Product Functionality

Accessible, operational product. Broken or abandoned products trigger immediate review.

5.3. Ecosystem Engagement

Responsiveness to ACC communication within 14 days. Participation in governance discussions when relevant to project category.

The ACC monitors listed projects through onchain signals and public product availability. Routine manual reporting is not required for projects in good standing.

VI. Review Triggers

A project enters formal review when any of the following occur:

  • Onchain activity declines by more than 50% over 60 consecutive days without communicated cause
  • Product becomes non-functional or inaccessible for more than 7 days
  • No response to ACC outreach within 30 days
  • Verified community complaints regarding project conduct or reliability
  • ASTR integration removed or significantly reduced without prior communication

Projects under review receive written notification with specific concerns identified.

VII. Removal Criteria and Process

Removal from dApp Staking is a significant action. The following framework ensures decisions are fair, documented, and transparent.

7.1. Grounds for Removal

A project may be removed if it meets one or more of the following criteria:

Criterion Definition Grace Period
Sustained Inactivity Onchain activity below minimum threshold for 90+ consecutive days 30 days to demonstrate recovery plan
Product Abandonment Core product non-functional or inaccessible for 30+ days 14 days to restore functionality
ASTR Disengagement ASTR integration removed or reduced to negligible levels 30 days to restore integration
Communication Failure No response to ACC outreach for 45+ days Final 14-day notice before removal
Bad Actor Behavior Verified malicious conduct, fraud, or ecosystem harm Immediate removal, no grace period
Value Misrepresentation Material false statements in application or reporting Immediate removal, no grace period

7.2. Removal Process

  1. Warning Notice: ACC issues written notice identifying specific deficiency and required remediation
  2. Grace Period: Project has defined period to address concerns (see table above)
  3. Review Hearing: If concerns persist, project may present case to full ACC
  4. Decision: ACC votes on removal. Requires majority approval.
  5. Publication: Removal decision and rationale published on Forum for transparency
  6. Slot Reallocation: Vacated slot offered to highest-ranked project in queue

7.3. Appeal Process

Removed projects may appeal through public referendum within 30 days of removal. Appeal requires community support to proceed to vote.

7.4. Reapplication

Projects removed for inactivity, abandonment, or communication failure may reapply after 6 months if deficiencies are resolved. Projects removed for bad actor behavior or misrepresentation are permanently ineligible.

VIII. Invitation to Participate

This proposal represents the ACC’s initial framework. We recognize that good governance requires community input.

We invite the Astar Collective to discuss:

  • Are the proposed entry requirements appropriately calibrated for 16 slots?
  • Should minimum thresholds differ by project category?
  • Is the evaluation scoring approach fair and transparent?
  • Are the removal criteria and grace periods reasonable?
  • What additional safeguards would strengthen the program?

Your feedback will directly shape the final framework. Please share your thoughts in this thread or contact ACC members directly.

Together, we can ensure dApp Staking rewards the builders who make Astar stronger.

Pit :astr:

Astar Community Council

4 Likes
Large-Scale dApp Staking Cleanup Initiative
8

Thank you — I think this is very good.

Will the submission of activity reports not be required?
If the ACC will be monitoring activities on an ongoing basis, then I believe it would be fine for report submission to remain optional.

2 Likes
9

Thank you for raising this point — I think it’s an important discussion.

The ACC view is largely aligned with the approach you described. Under the framework we are proposing, the ACC’s role should indeed be closer to that of ecosystem guardians, rather than acting as a compliance body imposing continuous reporting obligations on all projects.

The intention is not to create bureaucracy for its own sake, but rather to ensure that the ecosystem remains healthy and that staking slots are occupied by active and valuable contributors.

In practice, the monitoring model we are envisioning would rely primarily on continuous metric-based observation, rather than universal reporting requirements.

This means:

  • The ACC would continuously monitor key on-chain and ecosystem indicators (TVL, user activity, integrations, development activity, etc.), ideally through automated dashboards where possible.
  • If these indicators remain stable or improving, there would be no need for frequent reporting from the project team.
  • If the data shows concerning signals (for example: sharp decline in activity, broken functionality, or prolonged development inactivity), the ACC could then request a targeted report or clarification from the team.
  • For projects that are stable and performing well, a light periodic check-in (for example annually) could be sufficient.

The goal is to focus attention where it is actually needed, without creating unnecessary operational burden for teams that are already contributing positively to the ecosystem.

At the same time, as you pointed out, with the 16-slot system and higher entry barriers introduced by Tokenomics 3.0, it makes sense to strengthen the entry requirements and evaluation criteria upfront. Being selective at the entry stage reduces the need for heavy monitoring later.

So in summary, the intended balance would be:

  • Continuous ecosystem monitoring
  • Targeted investigation when red flags appear
  • Minimal reporting requirements for healthy projects

This approach allows the ACC to remain accountable for the integrity of the dApp Staking ecosystem, while still keeping the environment attractive and efficient for high-quality teams building on Astar.