The code is cleaning up, and we’ve got over 50 tests running successfully. We’re still waiting to hear on the Hackathon results, we’ve got our fingers crossed.

We’re starting development on the front end now. We have some screens ready in Figma. We’re building it out with Vite, Wagmi and Mantine right now.

Here’s one of the early screens to get an idea how the UI will look:

You can check out our branch on the Allo repo here: GitHub - DAOmasons/allo-v2: Core Allo V2 Contracts

Jord wrote up a development recap that gives some more insight into the decisions we’ve made thus far:

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

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

Repo Link

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 larger than 100-200 lines of code)

Repo Link

So after this pivot, We doubled down 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 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.

The talk on measuring grant impact with DeXe Protocol went well. Check out the recording.

We’re reaching out to applicants now to have initial conversations. If you’d like to apply to be a ship operator or volunteer, see the Sign Up link at https://grantshipsfun

We’ve added some technical documentation to the repo, with more to come.

See Spec.md 1 to learn about the Grant Ships contracts.

We need people to sign up !
Follow us on X!

Join our Discord and talk Grant Ships with us.

Join Our Telegram Group

Follow our channel on Warpcast

This week we’d like to thank DavidKieve from Nexe Protocol, Feems from Plurality, Mahesh from Karma and Carl Cervone for connecting about measuring grant impact!

Thanks all, this was a longer one to make up for the missed post last week. Feel free to reach out with any questions.

We’ve requested a 2 week extension to our Milestone Two deadline.

The reasoning for the request is largely in the previous post in the Development Log section. Basically it took us longer to get homed in on the final tech solution than we anticipated.

We need more time to get the UX the way we want it and getting the graph connections wired up is a good bit of work as well.

• 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

• 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/12/2024

• Milestone 4: 4 Weeks

  • Start: 3/04/2024

  • End: 4/01/2024