Argus: Arbitrage Analytics

[Proposal setup] Proposal title

Please provide your proposal title

Argus: Arbitrage Analytics

[Proposal Summary] Budget Information

Enter the amount of funding you are requesting in ADA

200000

[Proposal Summary] Time

Please specify how many months you expect your project to last

12

[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 DeFi lacks professional data on market efficiency. Arbitrage is invisible, preventing DEXs and large investors from verifying liquidity health or optimizing protocols.

[Proposal Summary] Supporting Documentation

Supporting links

• https://docs.google.com/document/d/1RoMrUBTqwmT3FdLbFwDb8JuMvmt78YZu2z72_7J179U
,
• https://drive.google.com/file/d/12v9UWXUZLcn3BEfiM2C1yv2BjYh1qPs7

[Proposal Summary] Project Dependencies

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

No

Describe any dependencies or write 'No dependencies'

No dependancies

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

Please provide details on the intellectual property (IP) status of your project outputs, including whether they will be released as open source or retained under another licence.

MIT

[Theme Selection] Theme

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

Analytics

[Campaign Category] Category Questions

Describe what makes your idea innovative compared to what has been previously launched in the market (whether by you or others).

This idea is not about inventing arbitrage or trading bots on Cardano – those already exist, as do generic DEX monitoring tools.

Existing DEX monitors mostly follow price changes and “reverse” transactions on a single platform. However, real arbitrage on Cardano often happens across multiple AMM DEXs: the trade that creates the opportunity may be on one DEX, while the arbitrage transaction is executed on another. Current tools rarely track this cross-DEX flow end-to-end.

Our approach is to monitor all major AMM DEXs simultaneously, reconstruct arbitrage paths across them, and attribute opportunities and trades at the ecosystem level, not per-Dex. This cross-DEX, analytics-only design is new to Cardano: it turns opaque, bot-only information into a shared, open dataset and dashboard that any user, analyst, or project can inspect and build on.

By turning complex arbitrage behaviour into clear, explorable data and visual timelines, we also lower the barrier to entry for new builders, traders, and projects coming to Cardano. Instead of needing bespoke infra or a custom bot to “peek behind the curtain”, newcomers can learn how AMMs behave here, study real arbitrage patterns, and prototype strategies or products on top of our open data and APIs. This makes Cardano’s DeFi landscape more transparent and approachable for cross-chain traders, analytics teams, and new protocols choosing which ecosystem to build in.

In recent Catalyst funds we reviewed Catalyst-funded tools and existing Cardano DeFi analytics, including DEX explorers, trading dashboards and MEV/arbitrage-related bots. Most of these focus on per-DEX views (pool stats, price charts, volume) or on private execution infrastructure for individual arbitrageurs. None of them provide an open, cross-DEX view that reconstructs arbitrage sequences end-to-end across multiple AMM DEXs and exposes them as a shared dataset and API. This proposal builds on that existing work by reusing public DEX data and indexers, but focuses specifically on cross-DEX arbitrage as a first-class, ecosystem-wide phenomenon.

Describe what your prototype or MVP will demonstrate, and where it can be accessed.

Our prototype will be an open-source analytics engine and web dashboard that connects to Cardano mainnet and reconstructs arbitrage opportunities across major AMM DEX pools in real time. It will show historical and live arbitrage windows (which pools/DEXs were involved, when the opportunity opened and closed, and whether it appears to have been captured).

Describe realistic measures of success, ideally with on-chain metrics.

Because this is an analytics tool that reads Cardano rather than a new smart contract, success is best measured by how much DEX activity we cover, how well we explain arbitrage on-chain, and the signals we can observe directly from the blockchain and public research.

1. On-chain coverage & arbitrage visibility

Index and analyse swaps from all major Cardano AMM DEXs, covering a large majority of current DEX volume.

Continuously detect and label cross-DEX arbitrage opportunities, publishing relevant metrics.

Success: by the end of the project, the system is reliably processing mainnet blocks in real time and has produced a historical dataset of several months of DEX activity with arbitrage tags stored and queryable.

1. Research & ecosystem understanding

Today there is effectively no Cardano-specific public research focused on cross-DEX arbitrage behaviour. Within 12 months of project completion, we aim for at least one Cardano-focused research output (for example, a public report, blog series, or conference talk) that uses this dataset to analyse arbitrage patterns on Cardano.

1. Market behaviour & arbitrage activity

• Arbitrage bot builders on Cardano are not transparent, so we cannot reliably measure “number of bots using this tool”. Instead, we use on-chain arbitrage behaviour as an indirect signal.
• We will measure the share of monitored DEX volume that we can classify as belonging to arbitrage sequences. Using a pre-launch baseline window and a post-launch window, we consider it a success if observed arbitrage volume grows by roughly 20% over the first 6 months of continuous operation, indicating that more opportunities are being identified and captured.
• In parallel, we will track the distribution of “arb window duration” (how long opportunities remain open). A reduction in average duration over time, while the number of opportunities remains stable or increases, is another signal that markets are becoming more efficient and that better tooling is available to arbitrageurs.

While the tool itself is read-only, it directly targets behaviour that generates on-chain transactions: arbitrage. By making cross-DEX arbitrage opportunities visible and easier to analyse, we lower the barrier for existing and new arbitrageurs to operate on Cardano. Better tooling makes it cheaper to build and maintain bots, and safer to test strategies, which in turn is expected to increase the number of arbitrage sequences executed on-chain and the volume they move. Therefore one of our core success metrics is a ~20% increase in observed arbitrage volume (and shorter average opportunity windows) in the six months after the tool is live: if more opportunities are found and captured, that shows up directly as additional DEX swaps and paths on Cardano.

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

Arbitrage on Cardano AMM DEXs is visible on-chain but practically invisible to most users: prices move, pools rebalance, and bots act, yet there is no shared view of when an arbitrage opportunity opens, how long it lasts, and how it is eventually captured. Our solution is to turn this hidden behaviour into a clear, open, cross-DEX dataset and dashboard.

We will build an analytics engine that integrates all major AMM DEXs on Cardano under a single model. For each DEX, we will ingest pool states and swaps, normalise them to a common format, and continuously compute implied prices for supported trading pairs. On top of this unified view, we will implement advanced arbitrage spotting algorithms that scan for price discrepancies between pools and DEXs, taking into account fees and slippage. Whenever a mispricing reaches a configurable threshold, the system will log a new arbitrage opportunity: which tokens are involved, which pools and DEXs are misaligned, when the opportunity opened, and what theoretical profit was available.

From there, we track how the opportunity evolves. As new transactions hit any pool that touches the relevant token pair, we recompute prices and update the opportunity:

• if the trade increases the price gap, the opportunity is extended and its parameters are updated;
• if the trade reduces or closes the gap, we classify the opportunity as likely exploited or naturally closed, and link it to the transaction(s) that realigned the prices.

This creates a time series of arbitrage events: when they were created, how long they lived, which pools and DEXs they touched, and which on-chain transactions appear to have captured them. All of this logic will run on Cardano mainnet, with configuration to replay historical data as well.

On top of the engine, we will provide a web dashboard and basic API. The dashboard will let users explore historical and live arbitrage activity: filter by token, DEX, time window, or minimum size; drill into specific opportunities; and see the exact transactions that created and closed them. The API and data export formats will allow bot builders, DEX teams, and researchers to consume the same dataset programmatically if they wish, without having to rebuild the indexing and detection pipeline themselves.

Architecture: https://drive.google.com/file/d/12v9UWXUZLcn3BEfiM2C1yv2BjYh1qPs7

Our project primarily engages three groups:

• Builders and researchers, who can use the dataset to understand Cardano AMM behaviour, design strategies, or produce Cardano-specific research on market efficiency and arbitrage;
• DEX and infrastructure teams, who can use the cross-DEX view to compare their pools’ price efficiency and tune their designs;
• Curious traders and community members, who gain a transparent, educational window into how arbitrage actually works on Cardano, without needing to operate a bot.

We will demonstrate impact in two main ways. First, on-chain coverage: by the end of the project we aim to continuously monitor the majority of AMM DEX volume on mainnet and maintain a queryable history of arbitrage-tagged events over several months. Second, ecosystem understanding: we will use this dataset (or enable others to use it) to produce at least one Cardano-specific research output on arbitrage behaviour, and we will track changes in observed arbitrage volume and opportunity duration over time as indirect signals that better tooling is available to arbitrageurs.

What is unique about this solution is its cross-DEX, analytics-only focus. We are not building another trading or arbitrage bot, and we are not tied to a single DEX. Instead, we treat arbitrage as a first-class, ecosystem-wide phenomenon and expose it as shared infrastructure: an open-source engine, dataset, and dashboard that turn opaque, bot-only information into something that any project, researcher, or user can inspect and build on. This contributes to Cardano by improving transparency in DeFi, enabling more informed protocol design, and leaving behind reusable tooling that can support future research and products, even if adoption remains niche at first.

[Your Project and Solution] Impact

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

Arbitrage is one of the main forces that keeps AMM prices aligned, but on Cardano today it is effectively a “black box”: a small number of bots interact with pools, prices move, and everyone else only sees the end result. By turning this opaque behaviour into an open, cross-DEX dataset and dashboard, our project brings transparency, research capability, and better design signals to the wider Cardano community.

Value to the Cardano community

• Developers and researchers gain a ready-to-use dataset and engine for understanding how Cardano AMMs behave in practice: where opportunities appear, how long they last, and how they are captured across multiple DEXs. This lowers the barrier for new tools, strategies, and academic or industry research focused specifically on Cardano.
• DEX teams and infrastructure providers can compare their pools’ price efficiency to others and see how design choices (fees, curves, incentives) affect arbitrage activity and market health. This encourages more data-driven protocol design and can lead to better execution quality and UX for end users.
• Community members and traders get a clear, explorable window into arbitrage on Cardano without needing to run a bot themselves. This has educational value (explaining MEV and AMMs with real data) and can make Cardano DeFi more approachable for newcomers and cross-chain users who are evaluating ecosystems.

How we will measure impact

Because arbitrage bots are not transparent about their tooling, we focus on on-chain and research-based signals rather than UI clicks:

• On-chain coverage and visibility: we will monitor all major Cardano AMM DEXs and keep a queryable history of arbitrage-tagged events. We will track metrics such as opportunities per epoch, how many pools/DEXs each opportunity touches, and how long windows stay open before prices realign.
• Market behaviour: we will measure the share of monitored DEX volume that can be attributed to identified arbitrage sequences. Using a pre-launch baseline and a six-month post-launch window, we consider it a success if observed arbitrage volume increases by around 20% and average opportunity duration decreases, indicating that more opportunities are being identified and captured.
• Research and understanding: there is currently no Cardano-specific public research focused on cross-DEX arbitrage behaviour. Within 12 months of completion, we aim for at least one Cardano-focused research output (report, blog series, or talk) built on this dataset, either by the project team or external analysts. This becomes a citable resource for future builders and researchers.

How we will share outputs

All core outputs will be fully open source under a permissive license:

• A public GitHub repository containing the indexing/detection engine, configuration for each integrated DEX, and documentation on how to run the system against mainnet.
• A hosted reference dashboard where the community can explore historical and live arbitrage activity without deploying their own stack.
• Periodic summary posts (e.g. blog posts or forum entries) highlighting key insights: how often arbitrage happens, which tokens and DEXs see the most activity, and how behaviour changes over time.
• Links to the dataset, repo, and dashboard will be included in our Catalyst reports, in the final close-out report and video, and shared in relevant Cardano community channels (developer communities, DEX and DeFi spaces, and research-oriented groups).

To gather feedback and iterate, we will involve the Cardano community in four ways:

• Share early prototypes of the dashboard in relevant Cardano developer and DeFi channels, inviting DEX teams, bot builders and analysts to try it and open GitHub issues.
• Run a short feedback form linked from the dashboard, asking users which views or metrics are most useful and what’s missing.
• Publish at least one interim progress update (post or thread) with preliminary findings and explicitly ask for comments and use cases from the community.
• Reach out to Intersect’s Open Source Committee (OSC) to present the project as an open-source DeFi analytics tool, request collaboration in amplifying it through Intersect’s open-source channels and working groups, and explore whether it can be highlighted alongside other community-maintained tooling.

This lightweight engagement loop is enough for a one-person project while still ensuring that real users can influence which features and metrics we prioritise.

[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?

I’m proposing this as a one-person project, scoped to match what I already do day-to-day: Cardano DeFi backends, arbitrage tooling, and production analytics.

Over the last few years I have worked full-time as a Cardano DeFi / DEX engineer, building smart contracts and off-chain logic for liquidity pools and swaps, a production DEX frontend (swap UI, pool management, portfolio), indexing pipelines for on-chain data, and an arbitrage bot that monitors multiple Cardano DEXes and executes trades within defined risk limits. Before Cardano, I spent more than a decade at Microsoft Development Center Serbia as a full-stack / backend engineer and then senior engineer on Azure / Microsoft 365 services, delivering and operating web services used by millions of users. This mix maps directly to Argus Arbitrage: robust ingestion, pricing logic, arbitrage detection and a usable analytics UI.

Feasibility is de-risked by an incremental plan: start with one major AMM DEX, verify pool states and prices against public explorers, then extend to more DEXes and pairs; continuously link detected opportunities to real transaction hashes for spot-checks; and use historical replay over several months of mainnet data as both a feature and a stress test of the pipeline.

Trust and accountability come from keeping everything open and verifiable. The engine, schemas, and metrics scripts will live in a public repo under a permissive license; each milestone has concrete evidence (repo links, exports, logs, screenshots, metrics summaries); and the final wrap-up includes a written report and walkthrough video. Because the whole stack is open-source and reproducible, the wider Cardano community can inspect, reuse or extend the work, and Catalyst voters can independently verify what was delivered.

[Milestones] Project Milestones

Milestone Title

Core engine & first DEX ingestion

Milestone Outputs

Public GitHub repository created with project structure, open-source license, and initial README.

Ingestion service that reads Cardano mainnet blocks/transactions and extracts swaps and liquidity events for the first DEX.

Pool state store that keeps current reserves and fee parameters for pools on the first DEX.

Detection and logging of pool interactions (swaps, liquidity add/remove) for the first DEX into a persistent data store.

Acceptance Criteria

The GitHub repository is publicly accessible, contains a clear license (e.g. MIT/Apache-2.0), and a README that describes the project scope and how to run the ingestion service.

Running a single documented command (e.g. docker compose up or npm run ingest) processes at least 10,000 consecutive mainnet blocks without crashing, and extracts transactions relevant to the first DEX.

For at least 5 sample pools on the first DEX, the stored reserves and fees in the pool state store match the values visible on a public DEX UI or explorer at a given block height.

For at least 20 sample transactions, the logged pool interactions (type of interaction, token amounts, pool ID, tx hash) match what is visible on-chain and in the DEX UI.

Evidence of Completion

Link to the public GitHub repository (including license file and README).

Screenshot or log snippet showing the ingestion service processing at least 10,000 mainnet blocks and counting relevant DEX transactions.

Short markdown/CSV table in the repo comparing pool reserves/fees from the pool state store with values from a public DEX UI or explorer for the 5 sample pools.

Sample export (JSON/CSV) or screenshots showing 20 logged pool interaction events with their corresponding transaction hashes and a note on how they match on-chain data.

Delivery Month

3

Cost

60000

Progress

30 %

Milestone Title

Multi-DEX support & cross-DEX arbitrage detection

Milestone Outputs

Per-DEX adapters and configuration for each additional integrated AMM DEX (beyond the first one).

A unified data model for pools, prices, and interaction events across all integrated DEXs, with a single schema used by downstream components.

Price engine that computes per-pair effective prices (after fees) on each integrated DEX.

Cross-DEX arbitrage detection logic that identifies price discrepancies above a configurable threshold and logs “opportunity opened / updated / closed” events into the data store.

Acceptance Criteria

At least 3 AMM DEXs are integrated (including the first from Milestone 1), each with a configuration file/adapter and basic documentation in the repo.

The unified data model is documented and used consistently: the same fields (e.g. pool_id, base_asset, quote_asset, fee_bps, interaction_type) are present for interactions and pool states across all integrated DEXs.

For at least 10 token pairs that exist on multiple DEXs, the price engine can output current effective prices per DEX via a CLI or simple script, and these values align with on-chain / DEX UI prices within a small tolerance.

When the system is run on live or replayed data for at least one full epoch, it produces a log of cross-DEX arbitrage opportunities (with at least 50 detected events), including DEXs involved, token pair, theoretical profit, and timestamps for open/close.

Evidence of Completion

Repository documentation listing all integrated DEXs, with links to their adapter/config files.

Schema documentation (e.g. a markdown file or OpenAPI/JSON schema) describing the unified data model for pools, prices, and interactions.

Sample output (CLI screenshot or JSON file) showing per-DEX prices for at least 10 token pairs and a brief note confirming alignment with public DEX/explorer data.

Export (JSON/CSV) of arbitrage opportunity logs for at least one full epoch, demonstrating >50 cross-DEX opportunities with details on DEXs, token pairs, open/close times, and estimated profit.

Delivery Month

6

Cost

60000

Progress

60 %

Milestone Title

Historical indexing & baseline metrics

Milestone Outputs

Historical replay and indexing of DEX swaps and interactions across all integrated DEXs for at least 3 months of past mainnet data.

Stored arbitrage-tagged events (open/closed opportunities) for this period, including duration, size, and pools/DEXs involved.

Baseline metrics computed for the indexed period, such as: opportunities per epoch, average and median window duration, and share of monitored DEX volume associated with arbitrage sequences.

A short technical note or report (in the repo) describing the methodology used to define and compute these metrics.

Acceptance Criteria

Configuration or scripts exist to replay at least 3 months of historical mainnet data, and logs show successful processing of that time range without critical errors.

The arbitrage opportunity store contains historical records for the replayed period, with at least 1,000 opportunities logged (open/closed events) across all DEXs.

Metric computation scripts produce a summary for the replayed period, including:

• total number of opportunities,
• opportunities per epoch,
• average/median duration,
• estimated share of DEX volume linked to arbitrage paths.

The methodology document clearly explains how opportunities are defined, how sequences are linked to volume, and any thresholds or assumptions used.

Evidence of Completion

Logs or screenshots showing successful historical replay over the target 3-month period, including start/end dates.

Sample export (JSON/CSV) of historical arbitrage-tagged events showing at least 1,000 entries with timestamps and DEX/pool references.

A metrics summary file (e.g. baseline_metrics.md or baseline_metrics.json) in the repo with the required statistics for the indexed period.

Link to the methodology document in the repo explaining definitions and assumptions.

Delivery Month

8

Cost

30000

Progress

70 %

Milestone Title

Public dashboard, API & packaging

Milestone Outputs

Web dashboard that shows live and historical arbitrage opportunities with basic filters (e.g. by token, DEX, time window, minimum size).

Public API endpoints (REST or GraphQL) to query arbitrage opportunities and key metrics (e.g. /opportunities, /stats).

Dockerized or scripted deployment (e.g. docker-compose.yml and/or deployment scripts) to run the ingestion engine, database,

API, and dashboard together.

Updated documentation including:

• how to deploy the system,
• descriptions of API endpoints,
• basic usage examples (e.g. querying opportunities for a token pair).

Acceptance Criteria

The dashboard can be run locally (or in a simple hosted environment) and:

• displays a list of current/open opportunities,
• allows filtering by at least token and DEX,
• provides a detail view for an individual opportunity (showing pools, times, and related tx hashes).

The API exposes at least two read-only endpoints for opportunities and summary stats, returns JSON responses, and is documented in the repo.

A single documented command (docker compose up or similar) starts all core components (database, ingestion, API, dashboard) and connects them successfully.

Documentation includes at least one worked example of calling the API (via curl or a simple script) and interpreting the response for a specific token pair or time window.

Evidence of Completion

Screenshots or screencast of the dashboard running, showing filters and an opportunity detail view.

API documentation (OpenAPI spec or markdown) and example curl commands included in the repo, plus sample JSON responses.

Docker or deployment configuration files in the repo, along with a note describing the one-command startup process.

A short usage guide in the README or separate doc demonstrating an end-to-end flow: starting the stack, opening the dashboard, and querying the API.

Delivery Month

10

Cost

20000

Progress

80 %

Milestone Title

Project Wrap-Up & Community Handover

Milestone Outputs

A concise written project summary (PDF or markdown) that:

• recaps the original goals and scope of the project,
• reports on the main metrics and targets defined in the proposal (coverage, indexed period, number of opportunities detected, observed change in arbitrage activity),
• describes the current state of the codebase, dataset, and dashboard,
• outlines realistic options for further development or reuse by others.

A short recorded walkthrough video (screen capture with voiceover) that:

• shows the system running end-to-end (from ingestion to the dashboard),
• demonstrates exploring at least one real arbitrage opportunity in the UI,
• briefly explains the key findings and takeaways from the project.

Acceptance Criteria

The written summary document:

• clearly lists the main metrics/targets from the “Measures of Success” section and states whether each was fully achieved, partially achieved, or not achieved,
• includes a short explanation for any target that was not fully met (for example, limited time, market conditions, or technical constraints),
• provides direct links or instructions for accessing the public repository, deployment instructions, and any published dataset or export method,
• contains a section describing suggested next steps (maintenance, future features, or how third parties can build on top of the work).

The walkthrough video:

• visibly demonstrates the dashboard and core functionality (multi-DEX data, arbitrage opportunities, filters, details for a selected opportunity),
• mentions the main project outputs (engine, multi-DEX support, historical indexing, metrics, and public interface),
• is understandable by a non-expert Catalyst voter who wants to see what was actually delivered.

Evidence of Completion

A public link (for example, to the GitHub repository or a shared document service) to the final written summary document, referenced in the Milestone Module submission.

A public link (for example, YouTube or similar) to the walkthrough video, also referenced in the Milestone Module submission and accessible to the community.

Delivery Month

12

Cost

30000

Progress

100 %

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

Core engineering & research (~70%)

• Designing and implementing the ingestion pipeline, DEX adapters and unified pool model.
• Implementing price computation and cross-DEX arbitrage detection logic.
• Historical replay, tagging arbitrage events, computing metrics.
• Building the web dashboard, API, and deployment tooling.

Documentation, reporting & project management (~20%)

• Writing technical docs (README, architecture, API docs, usage guides).
• Milestone statements, Proof-of-Achievement submissions, and final close-out report.
• Preparing the final research-style analysis piece on arbitrage behaviour.
• Planning work per milestone and keeping scope aligned with the requested budget.

Community, infra & misc (~10%)

• Hosting costs (node/indexer access, database, dashboard backend, domain).
• Any paid API tiers if needed (e.g. indexer providers) during development and testing.
• Time to prepare and publish demo material (screenshots, short posts, final video).

[Final Pitch] Value for Money

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

The requested 200,000 ADA covers a 12-month full-time effort by a single specialist responsible for all aspects of the project: core backend, DEX integration, arbitrage detection logic, historical indexing, frontend/dashboard, documentation, deployment, and Catalyst reporting. There is no additional management, marketing or overhead team to fund.

For a full-time year (~2,000 hours), this corresponds to an effective rate of around $40/hour. That sits at the low end of typical professional blockchain developer rates, where multiple independent sources estimate experienced blockchain developers at roughly $41–$150/hour globally, with a worldwide average around $78/hour.

In other words, the requested budget is essentially a single senior-specialist year plus modest infrastructure costs (node/indexer access, a small database, and hosting for the reference dashboard/API), not an inflated multi-person team or agency bill. Paying an external blockchain development agency for a bespoke analytics project of similar scope would very likely land in the same or higher cost bracket, often with separate line items for project management and profit margin.

From the ecosystem side, the project delivers shared infrastructure rather than a one-off app:

• A reusable multi-DEX ingestion and normalization engine for Cardano AMM pools.
• A cross-DEX arbitrage detection pipeline that tags opportunities and their lifetimes directly from on-chain data.
• A historical dataset and metrics describing arbitrage behaviour on Cardano over several months.
• A public dashboard and API that anyone can build on (arbitrage bot builders, DEX teams, researchers, educators).
• At least one Cardano-specific research/analysis output on cross-DEX arbitrage, which currently does not exist in the ecosystem.

All of this is released as open-source code and open data, so the value is not limited to one product instance: DEXs, analytics teams, or arbitrage bots can quietly reuse the engine and metrics, and future research or tooling can be built on top of the dataset without re-implementing the heavy lifting.

Given that:

• the budget roughly matches a modest full-time blockchain engineer salary rather than a premium multi-vendor contract,
• the outputs form a long-lived, reusable analytics and research layer for Cardano DeFi, and
• the work is fully open-sourced and documented for others to pick up even if adoption is initially niche,

this project represents a cost-efficient way to fund a year of focused protocol-level tooling and data work that the wider Cardano ecosystem can benefit from over time.

[Self-Assessment] Self-Assessment Checklist

I confirm that evidence of prior research, whitepaper, design, or proof-of-concept is provided.

Yes

I confirm that the proposal includes ecosystem research and uses the findings to either (a) justify its uniqueness over existing solutions or (b) demonstrate the value of its novel approach.

Yes

I confirm that the proposal demonstrates technical capability via verifiable in-house talent or a confirmed development partner (GitHub, LinkedIn, portfolio, etc.)

Yes

I confirm that the proposer and all team members are in good standing with prior Catalyst projects.

Yes

I confirm that the proposal clearly defines the problem and the value of the on-chain utility.

Yes

I confirm that the primary goal of the proposal is a working prototype deployed on at least a Cardano testnet.

Yes

I confirm that the proposal outlines a credible and clear technical plan and architecture.

Yes

I confirm that the budget and timeline (≤ 12 months) are realistic for the proposed work.

Yes

I confirm that the proposal includes a community engagement and feedback plan to amplify prototype adoption with the Cardano ecosystem.

Yes

I confirm that the budget is for future development only; excludes retroactive funding, incentives, giveaways, re-granting, or sub-treasuries.

Yes

[Required Acknowledgements] Consent & Confirmation

I Agree

Yes