Please describe your proposed solution.

The aim is to research the viability of Hydra as a general DeFi platform, following a B2B design pattern where protocols (DEXes, lending platforms, oracles etc) are represented in the head as participants.

The main output of the research will be a white paper which will

• Outlining the design
• Educating on how Hydra works
• Contributing new ways to thinking about how to structure systems around Hydra
• Proposed "B2B" design (protocol-to-protocol is perhaps more accurate)
• User interaction, how to deal with B2C
• How to deal with main net interactions without closing the head
• Incremental settlements
• Deposit contracts
• Main net congestion
• Malicious or compromised participant
• Evaluate performance and limitations
• Throughput
• Number of participants and impact on performance
• Number of UTxOs and impact on performance
• Outline some best practices to maintain performance
• Highlighting notable benefits and feature adds
• Flash loans and associated liquidation and arbitrage improvements
• Possibility for low/no fees increasing capital efficiency
• Larger script sizes, enabling more sophisticated smart contracts and protocols

In addition to the white paper, the targeted deliverables comprise of an MVP of how Hydra can be used as a B2B platform, with a showcase of how B2C relations can be handled through wallet authentication and indexing. Instead of reinventing the entire DeFi stack, the MVP will focus on the B2B design pattern and associated B2C interaction through a simple, creative application similar in function to the Reddit experiment from 2017 r/Place.

Finally I will seek to make a list of memorandum of understandings (MOUs) from relevant DeFi projects interested in exploring further and possibly being a contributor to a full DeFi head solution.

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

The solution will principally aim to achieve four goals:

1. Show the wider community a useful way of thinking about Hydra in applications
2. Bootstrap the collaborative work that is required to explore Hydra as a general DeFi platform, work that would otherwise be very hard to coordinate and align incentives for between competing projects
3. Find a solution to the issues facing Cardano DeFi at present, in particular
4. Congestion
5. Batchers
6. Script memory capacity
7. Efficiency
8. Contribute to lowering the congestion on the main chain through funneling a lot of traffic into Hydra applications

Let’s dig a bit more into each one:

Show a useful way of thinking about Hydra applications

Hydra as a technology stack is a flexible and useful tool, however the applications that are built using it depends on the way people understand it. As a “mini layer 2”, a “session specific side channel”, and other previously mentioned ways of thinking about Hydra, the proposed applications are very niche and limited; however these are by no means the only ways of understanding which role Hydra can play.

Hydra can for example also be thought of as an extension of the existing smart contracts, allowing more complex interactions such as providing the infrastructure for flash loans, or simple improvements like exceeding the memory and computational limits.

Another way of thinking about how to use Hydra is through B2B platforms. In particular if representatives from multiple DEXes, lending platforms, oracles and professional market makers collaborate inside a Hydra head in a B2B manner, a whole slew of new products can be built with negligible risk of congestion, no hard limits to transaction complexities and with no/trivial transaction fees. This in turn will enable much needed new features to Cardano DeFi users such as flash loans, automated yield harvesting, more capital efficient arbitrage, liquidations, possibly leverage trading and more.

Bootstrap the Hydra DeFi work

An important issue currently standing in the way of Hydra being explored as a B2B solution for DeFi at the moment is the competitive nature of the potential participants. Hydra is not ideally suited for DeFi as an application specific platform, for example the benefits for a DEX of using Hydra on its own is likely marginal or very complex. On the other hand, the benefit of 2 DEXes sharing a head, facilitating more efficient arbitrage is immediately obvious; however this is an unlikely spontaneous marriage since the initial work would require collaboration between competing firms.

This is why it is useful to bootstrap the design pattern and analysis, and present it as a public white paper. The potential participants can read up on the proposal and evaluate whether it is a direction they want to push their own development.

Find a solution to the issues facing Cardano DeFi

There are a number of problems facing Cardano DeFi at present, with secondary and undesirable effects.

• Congestion

