# Statement of Work

This proposal outlines the work required to enhance the integration of Snapshot with Gitcoin passport. The primary objective is to improve the validation strategy, ensuring that it effectively uses the passport to prevent spam proposals and votes and offers robust Sybil defense. [A preliminary scope of the problem space can be found here.](https://hackmd.io/@raidguild/rJ4e8wcnh)

# Deliverables

1. **Updated Schema**: A revised schema that lists stamps from the passport instead of verifiable credentials.
2. **Enhanced Validation Logic**: A validation mechanism that checks for both the passport score and any required stamps.
3. **Comprehensive Documentation**: Clear documentation detailing the changes made, how they function, and how they can be utilized by users.
4. **Tested Solution**: A fully tested solution ensuring that the new validation strategy works as intended without introducing new issues.

# Scope

The project focuses on enhancing Snapshot's integration with Gitcoin passport by revising the validation strategy, ensuring it effectively uses stamps and checks for the passport score, while also updating relevant documentation to reflect these changes. **TBD** xDAI will be deposited into Smart Escrow before initiating work.

# Exclusions

1. **Frontend Changes**: This proposal focuses on the backend business logic for use in snapshot. Any frontend changes are outside the scope of this work.
2. **UI/UX Design Overhaul**: While minor UI changes might be necessary, a complete redesign of the user interface is not included.
3. **Integration with Other Systems**: The focus is solely on the Snapshot and Gitcoin passport integration. Integrations with other systems or platforms are excluded.

All software developed by RaidGuild is provided as is and without warranty.

# Process

1. **Initial Review**: Begin with a comprehensive review of the current system to understand the existing validation strategy.
2. **Development**: Implement the changes as outlined in the scope, starting with the schema modification followed by the validation logic enhancement.
3. **Testing**: After development, test the updated system using the provided examples and any additional test cases deemed necessary.
4. **Documentation**: Update and create documentation detailing the changes and how to use the updated system.
5. **Feedback & Revisions**: Seek feedback on the changes and make any necessary revisions.
6. **Finalization**: Once all changes are approved, finalize the updates.

**Please Note: Our team will be dependent on Snapshot for prompt delivery, since we will need them to accept our PR for the raid to be considered complete/shipped.**

# Team

- Cleric: TW
- Monk: plor
- Paladin: Santiago

# Proposal

| Phases | Description | ETA |
| -------- | -------- | -------- |
| **Review** | Comprehensive review of the current Snapshot validation strategy. | 1 day |
| **Development** | Implement schema modifications and update validation logic. | 3 days |
| **Testing** | Thoroughly test the updated system using provided examples. | 1 days |
| **Documentation** | Update and create necessary documentation. | 1 days |
| **Feedback & Revisions** | Address feedback and make necessary revisions. | 1 day |
| **Total** | | **$2900** |

**Total Estimated Time**: 7 days

# Smart Escrow

Payment is in wxDAI or WETH on the Gnosis Chain network. The Raid Party’s multi-signature safe is available at the address **gno:0x830731D32Faf3E11d2B2BeC5b0AB9D06C5115513** on Gnosis Chain.

**Please reach out if you have any questions about this process.**

**We will begin upon verified payment of (TBD) into this Smart Escrow.**

> https://smartescrow.raidguild.org/ Raid ID: **Awaiting Client Address**
>

Smart Escrow allows for milestone-based funding and the Raid Party will continue development as long as each ongoing milestone has been funded. With Smart Escrow, any address can fund the escrow.

# Dispute Resolution

If you lose confidence in the Raid Party at any time, you may `Lock` the remaining funds in escrow. If you do not release funds upon completion of deliverables, the Raid Party may `Lock` the remaining funds in escrow. In both cases, `Lock` triggers the arbitration provider (e.g. LexDAO) to review the dispute. Based on their review, the arbitration provider decides which party should receive what, sending a transaction to the escrow contract transferring the appropriate amounts to each party.

We sincerely hope this won’t be the case, but all parties are protected nevertheless.

**We look forward to Raiding. Please reach out with any questions or concerns!**