Similar to Convex's cvxCRV, Amphora will support a amphCRV.

For this bounty you should fork Convex's cvxCRV system (the cvxCRV contract, the locking contract, and a voting system) and make some minor modifications:

• Since Curve's system requires whitelisting before we can vote lock/vote, the contract will need to contain a flag and store the $CRV in the contract until we've been approved.
• After approval it will need to lock the CRV to allow voting.

Success Criteria:

A successful bounty will include:

• Delivery of all three elements of the CRV locking implementation
• The ability to have users deposit CRV and receive amphCRV
• The ability for the locker contract to hold CRV until our implementation has been approved
• The ability for the locker contract to lock veCRV after our implementation has been approved
• The ability to claim rewards from our locked veCRV position and forward them to a treasury contract
• The ability for the owner to set a treasury contract
• The ability for an owner OR a vote manager role to vote using the veCRV position
• Unit tests (written in Hardhat) in the /tests folder. They should cover test cases for both before and after approval.
• Solidity 0.6.12 or 0.8.4 preferred but not mandatory.
• Should be well organized into its own folder under /contracts

Candidate Selection:

Preference will be given to Gitcoin candidates who have done similar types of work, and who outline the approach they would take in their application.

Preference is also given to candidates (on Gitcoin or not) who have worked with Amphora in the past.

Bounty Payout:

The payout for a successful implementation is $2k.

https://gitcoin.co/issue/29374

The goal of this bounty is to create a vesting system.

In the Amphora protocol, our main governance token is $AMPH, but when users receive rewards they are received in $vAMPH (Vesting Amphora) which is a standard ERC-20 mintable/burnable token with no additional special features.

Users will use a specialty vesting contract to vest and unlock the $vAMPH.

When a user creates a new vesting position, the contract will take their $AMPH and they will be able to choose between:

• An instant unlock that pays out 0.25 $AMPH per $vAMPH
• Up to a 4 year unlock that pays out 1.12 $AMPH per $vAMPH

A user can decide to select any amount of time within that time frame, the contract should mint the total amount of tokens and store it in the contract at the start. The should be able to claim their vested amount each day. The amounts in between those two options should be on a curve so that vesting longer is always significantly more favorable and not just a linear function.

When a user has additional $vAMPH to vest then the contract will either need to:

• A) Figure out how to adjust the end date and tokens to claim per day, so the users new vest is properly factored in.
• B) Or, create a new vesting streaming.

If option B (which is likely safer) then it should also:

• Have a function to look up all streams
• Have a function to claim from all streams at once.

If you choose to implement with multiple streams you can choose the structure you think is best, either multiple streams defined by a mapping, or an array, or even different contracts deployed via a factory.

Elements of a Successful Bounty:

• A vesting contract that accepts token X
• Lets a user pick a day between A and B and creates a vesting stream of claimable tokens
• Users can easily see their total vesting tokens and tokens available to claim from each position with viewable functions
• Users can easily see the final vesting date of each stream
• You've written detailed test coverage (in Hardhat) that fits into /AmphoraProtocol/tests and tests each element of the vesting contract
• The contract owner should be allowed to pause/halt the creation of new vesting streams.
• Implementation is preferred in Solidity 0.6.12 or Solidity 0.8.9 so it aligns with other contracts in the repo.
• If using Solidity 0.6.12 please ensure to use the appropriate safemath libraries from the repo.

Candidate Selection:

Preference will be given to Gitcoin candidates who have done similar types of work, and who outline the approach they would take in their application.

Preference is also given to candidates (on Gitcoin or not) who have worked with Amphora in the past.

Bounty Payout:

The payout for this bounty is $3k in USDC.

https://gitcoin.co/issue/29373

Similar to Convex's cvxCRV, Amphora will support a amphCVX

For this bounty you should create a contract that can

• Accept CVX from a user and return minted amphCVX.
• Lock the CVX balance as vlCVX in Convex.
• Claim rewards from the Convex contracts for vlCVX and send them to an address called 'RewardSplitter'
• Delegate vlCVX voting power to an address defined by contract owner.
• Let the owner change the RewardSplitter.

Success Criteria:

A successful bounty will include:

• Delivery of the contract with features outlined above.
• Unit tests (written in Hardhat) in the /tests folder. They should cover test cases for both before and after approval.
• Solidity 0.6.12 or 0.8.4 preferred but not mandatory.
• Should be well organized into its own folder under /contracts

Candidate Selection:

Preference will be given to Gitcoin candidates who have done similar types of work, and who outline the approach they would take in their application.

Preference is also given to candidates (on Gitcoin or not) who have worked with Amphora in the past.

Bounty Payout:

The payout for a successful implementation is $2k.

https://gitcoin.co/issue/29375

We want to combine some of the Booster and Vault Controller logic to make a cleaner integration.

The goal for user experience:

• User goes to our site, and sees a list of assets they can deposit. These are both regular ERC20 tokens and LP tokens.
• The user hits deposit, and the asset goes into their vault.
• If the asset is an LP token the user sees rewards growing in their vault and can hit a 'claim' button to claim those rewards.

Current issues:

• To start vaults only counted a users collateral balance using ERC-20 tokens in the address. We updated this to include LP tokens by adding a balance tracker, this way LP tokens can count as collateral AND be deposited into BaseRewardPools.
  -- But, this means we've got to have two different functions to support depositing ERC-20 and LP tokens, and it is messy.
• The current Booster logic is sloppy and challenging to maintain.

Ideal:

• Vault Controller contains a mapping of supported tokens (ERC-20 and LP tokens)

• Each token now has a "wrapping" address, a contract which will wrap the token and apply any needed logic.

• Each token will have a reward pool (like the kind in the booster) generated for it when it is added to the system.

• Vault Controller contains a mapping of tokens -> a token wrapping contract

• Vault Controller contains a struct mapping of reward pools.

• Vault Controller has one deposit function.

• The deposit function checks if a token is supported, if it is, it then checks if it is an LP token (such as $3CRV).

• If it is an LP token, the token is sent to a wrapping contract. The wrapping contract deposits the $3CRV into Convex. It then deposits a $w3CRV into the users vault, and a $3CRVdepositToken into the BaseRewardPool on behalf of the vault address.

• If it is not an LP token, it should be sent to the wrapping contract. The wrapping contract will just hold the token. It then deposits a $wX token into the users vault, and a $XdepositToken into the BaseRewardPool on behalf of the vault address.

• The users collateral is calculated by reading the wrapped tokens + any regular ERC-20 tokens. So Oracles will need to map both.

• When a wrapped token is liquidated, the depositToken will need to be withdrawn from the reward pool, then the token will need to be unwrapped and the underlying ERC-20 token will be sent to the liquidator.

The file /contracts/USDA.sol is based on "USDI" from Interest Protocol, but the contract has been changed to include a fee on transfer mechanism through its inherited contract in /contracts/token/UFragments.sol

For this bounty, you should:

1. Review the changes to the contract.
2. Make any suggestions on improving efficiency or code.
3. Identity and propose a solution to issues.
4. Write a series to cases to test the new features.

The tests should cover:

• Standard transfers
• Deposits and withdraws from a Curve pool
• Deposits and withdraws from a Uniswap V2 pool
• Exchanges with a Curve pool
• Exchanges with a Uniswap pool
• That all update functions have correct permissions
• That all update functions are working

Tests should be written in Hardhat and be added into the testing set up on this repo.

Bounty Payout:

This bounty will pay out $500 in USDC

https://gitcoin.co/issue/29376