DeFi suffers tremendously from, and contributes a lot to congestion on the main network. This not only makes for a bad user experience when trades take hours to complete, but it makes applications that rely on time sensitive transaction like liquidations and short-duration oracle feeds inherently unsafe to use and operate. The secondary effects of this is that either those protocols take the risk and operate unsafely, possibly putting users' assets at risk, or they simply don't launch at all, making the Cardano ecosystem all the poorer for it.

• Batchers

Batching scripts were introduced as a design concept to attempt to deal with global states like the exchange rate in an AMM style DEX or dynamic interest rates in pooled lending protocols. Batchers suffer from some inherent issues, the primary of which is the tradeoff between permission and security.

Having fully permissionless batchers opens the protocol up to "dusting" or other types of spam attacks where external parties run the batching script without actually contributing to the protocol operation.

Creating a "partially permissioned" or even just completely permissioned system where the protocol development team operates the batching scripts exposes the protocol and its' users to a host of issues.

• Script memory capacity

The current transaction size restrictions are permissive for a lot of applications, but for transactions requiring a lot of data, such as a many-to-many relational check, the transaction size limitations are quite strict which limits the complexity of the features that can be implemented.

• Efficiency

Hydra allows for a few novel things to be done that will improve DeFi dramatically in terms of efficiency and capital efficiency. Lowering/removing transaction fees could be an option due to the "B2B" nature of the proposed solution, but leveraging the technology in particular the fast finality and the snapshot mechanism, features such as flash loans might be possible to implement.

Flash loans are an interesting blockchain innovation that makes certain transactions and markets much more capital efficient and accessible. Flash loans make actions like liquidations, arbitrage, collateral swaps etc either much more efficient or possible in the first place.

Lowering the congestion by funneling traffic into Hydra

By moving some of the DeFi trading traffic into a Hydra layer, and removing some of the extraneous traffic generated by batching scripts, this solution could improve the congestion of the main network. It won't be a one-stop-fix-all solution, but paired with other developments and future improvements like input endorsers, it will certainly help improve the usability of Cardano at scale.

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

The success criteria of the MVP and white paper are quite different.

White paper

The ultimate success of the white paper is the deployment of a Hydra DeFi platform based on the work, however intermediary goals can be measured through engagement through public metrics like citations and social media coverage, and business metrics such as approvals and commitments by key operational contributors that show interest in participating/adopting the design. Towards this purpose a list of MOUs from relevant projects will be started, and getting one representative from each vertical (DEX, lending, oracle, trading/market making/liquidations) would be considered an initial success, getting multiple participants, for a more competitive environment would be a more solid intermediary success.

MVP

A successful deployment of the MVP will be measured through user engagement with the actual dApp, but also GitHub engagement such as forks. If few people engage with the dApp, but there is a lot of traffic in the GitHub repo, the MVP is considered a success. If there is a lot of engagement with the dApp but few interactions with the GitHub repo, marketing efforts (funded by the dApp revenue) will be spent to bring focus to the open source components.

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

Once the white paper is finished and published, it will be shared in a few ways.

The first is through writing highlights, simplified breakdowns and explainers to be shared on social media, hosting AMAs and when invited doing interviews.

The projects signing the MOUs for the white paper deliverable will also be asked to share links to the white paper on their social media channels to bring attention to it.

A collaboration with the Hydra team for the white paper is in talks, and a possible co-authoring and publication on IOG’s website will bring a lot of attention to it, however no firm commitments have been made.

The dApp built on the MVP is specifically designed to be quickly deliverable and to attract a lot of interactions, i.e. ideally to become “viral” within the Cardano community. This will in turn bring attention back onto the Hydra fundamentals underlying the product. In addition to the social elements of the dApp itself, there will be a “tps counter” that shows the max tps reached. This plays into the “1 million tps” meme that surrounds Hydra, but an initial benchmark shows that the application should be able to reach at least 1,000 tps, which if hit will hopefully make some wider waves bringing attention to the dApp, Hydra and Cardano as a whole.

