# Intuition Accountability Pact

## Project Overview

For my trial project, I built the *Intuition Accountability Pact*. It leverages the Intuition Remix App Template and uses [0xSplits](https://splits.org/) for the contract interaction.

**Project Requirements:**

- Utilize the template and the DID auth flow that's already established within the Remix template
- Perform a client-side contract interaction (with any contract) and send the resulting *txHash* to the server via Remix's actions
- Include asynchronous form validation using [Conform](https://conform.guide/) and [Zod](https://github.com/colinhacks/zod)

## Project Inspiration

Since I could choose any contract for the client-side interaction, I went with 0xSplits since I've wanted to build something using it.

I was seeing a lot of talk recently about folks wanting to write every day. I remember when I participated in a Mochi cohort that people tended to be more productive when there was some level of accountability from peers.

I saw the potential for using a Split with this paired with an Attestation primitive. For the full picture, I see te user would create the pact with another party, and then set a date in the future for evaluation. Peers or members of the community could then use attestations to signal how much they saw the user keep to their pact.

These attestations would be taken into consideration and then adjust the Split afterward, up to 90% going to the user. There will always be a 10% split to the partner for their role.

At this point, the Split will be updated and made immutable with the new percents. Then any funds that were pledged can be sent to the Split address.

### Project Status

The MVP *Accountability Pact* in the trial project does the following:

- User adds an *Accountability Address* that can be a person, a DAO, or a multisig
- User includes a brief *Pact Description* of what the Pact is for, such as the goal that they want to accomplish
- User sets the initial *Accountability Percentage* ranging from 10% to 80%. This is the percent that the *user* starts with in the Split, with the difference (from 100%) going to the accountability partner address

Once the user sets the terms (and they meet the async validation) the Pact is created. Behind the scenes, this is a 0xSplit created between the user and the accountability partner address with the initial percent allocation based on the inputs.

For now, the Splits created are immutable by default. Once the project is fully extended these would be *mutable* at first and only made *immutable* after the review phase.

## Longer Term Idea and Continuation

Longer term, I see the project having the following modifications and enhancements.

- Add in a database layer for persistence with the Split and metadata
- The Split is the core of the project, but there is metadata for each Pact, such as the description, attestations received, and the review date
- Add in the date for review where the performance is reviewed and attestations are added or reviewed
- After this, the user can finalize the Pact, which will be adjusted based on attestations received
- Example: if someone starts at a 20-80 Split (hard mode) and receives X positive attestations, their percent will increase (potentially up to 90-10)
- The finalized Pact is then made immutable and locked in
- Funds sent to the Pact (Split) will then be able to be withdrawn with the new percentage
- Consider programmatically generating either a DAO or Safe for the accountability address so folks can have the same accountability partner with the same starting percent in the future
- Right now, Splits are deterministic based on the parties and their percents. Creating the exact same Split will fail

## Project Demo and Notes

My code is in a repo forked from the Intuition Remix App Template: [Intuition Accountability Pact](https://github.com/jonathanprozzi/intuition-accountability-pact).

On Thursday evening, I recorded a brief project demo that I shared in the group chat. I'm going to re-record with Loom for easier sharing.

## Learnings

This was a great way to learn more about Remix.

- I've previously used React Hook Form (RHF) for most of my form interactions, so using Conform was new. I like Conform's approach. It handles a lot of the scaffolding that we'd usually do to wrap RHF such as custom inputs that handled much of the boiler plate for form responses.
- I've previously used Yup over Zod for most of my larger projects, but I'd been intending to switch fully over to Zod. This was a great opportunity to compare and contrast Zod and Yup. I appreciate the schema-first approach for form validation, including the custom logic and custom messages that Zod supports.
- There were some complexities with Conform when preventing default submissions on the form. Since we needed to have the tx hash prior to the form submission, we need to prevent default. Conform (and Zod)'s validation works seamlessly out of the box when using the Remix form submissions, but when using prevent default I had to handle surfacing the error messages to the user. I also wanted to include error handling for the contract calls, so I also handled those separately and then only allowed form submission once all of the errors from the async validation were gone.
- Instead of using wagmi's lifecycle hooks (such as `useContractWrite`) I ended up wrapping the `contractWrite` calls with a reducer dispatcher to have more control over when the state changes were surfaced. I did this since I wanted a bit more finegrained progress updates for the user since we had the client-side transaction and the form submission. Using the dispatcher allowed for more possible states and errors, and then I added these as a status indicator to the UI.