[Proposal setup] Proposal title

Please provide your proposal title

High-Performance Cardano DEX Indexer — Rust + gRPC

[Proposal Summary] Budget Information

Enter the amount of funding you are requesting in ADA

76500

[Proposal Summary] Time

Please specify how many months you expect your project to last

4

[Proposal Summary] Translation Information

Please indicate if your proposal has been auto-translated

No

Original Language

en

[Proposal Summary] Problem Statement

What is the problem you want to solve?

Cardano DEX data is fragmented. Heavy TS/REST indexers hurt speed and portability. We need a Rust + gRPC, light-node indexer to unify swaps/LP events for L1, sidechains, and forks.

[Proposal Summary] Project Dependencies

Does your project have any dependencies on other organizations, technical or otherwise?

Yes

Describe any dependencies or write 'No dependencies'

https://github.com/txpipe/dolos

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

License and Additional Information

Project is going to be released under Apache 2.0 license

[Theme Selection] Theme

Please choose the most relevant theme and tag related to the outcomes of your proposal

Infrastructure

[Campaign Category] Category Questions

Mention your open source license and describe your open source license rationale.

License: Dual MIT OR Apache-2.0 (Rust ecosystem standard).

Rationale: Permissive and fork-friendly for wallets, DEXs, aggregators; Apache adds explicit patent grant; MIT keeps usage simple. Works well with static/dynamic linking, generated Protobuf code, and vendor extensions. Contributions via DCO, SPDX headers, NOTICE file; third-party crates keep their own licenses.

How do you make sure your source code is accessible to the public from project start, and people are informed?

Repo public day-1 under a dedicated GitHub org. Roadmap/issues/milestones visible. Versioned proto/ published with releases. main protected, all PRs open. We’ll announce links on Discord, X, and Catalyst updates; publish bi-weekly progress notes and changelogs; accept community RFCs/issues.

How will you provide high quality documentation?

Docs-as-code: mdBook + cargo doc + generated proto docs. Deliverables: Quickstart (with light node), gRPC API reference with examples, event taxonomy (swaps/LP), reorg semantics, config/metrics, deploy guides (Docker/K8s), sample clients (Rust/Go/TS), and gRPCurl/Postman collections. CI enforces doctests/link checks; docs versioned per release and hosted on GitHub Pages, with diagrams and short tutorial videos.

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

Solution

Overview

We will build a Rust-based, gRPC-first Cardano DEX indexer that runs against a light data node and produces a unified, typed feed for:

• AMMs: swaps, liquidity add/remove, pool create/retire

• Orderbooks: order placed/amended/canceled, matches (partial/complete), and orderbook snapshots/deltas

The system is portable (L1, sidechains, forks), reorg-safe, and optimized for low-latency streaming with strong contracts (Protobuf). Inspired by Indigo’s Iris canonical-events approach, we adapt it to Rust + gRPC and extend it to orderbook markets.

---

What we deliver

• Canonical DEX schemas (AMM + orderbook) with deterministic IDs, provenance, and clear status lifecycle

• gRPC APIs for server-streaming and point-in-time queries (auto-generated clients for Rust/Go/TS/Python/Java)

• Light-node compatibility for fast bootstrap and low OPEX (seamless fallback to a full node if needed)

• Reorg-safe semantics (Observed → Confirmed; compensating events on rollback)

• Pluggable sinks (Postgres, Parquet, Kafka/NATS) and operator tooling (metrics, health, dashboards)

• Docs & examples: mdBook, API reference, event taxonomy, sample consumers, gRPCurl/Postman recipes

---

Architecture (pipeline)

1. Ingest

   Subscribe to a light data node for blocks/txs/UTxOs; backfill via range requests with slot-based checkpoints.

2. Detect

   Per-DEX detectors identify relevant scripts/UTxOs (AMM pools/routers, orderbook markets/orders).

3. Decode

   Extract parameters from datum/redeemer/witnesses and state transitions.

