pitch: multiple types of rounds

[lmcorbalan]

Context

When a DAO lunches and it tries to bootstrap an ecosystem of builders, the DAO creates a grant program to compensate those who are interested in building the projects it is interested in, so that it can ensure its community and ecosystem grows in a healthy way with accountability and opportunity for others in the future.

When its grants program starts to grow, the DAO wants to make sure it can keep track of each of the projects success and encourage them to participate in other events they have, so that it doesn’t lose talent from its ecosystem.

The goal of any direct grants program is to attract and retain builders in an ecosystem.

So BootNode team is building a new Direct Grant Program product/feature. Ideally it would be included as part of the Grant Stack.
This new grant program has a different flow than the current one, and it goes like:

• Program Manager creates Grant Program

  • nothing changes here

• Program Manager creates new direct grant round

  • it doesn't have a defined matching amount, the DAO could have an open or closed budget
  • it doesn't have application/round stages
  • grant payouts are pulled from an external wallet to project wallet, ideally a DAO multisig
  • grant payouts do not depend on a voting process, the application goes through the DAO reviewing process which decides if the application is accepted or not, then at at some point agreed by the project and the DAO during revision process (milestone) the PM triggers a disbursement
  • projects can apply while the round is open
  • applications statuses are (it may need more):

    - received 
               -> in review
                           -> accepted
                           -> rejected
                           -> withdrawn
               -> withdrawn

• Builder creates project

  • nothing changes here

• Builder applies with project to a Direct Round

• DAO review project application

• Builder updates application

• Program Manager approves/rejects builder’s application

• Program Manager pays builder’s accepted grant when milestone is reached

Problem
The current system only allows the creation of a single type of round, the one that is set as roundImplementation on the RoundFactory contract.

Solution
Update the current implementation of the RoundFactory contract, allowing the deployment of different roundImplementations based on a type identifier.
It may be also necessary to make some changes on IRoundImplementation to make it more generic, removing some of the functions that are coupled to the current RoundImplementation (QF round). e.g. vote, setReadyForPayout and updateStartAndEndTimes.

[thelostone-mc]

Hmm as opposed to having different flavours on RoundImplementation.
I'm wondering if those functions which you mention get moved to the voting strategy contract.
That way: If you wanted to use QF -> you would be able to interact with the voting contract to get all the functionality

Could you list out what all functions you feel aren't required as a part of the direct grants program which shouldn't live on the round implementation (assuming you had to use the same one)

[lmcorbalan]

The changes I would propose are:

RoundFactory (to handle multi type rounds deployment process)

• add mapping(bytes32 => address) roundTypes ( type id -> round implementation address)
• add function updateRoundType(bytes roundType, address newRoundImplementation) external onlyOwner
• remove updateRoundImplementation function
• update create function
  • add bytes32 roundType parameter
  • deploy round based on roundType
• update event RoundCreated
  • add bytes32 roundType
• remove event RoundImplementationUpdated
• add event RoundTypeUpdated(bytes32 roundType, address roundImplementation)

