Blaze: Maintenance, Security Improvements, Testing & Assurances for the Blaze SDK

[GENERAL] Name and surname of main applicant

[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language

[GENERAL] Summarize your solution to the problem (200-character limit including spaces)

We are building a typescript SDK which we ambitiously intend to be the flagship developer tool of Cardano, we will invest these funds to appropriate improvements, test suites, code analysis of blaze.

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

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies.

[GENERAL] Will your project’s output/s be fully open source?

[GENERAL] Please provide here more information on the open source status of your project outputs

Blaze is an open source project and will remain open source for it's entirety, all work in this catalyst proposal will be open-source in the same repository at https://github.com/butaneprotocol/blaze-cardano

https://www.npmjs.com/package/@blaze-cardano/sdk

[SOLUTION] Please describe your proposed solution

The necessity for Blaze comes from these requirements while building a DeFi web app:

• Transaction construction is a crucial component of Cardano DeFi
• Want to do tx building in the browser (must deploy to JS or WASM)
• Dependency on wasm tooling is unideal for ergonomic reasons, known in javascript community
• Want a tool which is entirely procedural, making certain optimisations such as output ordering easier & more efficient to accomplish
• A tool with a focus on developer experience (packaging, well typed API)

How Blaze differs from other typescript apis is the low-level usage of cardano-js-sdk, which we use for types and serialisation, it's packaging, and it's manual control over various low-level transaction construction. Blaze is the only lucid-alternative with procedural-style construction to build in this way, taking great consideration of developer experience through the lens of decentralised finance.

By having dedicated funding to make various improvements in this area we can make Blaze a production-ready system (indicated by a 1.0.0 semver release), where it can be used in serious DeFi projects.

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

DeFi applications will heavily consider security among other aspects, if there is major adoption of the SDK for development of smart contracts and then also for deployment of frontends, this will be a win for the ecosystem because of the saved resources. When the library is used, projects should be relying on it for testing purposes as well as runtime.

[CAPABILITY & 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 Butane team has demonstrated itself as one of the top development teams in Cardano, producing a highly well-received protocol testnet and yellowpaper which has encouraged community and developer confidence in their technical merit. Blaze, in its current state, already offers a clean and efficient transaction building SDK and emulator that is being integrated within Butane to be used as the protocol's off-chain component.

Given the project is open source and has utility to effectively all developers on Cardano, the intention is to gather feedback from the developer community to shape Blaze into a highly efficient and usable platform for building applications on.

[PROJECT MILESTONES] What are the key milestones you need to achieve in order to complete your project successfully?

Milestone 1: Comprehensive and Polished Base SDK

A: Milestone Outputs

• Working and validated implementations of various chain providers (e.g. Blockfrost, Maestro, e.t.c.)
• Utility functions for interacting with the chain in a safe and ergonomic manner as transactions are built and queried
• A clean, consistent, and battle-tested SDK for building and submitting transactions, and for querying the chain

B: Acceptance criteria

The milestone will be accepted when Blaze has implemented functionality in a manner satisfactory for a first major release

C: Evidence of milestone completion

The evidence of milestone may be analysed by reading the codebase at the GitHub link or by reading through the documentation page at https://blaze.butane.dev, which will have relevant examples. Users can also examine Blaze's various published packages.

Milestone 2: Checks & Tests Regarding Transaction Construction with In-Build Safety Features

A: Milestone Outputs

There will be checks added to transaction construction and/or analysis of code to give assurances that:

• the transaction is not being reused (preventing bugs around shared references to txs), mainly preventing errors around the completion phrase.
• value is not unintentionally lost, whether through change accidentally going to wrong output, or mis-burning assets when not specified.

There will additionally be tests around transaction construction which attempt to:

• pass invalid types through (if typescript is used incorrectly?)
• identify problems around UTxO selection
• identify issues with change setting, to assure that users assets are never lost

From a developer experience standpoint, literate error messages should accompany the checks. Where code is analysed, logical explanations will be attached in comments / documentation to show where consideration has been placed. Other various additional tests/criteria may be identified & added to this milestone, within the general topic.

At the end of this milestone, version 1.0.0 of Blaze packages should be ready to publish and release.

B: Acceptance criteria

There are new documentation around the milestone outputs, such as comments, there are new branches for the aforementioned assurances in the code, and there are new test files. General basic use of the API shouldn't be vulnerable to the problems addressed.

C: Evidence of milestone completion

Will require reading the published codebase on GitHub and published packages.

Final Milestone: First Full Release and Repository Set Up for Longevity

A: Milestone Outputs

• A well-organised, active, and maintained GitHub monorepo for Blaze
• Extensive developer documentation, user guides, tutorials, contribution guides, e.t.c.
• Integration of new features, providers, e.t.c. as they release and are deemed appropriate
• Public task-boards and roadmaps in adherence with open-source principles (i.e. GitHub Projects)

B: Acceptance criteria

• Blaze regularly sees active issues, pull requests, releases, and other relevant activity
• The packages remain up-to-date and any issues/bugs are responded to with satisfactory speed
• Project plans are communicated and well set-up in a public forum such as GitHub Projects

C: Evidence of milestone completion

The Blaze GitHub repository will be where most activity occurs, so users and developers are encouraged to monitor progress there.

[RESOURCES] Who is in the project team and what are their roles?

Micah Kendall - programmer, initiated blaze project.

Jay Taylor - programmer

We will take this project as the team of butane (https://butane.dev), recruiting more developers where appropriate using the budget.

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources

All costs of the project go towards manpower costs (contracted / employed developers) and other relevant costs for hosting and maintaining a public GitHub repository.

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

We are asking for significantly less than a full time developer would cost us, for approximately a year, to build & maintain a tool that will likely require more than one single developer, and which we expect to maintain for longer.