4. Normalize

   Map to canonical AMM events or Orderbook events; compute pool deltas and maintain in-memory orderbook state.

5. Emit

   Stream typed events over gRPC with filtering and backpressure; optionally write to sinks (Postgres/Parquet/Kafka).

6. Reorg Manager

   Track chain head and confirmation depth; issue compensating events and periodic book snapshots for fast recovery.

Implementation uses Rust async (Tokio), tonic + prost, and tower middleware. The binary is lightweight and container-ready.

---

Canonical event model

AMM events

• SwapEvent

  Fields: tx_hash, slot, block, dex_id, pool_id, in_asset, in_amount, out_asset, out_amount, fee_paid, trader, pool_after, dex_specific

• LiquidityAddEvent / LiquidityRemoveEvent

  Amounts per asset, LP tokens minted/burned, reserve deltas, fees

• PoolCreateEvent / PoolRetireEvent

Orderbook events

• OrderPlacedEvent

  market_id, order_id, side, price, quantity, owner, tif?, flags?, tx_hash, slot

• OrderAmendedEvent

  Quantity/flags adjustment (or normalized cancel+place for UTxO replacement)

• OrderCanceledEvent

  Voluntary cancel or protocol invalidation

• MatchEvent

  market_id, taker_order_id, maker_order_id, price, quantity, trade_id, fees, tx_hash, slot (supports partial fills; multiple matches per tx)

• BookSnapshot / BookDelta

  L2 (price-level aggregates) by default; optional L3 where feasible. Includes monotonic sequence and checksum for integrity.

Common fields across all events:

• Provenance: (slot, block, tx_index, action_index)

• Deterministic event_id for idempotency

• Status: Observed | Confirmed | Reorged

• Metadata: dex/market identifiers and optional protocol-specific details

---

gRPC interface (outline)

Indented example of service methods and filters (Protobuf schemas provided in proto/):

// Subscribe filters

message Subscribe {

  string dex_id    = 1;   // optional

  string market_id = 2;   // for orderbooks

  string asset_in  = 3;   // AMM filter

  string asset_out = 4;   // AMM filter

  uint64 from_slot = 5;   // backfill start

}



service Index {

  // AMM

  rpc StreamSwaps(Subscribe)      returns (stream SwapEvent);

  rpc StreamLP(Subscribe)         returns (stream LiquidityEvent);



  // Orderbook

  rpc StreamOrders(Subscribe)     returns (stream OrderEvent);

  rpc StreamMatches(Subscribe)    returns (stream MatchEvent);

  rpc StreamBookDeltas(Subscribe) returns (stream BookDelta);

  rpc StreamBookSnapshots(Subscribe) returns (stream BookSnapshot);



  // Point-in-time queries (pagination omitted here)

  rpc ListSwaps(Query)   returns (SwapPage);

  rpc ListMatches(Query) returns (MatchPage);

}

• Server streaming yields low latency with built-in flow control.

• Reflection/health endpoints support tooling; metrics exposed for SRE dashboards.

---

Light-node compatibility

• Primary dependency is a light data node exposing blocks/transactions/UTxOs.

• Fast bootstrap: ingest historical ranges, persist checkpoints, then switch to live stream without restart.

• If a light node lacks specific fields in a range, connectors fallback to a full node only for that slice.

• This makes bring-up on sidechains/forks practical on modest hardware.

---

Reorg safety & correctness

• Lifecycle: emit Observed immediately; promote to Confirmed after N blocks (configurable).

• Deterministic IDs: hash of canonical ordering + normalized payload prevents duplicate counting.

• Compensating events: on rollback beyond confirmation depth, emit retractions/adjustments; orderbooks also emit or request a fresh snapshot when needed.

• Invariant checks: AMM reserve/fee conservation; orderbook price-time priority and sequence monotonicity enforced by tests.

---

Performance & scalability

• Bounded channels between pipeline stages for backpressure.

• Zero-copy where possible (bytes, prost) and batched writes to sinks.

