impactmarket / smart-contracts-dao

Solidity smart-contracts for impactMarket protocol.

impact-market-smart-contracts

Solidity smart-contracts for impactMarket protocol

Install

$ nvm use
$ yarn

Build / Test / Deploy

$ yarn build
$ yarn coverage
$ yarn deploy
$ yarn test

Documentation

• Generate with yarn docgen
• Navigable HTML documentation from ./docs/index.html

Contracts

Contract	Purpose	Address
/airgrab/MerkleDistributor.sol	Merkle Distributor for the initial token airgrab	0xd2b20e06C19e7b7E7E385b0F1386Cdde8C6dCd2B
/community/CommunityImplementation.sol	A UBI community that is funded by Impact Labs which beneficiaries claim from	0xEc94c60f17F7f262973f032965534D1137f1202c
/community/CommunityMiddleProxy.sol	CommunityMiddleProxy	0xe8037e4ceEd80EC6D02f482a5A35E0011245FCDC
/community/CommunityAdminProxy.sol	Proxy contract that orchestrates creation of new Communities	0xd61c407c3A00dFD8C355973f7a14c55ebaFDf6F9
/governance/ImpactProxyAdmin.sol	Contract that is in charge of all the proxies	0xFC641CE792c242EACcD545B7bee2028f187f61EC
/governance/PACTDelegator.sol	Proxy contract that manages creation, execution, cancellation of proposals	0x8f8BB984e652Cb8D0aa7C9D6712Ec2020EB1BAb4
/governance/PACTTimelock.sol	Timelock that marshalls the execution of governance proposals	0xca3171A5FCda4D840Aa375E907b7A1162aDA9379
/token/DonationMinerProxy.sol	Proxy vesting contract for non-airgrab distribution of tokens	0x1C51657af2ceBA3D5492bA0c5A17E562F7ba6593
/token/ImpactLabsProxy.sol	Vesting contract for ImpactLabs distribution of tokens	0x767DA1d208DDA5bc517dcd4ba2A83591D68A5535
/token/PACTToken.sol	The Impact Markets cERC-20 token contract	0x46c9757C5497c5B1f2eb73aE79b6B67D119B0B58
/token/TreasuryProxy.sol	Contract that manages the funds	0xa302dd52a4a85e6778E6A64A0E5EB0e8C76463d6
/token/TreasuryLPSwapProxy.sol	Contract that manages the funds	0xb062e54eBe08d3f720Fc2798f5D6B282df7753ED
/staking/StakingProxy.sol	Contract that manages the staking	0x1751e740379FC08b7f0eF6d49183fc0931Bd8179
/governor/impactMarketCouncil/ImpactMarketCouncilProxy.sol	ImpactMarketCouncilProxy	0xF2CA11DA5c3668DD48774f3Ce8ac09aFDc24aF3E
/ambassadors/AmbassadorsProxy.sol	AmbassadorsProxy	0x25f58d8C2522dC7E0C53cF8163C837De2415Ba51
/airdropV2/AirdropV2Proxy.sol	AirdropV2Proxy	0x482E748D452e6ECD86D58E597B673C5E653dAbe9
/learnAndEarn/LearnAndEarnProxy.sol	LearnAndEarnProxy	0x496F7De1420ad52659e257C7Aa3f79a995274dbc
/deposit/DepositProxy.sol	DepositProxy	0xF9163f95DF91ad103659cb7C8936Aceb63c7E410
/microcredit/ImpactMultiSigProxyAdmin.sol	Contract that is admin for some proxies	0x5e7912f6C052D4D7ec8D6a14330c0c3a538e3f2B
/microcredit/MicrocreditRevenueProxy.sol	Contract that receive all interest from the microcredit contract	0xa75D14c212df85F24ead896747cb1688C1F889D7
/microcredit/MicrocreditProxy.sol	Proxy for the microcredit pilot	0xEa4D67c757a6f50974E7fd7B5b1cc7e7910b80Bb

smart-contracts-dao's Issues

Merkle Distributor

Governance DAO (18)

• #4
• #5
• #6
• #7
• #8
• #9
• #10
• #11
• #12
• #13
• #14
• #15
• #16

