commonsbuild / proposal-inverter Goto Github PK

Is it possible to add this as a feature to the proposal inverter?

Simply adding an attribute to the proposal inverter "Minimum number of DAOs" or "Minimum Funding"
And allowing the contract to be initialized with less then the minimum, but "Frozen" until the minimum is met.

The minimum horizon and allocation per epoch determines the minimum funds that are required before funds can begin being allocated to brokers. There may be other funding goals that need to be met over a longer course of time. This may be out of scope of this project, but may be an important case to consider.

1. How do we track these funding milestones? For example, the initial minimum funds may be 300 tokens, but over the course of 20 epochs, the funding milestone may total 500 tokens while the project continues development.
2. What happens if funding milestones are not met? Should there be changes to certain parameters, like decreasing the allocation of funds per epoch to accommodate lower funds? Should the proposal be cancelled altogether?
3. What happens if funding milestones are met?

Since owners can deploy a proposal without meeting a minimum horizon, the process of the proposal inverter is effectively split into two phases:

1. The "Fundraising" phase, where the proposal remains stagnant until enough funds have accumulated to meet the minimum requirements.
2. The "Research" phase, where the proposal begins to allocate funds to the committed brokers.

Should the "Fundraising" phase not reach its target in a timely manner, the owner of the proposal may choose to cancel the proposal. In this case, the funds should be returned to the payers.

• In the ProposalInverter.cancel() method, if ProposalInverter.started is False, then the funds in the ProposalInverter.payer_contributions should be reallocated to their respective payers and all committed brokers should have have their stake reallocated to them

Spin up Owners, Brokers, and Payers dynamically per step.

Testing the economics (The flow of value through wallets)

And also the mechanism (Lot's of Owners, Borkers, and Payers)

And having actors with overlapping roles.

The owner should be able to choose a consensus mechanism on initialization

1. Owner has full authority
2. Any Payer has authority
3. Unanimous Payers have authority
4. Percentage of Payers have authority
5. Fund-weighted authority

At the moment, the WhitelistMechanism is designed to be a one way system. Once brokers are whitelisted, they stay there permanently. When a vote for a broker is changed, this may affect a broker's whitelist status.

However, this means that a broker that is already committed to a proposal may be removed from the whitelist, but still remain a broker on the proposal. Whether or not the broker should be immediately removed from the proposal is an open question.

• Keep past voting information in the WhitelistMechanism
• Add a remove_from_whitelist method
• When a voter votes, consider what happens if the broker is already in the whitelist. If the minimum condition is not longer met, then the broker is removed from the whitelist and added back to the waitlist
• Add removing unit tests

There may be a minimum amount of funds a payer must pay if they choose to contribute. This is to help ensure payers will not play a long waiting game of trying to contribute as little as possible to get a proposal running.

• Add a parameter that defines the minimum payer contribution
• In the ProposalInverter.pay() method, the payer's contribution should be checked to be greater than or equal to the minimum payer contribution