• Sharding: split by slot range (AMM) or market (orderbook) to scale horizontally.

• Target p95 latency (block seen → event emitted): ≤ 2s on L1; ≤ 1s on faster sidechains (tunable and benchmarked).

---

Storage & exports (optional)

• Postgres for convenience queries and dashboards

• Parquet (S3/FS) for analytics and reproducible research

• Kafka/NATS for streaming pipelines and multi-service fan-out

These sinks are pluggable; the core indexer remains storage-agnostic.

---

Security, ops & reliability

• Transport: TLS/mTLS ready; optional auth/quota middleware (Tower) for hosted endpoints

• Observability: Prometheus metrics (lag, throughput, reorg counters, snapshot size), structured logs, gRPC health

• Supply chain: cargo audit, SBOM, reproducible builds; CI gates for lint/tests/property/fuzz/SAST

---

Documentation & developer experience

• Docs-as-code: mdBook + cargo doc + generated gRPC docs from Protobuf.

• Event taxonomy: AMM + orderbook schemas with worked examples and edge cases (multi-hop swaps, partial fills, IOC/FOK).

• Quickstarts & samples: runnable clients in Rust/Go/TS; gRPCurl/Postman collections; deployment guides (Docker/Helm).

• Versioning: semantic versioning for Protobuf; deprecation windows and migration notes for safe upgrades.

---

Portability to sidechains & forks

• Network profiles (TOML/YAML) capture genesis params, cost models, asset policy IDs, DEX/market registries, and address formats.

• Bring-up on a new network becomes: point to the light node, load the profile, replay from genesis or a known checkpoint, and start streaming.

• Profiles are versioned and testable; example profiles provided for L1 and at least one sidechain/fork.

---

Inspired by Iris, adapted for Rust + gRPC + orderbooks

Iris demonstrated the value of canonical, protocol-agnostic events. We adopt that philosophy and extend it by:

• Implementing in Rust for performance and small operational footprint

• Exposing gRPC for typed, streaming contracts and code-generated clients

• Supporting light-node ingestion for fast bootstrap

• Adding orderbook normalization (orders, matches, snapshots/deltas) alongside AMM coverage

---

Out of scope (for clarity)

• Running a custodial matching engine or centralized relayer

• Price oracle publication

• Non-DEX protocols (lending, CDPs, etc.) in this phase

---

Conclusion

This solution turns fragmented, heavy, and brittle DEX data access into a portable, verifiable, low-latency public good. By unifying AMM trades and orderbook activity behind a Rust + gRPC, light-node-compatible indexer—with canonical schemas, reorg-safe semantics, and strong DX—we enable faster integrations, better user experiences, and rapid sidechain adoption across the Cardano ecosystem.

[Your Project and Solution] Impact

Please define the positive impact your project will have on the wider Cardano community

Ecosystem impact

• Shared market-data backbone: A single, open, typed feed for AMM swaps/LP and orderbook orders/matches/book state replaces ad-hoc decoders and brittle REST/WS feeds. One integration works across DEXs and networks.

• Faster sidechain bring-up: Light-node compatibility enables day-one market data on partner chains and forks, accelerating liquidity, listings, and developer onboarding.

• Standardization: A canonical DEX event taxonomy (AMM + orderbook) becomes a neutral reference for protocol teams, integrators, and researchers—improving quality and comparability.

• Transparency & trust: Deterministic IDs, reorg semantics, and verifiable orderbook snapshots/deltas yield reproducible analytics, fair price discovery, and simpler auditing.

• Public good: MIT/Apache-2.0 licensing, documented schemas, and sample clients create a durable community asset that others can extend (new DEX mappers, sinks, or markets).

Impact for builders & integrators

• Weeks → hours: Import a generated gRPC client (Rust/Go/TS/Python/Java), subscribe to StreamSwaps, StreamLP, StreamOrders, StreamMatches, and—if needed—StreamBookDeltas/Snapshots, then ship.