Buyback PACT

Is your feature request related to a problem? Please describe.

_

Describe the solution you'd like

The DAO would use the reserve assets, deposit them on an AMM and use the interest to buyback PACT.

Additional context

_

Donation Bucket / Social Mining Unit tests

Migration of old communities

Economics: genesis recipients confirmed / formalized

DAO unit tests, convert to Truffle/hardhat

Vesting contract for original airdrop recipients

https://github.com/gitcoinco/governance/blob/main/contracts/TreasuryVester.sol

Allow communities to use other currencies

Is your feature request related to a problem? Please describe.

Currently, every community uses cUSD.

Describe the solution you'd like

Every community should be able to select a currency to use.
It should also be possible to change the currency at any moment. Changing the currency should swap existing balance of the community with the new currency.

Additional context

This allowed currencies should be governable by the DAO.
Make sure this currencies addresses are upgradable by the DAO, converting all funds.

stories as NFTs

• A contract that can mint stories
• Only beneficiaries can mint
• This contract will then integrate with ARI nft marketplace aftermarket contract

Deploy DonationMiner on another networks

Is your feature request related to a problem? Please describe.

Currently, the impact farming is deployed only on Celo network. This limit us to the Celo users and cStables circulating.

Describe the solution you'd like

We should be able to attract capital (donations) from other networks.

Additional context

Currently, 40% of the total PACT supply is allocated to the impact farming on Celo. It should still be 40%, but split across chains.
The goal is to deploy only the bare minimum to get the donations rewards working on another chains.

Clone gitcoinco/governance module

https://github.com/gitcoinco/governance/blob/main/contracts/GovernorAlpha.sol

Script for retroactive airdrop recipients (by 17th Aug)

Token holdings:

