# Grant Ships - Milestone 2 Amended Schedule

**Current Amended schedule:**
* **Milestone 1, 3 weeks**
* Start: 11/20/2023
* **Milestone 2: 9 Weeks (+1 week for holidays)**
* Start: 12/11/2023
* **Milestone 3: 3 Weeks**
* Start: 2/26/2024
* **Milestone 4: 4 Weeks**
* Start: 3/18/2024
* End: 4/15/2024

**DAO Masons Feb 12 2024:** An additional 2 weeks is required to work out bugs related to MVP delivery. New Milestone 2 end date is Feb 26 2024, ready for demo Feb 23 2024.

**DAO Masons Jan 29 2024:** As mentioned at the meeting Friday, because of the additional scope added to make the project work as intended (Allo contracts), while satisfying the requirements of running a multi-manager program on Arbitrum, we are requesting an additional two weeks for Milestone 2.

**Original Schedule:**

* **Milestone 1, 3 weeks**
* Start: 11/20/2023
* **Milestone 2: 7 Weeks (+1 week for holidays)**
* Start: 12/11/2023
* **Milestone 3: 3 Weeks**
* Start: 1/29/2024
* **Milestone 4: 4 Weeks**
* Start: 2/19/2024
* End: 3/18/2024

**Amended schedule #1:**
* **Milestone 1, 3 weeks**
* Start: 11/20/2023
* **Milestone 2: 9 Weeks**
* Start: 12/11/2023
* **Milestone 3: 3 Weeks**
* Start: 2/12/2024
* **Milestone 4: 4 Weeks**
* Start: 3/04/2024
* End: 4/01/2024

**Amended schedule #2:**
* **Milestone 1, 3 weeks**
* Start: 11/20/2023
* **Milestone 2: 11 Weeks**
* Start: 12/11/2023
* **Milestone 3: 3 Weeks**
* Start: 2/26/2024
* **Milestone 4: 4 Weeks**
* Start: 3/18/2024
* End: 4/15/2024

We're not asking for any additional funds.

## How we got here.

### What was wrong with the original plan

The original plan for Grant Ships was to build a front end using existing smart contracts. The plan was to never touch Solidity at all, to save time and test player behavior before 'locking in' the game rules in a Smart contract. As we all know, contract development is time-consuming and challenging.

We also planned on sourcing data from existing protocols data using their subgraph endpoints. We would instead focus more on the event, gathering the people, and making sure the game is played as expected.

This was a great plan on paper. However, once we began doing our initial tests, we began to discover issues.

- The original design as presented in the proposal involved the facilitators holding all the funds in a safe. Even though we were willing to tolerate this centralization for the test round, it was still vulnerable to capture.
- Accounting errors. We would have needed to partition the funds in the safe and manually keep track of which funds are going to which project. This meant that we were now tracking everything through spreadsheets, which is error-prone. Again, tolerable for a test round but not ideal.
- **The biggest challenges came from the Safe API**. We didn't know this, but pushing TXs to a Gnosis Safe involved signing, hashing, and posting data to a centralized server. **This gets complicated when you are trying to use Hats**. We could not find a seamless way to make Hats (onchain) work with this API (offchain) without making our ship operators do things manually.
- Also, gas estimation is another issue. Having worked with the Gnosis gas estimation API for MolochDAOs, I've learned the challenges of relying on a centralized API for Multicall transactions. It can sometimes be an unnecessary blocker. Also, L2's calculates gas differently. These challenges are surmountable but weighed in the decision process for steering away from Safe.
- So in essence, we had no way of having our ships post grant requests to facilitators.
- Data availability was another issue. We were unprepared for the amount of content required to provide a seamless experience in the app.
- In essence **The code required to make this work would have been more complicated and intensive than what we have currently**

### Pivot 1: Allo Attempt 1

So at first, we decided to give Allo a go. They had a lot of the things we needed. However, we quickly learned that Allo uses its role system. We made a snap judgment and assumed that the integration may cause more issues than it was worth.

It's worth noting that this was an error on our end. Had we dug a little deeper or met with Zaak earlier (he was on vacation at the time), we would have discovered that the strategies are wide open and we definitely could have made this work.