• Lower infra burden: No db-sync on the hot path. Single binary or Docker image runs on modest hardware; ideal for small teams and sidechains.

• Reliability at scale: Backpressure, bounded queues, idempotent event IDs, and confirmation depth make production consumption predictable for UIs, bots, and aggregators.

Impact for users

• Better UX in wallets & explorers: Real-time AMM trades, LP activity, and live orderbooks with consistent formatting.

• Safer decisions: Consistent fees/amounts, verified book integrity, and clean rollback handling reduce misinformation and “phantom” trades.

• More apps, faster: Lower integration cost unlocks more tools on Cardano L1 and new partner chains.

Quantifiable outcomes & KPIs

Coverage & adoption

• ≥ 2 AMM DEXs and ≥ 1 orderbook DEX mapped to the canonical schema.

• ≥ 10 active consumers (unique client fingerprints) across wallets/explorers/analytics/bots.

• ≥ 2 sidechain/fork profiles publicly validated with bring-up guides.

Performance & reliability

• P95 event lag (block seen → event emitted): ≤ 2s on L1; ≤ 1s on faster sidechains.

• Reorg recovery: full reconciliation and steady state < 60s after a 3-block rollback.

• Bootstrap time: < 12 hours from genesis on L1 via light node (documented hardware); < 2 hours for a fresh sidechain.

Usability & DX

• ≥ 3 sample clients (Rust/Go/TS) and a gRPCurl/Postman collection.

• Docs satisfaction from integrator survey: ≥ 4/5 average.

• Monthly tagged releases with changelogs; SBOM + reproducible builds.

Open-source health

• ≥ 10 external issues triaged and 5 community PRs merged (decoders, docs, sinks).

• RFC process adopted with ≥ 2 community proposals (e.g., new order flags, checksum formats).

Alignment with Cardano goals

• Scalability & interoperability: Light-node + gRPC makes high-quality market data accessible across L1, sidechains, and partner chains.

• Developer growth: Strong DX (schemas, clients, guides) lowers friction for trading UIs, analytics, and liquidity tooling.

• Research & compliance: Canonicalized events and verifiable orderbooks support rigorous studies (slippage, liquidity, volatility) and simpler reporting.

Sustainability after funding

• Low OPEX: Small footprint allows inexpensive public endpoints and self-hosting.

• Community extensions: Modular DEX mappers and sinks; a maintained DEX Registry plus “good first issues” to grow contributors.

• Optional services without lock-in: Hosted endpoints and enterprise add-ons can exist while the core remains permissively licensed.

Adoption plan

• Early integrators: 3–5 partners (wallets, explorers, aggregators, one sidechain) for weekly feedback and test feeds.

• Devrel & comms: mdBook docs, tutorials, sample repos, and bi-weekly updates on Forum/Discord/X.

• Path to default: PRs to “awesome-Cardano” lists; Nix/Docker recipes and Helm charts for one-command deployment.

Risk-adjusted impact

• AMM-only delivery still yields a unified, reorg-safe stream for swaps/LP that cuts costs and integration time.

• With orderbooks (planned), market makers and UIs gain a production-grade book feed (snapshots + deltas), closing a major gap for professional tooling.

Before vs after

• Before: Each team runs db-sync, writes per-DEX decoders, builds REST/WS, hand-rolls rollback logic, and fights drift across networks.

• After: Use the Rust gRPC indexer, subscribe to canonical streams, and ship. Porting to a sidechain is “point to another light node + load a profile.”

Long-term effects

• Compounding integrations: Each new DEX mapper benefits all consumers immediately; each new consumer validates and improves the standard.

• Better liquidity signals: Consistent swaps, LP deltas, and orderbook depth improve routing, aggregation, and capital efficiency.

• Faster experimentation: Sidechains iterate on block times/VM features without waiting for heavy infra—accelerating innovation across Cardano.