A simplified breakdown of both the MVP architecture and the white paper will be hosted on the dApp website, making the outputs of the work more approachable for non-developers.

What is your capability to deliver your project with high levels of trust and accountability?

I have a strong background in mathematics, computer and data science research, along with 2 years professional experience working within the Cardano ecosystem. I have a good network of possible contributors and projects that might benefit/want to contribute, and many of them have already expressed interest in contributing. The dApp is already underway development-wise, currently being worked on out-of-pocket, and the goal is to have at least an interactive demo of the front end to show at Rare Evo in August. The major components of the system architecture for the Hydra backend is in place, and there are currently only a few known unknowns.

For the white paper I have relevant experience working with DeFi protocols and the EUTxO specific strengths and challenges presented by these, and a strong focus on actionable results and experience with product/business related questions, so it won’t be an academic exercise. I also have experience producing and presenting research level material and analysis both from my work within the Cardano space, and from my previous work in the data science industry and algorithm design.

Catalyst funding will provide the means to combat the two main obstacles to delivering: dedicating the required amount of working time to it and covering the out-of-pocket costs of hiring outside talent to deliver components like design, manage social media and infrastructure costs for hosting the required backend and indexer.

What are the main goals for the project and how will you validate if your approach is feasible?

The main goals are:

• Research and write a white paper on Hydra as a B2B layer for DeFi
• Obtain MOUs from relevant projects within each relevant vertical, wanting to contribute to the Hydra DeFi protocol
• Complete and deliver an MVP and a dApp built on that design pattern
• Document, open source and share the relevant code base

The feasibility of the project has been evaluated through thorough discussions and workshops with relevant developers, engineers, ecosystem participants (two DEXes and an oracle) and the Hydra team, along with proposing different benchmarks of the performance of the Hydra nodes which have been shown to be satisfactory.

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.

White paper

The white paper will aim to present a proposed design for DeFi as a Hydra platform application, along with some use cases and improvements related to the approach. In addition, attention will be brought to the possible security concerns (such as adverse participant behavior, unexpected closure, failure to validate transactions etc) along with proposed solutions. Performance benchmarks will be provided, and where relevant, proposals for future developments on the part of the Hydra team will be presented.

The white paper will likely be an ongoing process through the entire 6 month period, with the last month ideally being left for editorial and compounding data from the MVP deliverable.

MOUs from relevant verticals

During the writing of the paper, relevant projects from the different verticals will be contacted, with the goal of getting feedback on the proposed material and possibly an MOU indicating interest in pursuing the contribution to a platform based on the white paper proposal. A number of projects have already voiced interest in the direction, and signing an MOU is a low barrier of commitment for each individual project, but does signal the willingness of the ecosystem to explore further.

The goal is to have a complete list (at least one from each vertical) of relevant MOUs by month 5.

Complete and deliver MVP

The MVP is already in development, and has an early prototype front end design, along with a system architecture for the back end in the works, detailing the Hydra node, main net data indexer, web3 wallet session authentication etc. In the spirit of “fail fast and adapt” the next step is to put together a database, Hydra node and indexer for testnet to measure performance and viability of data flow.

The goal is to deliver the MVP within 4 months of receiving funding.

Document and open source

Prior to open sourcing the code, the relevant diagrams and documentation will be written up and shared in a digestible format so that the general public can get a sense of how Hydra is being used. The MVP will be launched as soon as it is ready, and the code open sourced some time after (to leave room for improvements based on performance in the wild), but no later than the end of the scope of time.

Please describe the deliverables, outputs and intended outcomes of each milestone.

White paper

A white paper delineating a design proposal for using Hydra as a B2B platform for DeFi applications, including breakdowns of performance, security and business cases. The Hydra team, although hard at work with the continued development of the tech stack, have expressed interest in the work and will be invited to contribute to it.

MOUs