However, we didn't know this so we had another pivot

### Pivot 2: Vanilla contract

[Repo Link](https://github.com/DAOmasons/request-registry)

We decided to make a contract that wouldn't handle funds but could handle all the Metadata and amounts. This would at least handle the accounting issues and Metadata needs previously mentioned.

However, as we began to codify the rules, we began to discover that this plan was creating a lot of extra work. Way more than anticipated.

Around this time, I started meeting with Zaak from Allo and talked through each of the needs of the project. It was clear that we were going to save some time with Allo.

One caveat here is that Zaak had mentioned that building a strategy generally takes a couple of days and only involves 100-200 lines of code. This wasn't the case for us (also most of the strategies in the repo are much, much larger than 100-200 lines of code)

### Final Pivot: Allo, GameManagerStrategy and GrantShipStrategy

[Repo Link](https://github.com/DAOmasons/allo-v2/tree/grantShips)

So after this pivot, I doubled down my efforts on Allo. Overall, the contracts and tests likely took a couple of weeks of very intensive dev, with some extra time for docs, edits, etc.

The good news is that the strategies we built are far better than the original vision. Some of the features include:

- **Increased capture resistance**. No one holds the funds. They can only be withdrawn by certain roles, to one address. Flags are onchain and can stop a ship immediately.
- **Increased plurality**. The original plan called for one type of Grant Ship that did grants one way. However, GameManagerStrategy can deploy any type of ship. In the future, we will be able to adapt existing Allo strategies and turn them into GrantShips (ex. Retroactive Ship, MicroGrant Ships, RFP, etc)
- **Better UX**. Because our data sources are aligned, there is far less need to send users to other applications. All the data they need will be in front of them. We were also able to reduce the amount of overall transactions needed.
- **Record-keeping**. The way we handle and store data is a 10x improvement over what we had initially planned. Better yet, it's looking like new features recently [built on TheGraph](https://thegraph.com/docs/en/developing/creating-a-subgraph/#file-data-sources) are going to allow us to reliably index data from IPFS. This means that we will be able to structure our data in many useful ways, for a wide array of actors, under one API.

Also, these contracts are tested, and we are confident they suit our needs to play Grant Ships. The direction is solidified. We are currently refining the designs and building the application. Here is a screenshot of the application in action.

[Repo Link](https://github.com/DAOmasons/grant-ships-app)


### Why do we need the time

- Contracts ate up most of our time for app development
- With new contracts comes peer review and continuing deployment for testing
- Also, the UX is different (better), so we had to rethink our designs.
- There's far more to index on the subgraph now, so we have to spend time structuring our data.
- This is unrelated to dev, but we've had a lot of trouble finding Ship Operators. We've outlined some plans with Feems, but this will take some time to promote well.
- While the Metadata structure Allo uses is awesome. It took time and research to figure out how I would get all the data into the app in a way that didn't suck (loading IPFS data from the client). The tool Allo uses (Spec) is not yet open to the public.

### How we plan to speed this up.
- Building vertically. Essentially, I plan to build one slice of the app's functionality at a time. This reduces how much I will need to rebuild if changes are needed to the contracts after review.
- Continuous QA. Once the app has enough functionality, we've selected roles for QA to make sure bugs are caught early and often.
- We've picked up a designer Intern (Sun Jo) to help us with designs. Knowing the UX flow in advance has helped us solidify our vision and will reduce rewriting code.

### What we can do better next time.
- While we did include the broad strokes of this info in our devlogs, we should have been providing updates to Plurality every time there was a major pivot.
- The challenge here would have been being 'sure' a direction was viable or non-viable before testing it out completely. It's hard to communicate while deep in the dev process. But we can do this better.
- The meeting on Friday was our first step in this process, but we would like to do more product reviews in the future.
- Just be better at Solidity. While I can write Solidity, I'm more of a frontend/backend dev. Not being able to read the contracts fast enough during the research phase caused one unnecessary pivot (as mentioned above). However, the trial-by-fire experience of the Allo Hackathon has definitely helped a lot in this regard.