IRoundImplementation (notice I'm referring to the interface not the implementation)

• remove vote function
• remove setReadyForPayout function
• remove updateStartAndEndTimes
• update applyToRound
  • add bytes encodedParameters which would be decoded and used on each round type implementation

RoundImplementation

• change name to VotingRoundImplementation (or something related to QF maybe)

DirectRoundImplementation is IRoundImplementation

• new contract with direct round requirements

[thelostone-mc]

Hmm I'd have another suggestion in mind.
What would need to happen to use the same RoundImplemenation for both direct grants as well the existing QF rounds
If there are functions which aren't used -> we could discuss moving them out into QF voting contract

[0xZakk]

This feels very patch-y to me and I'm not convinced that adding round types is solving the underlying problem in a sustainable way. We do want the round to be flexible to accommodate different types of allocation strategies and there is arguably some logic in the round contract is really part the allocation/voting logic.

That said, I don't think adding round types solves the problem in a sustainable way. The round is the center of the protocol and what creates the set of design constraints within which allocation strategies can operate. Also, creating a new round type opens the door for even more round types, which is not a game I think we want to be playing.

I'll also add that, strategically, the round offers a consistent interface for people building on the protocol. In order for an ecosystem of tooling for rounds to develop, there needs to be a consistent interface for all rounds, which our current round contract offers. This is why vote(), setReadyForPayout(), applyToRound(), etc are on the Round and not on the strategies. It is way easier for someone building a front end for all rounds. Starting to create multiple round types is going to make it really difficult for people to build tooling around Allo.

@lmcorbalan - could you possibly expand on what issue you're running into with the current round that prompted the idea of creating round types? I'd be interested in specifically hearing what do you think should be possible with our current round implementation, but isn't.

[thelostone-mc]

Perfect. So me and @KurtMerbeth had another way of going about this.
We figured you could use the timestamps as is :

Time Settings:

• set the application and round start to the same
• set the application end and round end to the same (this could be max number if we want. round which never ends)
• if an operator wanted to abruptly end a round -> they could use the updateTimestamp function to make that decision

Voting Strategy ---> This is being renamed to AllocationStrategy

• The idea would be to introduce a new allocation strategy which does all the milestone review / payments
• the vote function in round would be renamed to allocate (this is something we are working on at the moment)

On Round contract

  function allocate(bytes[] memory encodedData) external payable {
    // slither-disable-next-line timestamp
    require(
      roundStartTime <= block.timestamp &&
      block.timestamp <= roundEndTime,
      "Round: Round is not active"
    );

    allocationStrategy.allocate{value: msg.value}(encodedVotes, msg.sender);

    // - only round opearator can call this function
    // - 1 time -> miletsone
    // - money is sent. 

    // Project Update
    // - voting contract 
    /// --> milestone 1 -> 

  }

In the new voting strategy

// store project -> milstone mapping
// capture status of every milestone within that mapping 

function allocation() {
 // get project id and milestone id 
 // change status of milestone to paid 
 // make the payment
}

// you would have other functions  like

function signalMilestoneComplete () {
// invoked by project owner to signal milestone has been completed
} 

function rejectMilestone() {
// can be invoked only by round creator 
}

In this way -> you would be using the allocation strategy to allocate funds to the project owners.
You would not need to use the payout function.

[0xKurt]

After a discussion with @thelostone-mc, I started a draft AIP to improve the RoundImplementation by removing quadratic funding related code from the round to increase the flexibility of the round contract and enable running rounds with all kinds of voting/allocation strategies.

It really makes sense to move all this code into the strategy, independent from direct grants.

I also shared my idea of the application statuses with @thelostone-mc , but would like to share it here too.
It makes sense to extend the application statuses (this will need another AIP, just sharing my thoughts)
The current implementation:
0: Pending
1: Approved
2: Rejected
3: Canceled

Especially 0: Pending is nothing one can relay on (at least on chain). Status 0 should refer to no application.
I would like to see something like:
0: no application
1: Pending
2: Approved
3: Rejected
4: ApprovedReapplied
5: RejectedReapplied
6: Free
7: Free

These should enable you to be as flexible as you need it.

[lmcorbalan]

I also shared my idea of the application statuses with @thelostone-mc , but would like to share it here too. It makes sense to extend the application statuses (this will need another AIP, just sharing my thoughts) The current implementation: 0: Pending 1: Approved 2: Rejected 3: Canceled

Especially 0: Pending is nothing one can relay on (at least on chain). Status 0 should refer to no application. I would like to see something like: 0: no application 1: Pending 2: Approved 3: Rejected 4: ApprovedReapplied 5: RejectedReapplied 6: Free 7: Free

So the idea for this is to use 4 bytes instead of 2, right?

[lmcorbalan]

Perfect. So me and @KurtMerbeth had another way of going about this. We figured you could use the timestamps as is :

Time Settings:

• set the application and round start to the same
• set the application end and round end to the same (this could be max number if we want. round which never ends)
• if an operator wanted to abruptly end a round -> they could use the updateTimestamp function to make that decision

ok!

Voting Strategy ---> This is being renamed to AllocationStrategy

• The idea would be to introduce a new allocation strategy which does all the milestone review / payments
• the vote function in round would be renamed to allocate (this is something we are working on at the moment)

This would be the only strategy linked to the round so this idea removes PayoutStrategy, right?

On Round contract

  function allocate(bytes[] memory encodedData) external payable {
    // slither-disable-next-line timestamp
    require(
      roundStartTime <= block.timestamp &&
      block.timestamp <= roundEndTime,
      "Round: Round is not active"
    );

    allocationStrategy.allocate{value: msg.value}(encodedVotes, msg.sender);

    // - only round opearator can call this function
    // - 1 time -> miletsone
    // - money is sent. 

    // Project Update
    // - voting contract 
    /// --> milestone 1 -> 

  }

I think that since on QF round voters will be using the allocate for voting, anyone should be able to call the round contract's allocate function, but the caller should be validated (if required) on AllocationStrategy allocate function.

[0xKurt]

So the idea for this is to use 4 bytes instead of 2, right?

Yea. The idea would be to have at least 3bit, but since 3 are a little bit off, I would propose 4bit too. :D

This would be the only strategy linked to the round so this idea removes PayoutStrategy, right?

Yes

I think that since on QF round voters will be using the allocate for voting, anyone should be able to call the round contract's allocate function, but the caller should be validated (if required) on AllocationStrategy allocate function.

That was the idea. Maybe not described in the best way :D

[lmcorbalan]

@thelostone-mc @ZakkMan @KurtMerbeth I need to apologize because I assumed everyone would be in context already, so I added a Context section in the discussion description

[thelostone-mc]

We will taking this up tomorrow and have a implementation + AIP proposed.

So this is what we will be taking care of :

• The creation of allocation strategy
• Moving payout and voting into allocation strategy
• Fixing it up so that direct QF works as it works currently
• Updating the interface to remove an un-needed functions

The changes here would be merged into v1.0.0 branch
https://github.com/allo-protocol/allo-contracts/tree/v1.0.0

The goal here is to introduce the allocation strategy and then have you guys review it to ensure you have everything you need to be unblocked

[nfrgosselin]

@lmcorbalan @thelostone-mc @KurtMerbeth @ZakkMan I'm organizing the threads here.

The proposed AIP from the Allo Protocol team (AIP-8) has been drafted and there is a discussion thread open. Please provide feedback over on the dedicated discussion thread.

Re: application status, I agree with @KurtMerbeth that this should be a separate AIP. I'll defer to you on whether you want to open a separate discussion thread for that.

[0xKurt]

@lmcorbalan @thelostone-mc @nfrgosselin
i created a new discussion(#26) for the application statuses.
Would like to hear your opinion on it.