## Multisig voting application:

[https://github.com/ftperez11/Daoism](https://github.com/ftperez11/Daoism)

### Project Overview:

Created this project as an assignment in my previous company. This is a voting application that checks the weight of a voter based on their stake in a Defi Pool. The application allows whitelisted members to create new proposals and vote on existing proposals. If the proposal is passed, it should be executed. Upon proposal execution, the contract should allow stakers to add / remove members from the Multisig wallet in an automated fashion.

The problems I faced initially was figuring out a way to get the contract to autonomously either add or remove members to the multisig wallet based on the results of the passed proposal. I realized I would be able to add the encoded function signature to the proposal and the contract would be able to execute a call to the function signature without it being obvious what the proposal was proposing. I also created a full test suite to confirm the functionality of the multisig.

## Work Projects

### Defi Protocol Pools Contracts

Worked as part of a 3 developer team to create a liquidity pool protocol. Protocol liquidity providers can stake their LP tokens and earn additional yield and voting benefits by locking up funds in pools. The challenge we faced was converting the code infrastructure created by an existing web3 platform to fit with the current architecture of our protocol. The original codebase we were expected to leverage did not have a test suite, and the contracts were written in vyper. So the first challenge was converting to the most recent solidity versioning, and making sure we were able to achieve 100% full test coverage.

I primarily focused on the initial depositor logic and rewarding the LP with new rewards tokens. This consisted primarily of the 3 core contracts.

We leveraged Open Zeppelins ERC20 token and clone factory contract. I was also responsible for writing the majority of the contract NatSpec documentation.

I also helped integrate the graph protocol to query for onchain pool data, as well as helped support the front end team with React/Typescript code.

### Fee Collection Contract

The basic idea behind this protocol feature is to allow anyone to partake in the protocol revenue generation model via creating new pools. This included the development of a new *Splitter* contract that the protocol can authorize to withdraw from the existing *FeeCollector* contract, and award funds to new pool creators. In this project I partnered with another back end developer to research the existing protocol and identify the best place to in incorporate this new contract in order to achieve the desired result of being able to share pool revenue with pool creators.

Some constraints we faced were: Revenue sharing would start at an initial fee percentage but would be able to be modified at the protocols discretion. The Protocol can authorize “boost” functionality, where the revenue share on any pool or factory can increase to a higher specified percentage. Also, if the pool owner address was not provided, all pool fee revenue would then go to the protocols treasury.

The initial step was to research and understand the architecture of the existing protocol in order to identify the best way to achieve the goal. Once this was understood the contract creation was relatively straightforward. We would ultimately create an external function to collect fees for pool creators. This function would be responsible for obtaining the pool id and balance from another contract, withdrawing the correct amount, and distributing the amount between the pool owner and the treasury.

### Proof of concepts:
- Decentralized Safe API utilizing Ceramic Protocol and ComposeDB.
- Uniswapv3 concentrated liqudity on 3rd party Defi protocol