Total to date

[GENERAL] Name and surname of main applicant

[GENERAL] Email address of main applicant

Additional applicants

Jonathan Rodriguez

Mladen Lamesevic

TxPipe

Demeter

[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] 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] If NO, please describe which outputs are not going to be open source. If YES, please write “Project will be fully open source.”

Project will be fully open source.

[METADATA] Category of proposal

[IMPACT] Please describe your proposed solution.

The Cardano DApp ecosystem lacks open-source production-grade code, particularly evident in the closed-source nature of the top three Cardano DEXs. Due to limited information sharing between development teams, redundant work, such as the similar improvements to the batcher architecture, is being performed independently by each DEX. This is especially an issue if a new development team from a different ecosystem wants to launch a DEX (or project of a similar scale) in Cardano. Right now, on Cardano, a new team would only be able to find a few very brief technical articles going over the batcher architecture, and the outdated MinSwap codebase (written in Plutus V1 and a very small amount of Plutarch V1). The team would need to invest a considerable amount of capital to even get started with development using that information as a reference, and after all that money and time, the result would be a product that is similar to or even inferior to the existing closed-source applications. In contrast, on Ethereum a team that is new to the ecosystem can see the entire UniSwap codebase complete with architecture, design, implementation, security practices, and contract optimization techniques. If the ecosystem had more readily available production code, then all that time and money could go towards improving existing architectures / implementations and further the ecosystem as a whole, as opposed to how it is now where it has to be dedicated to playing catch up with closed source projects. 

To address this issue, we are committed to providing the community with five versatile production level open-source smart contract libraries. These libraries showcase best practices for smart contract design and architecture, security and unit testing, and optimization techniques and tricks. These libraries are designed to be composable, enabling them to be utilized as essential components for other smart contracts. Our approach includes releasing the libraries on GitHub with both the source code and compiled plutus scripts, eliminating the need for users to set up a development environment.

Merkle Tree Contracts

• Efficiently verifies data integrity and enables fast proof verification in large datasets.
• updatable multisig contracts
• Enables multiple parties to jointly manage and approve transactions, enhancing security and decentralization.

Single Asset Staking Contracts

• Facilitates collective staking of digital assets and distributes rewards among participants.

Linear Vesting Contracts

• A secure linear vesting contract with customizable parameters.

Bridge Contracts

• Facilitates communication and interoperability between different blockchain networks, enabling the transfer of assets and data

Yield Farming Contracts 

• A library to simplify the creation of yield farming pools

Furthermore, we prioritize the reliability and functionality of our smart contracts by subjecting them to rigorous user testing. This ensures that the contracts are thoroughly tested and dependable. Additionally, we offer a user-friendly development environment along with a concise tutorial to simplify the setup process for users.

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

The most frequent feedback we received as co-chairs of the IOHK developer experience working group was that the biggest pain point in Cardano development was the lack of accessibility to up-to-date smart contracts that are actually used in production. 

The contracts that we provide will fulfill this vital role. No longer, will developers be forced to build from the ground up, and independently discover design patterns and architectures over the course of many iterations of their project. With this proposal, developers will be able to learn from and improve upon production DApps. Instead of being forced to invest countless hours implementing an efficient batching architecture from scratch, they will simply be able to reference an existing production implementation and start from there, to modify, improve, or reimplement it as they see fit. 

[IMPACT] How do you intend to measure the success of your project?

The most important metric for measuring the success of this project is the feedback of developers who use it, regardless of whether they use it as a starting point to launch their own DApps, integrate it into existing DApps, or simply use it as reference material to learn advanced design patterns and production tricks and techniques from. We will also track the number of projects which utilize each of the individual contracts. Finally, the number of stars, forks and closed issues on the Github repo is a great naïve indicator for the success of the project. The entire process of development is easily trackable by viewing the Github commits and issues.

[IMPACT] Please describe your plans to share the outputs and results of your project?

We will collaborate with existing projects that use specialized versions of these contracts to adopt and co-market the generalized contracts to get it into the hands of Cardano developers. Additionally, these contracts will be easily accessible and deployable on Demeter.

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

Anastasia Labs has rapidly established itself as a leading development firm within the Cardano Ecosystem. Our team consists of highly skilled developers who have made significant contributions to various community projects, including Lucid, Agora, Liqwid-Plutarch-Extra, and Aada Finance. Furthermore our developers have had experience developing and publishing end-to-end DApps including production projects such as WingRiders and AnetaBTC.

In addition to our project involvement, our team has been actively engaged in the developer experience domain. We have actively participated in educational panels focused on DApp Security Practices and Design Patterns, and our members have served as co-chairs of the IOHK developer experience working group.

Furthermore, our collaboration with Emurgo Academy has been instrumental in educating aspiring developers, with our team playing an essential role in this endeavor. We have also recognized and recruited the most exceptional talents from the academy's classes.

We have developed software development kits (SDKs) that facilitate the integration of existing dApps with other systems through off-chain code. Our team has also designed various protocols, including bridges and staking systems, while also actively contributing to open-source smart contract languages and their associated standard libraries.

Overall, Anastasia Labs has established itself as a highly capable and versatile development firm with a broad range of expertise within the Cardano Ecosystem.

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

The main goal is for many developers to use these contracts as either reference material or to build on top of.

We already have some validation of the feasibility of this approach in the sense that many of these contracts have already been widely used in production and by students in Emurgo courses as starting points for their own projects, as such we do not expect much difficulty in generalizing them and getting developers to use them.

An issue that has been prevalent in similar projects is that once the DApps specified in the catalyst proposal were completed, although they may have been good examples at the time, they are not maintained and gradually the codebases become outdated and fail to keep up to date with best practices, new design patterns and architecture. In this case, the issue is mitigated by the fact that these contracts are currently used in production applications on mainnet. The projects using these contracts have agreed to adopt the generic implementations, and as a result, there is a large incentive to maintain and even consistently improve them.

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

Phase 1 - Generalize Contracts

2 months

This time will be spent adopting the contracts to general use, by removing application specific logic and providing more composability. 

Phase 3 - Unit Testing - Property Based Testing 

2 months

Implement extensive unit tests & property based tests for the generic contracts. Provide documentation that clearly illustrates the purpose of each test, and how each component of the testing framework is used (Plutus-Simple-Model, Plutarch-Context-Builder, Plutarch-Unit)

Phase 3 - Create examples and educational resource

2 months

Develop examples and educational content in a clear and concise manner. Use appropriate code snippets, diagrams, and illustrations to enhance understanding. Focus on practical, real-world scenarios to demonstrate the application of the code or concepts being explained. Create illustrations and thorough documentation for each production “trick” / development technique, design pattern and technical architecture. Clearly illustrate and highlight the importance of assertions that exist to prevent common vulnerabilities such as the dusk token attack or the datum size attack. 

Phase 4 - Bug Bounty (if budget permits) 

2 months

Conduct a public bug bounty for the released code base.

[CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

Phase 1. The set of generalized smart contracts

Phase 2. A comprehensive set of unit tests for each of the contracts

Phase 3. Thorough documentation and technical specification that illustrates the use-cases as-well-as the design patterns, security considerations, and production tricks and techniques that are used throughout the code.

Phase 4. Public Bug Bounty where participants can search for and submit vulnerabilities

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

Engineering hours: 500

Total: $40,000

The engineering hours include robust documentation and associated education materials, in addition to the actual smart contracts and associated offchain code.

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

TD

[IMPORTANT NOTE] The Applicant agreed to Fund10 rules and also that data in the Submission Form and other data provided by the project team during the course of the project will be publicly available.