• 30% Team allocation (vested for 9 years)
• Create vesting contract for team
• Impact Labs multi-sig target
• 10% Retroactive airdrop (we'll create script)
• 40% Donation mining / "Treasury"
• 20% Spare/DAO reserve / "Treasury"

Main: donation bucket / token reward contract (by 31st Aug)

[TBD] Private communities

(This is WIP)

Is your feature request related to a problem? Please describe.

There's possible interest in having private communities. Even though, these interested parties will not want to run their own infrastructure. Initially, we thought of deploying standalone contracts, but that initially worked because we used our own indexer. Although, it does not work since we are using TheGraph. On top of that, it's hard to keep updating in terms of contract functionality.

Describe the solution you'd like

Communities should have an option to be private. They should not be able to switch between private and public. Once defined, it's done.

Additional context

Private communities should not have their information indexed for general UBI global data and should not have ambassadors.

Create token contract

Clone of https://github.com/gitcoinco/governance/blob/main/contracts/GTC.sol

Raise PR for Romulus

Community Claim Function (by 6th Aug)

Deposit and redirect interest as donations

Is your feature request related to a problem? Please describe.

The only donation mechanism working right now is one-time donation.

Describe the solution you'd like

It would be good to have other donation methods. One interesting model would be the deposit and redirect interest. This was the user won't spend money and is always donating until removing that.

Additional context

It should get rewards as well.

Limit number of beneficiaries per community

Is your feature request related to a problem? Please describe.

When a community is created, there's no limit number of beneficiaries. This is one of the trust assumptions and a real problem. Without any limitation, a new community can add hundreds if not thousands in minutes and drain a large amount of funds.

Describe the solution you'd like

To a more sustainable and controlled growth, communities should have a limit on the number of beneficiaries. The Ambassador of that community should be able to edit the limit as well as the subDAO.

Additional context

The limit could be zero, meaning, unlimited.

Upgrade existing Community contracts

Migrate funds to a new community?

Add ABDK floating point mathematics to donation mining contract

Upgrade all contracts to ^0.8.0

Add support to different community implementations

Is your feature request related to a problem? Please describe.

Currently, there's only one type of community (with some to have an exception). It's thinking about that exception that the idea of having different implementations came up. Different communities in different situations might need different community (aka smart contracts) implementation.

Describe the solution you'd like

At deploy time, it should be possible to send the address of the implementation to be used. That implementation should be in communityAdmin registry and it should be possible to add or remove implementations through a DAO proposal.

Connect DAO to Mining Contract

Retroactive Airdrop Unit tests

Discourse content

To be done by ImpactLabs

Reward mechanism (by 13th Aug)

Claim tokens, not immediately awarded at donation time

UI design elements document

Make contracts upgradeable

Auto staking

Is your feature request related to a problem? Please describe.

When a user makes a donation, a percentage of tokens are allocated. But to stake, the user needs to interact with the contracts.

Describe the solution you'd like

A user should have the option to auto stake. Meaning, once tokens are allocated they are automatically staked. The use should be able to opt ou/in at any moment.

Additional context

Add replace beneficiary

Is your feature request related to a problem? Please describe.

If a beneficiary loses an account, a new one is added. The problem is, it starts from the beginning, resulting in one beneficiary receiving more than the others.

Describe the solution you'd like

A method like replaceBeneficiary(_previousAddres, _newAddress) which would copy the status of _previousAddress to _newAddress and make _previousAddress a replaced beneficiary (so, not allowed to claim, etc)

Additional context

Should prevent the replaced address from doing anything, or this can be exploited.

Recurring donations

Is your feature request related to a problem? Please describe.

The only donation mechanism working right now is one-time donation.

Describe the solution you'd like

It would be good to have other donation methods. One interesting model would be the recurring donations as they exist today. The use would donate X each Y days.

Additional context

It should get rewards as well.

Mining Contract / Donation Contract (8 1/2)

• #17
• #18
• #19
• #20
• #21

Add support to redirect rewards

Is your feature request related to a problem? Please describe.

As other projects want to give part of their fees or allow users to redirect part of their yields, on impactMarket side, the donate and donateToCommunity only give the rewards to the address submitting the call, which if called within a contract is therefore the contract, not the user.

Describe the solution you'd like

donate and donateToCommunity should support selecting an address to redirect rewards.

Additional context

Maybe something like function donate(uint256 _amount, address _rewardsTo)

Withdraw generic tokens

Management of non-supported assets - withdraw to DAO

Connect DAO to CommunityFactory

Set owner on CommunityFactory -> DAO

Donation Referral

The Problem

People make donations, but they don’t currently have a way to share that (unless sharing the explorer URL) and they also don’t have an incentive to make others donate.

The Solution We Are Looking For

Donation Referrals. It would simply be a referral link (eg: https://impactmarket.com/?donation=true&referral=0xfa521384f3e13970fb&msg=4). All that must be trustless (verifiable on-chain). This is achievable using signatures. So when a user makes a donation, in the end, wou<ld sign a message to share as a referral link. That message should contain only the epoch number where the user donated. The signature is a hashed string that can then be used to verify on-chain by whom it was signed.

Because signatures don’t expire, each referral link should be usable only X times.
For each donation made using the referral link, both the person who donated and the person who created the referral will be considered as if they have donated Y$ more for each Z$ donated.

Example:

Lets consider, for each $10 donated, both users get another $0.10 and a referral link can only be used twice.
Bob donates $20 and shares a referral link
Alice donates $12 using the referral and is considered has $12.10 for rewards
Maria donates $5 using the referral link, does not get extra, and does not subtract the number of usages of the referral link
Amir donates $21 using the referral and is considered has $21.20 for rewards
Yolanda donates $11 using the referral, but it has expired and does not get extra rewards

This only requires changes on donate and donateToCommunity methods on DonationMinerImplementation contract.

Requirements

• Fork impactMarket repository and start working based on it (not from scratch)
• Open a PR once finished (or during development in draft mode)
• Tests (because it changes a existing contract, make sure you test migrations)

Definition Of Done

• Number of usage of a referral link must be editable (through DAO proposal)
• Donate to the treasury or community using referral and get extra rewards
• A referral link should work considering a past epochs (not only current epoch)
• All Tested

Milestones

• Donation Miner Implementation contract changes (with tests)

Allow DAO to send IPCT to recipients

Generic asset control

Add batch functionality

Is your feature request related to a problem? Please describe.

For a manager to add 5 beneficiaries it requires 5 transactions. It's a process that makes any action take longer.

Describe the solution you'd like

It should be possible to do addBeneficiaries(_beneficiaries).

Additional context

There should be a limit, due to transaction limits as well as to prevent a manager from adding a large number of beneficiaries.

Snapshot.org configuration

May require custom creation of a strategy

Ambassadors Contract

The Problem

For each community in impactMarket, a contract is deployed. While the DAO governs the treasury, acceptance, and removal of communities, it does not control what happens within each community. And in fact, that should not be the goal. Imagine the DAO worried with millions of beneficiaries in thousands of communities.

So, ever since the beginning (even when impactMarket was not a DAO), we used to have ambassadors. Ambassadors are impactLabs's team members and play a crucial role in accessing communities. They have direct contact with community(ies) on the ground enabling them to introduce, onboard, and create a community to start a UBI program on impactMarket.

Still, ambassadors have no control over those communities. They are not able to add or remove beneficiaries or managers. We are basically leaving the community to govern itself, in the hands of managers, the ones who are able to add/remove other managers or beneficiaries.

The Solution We Are Looking For

This current design leads to problems. The manager adds beneficiaries (or managers) at will. They might stop to answer ambassadors. Etc.

So the solution is to let ambassadors play their role accordingly. To do so, when a community is created, it should have an ambassador linked to it. Managers would not have the ability to add other managers, only beneficiaries. And other managers would be added by the ambassador. And ambassadors would be added/removed by impactLabs multisig.

As we want to keep the protocol open to anyone, for development purposes, impactLabs multisig should be seen as a “private entity” and it should be possible to have many different private entities. This allows any other entity to do the same, not depending on DAO’s decision. Private entities should be registered through DAO proposals. On the other hand, an ambassador can be directly added by the DAO too.

Ambassadors smart-contract holds private entities registry, where does the ambassador “belongs” (private entity or DAO)

Something like the following.

Requirements

The ambassadors’ contract needs to be upgradable like all the others are now and owned (which then can be transferred to the DAO).
Fork impactMarket repository and start working based on it (not from scratch)
Open a PR once finished (or during development in draft mode)
Tests

Definition Of Done

Ambassador contract is upgradable (following the same format as existing ones)
DAO add/remove private entities
Private entities and DAO add/remove ambassadors (each one controls it’s own)
Ambassador add/remove manager in a community where is an ambassador
All Tested

Milestones

Ambassadors contract (upgradable) (with tests)
Ambassadors adding/removing managers (with tests)

Economics: token mining / configuration

https://docs.google.com/document/d/1eYZgnav0rAVFBW1aZdMfiOQsPz9HRRzbE7XlQuc2be8/edit#heading=h.ut0wliunxym

Retroactive Airdrop (10 1/2)

• #22
• #23
• #24
• #25
• #26

10 1/2 days

Invalid method description in CommunityAdmin

Just read the description for onlyOwnerOrUBICommittee method. Should be obvious.

https://github.com/impactMarket/impact-market-smart-contracts/blob/d60d7b219e04964d283b16a23ae42aaa21abfdf8/contracts/community/CommunityAdminImplementation.sol#L152-L155

Architecture Overview Document

Create Discourse forum

ipfs hash on community contracts

Is your feature request related to a problem? Please describe.

The /community/list endpoint on impactMarket backend uses data from two sources, a database, and TheGraph. But as of now, TheGraph is only indexing information from the contracts.
It would be too expensive to order by country the biggest communities in a given country once there are 1000 communities in a given country and 10000 globally. The same with ordering by distance.

Describe the solution you'd like

TheGraph allows to get data from IPFS and index it together with smart contracts data. This would allow performing a single query to a single data source avoiding long queries and possible errors.

Additional context

• https://ipfs.io/
• https://thegraph.com/docs/en/developer/create-subgraph-hosted/#ipfs-on-ethereum-contracts
• https://thegraph.com/docs/en/developer/create-subgraph-hosted/#defining-fulltext-search-fields

Access control / DAO / documentation

Front end / claim page

ImpactMarket website/app - ImpactLabs

Claim - initial airdrop
Claim - new rewards from donations