Frame 59921.svg

Kava

Lorem ipsum dolor sit amet consectetur. Id turpis nunc cras ac. Nisi egestas ultrices feugiat montes pulvinar egestas enim. Amet quam posuere lorem molestie sed. Lorem ipsum dolor sit amet consectetur. Id turpis nunc cras ac. Nisi egestas ultrices feugiat montes pulvinar egestas enim. Amet quam posuere lorem molestie sed.Lorem ipsum dolor sit amet consectetur. Id turpis nunc cras ac. Nisi egestas ultrices feugiat montes pulvinar egestas enim. Amet quam posuere lorem molestie sed.

Lorem ipsum dolor sit amet consectetur. Id turpis nunc cras ac. Nisi egestas ultrices feugiat montes pulvinar egestas enim. Amet quam posuere lorem molestie sed.

King_Logo.svg

King

## Introduction
It is with great pleasure and enthusiasm that WOOF! Software takes the reins as the development team for King Protocol. This opportunity allows us to continue the fantastic work started by the Etherfi team, whose innovative approach has laid a solid foundation for the protocol’s growth and success. The initial TVL of the protocol was an impressive $5M, and we are committed to further enhancing its capabilities and expanding its impact.
## WOOF! Software as an Angel Investor
For the first time in our journey, WOOF! Software stepped into the role of angel investor with King Protocol. This marks a significant milestone for us and reflects our belief in the protocol's potential to redefine the restaking rewards landscape. Our investment is not just financial but also deeply integrated into the development and operational growth of King Protocol.
### Key Contributions by WOOF! Software
Our team has been actively involved in various aspects of the protocol’s evolution. Here are some key areas we’ve focused on:
1. **On-Chain Rebranding:** Transitioning the protocol from LRT² to King Protocol was a critical step in redefining its identity and aligning it with its ambitious goals.
2. **Website Design and Development:** We designed and developed a user-centric website with an IPFS-based approach for enhanced decentralization. This included seamless integration with Uniswap for improved user experience.
3. **Point System Design and Development:** A robust and scalable point system was crafted to incentivize users and enhance engagement within the protocol.
4. **Governance Development:** We implemented on-chain governance mechanisms to ensure transparent and community-driven decision-making.
5. **Additional Enhancements:** From streamlining reward distributions to optimizing the user journey, we have tackled numerous other challenges to ensure King Protocol’s success.
## Working with the King Protocol Team
One of the most rewarding aspects of this project has been the opportunity to collaborate with the talented King Protocol team. Each member brings unique skills and insights that have greatly contributed to the protocol's success:
1. **Syko:** The architect of Etherfi, whose vision and technical acumen continue to guide the protocol’s design and functionality.
2. **Joe:** An inspiring CEO who effectively drives the team and manages the protocol’s growth. His leadership sets the tone for success.
3. **Ivan:** Joe’s right-hand man and a brilliant product owner. Ivan’s ability to manage everything seamlessly has made him an invaluable asset. We hope to collaborate with him on future projects.
4. **Eric:** The genius behind King Protocol’s tokenomics. His expertise in controlling token emissions and crafting balanced expectations has been truly impressive.
## The WOOF! Software Team
Our team members have contributed their unique expertise to the development of King Protocol:
1. **Nikita Berejnoy:** Partial CTO at King Protocol, whose technical leadership ensures smooth operations.
2. **Bohdan Bondar:** PM and communicator, bridging gaps between teams and ensuring alignment on objectives.
3. **Misha Mishin:** Frontend developer, develop user interface and feature code.
4. **Gleb Golyan:** Frontend lead, delivering exceptional user interfaces and experiences.
5. **Dmytro Orlov:** Designer, creating visually appealing and functional designs.
6. **Dmytro Babenko:** Adviser and technical support, providing critical insights and assistance.
## Looking Ahead
As we continue to develop King Protocol, we remain committed to delivering innovation, efficiency, and value for its users and stakeholders. It has been an honor to work with such an exceptional team, and we are excited to see how King Protocol evolves and shapes the future of restaking rewards.



King Protocol, (formerly LRT²) is a unified restaking rewards protocol acting as a vault that holds the rewards tokens as underlying assets. Through King Protocol, LRT projects can pool restaking network protocol rewards into a single vault and issue vault share tokens to their stakers (or distributor contract). This system cuts transaction costs and streamlines the rewards process, great for those with smaller stakes who might find it easier to manage and trade their shares collectively. Larger stakeholders can redeem and possibly arbitrage, which will drive the market price of King token.

WOOF! team taking key role in King Protocol development. Our team invested in King on early stage.

Ronin_Logo.svg

Ronin

Compound_Finance_Logo.svg

Compound Finance

## Backstory
Surprisingly, Compound Finance became our first—and, at the time of writing, our primary—client. Our company was born in our hearts and minds long before that, but the official starting point was a serendipitous meeting at Mainnet in New York in the fall of 2023. That’s where Pasha Bergman met Bryan Colligan from AlphaGrowth, who casually asked, "Can you deploy a few markets for Compound?"

