# Grant Ships Technical Treatment

**Goals:**
- Create the Grant Ships game regardless of tech being used.

### **Main Actions:**

**Deployments:**
- Ships
- Hats
- Allocation Strategy
- Certs or NFTs
- Project Standard?

**Ship:**
- Signal Allocation

**Facilitators:**
- Send Allocation
- Mint Receipt (Cert)
- Warn users (Yello Flag)
- Strongly warn users (Red Flag)

**Voters:**
- Allocate voting token to ship registries.
- Could possible mint project token (certs or NFTs) to help 'Boost' a project signal.

**Projects (Recipients):**
- Post updates

**Main cycle**
- [x] Ships allocate
- [x] Facilitators send
- [ ] Voters select ships

**Ship Allocation**
- Ship is a delegate key on Facilitator safe
- Ship makes a transaction on the safe
- Metadata (project name, description, address, site, GH, impact metric, funding shema*)
- Send funds
- Project minting registry (Certs, if possible)

**Facilitators Send**
- Facilitators sign
- Diligence
- Sign

**Voters Select Ships**
- Facilitators airdrop voting token to voters based on Arb holdings at snapshot and other voting modifers (participation)
- We use the Allo Donation Voting Strategy
- Funds aren't disbursed this way.
- We earmark Ships next round of allocations based on voting amounts

**To Test:**
- Delegate key TXs
- Metadata, what will this be stored in?
- Send funds
- And registry
- Is Allocation TX seemless, does it work as intended? Does it create the necessary data?
- Can we do it all from the frontend?
- Comparison between Allo and Jokerace
- Deploy a Voting strategy
- airdrop a token
- Vote with the token
- Check to see if the transactions populated the data that we need for the view.

* Funding Schema:
Ways to send the funds. Could be streaming, fund once complete, fund in advance, milestone, RFP.

* Conviction Style Negation Mechanism
- Potential way to remove or automate facilitators
- Optimisticly sends funds within a certian time period.
- All voters can vote to stop or delay the funds by locking up voting power
- If it reaches first threshold of voting power, time period is extended, fuinding is delayed
- Voters can contiue to vote no and move the vote into the next threshold
- If delayed three times, TX is cancelled. Ship is automatically red carded
- Can be its own Allo strategy or adapter for other Allo strategies

Question for Spencer:
- How can hats easily hook into existing address-based permission systems (ex. Allo, Push Protocol)

## Using Allo For the Whole Damn Thing

### How it works

- Facilitators create an Allo Profile

- Facilitators create a pool with RFPStrategySimple for each GrantShip
- GrantShip Applicants create a profile for the ship they would like to operate
- Facilitators select the team they would like to operate the ship with by calling the public ``allocate`` function. Which calls the RFP strategy's private ``_allocate`` function under the hood.
- When ``RFPStrategySimple``'s ``_allocate`` is called, it renders the pool ``inactive``.
- When a ship wants to allocate to a project, they call ``submitUpcomingMilestone`` which adds a ``Milestone`` to the pool.
- Facilitators can then review the milestone's metadata. (This comes with some concerns around the milestone queue as listed below)
- Facilitators can reject a milestone by calling ``_rejectMilestone``
- If for any reason, Facilitators can pull a ship's funding by calling ``withdraw``
- After the milestone (Ship Funding Request) is sent, the Facilitators can distribute those funds in sequence by calling distribute() on the Pool, which calls _distrribute() on the strategy.
- When distribute is called, then the funds (any token) are transferred to the recipient address. This is tricky, because we actually want the funds to go to the project, not the Ship. There might be a way around this.

ISSUES:
~~- Potential bug: Milestones are processed in sequence.
- Worse yet, I don't see a way for rejected proposals to be removed from the queue, so they pass and distribute, even if with the status of rejected?
- Has this strategy been audited?
- Good news is that if I'm understanding this correctly, this could be pretty easily fixed by skipping milestones that are rehected~~
- Grant ships must add projects as recipients
- Distributions must be processed in sequence
- Still unclear if we're using our own Allo protocol or hooking into theirs
- Overall, the contract is a little too geared towards RFPs (go figure) to be hacked into a Grant Ships contract.
- Would need to create our own.

CHANGES REQUIRED:
- Milestones would have to change to a Mapping of Subgrants ``
- The Subgrant would have to include its own recipientAddress & amount
- We would send the funds to the Subgrantee's recipientAddress
- distribute function signature would include the Subgrant
- We would use the Subgrant amount instead of percentage
- We would prevent allocation to rejected Subgrants (milestones)
- We would need to make sure

### Resources

#### Allo:

#### RFPStrategySimple:

    struct Recipient {
        bool useRegistryAnchor;
        address recipientAddress;
        uint256 proposalBid;
        Status recipientStatus;
        Metadata metadata;
    }

#### ProfileRegistry:

    struct Profile {
        bytes32 id;
        uint256 nonce;
        string name;
        Metadata metadata;
        address owner;
        address anchor;
    }

    struct Metadata {
    /// @notice Protocol ID corresponding to a specific protocol (currently using IPFS = 1)
    uint256 protocol;
    /// @notice Pointer (hash) to fetch metadata for the specified protocol
    string pointer;
}

## Simple Safe Prototype

### Three main actions
- Ships signal what they want to fund.
- Facilitators review request and send funds or reject
- After allocation period, voting starts to decide performance and future allocations for each ship.

### Part 1: Signal
Send a transaction to the facilitator's safe.

#### How?

- Safe transactions are stored offchain before it's set up for signing
- This data is stored on Safe Transaction Service API
- It is permissioned to usually only accept transactions from the signers (owners)
- However, there is a way around this with a API called delegateKey
- Delegate key allows non-owners to send a transaction to the API
- Then Safe owners can review and sign if they approve

#### Pain Points
- Permissions: How do we allow Ships to choose who can send requests to the Facilitator safe.
- [ ] Option 1: They use their own Safe to decide on allocations as a group (shitty UX, or slightly less shitty UX and heavy app build)
- [ ] Option 2: We manually whitelist addresses from Safes through the delegate key (easiest)
- [ ] Option 3: Use Hats and Hats wallet to manage onchain permissions (Good UX, Pretty intensive build and experimentation, we can get help)
- Creating a Transaction:
- A lot of work application side.
- Needs to encode the transaction
- Needs to encode multicalls
- Needs to manually calculate
- Partitioning
- How much is allocated to each ship.
- Safes for each ship
-
- Metadata
-