# Hydra Deployment Coordination

This document outlines the initial architecture of the Hydra DAO and is intended to coordinate the onboarding of funds, members, and tech deployment.

## Initial Architecture

### Treasury

Hydra's treasury will exist on mainnet and be managed in a Gnosis Safe. Initially the Safe will be configured with multisig signers, but we can later upgrade to direct governance tooling.

### Share Accounting

Shares will use a modified ERC20 contract which implements transfer restrictions. The following restrictions will be implemented:

* Allowlist of holders
* Transferable among holders
* Moderated by Safe (issue more, burn, force transfer)
* Maybe disable issue/ burn once we have max supply and use force transfer instead

NOTE: Moderator Safe could be a separate Safe with higher

### Voting

Hydra will use a Snapshot space with an ERC20 voting strategy.

* Quorum: 10% of holders (See operating agreements to confirm)
* Token weighted votes
* Simple majority

### Escrow modules

Protect against investees from giving bad address. Require withdraw. Retain ability to claw back

### Vesting

Inflation rewards will be minted at the initial issueance and held by the Safe, then distributed quarterly. (Try Sablier)

### Ragequit

A custom ragequit contract will be created which will issue a nontransferable claim NFT representing the member's legal claim to the total book of illiquid positions at the time of ragequit.

Perhaps instead of burning, preserve tokens but send to a ragequit bank/ 0xqu17 address.

### Guild Kick

The Gnosis Safe will also have the ability to burn a member's tokens and issue them a claim NFT.

### Execution

Decisions can be executed manually by multisig owners, or the DAO can configure the Reality.ETH Zodiac module to bring Snapshot results on chain.

* NOTE: If we use Reality.ETH it is important to carefully select an arbitrator, and waiting periods, and configure monitoring on any attempted Reality.ETH transaction. Misconfiguration or inattention can lead to unrecoverable losses. I would recommend we just rely on multisig signers to start

### Disperse

Start planning architecture for future fund returns & distributions
0xsplits?

## Launch Operations

### Deployment

0. Define token restrictions & voting requirements
1. Deploy & configure mainnet Gnosis Safe
2. Develop, test, and deploy a custom restricted token (or off the shelf if requirements match a well audited existing implementation)
3. Configure snapshot strategy
4. Accept funds from eligible members
5. Create & execute batch issuance transaction for token to members
6. Turn off issuance & burn to cap max supply

### Onboarding funds

Accepted members will be invited to send funds to a mainnet Gnosis Safe.

### Security Token Distribution

Members will specify to what address they want to receive their Hydra ERC1400 tokens.

Once most (all?) funds have been received, a multisig signer will prepare a batch minting transaction using the Gnosis Safe airdrop app or transaction builder.

Once approved, the transaction will be executed and all members will receive their tokens.

## Implementation notes

The ERC1400 token here is audited and implements the required restrictions (moderation & controllability). We might be able to use it off the shelf

https://github.com/tenx-tech/tenx-token/blob/master/contracts/token/ERC1400.sol

## Dates

Mid October: Funding Starts
Nov 3: All Hands