A list of memorandum of understandings, signifying projects’ interest in being a part of a Hydra DeFi platform as described in the white paper. This list should cover the DeFi verticals involved to truly unlock DeFi (oracles, DEXes, lending protocols and professional traders), and can be used to form a strong foundation for a subsequent funding proposal. Each of the projects might not want to/be able to commit their developers to a new project that is reliant on the work of others as well to be beneficial, but the MOU can include a service agreement clause, where a funded Hydra DeFi platform proper can compensate the projects involved to revamp their product as required by the novel operating mechanism in Hydra compared to their existing smart contracts.

MVP

The main deliverable is a dApp allowing users to connect their wallet and interact with the dApp which is operating in the backend with Hydra as a B2B ledger.

A secondary deliverable is a reference source of written material explaining the role of Hydra in the dApp and the potential use cases the B2B design opens up to; presumably followed by appearing on various channels and Twitter spaces for interviews and AMA’s.

An intended outcome is for the MVP to raise funds for continued development and pave the way for future consulting and business development.

Document and open source

The Hydra related components of the MVP, specifically the main net smart contract indexer monitoring a user’s access through funds sent to a smart contract or wallet, and the session specific information relay, taking a wallet authenticated user request from the front end and submitting the relevant transaction to the Hydra node.

In addition a set of very approachable documents with visual aids and diagrams explaining exactly how everything works. This will allow new developers to quickly pick up Hydra and see the wider potential of the technology and how it could fit their projects.

Please provide a detailed budget breakdown of the proposed work and resources.

The budget is broken down into two major components

1. A salary budget
2. A discretionary spending budget

The salary budget is based on a reasonable market competitive rate (based on experience, background and competing offers) of $10,000 per month. There has been considerable work done on this already, which will not be compensated. The actual amount asked is based on

$10k x 6 (months) / 0.28 (current ADA price) ~ 214k ADA

The discretionary spending budget includes compensation of hired designer, front end and backend developers for implementation of the MVP (highly active during the first 4 months after funding), infrastructure and possible marketing/community management for the MVP until the project can potentially support itself ~ 60k ADA

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

Trym Måke Bruset - project lead/researcher

Will lead the development of the MVP by providing all relevant documentation and product specifications, and directing the development hands on through the process, working with external parties for design, front end and backend implementation.

Experience with product management and system design in the web3 space along with joint venture project lead experience within the maritime industry provides a solid foundation to ensure this is an achievable goal.

In parallel Trym will focus on the research, testing, analysis and writing of the white paper, and leverage connections within the space to continuously collaborate with relevant DeFi parties and work on collecting the list of MOUs.

An extensive academic background (2 BScs in mathematics and computer science and an MSc in Pure mathematics and mathematical logic), along with earlier contributions to research both academic (consulted on 2 other masters' and a bacherlor's thesis) and industrial (contributed to maritime data processing research at THSiS online event, and an update to the ISO15016 standard for weather normalization and operational efficiency indexing for cargo ships), gives a solid foundation for the research and writing work that is required.

Hands on experience with both using and developing DeFi dApps on Cardano provides not just a solid understanding of the subject matter, requirements and current challenges; but also means that the required network to get real feedback from projects and to collect the MOUs is ready made.

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

The potential of a B2B Hydra DeFi platform is great in terms of attracting TVL, traffic to the ecosystem, proving the capabilities of Hydra and Cardano as a whole, remove DeFi congestion from main net, enable time sensitive applications to build safely without introducing a fee market on L1. The exploration of the viability of Hydra for this area of application is not well incentivized as it requires either an independent party to do the preliminary work (this proposal) or a set of competing projects collaborating on a project that might prove to have a delayed return on investment, or even to prove unviable.

The hybrid approach of providing an MVP alongside a research focused white paper is an effective way of bootstrapping the B2B approach to Hydra design, which has wider application areas than DeFi, such as interactive NFT projects, games and more.