That’s when the fun truly began. Working with Compound was nothing short of a pleasure. It was our first experience collaborating with a DAO, navigating through a maze of service providers, community opinions, and delegates. It was an unforgettable journey that allowed both our company and our team members to grow in ways we hadn’t anticipated.

By May 2024, we secured a grant to support Compound for the next 12 months, giving us the resources to build a dedicated team around the product.

WOOF! actively votes on the DAO, pushes proposals, and collaborates closely with various delegates. We are signers on the Compound Community Multisig and admins on the Compound Forum.

We’ve assembled a dedicated team of smart contract, back-end, and front-end developers working exclusively on Compound, supported by internal resources for design, QA, and DevOps. Our commitment to the long-term success of Compound is unwavering, and we’re dedicated to doing whatever it takes to help it thrive.

## What's Next?
Compound v4. Our mission is to make Compound even more successful and dominant in the market. We’ve already begun by building a brand-new decentralized front end from scratch, developing a position migrator from other protocols, and creating an entirely new dimension for Compound—Sandbox.

Sandbox is an addition to Compound v3 that will allow anyone to create a market, manage it, and earn revenue. It’s a game-changer that will bring unprecedented flexibility and growth opportunities to the ecosystem.

Globally, we are taking steady, strategic steps toward Compound v4. You can follow our journey and track our progress through our updates on the forum which we are parsing here.

In the meantime, we invite you to explore all that we’ve already accomplished statistical. Also, feel free to read our another case studies.

Compound is one of the largest lending borrowing protocols on the entire crypto market. Compound was launched in September 2018 and peaked with $12Bn TVL.

## Motivation
In consultation with some of the Compound team members and listening to the Compound community, we figured out that the Compound community is interested in the improvement of reward distributions.

Currently, most Comets are incentivized by COMP only. More and more ecosystems and projects are willing to incentivize Comets with their tokens (e.g. Aribtrum). However, Compound lacks the functionality to support or distribute rewards in any tokens except COMP. Therefore, Compound also lacks the infrastructure to distribute rewards in more than one token at a time.

We would like to build a solution that allows Comets to incentivize participants with multiple tokens.
## Requirements
1. Ability to incentivize Comet with 2 or more tokens at the same time.
2. Seamless transition: users shall not perform any actions to start receiving rewards in additional tokens.
3. Do not upgrade existing smart contracts.
4. Ability to relaunch incentivization program for the same token (for example: distribute 100K USDC in Q1 2024, then stop distribution and redistribute another 200K USDC in Q3 2024).
5. Reusable code: the solution shall be reusable for future Comets and applicable to existing Comets.
## Challenge
Current CometRewards.sol allows only one incentivization token per Comet. It prevents the utilization of any other rewards, since it cannot be reset and the coefficient constant cannot be changed.

Comet.sol stores **Accrued Value** (baseTrackingAccured) and constantly increases it. CometRewards.sol distributes rewards based on the Accrued Value of the user. The current approach has one accrued value and no additional accrued values could be added without changing Comet.sol which is not allowed by requirement 3. The accrued value is an infinite line, that starts when the user performs supply and never ends.

Incentivization campaign with new token(from third parties like Arbitrum) will not last forever, but will start and end periodically. Which means, that for the correct calculation of the multiple rewards for every user, the multiple rewards flow should track the accrued value of every user at the start and at the end of each incentivization program for each token.
## Features
#### CometRewardsV2 contract:
1. Will utilize CometRewards contract, as it already contains some token rewards.
2. Will get the existing reward info from the CometReward during the setup.
3. Will have the same interface as CometReward + new functions for the CometRewardsV2 functionality.
4. Will redirect any calls connected to the existing reward to CometRewards. It will redirect calls connected to the existing reward in the rewardConfig mapping.
5. Will store Merkle tree root hash for every incentivization program start and end.
6. Will verify Merkle tree proofs.
7. Will contain functionality for multiple rewards - new storage structure and new functions to store several reward tokens (except the one already set in BaseRewards).
8. From this moment all new rewards will be added to the CometRewardsV2.sol, while CometRewards.sol will work for the compatibility.
#### Back-end:
1. Generate Merkle tree hash from all users using OpenZeppeling/merkle-tree lib for the specific comet at the moment of generation of new rewards campaign.
2. Call CometRewards to start/finish a new incentivization program. Or the admin can make it manually.
3. Update the Merkle tree hourly/daily (should decide) to track new users who appeared in the protocol during the new incentivization program.
4. Export list of proofs for Merkle tree hash.
## Use cases
**Start/end new incentivization program**
The back-end will generate a Merkle tree hash from all the users in particular Comet and store it into CometRewardsV2 on the admin call. The back-end can also generate a Merkle tree and return it. Admin could set up the hash manually. We assume that start and end point hash will be generated and settled via governance proposal pipeline in every incentivization campaign

**New users appear during the incentivization program**
In case when the user was not a participant in Comet before the campaign started, the accrued value will be received directly from SC. If the user's address was not in the Merkle tree, but it exist in Comet, the user appeared during the campaign.