Bottom line: This project converts fragmented, heavy, and brittle DEX data access into a portable, verifiable, low-latency public good—unlocking faster integrations, better UX, and rapid sidechain adoption across the Cardano ecosystem.

[Your Project and Solution] Capabilities & Feasibility

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

Delivery readiness & accountability

• Open development from day-1: Public GitHub repo, project board, issues, RFCs, and tagged releases with changelogs. Dual license MIT OR Apache-2.0, DCO and SPDX headers.
• Clear governance: Roadmap with exit criteria per workstream; fortnightly progress notes; demo videos for major increments; budget vs. deliverables tracked publicly.
• Quality gates: CI enforcing lint, unit/integration/property tests, fuzzing for decoders, SAST, dependency audits, reproducible builds, SBOM.
• Ops hygiene: Structured logs, Prometheus metrics, gRPC health checks, and Grafana dashboards. Single static binary + Docker; optional Helm charts.

Technical approach (why it’s feasible)

• Rust + gRPC + light-node first: Async pipeline (Tokio) with bounded stages: ingest → detect → decode → normalize → emit. Compatible with a light data node for fast bootstrap; graceful fallback to full node when needed.
• Canonical schemas: AMM events (swaps, LP add/remove, pool lifecycle) and orderbook events (order placed/amended/canceled, matches, book snapshots/deltas). Strong typing via Protobuf with cross-language clients (Rust/Go/TS/Python/Java).
• Reorg safety: Deterministic event IDs, configurable confirmation depth, compensating events, and periodic orderbook snapshots with sequence and checksum to guarantee client recovery.
• Scalability: Shard by slot range or market; backpressure via bounded channels; batched sinks (Postgres, Parquet, Kafka/NATS); zero-copy where possible (bytes, prost).
• Security & reliability: mTLS-ready transport, rate-limit/auth middleware (Tower), supply-chain checks, and least-privilege runtime configs.

Validation plan (how we prove it works)

1. Contract correctness
   • Versioned Protobufs with breaking-change checks in CI.
   • Golden-file tests from real block/tx fixtures; cross-language client compile tests to ensure SDKs are usable.
2. Accuracy & reorg semantics
   • Property tests for idempotent IDs, canonical ordering, and at-least-once delivery guarantees.
   • Reorg simulator generating N-block rollbacks; assert full reconciliation <60s for 3-block scenarios.
   • AMM invariants (reserve/fee conservation across swaps/LP); orderbook invariants (price-time priority, monotonic sequence, snapshot+delta parity).
3. Performance
   • Load tests with realistic block cadence and market activity.
   • Targets: p95 end-to-end latency (block seen → event emitted) ≤2s on L1, ≤1s on fast sidechains; bounded memory under bursty flow.
4. Interop & DX
   • Quickstart against a public light node; grpcurl/Postman recipes; sample clients (Rust/Go/TS) validated in CI.
   • Docs NPS checkpoints via integrator surveys (goal ≥4/5): mdBook guides, API reference, event taxonomy, reorg playbook.
5. Security
   • cargo audit, SBOM, reproducible builds; fuzzing (cargo-fuzz) for datum/redeemer parsers; static analysis in CI.

Risks & mitigations

• DEX heterogeneity: Start with widely used AMM/orderbook patterns; modular decoders per protocol; community RFCs for edge cases.
• Light-node gaps: Connector abstraction with seamless fallback to full node for missing ranges/fields; clear docs on required capabilities.
• High event rates: Bounded queues, backpressure, per-market sharding; performance budgets and regression tests enforced in CI.
• Schema churn: Semantic versioning, deprecation windows, migration guides, and compatibility tests to protect integrators.

Why this inspires trust

• Transparent, measurable process (public code, tests, benchmarks, demos).
• Proven building blocks (Rust async, gRPC streaming, canonical AMM + orderbook models) applied with rigorous validation (property/fuzz testing, reorg simulator, invariants).
• Contracts and licensing that reduce lock-in and make integration straightforward for wallets, explorers, aggregators, and sidechains.

