This document sketches a rough spec for a contract that enables a cleric to spin up a new raid in one transaction, complete with all the onchain tools necessary for the raid.

## Current Status

* Much of the implementation has been completed
* The primary thing missing is support for the [new version of Smart Invoice](https://github.com/SmartInvoiceXYZ/smart-invoice/blob/develop/packages/contracts/contracts/SmartInvoiceSplitEscrow.sol), which uses a different factory than the old Wrapped Invoice version

## Links

* [Github repo](https://github.com/raid-guild/raid-party-spinup)
* [Hats tree diagram in figma]( https://www.figma.com/file/ddUaNM1N3T2UzOoYSh4buX/Hats-%3C%3E-Raid-Guild?type=whiteboard&node-id=0-1&t=bgrfqJj8Q3n8y1ko-0) — *focus on the branch of the tree under the Raid Manager hat*

## Overview

All raids have raider roles, a Smart Invoice for invoicing and receiving payment from the client (and splitting out spoils to the DAO), and a multisig that the raid can use to collectively control the Smart Invoice and execute any other necessary onchain actions (such as payments to raiders).

The Raid Spinup contract makes it easy to spin up and manage these elements in a cohesive, connected fashion.

It deploys the following elements:

1. Creates a new multisig for the raid party
- Signers are gated by the Hats from (3) via MultiHatsSignerGate
2. Creates a Hat representing the raid party and mints it to the raid party
3. Creates Hats for all possible raider roles (child of raid Hat)
4. Creates a Hat for the client (child of raid Hat)
5. Creates and configures a Smart Invoice
6. Creates and configures a

## Rough Spec

### Raider Roles
We take advantage of the Hats Protocol addressable (semantic) id scheme to standardize the ids of the hats associated with each raider role.

We can also use bitmasking for efficient storage of which roles exist for a given raid.


### Raid Data

A raid is comprised of its existing raider roles, its active state, its MultiHatsSignerGate (plus its multisig, the address for which can be retrieved from the signer gate), and its Smart Invoice


### Cleric Functions
Only a valid Raid Guild Cleric can call these functions. This contract assumes that all

#### createRaid


For each role in `_roles`, creates the relevant hat with full details.

For each role *not* in `_roles`, creates the relevant hat but with empty details. If the role is later added to the raid, these details will be filled out then.

The main thing missing in this contract's implementation is support for the new version of Smart Invoice: [SmartInvoiceSplitEscrow](https://github.com/SmartInvoiceXYZ/smart-invoice/blob/develop/packages/contracts/contracts/SmartInvoiceSplitEscrow.sol).

##### To deploy SmartInvoiceSplitEscrow via SmartInvoiceFactory:
* Implemented on both goerli and gnosis chain. Deploying a SmartInvoiceSplitEscrow is same process as the SmartInvoiceEscrow with the only differences being:
* Invoice type is "split-escrow" rather than "escrow"
* The bytes param _data must include two more values, _dao (DAO address) and _daoFee (basis points for spoils).
* The implementation addresses can be found in the deployment folder under contracts in develop branch

### Raid Party Functions
Only the raid party multisig can call these functions

#### addRoleToRaid
Adds a new role to the raid. Fills out the role hat's details.

#### mintRoleToRaider
Mints a role hat to a raider's address.

#### addAndMintRaidRole
combo of the above two functions

#### mintRaidClientHat
mints the client hat to the client's address

#### closeRaid
Sets the raid active status to `false`

## Other Requirements

* Tests (some are done)
* Ensuring that front ends (primarily DungeonMaster) can effectively parse the relevant data and events.