Yieldgate Grant Application

Yieldgate Grant Application

  • Project Name: Yieldgate
  • Team Name: Yieldgate
  • Payment Address: sebas.eth
  • Level: :seedling: Seed

Project Overview :page_facing_up:

This is a freeform grant application aimed at funding the ongoing development of Yieldgate’s vision of a yield-based creator and project support ecosystem.

Overview

In its current form, Yieldgate is a platform to support projects and creators with yield. It’s the result of our team’s effort at ETHGlobal’s ETHAmsterdam 2022 Hackathon. The project became a finalist, winning the 1st prize from Aave, and receiving four more prizes from Coinbase, WalletConnect, Polygon, and ETHGlobal.

With Yieldgate, supporters can stake assets and have the generated yield be claimable by their selected beneficiary. Our long-term vision involves becoming the go-to platform for programmable yield, yield-gated content and no-loss payments, donations, investments (e.g. NFT minting), bug bounty pools, subscriptions, and DAOs.

Currently, Yieldgate is deployed on the Polygon Mumbai and Rinkeby testnets using Aave as the yield-generating protocol. Eventually, we’d like to offer an SDK and to develop integrations with a range of DeFi protocols and selected dapps (e.g. Radicle, Gitcoin, etc.). We currently host our code on GitHub but we are excited to learn how to use Radicle and see how to integrate it into our operations. Radicle projects will be among the first profiles to be integrated on Yieldgate.

We also believe in decentralization and align with Radicle’s vision of backing the FOSS and Web3 ecosystems. We believe that the yield-based support mechanism that we’re bringing to life could become a big source of funding for projects in this space.

Team :busts_in_silhouette:

Contact

Legal Structure

  • Registered Address: NA
  • Registered Legal Entity: NA

We are not incorporated yet. The grant money will be partially used to fund infrastructure and design needs of the project itself and will otherwise be distributed to the team members according to their respective contribution.

Team members