Bottom line: The approach is technically conservative, operationally disciplined, and openly verifiable—positioning us to ship a production-grade, portable indexer for AMM swaps/LP and orderbook data with high reliability from day one.

[Milestones] Project Milestones

Milestone Title

Foundations: gRPC service, light-node ingest, AMM swaps (1 DEX)

Milestone Outputs

• Public GitHub repo (MIT OR Apache-2.0), CI pipeline, issue templates, RFC folder.

• Protobuf v0.x: core types (SwapEvent, LiquidityEvent placeholder), Subscribe, and base Index service.

• Rust server skeleton (tonic/prost), health/reflection, basic filters, bounded channels.

• Light-node connector: block/tx/UTxO ingest; slot-based checkpoints.

• AMM decoder for one reference DEX: swaps only (no LP yet).

• Sample client (Rust or Go), mdBook “Quickstart” and API overview.

Acceptance Criteria

• cargo build/tests pass in CI; server starts locally with health OK.

• StreamSwaps returns canonicalized swaps for a documented historical slot range (≥1,000 blocks) from a light node.

• Deterministic event_id and canonical ordering documented; golden-vector tests pass for the range.

• Repo public with tags, license, and contribution guidelines.

Evidence of Completion

• GitHub tag v0.1.0 with changelog;

• Protobuf published under proto/ with versioned package;

• Demo recording (5–10 min) showing ingest, grpcurl swap stream, and sample client output.

• mdBook site (or README) with Quickstart and run logs for the test range.

Delivery Month

1

Cost

16000

Progress

20 %

Milestone Title

Reorg & backfill: confirmations, LP events, sinks

Milestone Outputs

• Reorg manager: configurable confirmation depth; Observed → Confirmed; compensating events on rollback.

• AMM LP support: LiquidityAddEvent / LiquidityRemoveEvent + pool state deltas.

• Backfill endpoints (slot/time range) for swaps & LP.

• Pluggable sinks: Postgres (convenience) and Parquet (analytics).

• Reorg simulator test harness + property tests (idempotency, ordering).

Acceptance Criteria

• Simulated 3-block rollback: consumer state reconciles to canonical after replay (test report).

• Backfill for swaps/LP over a documented range returns identical results across repeated runs.

• Postgres table schemas & Parquet files generated from a sample run; schema docs included.

• Golden-vector tests extended to LP events; all CI checks pass.

Evidence of Completion

• GitHub tag v0.2.0, changelog, release images.

• Test reports from reorg simulator and backfill determinism checks.

• Example SQL queries + Parquet sample in /examples with README.

• Short demo video: run rollback sim, show compensating events and final parity.

Delivery Month

2

Cost

24500

Progress

60 %

Milestone Title

Orderbook core: orders, matches, L2 snapshots (1 market)

Milestone Outputs

• Orderbook decoder for one reference orderbook DEX, one market.

• Canonical events: OrderPlaced, OrderAmended (or normalize replace), OrderCanceled, MatchEvent.

• gRPC streams: StreamOrders, StreamMatches, StreamBookDeltas, StreamBookSnapshots.

• Sample client renders L2 book and prints trades; docs updated with orderbook taxonomy.

Acceptance Criteria

• Monotonic sequence and checksum verification pass in CI.

• Streaming filters (market_id) work and are documented; demo client subscribes and renders top-of-book.

• Backfill queries return consistent order/match history for the market.

Evidence of Completion

• GitHub tag v0.3.0, release artifacts, updated Protobufs.

• Demo video: subscribe to deltas, request a snapshot, verify book integrity, and display live matches.

• mdBook section: orderbook events, snapshots/deltas, recovery playbook.

Delivery Month

3

Cost

26000

Progress

80 %

Milestone Title

Hardening & adoption: packaging, metrics

Milestone Outputs

• Packaging: Docker image, example Compose

• Observability: Prometheus metrics (throughput, lag, reorg counters, snapshot size) + Grafana dashboard JSON.