**Note:** CometRewardsV2 will call CometRewards only for legacy rewards (publicly available in the config). All new rewards will be processed directly via the new CometRewardsV2.sol contract.

## Front-end Integration
Flows of integration CometRewardsV2 in existing frontends:
#### Read flow
1. dApp calls the backend and gets proof for a particular campaign for a particular user
2. dApps reads the CometRewardV2 with proof parameter
#### Write flow
1. dApp calls the backend and gets proof for a particular campaign for a particular user
2. dApps calls the write method the CometReward with proof parameter
3. User sign the transaction

To make the proof system maximum clear, we are going to upload this information into Github.
## Library
Additionally, we are going to create TypeScript library that is going help to integrate new functionality into existing dApps. Library will help with generation of proofs.
## Milestones
#### M1: Smart contract development
1. Define the new functions and storage structure for the new contract.
2. Add integration of the existing contract - for the re-calls for legacy rewards.
3. Keep the existing interface for compatibility.
4. Implement new functions to support multiple rewards with independent settings - while keeping the original config structure as a reference.
5. Implement new admin methods, to store Merkle tree hash into CometRewardsV2.sol.
6. Provide 100% unit test coverage.
7. Provide integration fork tests checking the support of the legacy rewards.
8. Provide a testing stage with testnet deployment and end-to-end testing scenarios.
9. Deployment scripts.
10. Documentation update.
#### M2: Back-end development
1. Development of collecting user data service.
2. Development of Merkle trees generation service.
3. Development of functionality to start a new campaign.
4. Development of functionality for updating Merkle root.
5. Development of functionality for setting up final Merkle root and stop campaign.
6. Development of call transaction system.
7. Back-end and SC integration.
8. Integration fixes.
9. Unit test coverage.
10. End-to-end testing.
11. Create documentation.
#### M3: Post audit fixes
1. Post-audit fixes and production launch.
#### M4: Production deployment
1. Mainnet deployment
2. Back-end production deployment
## Deliverables
1. Smart contracts codebase on GitHub
2. Back-end codebase on GitHub
3. Post-audit fixes
4. Smart contracts deployment
5. Back-end deployment
6. Smart contract connection assistance
7. Documentation update

Compound was able to distribute rewards only with COMP tokens due to the unique design of the protocol. Our goal was to create an infrastructure around Compound, without changing original codebase to allow distribution in any other tokens in different streams.

## Introduction
We are excited to present the full scope of work required to integrate Uniswap V3 LP positions as collateral for the Compound V3 protocol. This ambitious project aims to extend the protocol’s functionality while maintaining efficiency and a seamless user experience. As a result, Compound V3 users will soon be able to supply Uniswap V3 LP positions as collateral, opening up new opportunities for liquidity provision and lending.
## Solution Overview
### Whitelist
The governance will whitelist the pool address representing the asset pair. Each pool can have multiple fee tiers, but typically only one or two tiers per pair are actively used. For example:
- USDC/USDT has a 0.01% fee tier.
- ETH/LINK has a 0.3% fee tier.
We’ll maintain one (maximum two) pools per pair based on volatility.
### Supply
The supply method will use the ERC721 token ID instead of the traditional ERC20 value and asset address. Using Uniswap V3’s libraries, we can compute the pool address and retrieve position details using the position manager. Token IDs will be stored for both user-specific and global positions, enabling efficient tracking.
### Total Supply Recalculation
The recalculation of total supply involves extracting underlying assets, converting them into a single asset using Chainlink price feeds, and aggregating the values. To avoid high gas costs associated with recalculations, we propose an off-chain service leveraging Chainlink Automation. This approach minimizes on-chain computation and reduces protocol expenses while maintaining decentralization.
## Key Features
1. Chainlink Automation Integration
   - Chainlink’s decentralized network will handle total supply recalculations.
   - Off-chain calculations will reduce gas costs, and the results will be periodically set on-chain by a keeper contract.
   - The keeper contract must be whitelisted by Compound governance.
2. Rewards Management
   - Option 1: Absorbers collect rewards and recompound them into the same position, increasing transaction costs for liquidators.
   - Option 2: Users interact with LP positions to rebalance rewards manually.
3. Buy Collateral
   - A simplified interface for liquidators to purchase collateralized LP positions using token IDs.
4. Bulker
   - A separate contract to streamline the supply of ERC721 tokens.
   - Provides an option for users to create and supply LP positions in one transaction.
## Collaborations
Working on this project has been a fantastic opportunity to collaborate with Chainlink’s Automation team, who provided valuable insights into decentralized recalculations. Their support has been instrumental in crafting a reliable solution.


In the shadow of Uniswap launching Unichain, Compound wants to take a leading position on the network. 

WO OF!

WOOF!

Portfolio

Compound Finance

Mega Case Study 🎉

Rewards System Improvement

Adding Uniswap v3 LP as Collateral

New Front-end

Sandbox: Permissionless Compound v3

Kava

Project was classified due to and NDA

Ronin

Review & audit of infrastructure & ecostystem

King

King Protocol development