[Proposal setup] Proposal title
Please provide your proposal title
Datum Explorer: Smart, Clean, Human-Readable On-Chain Data
[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
9
[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?
Hard-to-read CBOR datums waste developer and auditor time and cause subtle bugs. Datum Explorer helps, but lacks Blueprint support, rich schemas, and deep integration into dev tools.
[Proposal Summary] Supporting Documentation
Supporting links
[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 dependencies
[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 License
[Theme Selection] Theme
Please choose the most relevant theme and tag related to the outcomes of your proposal
Developer Tools
[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).
Existing tools for viewing CBOR data only display decoded field values, without showing field names. For more complex datums, developers must manually consult the datum definitions and match values to fields based on their positions - a tedious and error-prone process.
Our approach improves on this: while the current version of Datum Explorer provides some assistance, it struggles with common patterns, doesn’t leverage Plutus Contract Blueprint, supports only a limited set of schemas, and still requires a separate, minimal UI. Our solution addresses these limitations, making CBOR decoding more accurate, intuitive, and integrated.
In addition, most existing tools are standalone utilities rather than shared, composable infrastructure. Each project solves datum decoding in its own codebase, leading to duplicated effort, inconsistent UX, and fragmented standards. By focusing on an open-source library and shared schema/blueprint registry that wallets, explorers, and dApps can all integrate with, Datum Explorer turns datum decoding into a common, reusable layer. Improvements contributed by one team immediately benefit the entire ecosystem, making Cardano datum tooling more collaborative, consistent, and sustainable over time.
Describe what your prototype or MVP will demonstrate, and where it can be accessed.
Our prototype demonstrates a fully functional CBOR decoding tool that maps field values to their corresponding names using Plutus Contract Blueprint and extended schemas. Users can explore complex datums with an intuitive, integrated interface, eliminating the need for manual field matching.
The new features will be deployed into the existing application that is already accessible here: https://datum-explorer.wingriders.com/?schema=detect
Open-source code and documentation will be updated in the existing repository: https://github.com/WingRiders/datum-explorer
Describe realistic measures of success, ideally with on-chain metrics.
Since Datum Explorer is a tool for viewing and analyzing CBOR data, realistic measures of success focus on usage, adoption, and impact rather than on-chain metrics. These can include:
- Library & Schema Usage: Number of Blueprint schemas added to the public registry and the number of pull requests successfully validated through the CI workflow, including usage of comment-based directives in the schemas (Milestone 1).
- Feature Adoption: Adoption of enhanced display features specified in the schemas, such as bech32 address formatting, token tickers, and tooltips (Milestone 2).
- Library Distribution: Number of downloads of the Datum Explorer library.
- Outreach & Visibility: Marketing impact measured by published demo videos, social posts, and documented outreach to ecosystem teams (Milestone 4).
- Quality & Reliability: Successful unit test coverage, CI workflow validations, and resolution of bugs or errors in the codebase (Milestones 1–3).
Together, these metrics demonstrate that the tool is being used effectively, provides tangible productivity improvements for developers, and achieves its goals in the ecosystem—even without direct on-chain interactions.
[Your Project and Solution] Solution
Please describe your proposed solution and how it addresses the problem
The existing version of Datum Explorer streamlines interaction with Cardano datums by decoding CBOR data into human-readable formats based on schema definitions. Our project will elevate this tool into a full-featured platform for inspecting and interacting with on-chain data, accessible to both developers and non-technical users. The upgrade will focus on advanced display features, developer ergonomics, a browser extension, and community-driven schema support. It will also expand integration pathways, notably with Plutus Contract Blueprint integration. These enhancements will boost transparency, accelerate development workflows, and make datums easier to understand and work with across the Cardano ecosystem.
We will deliver these seven new features for the Datum Explorer:
- CIP-0057 Plutus Contract Blueprint integration: Modern smart contract toolchains (Aiken, Plinth, Plutarch, etc.) automatically produce a Plutus Contract Blueprint (plutus.json) as defined in CIP-0057. This file contains machine-readable type definitions for all datums and redeemers. Integrating Blueprint support eliminates the need for developers to manually write schemas in CDDL. This is a critical step for ecosystem adoption: once schemas are automatically generated from smart contract code, any project can contribute its schema to the public registry with no extra work, ensuring consistent, up-to-date datum definitions across the ecosystem.
- Chrome extension for parsing datums on any website:A Google Chrome extension adds a “Parse Cardano datum” option to the context menu whenever a user highlights a datum. Clicking it opens a side panel showing the decoded, structured datum inline, letting users explore datums directly in any web app, including wallets, explorers, and dApps, without switching tools.
- Custom rendering of common data structures:Common constructs like addresses, transaction hashes, and tokens will be shown in intuitive formats. Spending+staking credentials appear as bech32 addresses (clickable/copyable), transaction hashes link directly to explorers, and policyId+assetName are displayed as token tickers with quantities formatted according to decimals from the token registry. Users and projects can customize these displays via schema annotations or UI preferences.
- **Light/dark mode toggle: **A simple UI feature allowing users to switch between light and dark themes, improving readability in different environments.
- **Structured highlighting on hover:**When hovering over fields in the decoded view, the corresponding segment in the raw CBOR will be highlighted with a color-coded palette. This bridges the gap between the binary and semantic representations.
- **Comments as tooltips: **Comments embedded in CDDL schema definitions and Aiken code (“description” field in plutus.json) will be extracted and displayed as tooltips, helping users understand the meaning of specific fields at a glance.
- **Improved error handling and diagnostics: **Decoding errors will be surfaced with clarity, pinpointing the exact byte location. This improves usability for schema authors and developers troubleshooting malformed data.
This upgrade will position Datum Explorer as an indispensable tool for Cardano developers and projects requiring clarity and precision in their on-chain data workflows.
Technical Approach (Outline)
This section provides a brief overview of the technical approach to the implementation of the new Datum Explorer features. The full document can be found in the proposal supporting documentation.
1. Blueprint Integration
Enable first-class support CIP-0057 Plutus Contract Blueprint (plutus.json produced by e.g., aiken build).
Goals
- Parse Plutus Contract Blueprint → convert to BlueprintDatumAst[]
- Implement matching CBOR with BlueprintDatumAst similarly how it currently works for CddlAst
- Preserve schema metadata (description fields) from blueprints where possible
- Keep backend caching unchanged (serve JSON same way as CDDL)
Technical details
- Registry
- Allow JSON files to be present in the same folder structure as CDDL files.
- Enforce uniqueness of base file names. So there cannot be .json and .cddl in the same folder.
- Validate Blueprint schema files in CI for pull requests.
- Library
- Implement Blueprint parser module
- Validate Blueprint schema file (required sections: validators, datums, redeemers, definitions)
- Convert extracted types → BlueprintDatumAst[]
- Expose AST and diagnostics via the same API used for CDDL
- Frontend
- Detect .json extension and invoke Blueprint parser
- CLI
- Accept .json blueprint files as input along with datum title and CBOR to produce ReadableDatum
- Testing
- Add canonical Blueprint samples to registry test fixtures
- Unit tests for Plutus Contract Blueprint → BlueprintDatumAst[] transformations
Mockups
https://raw.githubusercontent.com/WingRiders/datum-explorer/refs/heads/main/extensions/mockups/1-blueprint-integration.png
2. Custom Display of Data Structures
Introduce a pluggable rendering layer enabling more intuitive visualization of common Cardano structures.
Examples of enhanced representations
- Address:
- Convert payment/stake credential hashes → bech32.
- Display clickable explorer link for the address.
- Customizable explorer in user settings (Cexplorer/Cardanoscan).
- Provide copy-paste button.
- Robust enough to recognize non-standardized ways of encoding addresses if used in existing datum definitions in the registry.
- TxHash:
- Display clickable explorer link for the transaction
- Customizable explorer in user settings (Cexplorer/Cardanoscan)
- Provide copy-paste button
- Token ticker:
- Convert policyId/assetName into ticker.
- We need to distinguish between policyId and assetName without relying on the field name. Both are of type “bytes”.
- Currency units:
- Respects token decimals.
- Convert quantity/policyId/assetName into formatted quantity of a token.
Configuration sources
- Schema-defined metadata
- CDDL: add a comment-based directive @displayAs.
- Blueprint: “description” field, which is populated by compiling Aiken code with comment before the field.
- User preferences
- Rich display toggle in UI (similar to dark/light mode)
_Mockups _https://raw.githubusercontent.com/WingRiders/datum-explorer/refs/heads/main/extensions/mockups/2-custom-display.png
3. Light / Dark Mode Switch
A simple UI improvement with a global theme toggle.
Implementation
- Tailwind or Next.js Theme provider.
- LocalStorage persistence.
- The default value is set based on the system theme.
- Does not affect backend or library.
Mockups
https://raw.githubusercontent.com/WingRiders/datum-explorer/refs/heads/main/extensions/mockups/3-app-theme.png
4. Tooltips
Enrich the ReadableDatum UI with tooltips taken from comment-based @tooltip directive in the schema.
- Attach them as metadata to corresponding nodes in ReadableDatum.
- Display them as tooltips in the frontend.
- Hovering over the (?) icon next to a field in the decoded datum shows the tooltip.
Mockups https://raw.githubusercontent.com/WingRiders/datum-explorer/refs/heads/main/extensions/mockups/4-tooltips.png
5. Highlight on Hover
A major developer-experience enhancement. When hovering over:
- a field in the ReadableDatum → highlight the corresponding byte slice in the raw CBOR
- a byte region in the raw CBOR → highlight the field in the ReadableDatum.
Technical work
- Fork cbor-x library and expose byte offset metadata in the decoded structure.
- Extend the matching engine to expose byte offset metadata:
- For each node in ReadableDatum, include {start, end} offsets.
- Frontend binds mouse events to corresponding slices.
- Use color palettes for multi-level nesting.
Reuse by ecosystem
Since ReadableDatum is exposed in the lib, the start/end offsets are available for use in:
- wallets
- explorers
- other debugging tools
_Mockups _https://raw.githubusercontent.com/WingRiders/datum-explorer/refs/heads/main/extensions/mockups/5-highlight-on-hover.png
6. Improved Error Handling
Enhance both CLI and UI with precise decoding errors. This feature is also fully reusable by external tooling (wallets, explorers, DApps).
Features
- Byte-level highlight of where decoding failed.
- Human-readable messages:
- “Unexpected type: expected list, got integer”
- “Missing field X at this location”
- Link error to CBOR byte slice.
Library-level changes: Matching engine will return error objects enriched with cborOffset.
_Frontend: _
- Highlight the exact portion of CBOR causing the issue.
- Display tooltip or side panel with explanation and path to the field causing the error.
Mockups: https://raw.githubusercontent.com/WingRiders/datum-explorer/refs/heads/main/extensions/mockups/6-error-handling.png
7. Chrome Extension: “Parse Cardano datum”
Key capabilities
- Detects user selection on a webpage (hex/CBOR base16 string).
- Add a right-click context menu action: “Parse Cardano datum”.
- Launch a side panel using the existing WASM-based decoder.
- Use endpoints from the hosted Backend.
[Your Project and Solution] Impact
Please define the positive impact your project will have on the wider Cardano community
Datum Explorer is already being used by developers and auditors in transaction analysis workflows. With these upgrades, we will broaden its applicability to wallets, explorers, and general dApp users. Enhanced tooling fosters ecosystem transparency, streamlines developer workflows, and boosts adoption of schema-driven datum standards. We’ll track adoption through usage metrics, community feedback, and the number of projects integrating the tool into their own workflows.
Developers & Auditors– Gain access to schema-driven decoding directly in their existing workflows, with faster integration options for local testing and live analysis. This reduces time spent on manual decoding and increases accuracy.
Wallet Providers – Can integrate datum decoding directly into wallet interfaces, enabling users to understand transaction details without leaving the app, improving UX and trust.
Blockchain Explorers – Benefit from an API and registry that can be embedded into explorer views, giving end users deeper insight into on-chain data without requiring specialized tools.
dApp Teams – Can use the upgraded registry to ensure their datums are consistently interpretable across the ecosystem, making onboarding for new users smoother and reducing support overhead.
End Users – Gain better visibility into what’s happening with their transactions, through wallets and explorers that integrate Datum Explorer, fostering transparency and confidence in using Cardano dApps.
Ecosystem Standards & Community – Expanded schema adoption drives standardization, improving interoperability and reducing fragmentation across projects building on Cardano.
[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?
The WingRiders engineering team (authors of Datum Explorer) has extensive experience in developing blockchain tooling, including hardware wallet integrations and smart contract interfaces. The proposed features are incremental and build on existing architecture, ensuring technical feasibility. Feature scoping is structured to allow flexibility in prioritizing the most valuable enhancements while maintaining delivery within scop
[Milestones] Project Milestones
Milestone Title
Blueprint integration
Milestone Outputs
- Library extended with CIP-57 Plutus Contract Blueprint parsing and matching with CBOR.
- Registry containing Blueprint schemas.
- App capable of parsing CBOR using a selected Blueprint schema.
- App capable of parsing CBOR using auto-detected Blueprint schema.
- Unit tests covering Blueprint schema parsing, validation, and matching logic.
- CI pipeline for the registry repository that automatically validates Blueprint files on every pull request.
Acceptance Criteria
- The library can successfully:
- load and parse CIP-57 Blueprint files.
- match a datum CBOR payload using a Blueprint schema (manual + auto-detection).
- produce a structured, human-readable representation based on the Blueprint schema.
- The public registry:
- contains at least one Blueprint schema file.
- has an active CI workflow validating all Blueprint files on every incoming PR.
- The app UI:
- Allows selecting a Blueprint schema from the registry and parsing CBOR with it.
- Automatically detects the correct Blueprint schema for a given CBOR payload and displays the parsed structure.
- Unit tests cover:
- parsing of Blueprint schema files.
- Blueprint schema validation.
- end-to-end parsing of CBOR into typed structures defined in the Blueprint.
Evidence of Completion
- Link to the code in a public repository showing implementation of Blueprint integration.
- Link to the public registry containing Blueprint schemas.
- Link to the CI workflow configuration verifying Blueprint schema validity in PRs.
- Video demonstrating app being capable of parsing CBOR with:
- a manually selected Blueprint schema
- auto-detected Blueprint schema
- Link to automated test results confirming successful Blueprint schema parsing and matching.
Delivery Month
2
Cost
60000
Progress
30 %
Milestone Title
Advanced data display & presentation features
Milestone Outputs
- Custom display of data structures
- Pluggable rendering layer for enhanced visualization of:
- Addresses: bech32 conversion, explorer links, copy button.
- TxHashes: clickable links, copy button.
- Tokens: policyId/assetName → ticker via backend-cached mainnet + testnet token registries.
- Currency units: amount formatting with token decimals; Lovelace → ADA.
- Support for metadata directives from:
- CDDL comments
- Blueprint description field (generated from Aiken comments)
- Rich display toggle in user settings.
- Updated documentation and workflow diagrams.
- Light / Dark Mode
- Global theme switch using Tailwind/Next.js provider.
- LocalStorage persistence and system-theme default.
- Tooltips
- @tooltip directive parsed into ReadableDatum.
- Tooltip UI with hoverable “?” icon.
Acceptance Criteria
- Custom display of data structures
- The library correctly interprets all display-related directives from CDDL and Blueprint.
- Frontend renders actionable enriched data:
- bech32 addresses (copy + explorer link)
- tx hashes (copy + explorer link)
- token tickers from merged token registry
- correctly formatted amounts using token decimals
- Backend successfully fetches, merges, and caches mainnet + testnet token registry data and exposes them to the frontend.
- Users can enable/disable rich display and select the default explorer.
- Light / Dark Mode
- Theme toggle works globally across the app.
- Theme preference persists in LocalStorage and respects system default on first load.
- UI components correctly switch styles in both modes.
- Tooltips
- @tooltip directives are parsed into the structured datum.
- Tooltip metadata appears in the correct fields of ReadableDatum.
- Frontend displays tooltips on hover using the “?” icon.
Evidence of Completion
- Link to the code in a public repository containing the changes
- Link to the screenshots/video showcasing the changes
- Link to the tests results in the open source GitHub repository
Delivery Month
4
Cost
60000
Progress
60 %
Milestone Title
Highlighting, Error Handling & Chrome Extension
Milestone Outputs
- Highlight on Hover
- Linked visual highlighting between ReadableDatum fields and raw CBOR byte slices.
- Forked cbor-x library with exposed byte-offset metadata.
- Matching engine extended to include { start, end } byte offsets on ReadableDatum nodes.
- Multi-level color palette for nested structures.
- Improved Error Handling
- Byte-level pinpointing of decoding errors in UI.
- Human-readable error messages (“expected list, got integer”, “missing field X”, …) explaining the error and field path
- Error objects enriched with cborOffset: { start, end } and failure path for easy integration by 3rd-party tools.
- Chrome Extension: “Parse Cardano datum”
- Chrome Manifest V3 extension integrating with Datum Explorer.
- Right-click context menu: Parse Cardano datum.
- Side panel rendering the decoder UI
Acceptance Criteria
- The system supports Highlight on Hover:
- Hovering a field in ReadableDatum highlights the exact { start, end } CBOR byte slice.
- Hovering a CBOR byte slice highlights the corresponding ReadableDatum field.
- All decoded nodes include offset metadata supplied by the forked cbor-x decoder and extended matching engine.
- Nested structures use a multi-level color palette without ambiguity.
- The system provides Improved Error Handling:
- Decoding and schema-matching errors pinpoint the exact failing byte range.
- The UI displays clear, human-readable explanations (e.g., expected list, got integer, missing field X).
- Error objects include cborOffset and full failure path, exposed publicly for 3rd-party integration.
- The UI highlights the failing CBOR slice and links it to the corresponding field or schema node.
- The Chrome Extension: “Parse Cardano datum” is fully functional:
- Right-clicking shows “Parse Cardano datum”.
- Selected CBOR is parsed using backend schema endpoints and displayed in a side panel.
- The UI in the side panel matches the main app decoder.
- Works under Manifest V3 without service workers; runs only on user interaction.
Evidence of Completion
- Link to repository commits showing:
- fork and modification of the cbor-x decoder exposing byte offsets
- matching engine changes adding { start, end } metadata to ReadableDatum
- UI updates implementing hover-linked highlighting and nested color palettes
- enriched error objects with cborOffset and failure path
- frontend components rendering byte-level error highlights
- Chrome extension implementation (Manifest V3, context menu, side panel UI)
- Demo video demonstrating:
- hover over ReadableDatum → highlights raw CBOR slice
- hover over CBOR → highlights ReadableDatum field
- decoding error view showing highlighted failing bytes and human-readable message
- Chrome extension parsing selected CBOR from any webpage and displaying it in the side panel
- Automated test results covering:
- propagation of byte offsets through the decoder and matching engine
- correct linking between metadata nodes and UI highlighting
- error object construction (offsets + failure path)
- extension content-script detection of selected hex
- Chrome Web Store (unlisted) build or packaged ZIP of the extension proving it is functional and installable.
Delivery Month
7
Cost
30000
Progress
80 %
Milestone Title
Community Engagement
Milestone Outputs
- Updated project documentation for developers, including the (README, architecture overview and practical examples).
- Short demo videos showcasing key features such as decoding, highlighting, tooltips and the Chrome extension.
- A minimum of five public posts across social platforms, including X, Discord and CoinMarketCap Community.
- Direct outreach to at least three Cardano ecosystem teams, including wallet providers, explorers and dev tooling teams, with scheduled meetings and collected feedback on whether they use the tool, plan to use it or, if not, their reasons for not adopting it.
- A public community survey, distributed both openly and directly to contacted teams.
- Effort invested in contacting the Intersect Open Source Committee to explore potential support processes and opportunities to increase tool adoption.
Acceptance Criteria
- Updated documentation available in the public GitHub repository.
- At least five public posts published across X, Discord and CoinMarketCap.
- Confirmed outreach to at least three ecosystem teams, with scheduled meetings and fully documented feedback regarding current or planned usage of the tool, including reasons if they decide not to adopt it.
- All demo videos published and accessible to the public.
- Public community survey completed, with results categorized and shared with the community.
- A transparent summary of the collected feedback from meetings and surveys, including positive, neutral and negative input.
- Documented attempt to connect with the Intersect Open Source Committee, along with any guidance or outcomes if provided.
Evidence of Completion
- Links to the updated developer documentation in the GitHub repository.
- Links to all published demo videos.
- A list of contacted ecosystem teams (wallets, explorers, tooling), accompanied by meeting notes and a summary of collected feedback.
- Link to the sample integration repository (if applicable).
- A final Community Engagement report containing screenshots and links to all public posts, survey results and a summary of all collected feedback.
- A published note documenting the attempt to engage with the Intersect Open Source Committee and any guidance received.
Delivery Month
8
Cost
20000
Progress
90 %
Milestone Title
Project Close-out Report and Project Close-out Video
Milestone Outputs
- A 2–3 page Project Close-out Report summarizing the results of the Datum Explorer upgrade project
- A section outlining the challenge KPIs and how the project addressed them
- A section listing the project KPIs and how each KPI was met or why adjustments were made
- A summary of key achievements, with emphasis on collaboration, ecosystem engagement and developer adoption
- A measurable impact overview, including usage indicators, Blueprint schema contributions, integration feedback from ecosystem teams and improvements in developer workflows
- A short written explanation of why the project matters and why the Cardano community should be excited about the results
- A set of links to all relevant sources and documents, including the upgraded repo, documentation, demos and registry resources
- A publicly available Close-out video (2–5 minutes) summarizing achievements, demonstrating the upgraded Datum Explorer (Blueprint support, enhanced visualization, error diagnostics, highlight features, Chrome extension) and outlining next steps
- A technical walkthrough inside the video showing the functioning tool and clear evidence of Catalyst-funded deliverables
- A final Community Engagement report containing screenshots and links to all public posts, survey results and a summary of collected feedback from outreach meetings, developer teams and ecosystem contributors
Acceptance Criteria
- The 2–3 page Project Close-out Report is completed and publicly accessible
- The report includes challenge KPIs, project KPIs, achievements, measurable impact data, and next-step plans
- All relevant links and documentation (repo, docs, demos, registry) are included and accessible
- A high-quality Close-out video (720p/1080p) is published publicly on YouTube
- The video clearly demonstrates the upgraded Datum Explorer and shows evidence of features developed with Catalyst funding
- The final Community Engagement report is published and accessible, including screenshots, outreach notes and survey results
Evidence of Completion
- A public link to the 2–3 page Project Close-out Report
- A public link to the Close-out video on YouTube
- Public links to all documentation, repositories, demos, and related resources
- A link to the Community Engagement report containing survey results, summaries of feedback gathered from ecosystem teams, and all public announcements/posts
Delivery Month
9
Cost
30000
Progress
100 %
[Final Pitch] Budget & Costs
Please provide a cost breakdown of the proposed work and resources
Milestone 1: Blueprint integration
- Milestone Budget: ₳ 60,000
- Resource MDs:
- Software engineer (senior & junior): 60
- Project manager: 6
Milestone 2: Advanced data display & presentation features
- Milestone Budget: ₳ 60,000
- Resource MDs:
- Software engineer (senior & junior): 60
- Project manager: 6
Milestone 3: Highlighting, Error Handling & Chrome Extension
- Milestone Budget: ₳ 30,000
- Resource MDs:
- Software engineer (senior & junior): 30
- Project manager: 3
**Milestone 4: Community Engagement **
- Milestone Budget: ₳ 20,000
- Resource MDs:
- Marketing: 10
- Business development: 10
- Project manager: 10
Final Milestone: Close-out report sample video
- Milestone Budget: ₳ 30,000
- Resource MDs:
- Software engineer: 10
- Marketing: 20
- Project manager: 10
[Final Pitch] Value for Money
How does the cost of the project represent value for the Cardano ecosystem?
By enhancing a live and actively-used open-source tool, we minimize overhead and ensure that each improvement delivers immediate ecosystem value. Features are prioritized for high impact, supporting developers, auditors, wallets, and explorers. Our commitment to open-source licensing guarantees that all outputs will be freely available for the Cardano community.
[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