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.
5.4. Monitoring and Reporting Framework
The ACC’s role is to act as a guardian of the dApp Staking ecosystem, ensuring that the limited slots are occupied by active and valuable contributors.
For this reason, the framework prioritizes continuous ecosystem monitoring rather than universal mandatory reporting.
The ACC will monitor ecosystem health through:
-onchain activity metrics
-public dashboards and analytics tools
-product availability and functionality
-development activity and ecosystem integrations
Where possible, this monitoring should rely on automated or semi-automated data sources, allowing the ACC to track ecosystem performance efficiently.
Projects that remain active and healthy will not be required to submit routine reports.
Instead, reporting requirements become trigger-based.
If objective indicators show potential issues — such as sharp activity decline, extended product downtime, or loss of ecosystem relevance — the ACC may request a targeted activity report or clarification from the project team.
For projects performing well, the ACC may conduct light periodic check-ins (for example annually) to maintain transparency and communication without creating unnecessary administrative burden.
This approach ensures oversight remains data-driven and proportional, allowing productive teams to focus on building while still protecting the integrity of the dApp Staking ecosystem.
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
- Warning Notice: ACC issues written notice identifying specific deficiency and required remediation
- Grace Period: Project has defined period to address concerns (see table above)
- Review Hearing: If concerns persist, project may present case to full ACC
- Decision: ACC votes on removal. Requires majority approval.
- Publication: Removal decision and rationale published on Forum for transparency
- 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 
Astar Community Council