Feature/306 307 308 309

.github/ISSUE_TEMPLATE/arbiter-nomination.md

@@ -0,0 +1,109 @@
+---
+name: Arbiter Nomination
+about: Nominate a candidate for the arbiter committee
+title: '[Arbiter Nomination] '
+labels: arbiter-nomination
+---
+
+# Arbiter Committee Nomination
+
+Thank you for nominating a candidate for the Vortex Protocol's arbiter committee!
+
+---
+
+## Candidate Information
+
+**Candidate Name (or pseudonym):**
+[Name or pseudonym]
+
+**Contact Information:**
+- Discord: @[handle]
+- GitHub: [@handle](https://github.com/handle)
+- Email: [email@example.com] (optional)
+
+---
+
+## Nomination Statement
+
+**Why should this person serve as an arbiter?**
+
+[Provide 2–3 paragraphs explaining the candidate's background, relevant experience, and why they would serve as a fair and trustworthy arbiter. Examples:
+- Years of involvement in protocol/blockchain communities
+- Experience resolving disputes or mediating conflicts
+- Demonstrated fairness, integrity, and impartiality
+- No apparent conflicts of interest with the protocol
+]
+
+---
+
+## Candidate Self-Attestation (Required)
+
+**Candidate must confirm:**
+
+- [ ] I confirm I want to be considered for the arbiter committee
+- [ ] I meet the eligibility criteria in [issue #115's arbiter code-of-conduct](https://github.com/stellar-vortex-protocol/vortex-contracts/issues/115)
+- [ ] I have no current conflicts of interest with the Vortex Protocol (see below)
+- [ ] I have reasonable availability to serve on the committee for a 12-month term
+- [ ] I commit to reviewing the [Dispute Resolution Design](../docs/dispute-resolution-design.md) and [Arbiter Election Process](../docs/arbiter-election-process.md)
+
+---
+
+## Conflict of Interest Disclosure
+
+**All candidates must disclose any potential conflicts of interest:**
+
+- [ ] I do not own or operate a solver on Vortex
+- [ ] I do not have family/close relationships with protocol core team or other arbiters
+- [ ] I am not currently a party to any active dispute or slash appeal
+- [ ] I have disclosed any other potential conflicts below:
+
+[List any other conflicts or potential concerns]
+
+---
+
+## Availability
+
+**How many hours per week can you commit to arbiter duties?**
+[e.g., "5–10 hours per week" or "on-call, typically <5 hours"]
+
+**Are you available for a 12-month term starting [month]?**
+[ ] Yes
+[ ] No, available starting [alternative date]
+[ ] Not sure yet
+
+---
+
+## Supporting Information (Optional)
+
+Links to relevant experience or community involvement:
+- [GitHub profile](https://github.com/profile)
+- [Prior dispute resolution/mediation experience]
+- [Community contributions]
+- Other relevant links
+
+---
+
+## Triage Notes (For Maintainers)
+
+*Leave blank when submitting; maintainers will fill this in during screening.*
+
+- **Eligibility Status:** [ ] Eligible [ ] Ineligible — Reason: [if ineligible]
+- **Screening Date:** [YYYY-MM-DD]
+- **Notes:** [Any additional comments on candidacy]
+
+---
+
+## Process & Timeline
+
+**What happens next:**
+
+1. **Screening (3 days)**: Maintainers review eligibility criteria and confirm the candidate is registered
+2. **Nomination Period (28 days)**: Community discusses the nomination; candidate may answer questions
+3. **Community Signaling (14 days)**: Community votes on all eligible candidates using the signaling tool (issue #120)
+4. **Admin Appointment (7 days)**: Admin appoints based on community endorsement (see [Arbiter Election Process](../docs/arbiter-election-process.md) for details)
+
+---
+
+## Questions?
+
+See the [Arbiter Election Process](../docs/arbiter-election-process.md) for FAQs and process details.

.github/ISSUE_TEMPLATE/solver-feedback.md

@@ -0,0 +1,56 @@
+---
+name: Solver Feedback
+about: Raise operational concerns about the protocol (distinct from bug reports and slash appeals)
+title: '[Solver Feedback] '
+labels: solver-feedback
+---
+
+# Solver Operational Feedback
+
+Thank you for taking the time to share your operational concerns or suggestions with the Vortex Protocol community.
+
+**Note:** This channel is for operational feedback, insights, and concerns from solvers navigating the protocol in production or on testnet. It is explicitly **not** for:
+- Bug reports (use the "Bug Report" template instead)
+- Formal slash-event appeals (see the [Slash Appeal Process](../docs/slash-appeal-process.md) instead)
+- General protocol governance proposals (see the [RFC Process](../docs/rfc-process.md) for formal governance)
+
+---
+
+## Concern Category
+
+What type of operational concern are you raising?
+
+- [ ] Fee or incentive structure
+- [ ] Fill window or timing constraints
+- [ ] Bond or collateral requirements
+- [ ] Route or market coverage gaps
+- [ ] Monitoring or observability limitations
+- [ ] Other (please describe below)
+
+## Operational Context
+
+**Describe the operational constraint or concern:**
+
+[Provide specific details about what you've observed in your solver operations that prompted this feedback. Include testnet/mainnet context if applicable.]
+
+**Scale and Impact:**
+
+[How broadly does this affect solvers? Is this a niche issue for specific route types, or a systemic concern? Any quantitative impact data?]
+
+---
+
+## Suggested Direction (Optional)
+
+If you have thoughts on how the protocol might better support your operational needs, share them here. This is input, not a binding proposal.
+
+[Suggestions and thoughts...]
+
+---
+
+## Triage Notes
+
+*For protocol maintainers:*
+- Triage target: within 7 calendar days of filing
+- Response: acknowledging receipt and indicating whether this is being considered, escalated to the RFC process, or closed with rationale
+
+See [Solver Feedback Process](../docs/solver-feedback-process.md) for details.

README.md

@@ -594,6 +594,24 @@ branch-protection / required-checks maintainer guide.
 For org-wide policies see the
 [org CONTRIBUTING.md](https://github.com/vortex-protocol/.github/blob/main/CONTRIBUTING.md).
 
+## Ecosystem & Grants
+
+The Vortex ecosystem grows through community-built tooling. We maintain a collection
+of **reference implementations** in this repository (`indexer/reference-indexer.js`,
+`examples/risk_aware_solver_bot.py`) intended as starting points for external contributors.
+
+### Building on Vortex
+
+Interested in building indexers, monitoring dashboards, integration libraries, or solver
+infrastructure? See the [Ecosystem Grants Program](./docs/ecosystem-grants-program.md)
+for how to get funding support once the protocol treasury governance process (issue #117)
+is adopted.
+
+Current ecosystem tooling examples:
+- `indexer/reference-indexer.js` — reference intent indexer (extend to production service)
+- `examples/risk_aware_solver_bot.py` — reference solver bot implementation
+- `solver_registry/` contract — solver reputation and tier management
+
 ## License
 
 [MIT](./LICENSE) © 2025–2026 Vortex Protocol Contributors

SECURITY.md

@@ -115,6 +115,14 @@ defended by the `IntentNotOpen` guard (idempotent after first call).
 
 ---
 
+### Proof of Reserves
+
+The protocol publishes a **public proof-of-reserves dashboard** (see [`dashboard/`](./dashboard/) and [`docs/proof-of-reserves-dashboard.md`](./docs/proof-of-reserves-dashboard.md)) that reconciles on-chain solver bond totals against this Assets-at-Risk table. This is a **transparency artifact, not an insurance guarantee** — it verifies that collateral is on-chain but does not guarantee solver performance or user fund recovery.
+
+The dashboard is continuously updated and independently reproducible (data sources and queries are published). Users should read this threat model and the FAQ in the dashboard for caveats.
+
+---
+
 ### Admin Key Operational Security (#122)
 
 The `Admin` address is the single most sensitive key in the protocol. It

dashboard/README.md

@@ -0,0 +1,100 @@
+# Proof of Reserves Dashboard
+
+This directory contains the Vortex Protocol's public proof-of-reserves dashboard — a transparency tool for verifying that the protocol's on-chain collateral (solver bonds) matches what the security model depends on.
+
+## Quick Start
+
+1. **View the live dashboard**: Open `index.html` in a web browser
+   - Or deploy to GitHub Pages, Vercel, or your preferred static host
+   - Update `CONFIG.contractId`, `CONFIG.network`, and `CONFIG.rpcEndpoint` to point to your deployment
+
+2. **Deploy to GitHub Pages** (automatic):
+   ```bash
+   # GitHub Actions will auto-deploy this directory on every push to main
+   # Dashboard will be available at: https://stellar-vortex-protocol.github.io/vortex-contracts/dashboard/
+   ```
+
+3. **Deploy to Vercel or other host**:
+   ```bash
+   vercel deploy ./dashboard
+   # or copy `dashboard/` to your static host
+   ```
+
+## Files
+
+- **index.html**: Single-page dashboard with embedded CSS and JavaScript
+  - No backend required; fetches live data from Stellar RPC
+  - Responsive design; works on desktop and mobile
+  - Refreshes data every 5 minutes
+
+## Configuration
+
+Edit `CONFIG` object in `index.html`:
+
+```javascript
+const CONFIG = {
+  contractId: 'YOUR_CONTRACT_ID_HERE', // e.g., 'CA...xpz'
+  network: 'testnet',                  // or 'mainnet'
+  rpcEndpoint: 'https://soroban-testnet.stellar.org', // Stellar RPC
+  refreshInterval: 5 * 60 * 1000,      // 5 minutes
+};
+```
+
+## Data Sources
+
+The dashboard queries:
+
+1. **`get_protocol_health()`** — returns aggregate stats (bonds, solver count, etc.)
+   - Fallback: **`list_solvers(start, limit)`** to enumerate and sum manually
+
+2. **Event stream** (via RPC) — for intent-state distribution and volume at risk
+   - Events: `intent_submitted`, `fill_intent`, `solver_slashed`
+
+3. **`get_treasury()`** — for treasury balance (once issue #37 deploys)
+
+## Building & Development
+
+### Local Testing
+
+```bash
+# Open in default browser
+open dashboard/index.html
+
+# Or use a local server (Python 3)
+python3 -m http.server 8000
+# Visit: http://localhost:8000/dashboard/
+```
+
+### For Production
+
+1. Update `CONFIG` with real contract ID and RPC endpoint
+2. Test against testnet first
+3. Deploy static files to GitHub Pages, Vercel, or your CDN
+4. Monitor for RPC failures and set up alerting
+
+## Documentation
+
+See [`docs/proof-of-reserves-dashboard.md`](../docs/proof-of-reserves-dashboard.md) for:
+
+- Detailed explanation of what data is displayed and why
+- Reconciliation logic against `SECURITY.md`'s Assets-at-Risk
+- Implementation options (client-side, server-side, hybrid)
+- Testing and validation procedures
+
+## Related Issues
+
+- **Issue #308**: This dashboard (proof-of-reserves)
+- **Issue #37**: Protocol treasury (future: display treasury balance)
+- **Issue #40**: Governance proposals dashboard (complementary; tracks votes)
+- **Issue #46**: `TotalBonded` aggregate counter (preferred data source)
+- **Issue #110**: Monitoring and alerting spec (technical foundation)
+
+## License
+
+MIT — same as vortex-contracts repository
+
+## Support & Feedback
+
+- Report bugs or suggest improvements on [GitHub Issue #308](https://github.com/stellar-vortex-protocol/vortex-contracts/issues/308)
+- Questions? See [SECURITY.md](../SECURITY.md) for threat model context
+