# RG Token Roadmap

- place for people to find info about the token --> landing page / marketing site
- the token itself --> token contract
- Token sale / distribution mechanism
- DAO to govern the funds collected
- A way to ensure that the funds can only come to RG --> special minion
- alternative: conviction voting?
- Way for prospective clients to use the token to get consultations --> consultation auction / wait list
- A way to recycle burnt tokens, e.g. as rewards for stakers or to be sold again

### Blog Post (or two)
- how to use the token to get priority access to RG services (including what those current services are)
- how to get the token
- how the token is sold, etc.

### Token contract and symbol - in progress
- mintable? No
- burnable? No
- ~~maybe when X tokens are burned, automatically mints X new tokens and sends *somewhere*~~
- ownable (by an RG minion)? No
- ==token symbol/design/art==
- outstanding decisions
- need a designer for the image/design/art
- where to deploy the token contract?
- mainnet vs. xDAI
- talk to Connext about best way to support bridging to Polygon and rollups in the future?
- do we have any mainnet protocol use cases / integrations in mind for our token?
- if deploy on mainnet, then we lose the ability to add any custom logic to the token itself
- [x] decision: ~~deploy/mint on mainnet => bridge to xDAI~~
- DECISION REVERSED: mint on xdai and worry about bridging later
- primarily due to high current gas costs
- "burned"/used tokens go to a multisig that RG controls (MVP for periodic distribution governance)
- What's the token supply?
- [X] 201,210,864.0
- Which token standard?
- [ ] ERC777
- [ ] ERC677 (default xDAI)
- transferAndCall
- [ ] regular ERC20

consider deploying a clone token on mainnet via Miso: https://miso.sushi.com/factory/token

### Sale & Distribution Mechanism
- Initial event
- Ongoing periodic events
- Ideally can use [Gnosis Auction](https://gnosis-auction.eth.link/) out of the box
- Safe App - we can use this in the RG-controlled multisig from the previous section
- outstanding decisions
- auction params
- (a) The first parameter you need to enter is the token address of the token you are about to auction. This is the token that the auctioneer will auction.
- tbd
- (b) The second parameter you need to enter is the token address you will accept for bidding. This is the token that the auction participants (bidders) will use to place their bids.
- wxdai?
- (c) The third parameter you need to enter is the amount of tokens (expressed in numbers) you are about to auction. Keep in mind that the value of this parameter has to be within the amount of tokens that you hold in the Gnosis Safe.
- ??
- (d) The fourth parameter you need to enter is the limit price you are willing to accept for the tokens you are about to auction.
- ??
- (e) The fifth parameter you need to enter is the minimal funding threshold you want to establish for your auction. This parameter will indicate to the bidders that unless the auction surpasses such threshold, there will be no auction settlement, and everyone will get their funds back. If the threshold is achieved, then all successful auction participants will receive their proceeds.
- ??
- (f) The sixth parameter you need to enter is the Order Cancellation End Time. This parameter will fix at what specific date and time bidders will no longer be able to cancel their orders. From the auction time, until the order cancelation end time, bidders can cancel orders at any time.
- ??
- (g) The seventh parameter you need to enter is the Auction End Time. This parameter will fix the specific date and time bidders will no longer be able to place their orders, and the auction will end.
- ??
- (h) The eighth parameter you need to enter is the minimum bidding amount per order. This parameter will establish the minimum price the auctioneers are willing to accept for their auctioned tokens.
- ??

### DAO
- Standard moloch DAO on DAOhaus
- proposals are made to fund RG to build things, e.g.
- web3 app public goods
- something for the RG token-holders
- could evolve over time
- no dev required, except for the special minion
- nice to have: DAOhaus will have a "share grab" proposal type to make the
- need to decide on DAO parameters
- voting and grace period
- proposal velocity
- outstanding decisions

### Minion - in progress
- where the collected funds will be held
- **mini spec**
- can only execute a single action: transferring wxdai from itself to a whitelisted address (i.e. an RG minion dedicated to this purpose)
- no ACE
- no withdraw
- open question: should the RG DAO be able to change the whitelisted recipient address?
- if yes, would enable experimenting with using other distribution tools such as Smart Invoice
- if no, might be a simpler narrative and be more secure
- **ux flow**
1. somebody (likely RG) submits a minion proposal to the SWORD DAO requesting X funds for a given public goods project
2. once that proposal is sponsored, the RG project team submits a minion proposal to the RG DAO to transfer X funds from the RG minion into the project team's multisig/subdao/whatever
3. If the original proposal fails, then executing the RG minion transfer will also fail. But if the original proposal succeeds, then the RG minion transfer will succeed and the X funds will be in the hands of the RG project team

### Consultation Auction & Wait List / Queue
- An interface for prospective clients to burn or stake the token to establish their place in line for a consultation
- could use what pixelportraits [is building](https://twitter.com/MarkBeylin/status/1383249152222527496?s=20) or build it ourselves
- ==**contract spec** - in progress==
- struct `request`
- `stake`: current amount of SWORD staked on this request
- `submitter`: msg.sender of `queue` call
- `submissionID`: unique ID of hire us form submission to tie the queue to the submission
- `queued`: timestamp of `queue` call
- `fulfilled`: boolean for whether the consult has been taken
- function `queue` adds a new consultation request to the queue
- `amount`: amount of SWORD to stake
- `submissionID`
- function `increaseStake` allows topping
- `amount`: amount of SWORD by which to increase the stake
- `submissionID`
- msg.sender must be the `submitter`
- function `withdraw` -- allows the submitter to withdraw their submission and stake if not fulfilled after X days/months
- `submisionID`
- msg.sender must be the `submitter`
- must be X days/months after `queued`
- function `fulfill` -- marks the request as fulfilled and recycles the staked SWORD by sending it to the recycler multisig
- `submissionID`
- msg.sender must be guild member
- sets `fulfilled` to TRUE
- ==**front end spec** - needs focus==
- integrates with hire us page so that form submissions include `queue` function calls
- reads unfulfilled requests and displays them ranked by current stake. Table shows...
- submitter address
- submissionID ?
- current stake
- queued time/date
- UI for `increaseStake`
- UI for `withdraw` (show if fulfillment deadline has passed)
- UI for `fulfill`
- nice to have
- total SWORD burned
- record highest stake
- average stake
- total consultations fulfilled