• Security & supply chain: SBOM, cargo audit gating, reproducible builds.

• Final documentation pass; community update + budget report (management & reporting).

Acceptance Criteria

• One-command local run (Docker) streams swaps and orderbook deltas using example configs.

• Metrics endpoint exposes documented gauges/counters; sample dashboard loads without errors.

• SBOM published; CI enforces cargo audit and build reproducibility steps

Evidence of Completion

• GitHub tag v1.0.0, release images, dashboard JSON, SBOM, and security report.

• Demo video: fresh deploy, metrics in Grafana, sidechain profile ingest producing events.

• mdBook “Operate & Observe” and “Sidechain Bring-up” guides; final budget & progress report.

Delivery Month

4

Cost

10000

Progress

100 %

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

We denominate the ask in ADA using a conservative rate of $0.75/ADA (current ≈$0.90). USD figures below are indicative only.

Total Ask

75,500 ADA (≈ $56,625 at $0.75/ADA)

• Development (M1–M3): 65,500 ADA (≈ $49,125)
• Proposal management & reporting (M4 allocation): 10,000 ADA (≈ $7,500)

Milestone-Linked Payouts

• M1 — Foundations (gRPC, ingest, AMM swaps – 1 DEX): 15,000 ADA (≈ $11,250) — 19.9%
• M2 — Reorg & backfill; LP events; sinks: 24,500 ADA (≈ $18,375) — 32.5%
• M3 — Orderbook core (orders, matches, L2 snapshots – 1 market): 26,000 ADA (≈ $19,500) — 34.4%
• M4 — Hardening, packaging, metrics, final reporting: 10,000 ADA (≈ $7,500) — 13.2%

Sum: 75,500 ADA (≈ $56,625)

Cost Rationale (Concise)

• Engineering effort (M1–M3): Rust services, canonical schemas (AMM + orderbook), light-node ingest, reorg/backfill, sinks, gRPC APIs, invariant/property tests, and orderbook snapshot/delta machinery.
• Operationalization (M4): Packaging (Docker/Helm), Prometheus/Grafana, SBOM & security checks, sidechain profile + bring-up guide, and final documentation.
• Management & reporting: Milestone coordination, progress updates, acceptance evidence, and budget reporting (allocated within M4’s 10k ADA).

Payment & Acceptance

• Milestone-based disbursements only after published artifacts, demo videos, and acceptance tests are available in the public repo (as defined in each milestone’s Acceptance Criteria/Evidence).
• No request for advance payment; each tranche is tied to verifiable outputs.

Scope Boundaries (to control costs)

• In-scope: 1 AMM DEX (swaps + LP), 1 orderbook market (orders/matches), gRPC APIs, sinks (Postgres/Parquet), reorg/backfill.
• Out-of-scope: Additional DEX integrations/markets beyond the above, hosted SLAs, non-DEX protocols (lending/CDPs), or premium dashboards (can be added later via community PRs or separate proposals).

This structure keeps the funding lean, milestone-accountable, and aligned with a conservative ADA rate—while delivering a production-grade, portable DEX indexer for Cardano.

[Final Pitch] Value for Money

How does the cost of the project represent value for the Cardano ecosystem?

Value for Money

Why this is efficient use of funds

• Public good with compounding reuse: A single, open, typed market-data layer (AMM + orderbook) that many teams can consume. Each new integrator or DEX mapper multiplies ecosystem value without multiplying cost.

• Lean, conservative budget: 75,500 ADA total using $0.75/ADA; no advance payments. Tranches are released only after verifiable outputs pass acceptance tests.

• Lower total cost of ownership (TCO): Light-node ingest avoids db-sync on the hot path, cutting infra footprint, bootstrap time, and ops burden for every adopter.

• Avoided duplicated work: Canonical schemas + gRPC streams eliminate bespoke decoders and ad-hoc REST/WS plumbing across projects.

• Permissive licensing: Dual MIT/Apache-2.0 ensures zero lock-in; the community can extend, fork, or host independently.