Our team has extensive experience in blockchain-related research, software development and entrepreneurship. It comprises experienced software developers and product managers with over 14 years of combined experience within the crypto space.

  • Sebastian Stammler (@seb): smart contract & back-end development

    Sebastian has studied mathematics at TU Darmstadt and the University of Cambridge and has subsequently worked as a mathematician in quantitative finance at Ernst & Young in Frankfurt, Germany. He then joined a software development startup for one year, finally starting a PhD in computer science at TU Darmstadt in the field of secure multi-party computation, which he is about to complete. Starting in late 2017, he gained his first blockchain venture building experiences during a startup accelerator program in Tel Aviv, Israel, together with Neal. Shortly afterwards, he joined the Perun research team (https://perun.network) at TU Darmstadt in 2018 to lead the development of the blockchain-agnostic state channels framework go-perun. He was a co-founder, Co-CEO and CTO of the resulting spin-off company PolyCrypt (https://polycry.pt), where he also lead the development of the Erdstall scaling network (https://erdstall.dev), initiated at ETHOnline 2020 as a finalist).

  • Dennis Zollmann (@zoma): full-stack development

    Dennis has studied computer science at Friedrich Schiller University of Jena. He has 8+ years of professional work experience as a Designer and Full-Stack Developer in the health industry. During the last 3 years he led a small team building the certified telemedical platform “arzt-direkt” (https://arzt-direkt.com) for video consultations between doctors and patients. After many years of keen interest he went full-time into web3 about 6 months ago and started developing a DeFi protocol about decentralized asset management (still in stealth mode as of today).

  • Neal Swaelens (@nealswa): business development

    Neal studied finance at the Frankfurt School of Finance and Management after which he gained work experience in consulting, banking, and private equity. He had his first leap into crypto in 2017 when he co-founded a startup with Sebastian focused on research into how blockchain can be applied within the public industry. After this, he joined Santiment (https://santiment.net), one of the first crypto analytics firms as a product manager where he built Sansheets and acted as an intermediary between institutional investors and the Santiment dev team. Over the past 2.5 years, he moved to the other side of the table as an early-stage investor, investing in startups across Europe, Israel, and the U.S. first at Plug and Play Ventures (https://pnptc.com) and AMPLIFIER (https://amplifierlab.io), and now at Towards Net Zero (https://towardsnetzero.com).

  • Raúl R Pearson (@raulrpearson): front-end development

    Raúl studied electrical engineering at Universidad Carlos III de Madrid and got a master’s degree in modelling, simulation and control at Universidad Nacional de Educación a Distancia. He started his professional life in renewable energy, designing and implementing control systems and user interfaces for high power electronics devices, including a one-of-a-kind 2M€ low voltage ride through mobile laboratory commissioned by the China Electric Power Research Institute. Eventually he turned to web technologies, one of his life-long interests, and started a web consultancy company in 2018. For the last 4 years, he has been delivering clean, modern and performant React frontends for many clients.

Team Code Repos

Team member’s GitHub accounts:

Team LinkedIn Profiles

ETHGlobal References

Project Description :page_facing_up:

The site you see when you visit yieldgate.xyz is the result of the work our hackathon team did during ETHAmsterdam:

This is great for a 2-day prototype, but we believe there’s some work that needs to be done before we can bring this product to market. We want to develop a much better brand specification and a more cohesive design.

We also need to revisit some of the tech stack choices that were great for a quick prototype but won’t provide the best foundation from which to continue building.

Our roadmap includes a redesign of the UX around a generic creator/supporter use-case instead of the current gating of markdown posts. This is a key change that will unlock integrations with other web3 projects but will require a non-trivial rework of the different models and views.

What follows is a high-level breakdown of how we plan to accomplish this.

Deliverables :nut_and_bolt:

  • Total Estimated Duration: 13 weeks
  • FTE: 33 days
  • Total Costs: 49,600 USDC

The total duration, FTE and cost values are calculated as a sum of the values provided for each of the milestones. One FTE equals 1,200 USDC. Keep in mind that the total cost also includes an estimated 10,000 USDC for design agency work.

Although not stated explicitly, we plan to have code reviews and end-to-end tests written for all the features that will drive our site and app. We also expect to have to do some refactoring of the current codebase. This will add some extra workload, but we believe it will be the best way to lay down the strong foundation we’re looking for.

All our code will be released under a permissive FOSS license (currently MIT) and will be available on GitHub and on the Radicle network.

Milestone 1 - UI/Brand redesign

  • Estimated Duration: 7 weeks
  • FTE: 12 days + design agency
  • Costs: 14,400 + 10,000 USDC

We want to explore a logo/brand redesign and we have a lot of things to think through regarding the UX. Here are some examples of things that are currently lacking in the current implementation:

  • It has a very poor creator/project discovery mechanism.
  • Our user profile creation is not very intuitive. We don’t really have any UI were creators can explicitly choose to create a profile, or any way to personalize it.
  • Creators can’t delete their profile.
  • We don’t think the current focus on content hosting (through markdown posts) is the path we want to follow, and a lot of the UI/UX is centered around that.
  • The staking and yield generation is not at all configurable and we’d like to provide more options.

Our team has to spend some time nailing down the vision for the product and rebuilding the site/app to match it. We think that the best way to find the polish we’re looking for is to work with a design agency to help us articulate that vision in the form of a design specification.

Milestone 2 - New homepage

  • Estimated Duration: 2 weeks
  • FTE: 6 days
  • Costs: 7,200 USDC

This milestone encompasses the implementation of the homepage redesign that will flow from the previous milestone.

We don’t anticipate this work to include too much complexity, but we do expect it to have a non-trivial impact on the codebase. Component and theme styling will have to be redone to fit the new brand specification.

Milestone 3 - New creator/supporter views

  • Estimated Duration: 4 weeks
  • FTE: 15 days
  • Costs: 18,000 USDC

The creator/project public view needs a thorough redesign. In our hackathon prototype we leaned into a use-case where creators can add markdown posts that get unlocked when supporters stake:

This created a dramatic effect that was great for the demo, but we don’t think that hosting content is the right thing moving forward. Our vision is that Yieldgate will provide the platform for creators and supporters to connect, but we want to provide as few constraints as possible on the value creation and delivery.

We also plan to have a private view for each user with a list of supported projects, total amount staked and other stats. It’s quite probable that we’ll model both creators and supporters with a single user abstraction, since it makes sense for a given user to be able to be both a creator and a supporter at the same time.

Users that only want to support will have the choice to keep their profile private. Users that only want to set up a public profile will always have the chance to become a supporter in the future. This view will also provide editing controls for the public profile when using the account as a creator.

Future Plans

We think this grant will unlock just the beginning of Yieldgate’s full potential. That is also why this grant will not enable us to go directly to mainnet but instead make significant steps forward in our development. The overarching goal of the team is to make Yieldgate the go-to-platform for creators, projects, and other public goods to get funded with yield, and other mechanisms. To achieve this, we aim to offer the best user experience to our users which in our view entails offering optionality (e.g. different assets, staking parameters, etc.) and lowering barriers of usage (e.g. integrations with multiple chains). Besides that, having a great user interface and flows is critical to making the platform intuitive and drive user acquisition. This grant enables us to move a lot faster towards achieving better user experience and with it get closer to a mainnet launch.

While we limited the scope of the initial grant to learn and iterate quickly, the next phase of milestones as a continuation to this grant would entail the following:

  • Better discovery mechanism: once someone has become a supporter for a project or cause, we believe that having a good discovery feature will drive engagement and will maximize the opportunities for more projects and supporters to connect. At the very least this will be a faceted search, “most popular”, “recent” or “growing the most” projects listings and some way for supporters to subscribe to updates. We expect to have to go through some iterations before we find the best implementation.
  • Documentation and FAQ: we’ll strive to build an intuitive UX but, as we onboard more users and add more features, we’ll need to improve how we provide support.
  • Integrating with Radicle: as mentioned in our introduction, we see a lot of potential in this yield-based support mechanism and we want to be close to where value is being created and exchanged. At some point we would like to explore an integration with Radicle so that projects could add a badge to their readme and rely on a Yieldgate SDK to make it easy for people to stake in their favor.
  • More staking options: we want to integrate with more yield protocols (currently using Aave) and offer a more configurable setup of staking pool and parameters.

In the long-run, Yieldgate will be sustainable as we are currently exploring several routes to monetize and decentralize the platform over time. However, we are also in discussions with several other protocols to discuss synergies and grants. We are confident that we would be able to completely bootstrap our development to the mainnet launch.

Additional Information :heavy_plus_sign:

During the ETHGlobal Amsterdam hackathon we got to meet some of the Radicle team. In the week after the hackathon we directly hopped on a call together with Kai, Lukas, and Bordumb. We were very happy to learn that there was a lot of common ground in vision on both the web3 ecosystem and for what we’re building. They also encouraged us to apply for the grant.

We hope this grant will kick off a long-term synergistic relationship between Radicle and Yieldgate. As mentioned in the Project Goals section, we anticipate to submit a second grant in the future and develop rich integrations with Radicle.


Thanks for taking the time to review our application and please do let us know if you have any questions :sun_with_face: :seedling:

4 Likes

Hello

General comments below:

  • The grant calls for too much work that is not related to the Radicle Ecosystem. For example, there is no explicit mention of this work being completely open-sourced, nor is there some 3rd party tooling related to Radicle mentioned. We are looking to fund work that will be open-sourced.
  • There is also no direct - or indirect - mention of any integration with Radicle itself. We are focused on funding growth in the Radicle ecosystem, whether it’s contributions to the core product or integrations with other protocols and tools.
  • Too much of the grant is focused on preliminary work that has little to do with building a core product (e.g. logo design, site design, etc.). We would rather focus on funding core product work.

Advice going forward:

  • I’d advise that we return to this once you have more of your initial product ideas fleshed out and especially if there is more explicit mention of open-source work with some tie in to Radicle’s ecosystem
  • I think the idea of pooling project funding to build yield is very interesting. I can imagine that Radicle itself might benefit from such a system. For example, Drips remain idle if the recipient does not claim them. It would be a lot better if unclaimed Drips could be funnelled to some protocol to accrue interest, thus putting the otherwise idle capital to work. Thinking through these sorts of problems are more in-line with what we’d be interested in funding.

Thank you and let us know if you have any questions.

1 Like

Hi @bordumb, thanks for taking the time to review our application and the valuable feedback! We are sorry to hear that the Radicle grants team doesn’t want to proceed with our application at this point but we understand why it doesn’t make sense with the current scope.

Nevertheless I’d like to clarify some issues that were raised in your comments and make a proposal for future steps.

We explicitly say in the “Deliverables” section:

All our code will be released under a permissive FOSS license (currently MIT) and will be available on GitHub and on the Radicle network.

Also, in both sections “Future Plans” and “Additional Information” we mention that an integration of Radicle projects on Yieldgate, and the other way around, is the ultimate goal of this collaboration.

We initially wanted to submit a grant proposal >$50k that would already have included the Radicle integration work. But from feedback that we received in talks with Radicle members, we got the impression that it is better to first apply with a smaller grant <$50k. Since milestones 2 and 3 are necessary to build our platform, we included these first and pushed the Radicle integration into future work.

We understand that logo and brand redesigns are out of scope of what Radicle would like to fund. However, we think that milestones 2 and 3 do represent work on our core product, which will ultimately have the potential to bring a new source of revenue to the wider Radicle ecosystem.

I would therefore propose that we remove milestone 1 and instead add an integration of Radicle as the third and final milestone. We will also take your suggestion into account regarding yield-generation from Drips! This is a great extension to the ideas we already had for Radicle.

Might this change the grant team’s mind regarding our application (taking into account that open-sourcing the work has always been a given for us and that Radicle itegrations would have been our follow-up grant proposal)?