What you get for 75,500 ADA

• Core capabilities: Rust indexer, canonical AMM & orderbook schemas, gRPC server streaming + queries, reorg/backfill, Postgres/Parquet sinks.

• Operational readiness: Docker packaging, metrics (Prometheus), health checks, Grafana dashboards, SBOM and cargo audit gates.

• Portability: Network profiles for L1 & a sidechain/fork; bring-up guides for rapid adoption.

• Developer experience: mdBook docs, API reference, event taxonomy, runnable sample clients (Rust/Go/TS), grpcurl/Postman recipes.

• Evidence & accountability: Tagged releases, demo videos, test reports (golden vectors, reorg simulator, reconstruction parity for orderbooks).

Payment structure (risk-managed)

• Milestone-based payouts aligned to objective criteria (artifacts + tests + demos).

• No prepayment: Funds unlock when outputs are delivered and verifiably functional.

• Transparent cadence: Public repo, CI, changelogs, and progress notes; easy to audit delivery vs. spend.

Cost rationale (concise)

• Engineering (65,500 ADA): Rust async pipeline, light-node connectors, canonicalization, reorg manager, orderbook snapshots/deltas, sinks, tests, and example clients.

• Management & reporting (10,000 ADA): Milestone coordination, acceptance packages (videos/reports), and community updates—kept lean to prioritize engineering.

Unit economics & ROI examples

Illustrative, to show leverage; not contractual targets.

• Per-integrator cost if N teams adopt:

  • 5 adopters → ~15,100 ADA per integrator equivalent

  • 10 adopters → ~7,550 ADA per integrator equivalent

  • 20 adopters → ~3,775 ADA per integrator equivalent

• Avoided engineering time per integrator:

  • Typical custom path (db-sync + decoders + WS/REST + rollback logic): 3–8 weeks of senior time.

  • With this indexer: hours to days to integrate (generated clients + canonical streams).

  • Even for the low end (3 weeks saved), across 10 integrators the ecosystem avoids ~30 senior weeks of work for the same one-time grant.

• Infra savings (directional):

  • Light-node ingest + single binary reduces persistent storage and CPU compared to db-sync stacks, lowering monthly OPEX for wallets, explorers, bots, and sidechains.

Risk controls (value protection)

• Conservative ADA rate: Budgeted at $0.75/ADA (below current ≈$0.90) to cushion volatility.

• Acceptance gates: Each milestone has clear outputs, criteria, and evidence—reducing delivery risk.

• Open continuity: All artifacts are public and permissively licensed; community can continue without the original team if needed.

• Test-first rigor: Golden vectors, property/fuzz tests, and a reorg simulator catch correctness issues early—preventing costly regressions for integrators.

Alignment with Fund goals

• Scalability & interoperability: Standardized, typed feeds across L1 and sidechains enable more apps to launch faster.

• Ecosystem leverage: One grant lifts many boats—wallets, explorers, aggregators, market makers, researchers.

• Sustainability: Small runtime footprint and community-friendly licensing reduce ongoing costs and support organic maintenance via PRs and new mappers.

Scope boundaries (cost discipline)

• In-scope: 1 AMM DEX (swaps + LP), 1 orderbook market (orders/matches), gRPC APIs, reorg/backfill, Postgres/Parquet sinks, sidechain/fork profile, packaging & metrics.

• Out-of-scope: Additional DEX integrations, more markets, hosted SLAs, or non-DEX protocols (can follow via separate proposals or community contributions).

Bottom line

For 75,500 ADA, the Cardano ecosystem gains a production-grade, portable DEX indexer (AMM + orderbook) that drastically reduces duplicated engineering and infra costs while accelerating time-to-market for many teams. Funding is milestone-guarded, outputs are open and verifiable, and long-term value compounds with every new integrator and DEX mapper.

[Required Acknowledgements] Consent & Confirmation

Terms and Conditions:

Yes