text:
---
yip: 44
title: Improve YIP categories
status: Implemented
author: sam bacha <sam@freighttrust.com>
discussions-to: https://gov.yearn.finance/t/yip-44-improve-yip-categories/3608

created: 2020-08-31
---

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

Add new `status`(s) to `YIPs` so that author(s) may better manage their `YIPs` in the context of community collaboration and so that governance is given the proper procedures to foster community cooperation.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the YIP is implemented, not *why* it should be done or *how* it will be done. If the YIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

This will _only_ add to the current state of `proposal YIPs` in that it only changes the _potential_ `statuses` available of a `YIP`. It does not add any `protocol` changes: only documentation and governance procedures (off chain only).

I proposal the following changes to reflect a new state of possible 'YIPs':

1. Modifying YIP Templates
2. Modifying YIP Validator Gemfile
3. Modifying YIP README file

## Motivation

<!--This is the problem statement. This is the *why* of the YIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the YIP proposes changing how something is calculated, you must address *why* the current calculation is inaccurate or wrong. This is not the place to describe how the YIP will address the issue!-->

> The current state of procedures for `YIPS` is inadequate as it unnecessarily limits the possible outcomes of a proposed `YIP` while not affording both the author(s) nor the governance council flexibility in being able to deal with community driven `YIPs`

This is a _documentation_ and _procedure_ change. In fact there is no explicit description for proposing such changes in governance _(that I could find)._

This change is needed as it better explains the _intent_ of the YIP format to author(s). It also provides for governance additional functionality in their procedures so as to not potentially 'alienate' author(s) by rejecting a YIP when it could have been withdrawn. This ensures that also the author(s) are active in the process of their submitted proposal and in the larger community (in so far as they are knowledgable about other potentially competing YIPS.)

## Specification

_Additions in 'BOLD'_

Proposed - a YIP that is ready to be reviewed in a governance call.
Approved - a YIP that has been accepted for implementation by the Yearn community.
Implemented - a YIP that has been released to mainnet.
Rejected - a YIP that has been rejected.
**Withdrawn - a YIP that has been withdrawn by the author(s).**
**Deferred - a YIP that governance has decided to wait for another YIP/some other change that should be bundled with it together**
**Moribund - a YIP that was once Implemented. It is now Obsolete 'AND' requires no explicit replacement.**

The "Withdrawn" status is similar - it means that the YIP author has decided that the YIP is actually a 'bad' idea, or has accepted that a competing proposal is a better alternative.

### Workflow Specification

```
Proposed -> Approved -> Implemented
  ^                     |
  +----> Rejected       +----> Moribund
  |
  +----> Withdrawn
  v
Deferred
```

#### New Statuses for YIPs

> To be added are the following

- Withdrawn
- Moribund
- Deferred

### Overview

<!--This is a high level overview of *how* the YIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->

#### New YIP statuses

- Withdrawn
  Means that the YIP author has decided that the YIP is actually a bad idea, or has accepted that a competing proposal is a better alternative.
- Moribund
  Obsolete and requires no explicit replacement, it SHOULD be marked "Moribund"
- Deferred
  Governance placed status upon a YIP that means that they would like to know more information, or that they would like to see if the author(s) can work with another proposed YIP and combine it into a single YIP, etc.

### Rationale

The reasoning behind this is that it is unclear what will happen to a YIP should material facts change during its initial formal proposal and when its actually voted on by governance. Changes may be introduced between then, and the author may want to withdraw the proposal. This also frees up the governance council in that they are no longer obligated to reject every single YIP that may no longer be relevant, instead sharing the responsibility with the actual author(s).

### Technical Specification

<!--
NOTE: NO PROTOCOL CHANGES ARE PROPOSED
THE ONLY TECHNICAL CHANGES ARE IN THE RUBY VALIDATION PROCESS FOR YIPS
-->

Technical implementation involves:

- changes in the validation Gemfile
- changes in the template `.md` file

#### Changes in Template `.md` file

Below is a sample `.yaml` file to illustrate the _new_ header that should be used in the `yip-template.md` file

```yaml
---
YIP: <YIP number>
Title: <YIP title>
Author: < firstName, lastName, @githubUsrName, contact@address.com >
Type: <Informational | Standards Track>
Status: <WIP | Proposed | Approved | Deferred | Withdrawn | Rejected |
           Implemented | Replaced | Moribund>
    Version: <major>[.<minor>]
    Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
    Requires (*optional): <YIP number(s)>
    Implementation (*optional): <Added if YIP passes>

Discussions-to: <Create a new thread on https://gov.yearn.finance/ and drop the link here>

* Requires: <YIP numbers>
* Replaces: <YIP numbers>
* Replaced-By: <YIP number>
---
```

#### YIP Validator (Ruby Gem)

> current version: `1.0.2`, should be bumped to `1.1.0`
> Changes located [github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25](https://github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25)

```ruby
    validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected']
```

```ruby
    validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected', 'Withdrawn', 'Deferred', 'Moribund']
```

See Files Changed here [https://github.com/sambacha/yip_validator/tree/YIP-Proposed](https://github.com/sambacha/yip_validator/tree/YIP-Proposed)

### Test Cases

See `travis-ci` logs for the `Rub Gem` update here [https://travis-ci.com/github/sambacha/yip_validator/builds/181226022](https://travis-ci.com/github/sambacha/yip_validator/builds/181226022)

```bash
total:2, valid:2, invalid:0, errors:0
	statuses: [["Withdrawn", 1], ["Implemented", 1]]
  raises exception if it includes invalid yips
spec/fixtures/invalid/yip-7.md is NOT valid:	 {:status=>["is not included in the list"]}

```

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 2
title: Burn YFI for fees
status: Rejected
author: Andre Cronje (@andrecronje)
discussions-to: https://gov.yearn.finance/t/proposal-1-yfi-fee-collection/25
created: 2020-07-19
---

## Simple Summary

**FOR**: Will continue to with the current burn model.

**AGAINST**: Rewards will be claimed via a staking model instead.

_NOTE: This was proposal 1 on-chain._

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x473afAb58B2C5D4DbC5FAD5D236f6658AD84E83b |
| Total for votes     | 502445.8576 (11.27%)                       |
| Total against votes | 3953417.1244 (88.72%)                      |
| Quorum              | 22.03% 𐄂                                   |
| Start block         | 10490942                                   |
| End block           | 10508222                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

repo_name: yearn/YIPS

repo_language: HTML

file_name: config

mime_type: text/plain


text:
---
yip: 61
title: Governance 2.0
status: Implemented
author: tracheopteryx, lexnode
discussions-to: https://gov.yearn.finance/t/yip-61-governance-2-0/10460#binding-snapshot-vote-28
created: 2021-04-20
---

## Authors

[@tracheopteryx](https://gov.yearn.finance/u/tracheopteryx), [@lex_node](https://gov.yearn.finance/u/lex_node)

## Summary

A proposal to establish the future of yearn's operational governance by extending certain of the Multisig's[[1]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) powers from YIP-41 (Temporarily Empower Multisig)[[2]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) on a newly clarified basis in coordination with newly empowered autonomous contributor teams ('yTeams').

## Status

This proposal passed on April 25, 2021 at 7:00 UTC with 99.97% voting for.\
See the vote on [Snapshot 80](https://snapshot.org/#/ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4).\
Learn about our voting rules in YIP-55[[3]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References).

## Abstract

if adopted, this proposal seeks to:

- ratify continued delegation by YFI holders to the Multisig of certain powers first approved in YIP-41 (Temporarily Empower Multisig), together with certain modifications and clarifications to the nature and scope of such powers as set forth below;
- delegate certain powers to a set of yearn contributor teams that have emerged organically from the community ('yTeams'), as appropriate for each yTeam based on its objective ('yGuard,' 'yBrain,' 'yDev,' 'yPeople,' 'yBudget,' 'yFarm,' 'yTx,' and 'yOps');
- update and clarify YFI holders' role in governance and the types of proposals available.

## Motivation

In August 2020, YIP-41 (Temporarily Empower Multisig) was approved by YFI holders to:

- temporarily empower yearn Multisig members "to make personnel & budgetary decisions" for a six-month period; and
- task the Multisig with "facilitating the creation and transition to a multi-DAO structure".

Since YIP-41 was approved, the Multisig has fostered a 'multi-DAO structure' by encouraging the development of autonomous 'yTeams' consisting of volunteer and paid specialist contributors.

The six-month Multisig empowerment period was extended for three-months via YIP-59[[4]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) on February 24th, 2021 and will expire on May 24th, 2021. Thus, before the expiration date, YFI holders should approve a new proposal to establish the future direction of yearn governance. This YIP constitutes such a proposal and, if approved, would supersede YIP-41 and ratify yearn's current *de facto* operational governance practices.

## Specification

### Governance 2.0 Overview

We present here the first phase of a progressive decentralization and improvement to yearn's governance. This proposal seeks to update the decision-making structures within yearn, not their software implementation. It is our intent to offer implementation proposals in the future once this model is validated and the appropriate technologies become available for use.

[![Gov 2.0 v1](/YIPS/assets/yip-61/figure1.png)

Yearn is a network of independent doers united by a shared vision. Our bias is on action over bureaucracy. We move fast with great freedom and agency. This is our way. Towards this end, we have pioneered a method of governance we call 'constrained delegation' whereby YFI holders delegate their governance powers to autonomous groups like the Multisig and yTeams and thus empower them to be creative. Gov 2.0 takes that a step farther by making governance powers discrete and transferable objects under the direct control of YFI holders.

### YFI Holders

Gov 2.0 connects YFI holders to yearn's products and teams through a more direct, aligned, and transparent mechanism --- giving them direct control over who gets to make decisions. Rather than being asked to make specific, operational decisions, YFI holders will conduct how power flows within yearn, wielding granular and clear control over every aspect of what yearn does.

YFI holders will now be empowered to take three kinds of actions:

| Proposal                         | Description                                                                                | Hypothetical Examples                                                                                |
| -------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Yearn Improvement Proposal (YIP) | A proposal to execute on any power delegated to YFI holders or outside the scope of enumerated powers | Ratify a new yTeam and assign it power; Burn the YFI minting keys; Do anything outside the scope of proscribed powers, like change yearn's name; remove a yOps signer; mint a new power   |
| Yearn Delegation Proposal (YDP)  | A proposal to change where any discrete decision-making power is delegated                            | Move the 'Pay Team' power from yPeople to a new yTeam; undelegate the 'Set Budgets' power from underperforming yBudget team and delegate to YFI holders until a new solution can be found |
| Yearn Signaling Proposal (YSP)   | A non-binding proposal to signal community feelings or intent on any issue                            | A suggestion to change membership in a yTeam; A desire for a new kind of vault or product                                                                                |

### yTeams

yTeams are small, autonomous groups of yearn contributors empowered by YFI holders to act independently in the best interest of yearn within a constrained domain of action and with enumerated, discrete decision-making powers.

Each yTeam will be organized around a group of signers. The signers for each yTeam should be nominated by rough social consensus of that yTeam and be reasonably acceptable to the Ops yTeam ('yOps'). yTeam signers are empowered to choose their own consensus mechanism for decision-making and curate their own discussion and feedback groups on telegram. Decisions issued by yTeams will be executed on-chain by the Multisig until a more decentralized system is approved for implementation.

It is important to note that yTeams are not the only teams that can work on the yearn ecosystem. Indeed, each of the current yTeams was formed permissionlessly, emerging on an ad hoc basis as enthusiasts grouped around a workstream. This proposal is merely recognizing that a number of such informal groups have achieved sufficient consistency of membership, quality of results and autonomy of internal governance to deserve a constrained delegation of powers from YFI holders. More informal contributors should continue working, alone or in groups, on yearn and seeking to have their contributions ratified by YFI holders on a more granular, post hoc basis; these informal groups may also eventually coalesce into additional yTeams.

See below under "Constrained Delegation" for additional thinking on the governance philosophy underlying yTeams.

| yTeam   | Objective               | Membership Pool                                                                                |
| ------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| yGuard  | Protect the vaults      | YFI Protocol Dev, YFI Strategists, YFI Mechanics, YFI Secret Admirers                                                                                |
| yBrain  | Manage the strats       | YFI Strategists                                                                                |
| yDev    | Manage the protocol     | YFI Protocol Dev                                                                                |
| yPeople | Curate the team         | YFI Compensation Working Group, YFI Advisors                                                                                |
| yBudget | Spend money well        | YFI Finances, YFI Advisors                                                                                |
| yFarm   | Grow the treasury       | YFI Secret Admirers, YFI Secret Entrance                                                                                |
| yTx     | Write transactions      | YFI Doers                                                                                |
| yOps    | Coordinate contributors | YFI Ops (initial signers: [@banteg](https://gov.yearn.finance/u/banteg), [@lehnberg](https://gov.yearn.finance/u/lehnberg), [@milkyklim](https://gov.yearn.finance/u/milkyklim), [@tracheopteryx](https://gov.yearn.finance/u/tracheopteryx)) |

### The Multisig

In effect, the Multisig is a special yTeam ('yChad') utilizing a Gnosis Safe multisig[[5]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) for on-chain execution. While most of the decision-making powers previously held by the Multisig move to yTeams, the execution power stays with the Multisig pending future proposals. The Multisig is tasked with executing the decisions issued by yTeams within their domains of action and with 'Veto Power' should they feel a decision needs further review. As we iterate on governance in the future, YFI holders can decide to delegate this 'Veto Power' to external arbitration or other forms of secure adjudication.

## Decision-Making Powers

| Power                     | Delegation  | Description                                                                                |
| ------------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Manage Powers             | YFI Holders | YFI holders can vote to create, assign, or revoke discrete powers to or from yTeams.                                                                  |
| Change YFI Token Contract | YFI Holders | Any interaction with the YFI token contract, such as to mint YFI or burn the minting keys, remains under the control of YFI holders.                  |
| Set Fees                  | YFI Holders | Set the standard fee structures in the Yearn Protocol                                                                                |
| Change Multisig Signers   | YFI Holders | As the Multisig will continue to hold critical powers over the near term, only YFI holders can vote to change its signers                             |
| Ratify yTeams             | YFI Holders | Formally ratify or deratify yTeams to control which yTeams can hold delegated powers                                                                  |
| Change yOps Signers       | YFI Holders | As yOps has the power to change signers of other yTeams, this is a special power to change the signers of yOps                                        |
| Spend Treasury Funds      | YFI Holders | Spend funds from the treasury                                                                                |
| YIP Power                 | YFI Holders | YFI Holders have the power to propose a YIP on anything not already delegated                                                                         |
| Execution Power           | Multisig    | The power to execute decisions made by YFI holders and yTeams on-chain                                                                                |
| Veto Power                | Multisig    | This power allows the Multisig to veto any decision and ideally should not be needed                                                                  |
| Transitionary Power       | Multisig    | A temporary power enabling the Multisig to operate under the mandate of YIP-41 until the set of decision-making powers covers all needed transactions |
| Emergency Powers          | yGuard      | Immediately intervene in case of attack or bug to shutdown or rollback strategies or vaults                                                           |
| Manage Strategies         | yBrain      | Activate, deactivate, tune, and maintain strategies                                                                                |
| Define Yearn Protocol     | yDev        | Decide what code is considered part of yearn and what isn't                                                                                |
| Manage Protocol           | yDev        | Maintain and improve the Yearn Protocol                                                                                |
| Add Strategies            | yDev        | Add new strategies to vaults                                                                                |
| Delegate Transactions     | yTx         | Create delegated transactions for the multisig to sign and execute                                                                                |
| Pay Team                  | yPeople     | Create, deploy, modify, or terminate Yearn compensation packages                                                                                |
| Set Budgets               | yBudget     | Create budgets for coordinape, grants, hiring, operations, or other workstreams                                                                       |
| Farm Treasury             | yFarm       | Farm with the treasury and make decisions on airdrops                                                                                |
| Ratify yTeam Signers      | yOps        | Formally approve or remove signers for each yTeam                                                                                |

## Implementation

This proposal requires no additional implementation beyond the adoption of new processes utilizing the platforms currently active within yearn.

The nested consensus mechanisms needed for yTeams can be implemented in a number of ways today, but after much discussion and feedback from the core team and yearn community the authors decided to limit this proposal to the social layer. The detailed description of yearn governance provided in the proposal is intended to guide the research and development of new governance platforms custom tailored to yearn's specific needs to be developed and proposed for our use in the near future.

Our friends at Gnosis[[5]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References), Colony[[6]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References), LEGO Dao[[7]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References), Snapshot[[8]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References), Tally[[9]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References), finance.vote[[10]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References), and Orca Protocol[[11]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) have offered to help us build whatever we need to implement our vision of governance.

## Examples

To help clarify how the changes proposed in this specification will function in the wild, here are some hypothetical examples of decision-making in Governance 2.0.

### Replacing a yOps Signer

Banteg goes rogue, starts shilling XRP hard and is absent from important Yearn work. Someone creates a YIP to replace him from yOps with Justin Sun (who has become a benevolent, humble, and trusted yearn contributor). The vote passes, banteg is removed as a signer and Justin is added.

### Creating a new yTeam

It turns out pension funds are yearn's golden opportunity. A group of contributors on the dev team have been working on a whole new product line. Someone creates a YIP to ratify this group as a yTeam ('yPension') and assign them management power over the new set of contracts for the pension product. The vote fails to pass, the new pension contracts remain under the control of yDev where they were made, and the pension group can still work but without specific power.

### Deciding on an Airdrop

Spurn Finance, an unauthorized fork of yearn on Iota launches and sends a large airdrop of SPYFI direct to the Multisig. They say in their docs it's supposed to "reward the yearn community." The yFarm team has the 'Farm Treasury' power which includes deciding on what to do with airdrops. They decide to give 50% of the tokens to Andre and the rest to a Coordinape[[12]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) contributor circle for distribution.

This causes conflict in the community. Some members feel the airdrop should have been given to all YFI holders proportional to their holdings. Other think they should have been given to vault users proportional to TVL. Others think all should have gone to the community contributors not just half.

yFarm decides to stick to their belief and they send their decision to yTx. yTx creates a transaction to implement yFarm's decision and delegates it to the Multisig. During this time there is much discussion on twitter, telegram, discord, and the forum. People ask the Multisig to veto it to give them time. Since there is so much turmoil, the Multisig does decide to veto and give the community more time to think about other options. yFarm is fine with that, they can always resubmit again later.

Someone makes a YDP to remove the 'Farm Treasury' power from yFarm but it fails since they were being super reasonable. A number of alternate allocations are suggested. Andre comes out and says thank you, but he doesn't want the airdrop. Someone puts forth a new split that goes to YFI holders, vault users, and a Coordinape circle that they agree to implement. yFarm likes it, but changes the proportions a bit, then they puts through the tx which the Multisig does not veto and it is executed.

### Redelegating Veto Power

Kitten Court (an unauthorized fork of Kleros Court on Dogecoin) comes out with a new product, the Veto Master 9000, it's an AGI that can decide on vetoes better than humans. Someone makes a YDP to move 'Veto Power' from the Multisig to the Veto Master 9000. It fails because this is obviously a skem.

### Yearn Proposals & Delegated Powers

Vitalik joins the dev team and people are so pumped they want him on yDev immediately. Someone writes a proposal to add Vitalik as a yDev signer and wants it to be a YIP. But YFI holders don't have that power, so the proposal can only be a YSP (Yearn Signaling Proposal). yOps has the 'Ratify yTeam Members' power, so it's up to them to decide. The YSP ends with 95% of voters signaling yes. yOps thinks this is meaningful, so they agree that if Vitalik wants the job, they will ratify him as a signer. He agrees. We all party in a space hotel.

### Adding a Product to the Yearn Protocol

Andre writes a new perpetual insurance product. This can be part of vaults and a stand-alone product. It's passed audits and looks great. Another community contributor, VALISfan1981, has also written a perpetual insurance product and she has deployed it already, unaudited on her own site which allows people to deposit into vaults with her insurance system. She wants yearn to adopt her product as part of the Yearn protocol.

yDev has the 'Define Yearn Protocol' power. They review both options, discuss with the community, and decide to add Andre's code as part of yearn and use dev team resources to develop it further. VALISfan1981 can continue to offer their alternative product, of course, but it will be offered as an outside service.

### Deciding Something Outside of Defined Powers

Dark Ghosty decides that the Spix's Macaw[[13]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) is the official bird of yearn and is telling everyone this on telegram. He's really pushing hard for it. Deciding on our official bird is not a defined power. Anyone can say that a bird is yearn's official bird, but that doesn't mean anything. But Ghosty loves that bird, so he does a proposal to adopt the Spix's Macaw as the official bird of yearn. The forum poll looks good, so he goes ahead and does a YIP, and that passes. The Spix's Macaw becomes the official bird of yearn.

### Aggressive Attempt to Fund a New Project

The Coordinape team wants to ask yearn for a grant to fund development. They can ask yOps since they have a set amount of money for stuff like this that they get from the treasury as determined by yBudget via their 'Set Budgets' power. yOps says no, so Coordinape decides to ask yBudget directly to allocate them some recurring funds, but they say no too. Then they go to yDev and ask to be added to the Yearn Protocol with the 'Define Yearn Protocol' power so the dev team will help them build their product, but they are too busy.

Next option, they do a proposal to ask YFI holders to fund them. They get to the YIP but it fails. The Coordinape team is pissed. They work their asses off and have an amazing product. So they craft a devious plan...

First they do a new proposal to ratify themselves as the yApe yTeam. The YIP passes! yOps talks to the new yApe team and together they decide who the signers should be, and yOps formalizes them with their 'Ratify yTeam Members' power.

yApe is a yTeam but they have no power. They do a YDP to take the 'Set Budget' power from yBudget and spend thousands of dollars on a marketing campaign to convince YFI holders. But YFI holders don't buy it, they can tell something is off, and the YDP fails. yApe does a new YIP to create a new power 'Fund Coordinape' and this fails too. The community is not happy with Coordinape, so someone does a YIP to deratify their yTeam, it passes.

After some soul searching, the team recognizes their mistake, makes an apology, and yOps decides to give them a grant. It's enough to make a sick product which changes the world.

## Rationale

### Constrained Delegation

The authors of this YIP embrace the principles of creative freedom for yearn contributors set forth in what has come to be known as "the yearn manifesto"[[14]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References). Anyone with the requisite talent, ideas and willingness to work should be able to contribute to yearn, even if they do not hold YFI, and even if YFI holders do not authorize them to do so. Thus, we see the merits of what may be called a 'core development' philosophy of technology governance, and do not believe that yTeam members should need to be elected by or otherwise formally *accountable* to YFI holders. On the other hand, we also recognize the 'tyranny of structurelessness' that can ensue when anarchist principles of self-organization are pushed to the extreme, as well as the omnipresent threat that core-style governance can become captured through its dependence on the patronage of for-profit corporations and their proxies ('associations,' 'foundations,' 'consortiums,' etc.)

Similarly, we recognize both the potential benefits and perils of bottom-up, DAO-style governance. YFI was disseminated as 'the governance token of yearn'. Although the meaning, scope and mechanisms of such governance were (perhaps deliberately) under-specified at the time of YFI's creation, certain emergent cultural values are fairly clear: YFI holders expect that they have a vital value-creation role in the yearn community even if they do not have technical skills and are not 'core developers' or other highly active creative participants in yearn. Furthermore, YFI holders expect that yearn contributors do not work *contrary* to YFI holders' interests. For example, it would be unacceptable for the Multisig to drain the entire treasury to give themselves unearned or excessive bonuses. But, just as creative autonomy can degenerate into the tyranny of structurelessness, so, too, DAO governance can deteriorate into "the tyranny of the masses"---bikeshedding, needless bureaucracy and populist political haggling are all apt to emerge when decision-making is driven by those who view crowdsourced governance as an end-in-itself.

We can see the tension between creative freedom and group consensus play out at the practical level in a kind of Catch-22 faced by creators. If all decision-making authority is vested in governance token holders, then, in theory, all uses of community resources should be pre-approved by token holder voting. So, for example, if a developer needs a budget to create a new product, the developer would first need to write up a spec & get it and the budget approved by YFI holders. However, this is far from ideal, because developing such a spec itself requires effort and resources, and the approved spec may unnecessarily constrain freedom, requiring the developer to go back to governance to get re-approval for deviations from the spec that are inspired during the development process. On the other hand, a developer could self-fund the product and submit it for ratification of YFI holders and a financial reward after it is done, but this is also suboptimal: it essentially creates a negative externality on developers by requiring them to bootstrap a project that might not end up with product/market fit or an adequate reward, thus deterring new contributions.

Because of the way the Multisig was empowered in YIP 41, the yearn community has generally skirted this governance Catch-22. Most new development has been funded at the discretion of the Multisig and, after funding but before full deployment, has been ratified to become an official part of yearn through a proposal to YFI holders. We believe this is an important part of why the yearn community is known for having some of the most capable volunteer developers with the most aggressive pace of innovation of any DeFi community. If political debates were a gating item to every new project, good devs would be deterred or hampered from contributing to yearn, yearn's progress would be slow.

We note, however, that while this process has been effective, it has led to a muddled conception of governance that spawns many questions, e.g.: 'How meaningful can governance be if YFI holders are only asked to sign off on a new development after there are material sunk costs?' 'What does it mean for a new product to be 'accepted into yearn,' and who gets to decide that?' 'What do YFI holders govern?'

Our modest proposal for threading the needle through these philosophical tapestries is a model we call 'constrained delegation'--in effect, YFI holders delegate their governance powers to autonomous groups like the Multisig and yTeams and thus empower them to be creative. These battle-tested, YFI-approved yTeams are privileged to be able to get funding on a more spontaneous, informal basis and have their contributions presumed to be 'yearn-official', but are still subject to being monitored by YFI holders and disenfranchised if they abuse their roles.

In contrast to core governance (which is top-down relative to users and bottom-up relative to creators) and DAO governance (which is top-down relative to creators and bottom-up relative to users), 'constrained delegation' avoids subordinating either group to the other. Instead, we propose using a kind of checks-and-balances system that has more in common with the governance of corporations than that of *kibbutzes*, while still being more open, creative and spontaneous. Unlike with a corporation, yearn has no state charters, legal agreements or fiduciary relationships. YFI holders have not made an investment of capital into yearn, do not hold 'shares' with rights defined by a state statute, and should not expect that yTeam members will act like single-minded automatons blindly devoted to increasing YFI holders' profits at the expense of more multifarious purposes. Rather, if yearn is similar to a corporation, it is more like an idealistic version of a public benefit corporation---a public commons that exists to simultaneously benefit many different kinds of stakeholders (users, creators, students, other friendly DeFi communities, etc.) in a delicate set of tradeoffs.

Through rough consensus, YFI holders govern *de facto* rather than *de jure* and use that socially constructed governance influence to actively monitor and, to the extent desired, modulate the behavior of contributors. When it comes to governing yTeams, this governance may often look very similar to YFI holders 'doing nothing,' because YFI holders have already endorsed the Multisig and yTeams and they are presumed to act on a selfish but incentive-aligned basis consistent with the expectations of the community. However, when the contributors stray too far, or fail to communicate adequately, YFI holders should always be waiting in the wings to intervene in the situation, revoke their endorsement and restore a positive-sum equilibrium for the yearn community.

### The Future

This proposal architects a powerful, flexible, and novel form of decentralized governance that satisfies two critical needs: 1) giving YFI holders clear control and 2) empowering the team to execute with the speed yearn is famous for.

We believe that DAOs are in their infancy and there is much to learn. Although the promise of fully on-chain and trustless governance is alluring, we are not there yet. Behind every DAO implementation, there is a group of trusted contributors. Our model seeks to foreground these trusted relationships and give YFI holders the ability to modify them directly.

This proposal provides a northstar for implementations of Gov 2.0 that can iterate and improve over time. Here are some additional ideas we would like to explore further in the future:

- implement nested multisig-style consensus mechanisms such that each yTeam has execution power for their domain of action, flexibly reconfigurable based on delegated powers
- move away from proxy voting via either a tool like SafeSnap[[15]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References) or an on-chain L2 implementation with something like Compound's Governor Bravo[[16]](https://gov.yearn.finance/t/yip-61-governance-2-0/10460#References)
- tokenize decision-making powers as NFTs for improved transparency and functionality
- deprecate veto power via third-party arbitration
- utilize Coordinape for some yTeams, for example:
  - budget allocation circle (yBudget)
  - compensation setting circle (yPeople)
- explore using conviction voting to establish new yTeams and their membership
- migrate to on-chain voting using Colony v2, utilizing reputation for yTeams
- collaborations with Gnosis, Colony, LEGO Dao, Tally, finance.vote, and Orca Protocol
- establish practices for ratification of yTeams wielding off-chain decision-making powers on domains such as marketing, docs, and the web

## Credit

This proposal is the result of months of work across many teams and has benefited from the advice and feedback of dozens of brilliant people. You know who you are. Thank you. And a special shout out to the YFI Governance telegram group in particular for the regular and lively discussions.

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4)_

## References

[1] [FAQ - yearn.finance 10](https://docs.yearn.finance/faq#what-is-the-multisig-and-what-do-they-do)\
[2] <https://gov.yearn.finance/t/yip-41-temporarily-empower-multisig>\
[3] [YIP-55: Formalize the YIP Process 8](https://gov.yearn.finance/t/yip-55-formalize-the-yip-process/7959)\
[4] <https://gov.yearn.finance/t/yip-59-temporarily-extend-multisig-empowerment>\
[5] [https://gnosis-safe.io/ 7](https://gnosis-safe.io/)\
[6] [https://colony.io/ 4](https://colony.io/)\
[7] [https://twitter.com/lego_dao 6](https://twitter.com/lego_dao)\
[8] <https://snapshot.org/>\
[9] [https://www.withtally.com/ 1](https://www.withtally.com/)\
[10] [https://www.finance.vote/ 2](https://www.finance.vote/)\
[11] [https://www.orcaprotocol.org/ 9](https://www.orcaprotocol.org/)\
[12] [http://coordinape.com/ 8](http://coordinape.com/)\
[13] [Spix's macaw - Wikipedia 10](https://en.wikipedia.org/wiki/Spix's_macaw)\
[14] <https://gov.yearn.finance/t/how-we-think-about-yearn>\
[15] [https://blog.gnosis.pm/introducing-safesnap-the-first-in-a-decentralized-governance-tool-suite-for-the-gnosis-safe-ea67eb95c34f 2](https://blog.gnosis.pm/introducing-safesnap-the-first-in-a-decentralized-governance-tool-suite-for-the-gnosis-safe-ea67eb95c34f)\
[16] [Compound | Docs - Governance 3](https://compound.finance/docs/governance)

## Information

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4)_

| Name          | Value                                                                     |
| ------------- | ------------------------------------------------------------------------- |
| Snapshot Space | [ybaby.eth](https://snapshot.org/#/ybaby.eth)                            |
| Strategie(s)  | pagination, delegation                                                    |
| Author        | 0x29C4dbC1a81d06c9AA2fAed93Bb8B4a78F3eabDb                                |
| IPFS          | https://ipfs.fleek.co/ipfs/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4 |
| Voting System | Single choice voting                                                      |
| Start date    | Apr 20, 2021                                                              |
| End date      | Apr 25, 2021                                                              |
| Snapshot       | https://etherscan.io/block/12276205                                      |

## Results

| Result | Value               |
| ------ | ------------------- |
| Yes    | 683.09 YFI (99.97%) |
| No     | 0.2 YFI (0.03%)     |


text:
---
yip: 31
title: YFI Inflation Distribution
status: Rejected
author: Substreight (@substreight), DeltaTiger (@deltatigernz), Hannes Graah (@Graadient), Daryl Lau (@Daryllautk)
discussions-to: https://gov.yearn.finance/t/yip-31-yfi-inflation-distribution/1445
created: 2020-07-30
---

## Simple Summary

Divide any further YFI inflation, allocating 50% to Liquidity Pools and 50% to the Multisig.

## Abstract

- There are currently no funds being allocated to developing and improving the yearn ecosystem.
- Further inflation of YFI provides an opportunity to fulfill funding needs.

## Motivation

Using YFI from inflation to fund development is a sustainable mechanism to strengthen the yearn ecosystem and align contributors.

**FOR**: Allocate 50% of YFI inflation to Liquidity Pool incentives and 50% to the Multisig.

**AGAINST**: No changes to YFI inflation distribution.

## Specification

### Overview

- Designate 50% of future YFI emissions to LP rewards contract.
- Designate 50% of future YFI emissions to Multisig (or DAO if applicable).
- This will stay in place until stopped or adjusted.

### Rationale

Some YFI should be reserved to secure and improve the yearn ecosystem while properly incentivizing liquidity pools. Starting with a 50% // 50% split to LPs and Multisig, respectively, allows proper funding for both stakeholders, while retaining flexibility to adjust the distribution if necessary.

Reference

- Inflation schedule proposal [YIP-30](https://github.com/yearn/YIPS/blob/master/YIPS/yip-30.md)

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x24394A4758DBdCf6fcbC14dc35af64Ac0D9a450A |
| Total for votes     | 3304.5260 (42.28%)                         |
| Total against votes | 4509.5851 (57.71%)                         |
| Quorum              | 73.42% ✔                                   |
| Start block         | 10560736                                   |
| End block           | 10578016                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 60
title: Airdrops to Yearn Vaults
status: Implemented
author: lehnberg (@lehnberg)
discussions-to: https://gov.yearn.finance/t/yip-60-airdrops-to-yearn-vaults/10356
created: 2021-04-07
---

## Authors

[@lehnberg](https://gov.yearn.finance/u/lehnberg)

## Summary

Formalize how airdrops to Yearn vaults are handled: Tokens that are worth the effort, are sustainably claimed and donated to the affected vault as its `want` token in order to boost the returns of vault depositors.

This, in order to be aligned with what is the fundamental proposition for end users and third party integrators alike: Having a gas efficient, frictionless, set-it-and-forget-it way of earning compounding returns through Yearn's vaults.

## Background

The Ellipsis airdrop[[0]](https://gov.yearn.finance/t/yip-60-airdrops-to-yearn-vaults/10356#References) and the resulting eligibility for the yveCRV to receive tokens over the course of a year has resulted in Yearn governance discussions[[1]](https://gov.yearn.finance/t/yip-60-airdrops-to-yearn-vaults/10356#References) about how this should be handled.

While this is the first airdrop of its kind, it is unlikely to be the last. It would be beneficial to agree on a general approach that outlines how these situations are to be handled.

### Airdrop factors

- Cost to claim. Claiming airdrops can involve manual work, sometimes on different chains than Ethereum, for uncertain rewards.
- Time periods to claim. Claiming may at times be done in one go, and other times over multiple times, sometimes lasting as long as a year or more.
- Relationships and image. Acting in bad faith, i.e. "claiming & dumping" can lead to exclusion from future airdrops, bad publicity, and being labeled as an adversary rather than a partner.
- Tokenomics. Depending on the protocol design, there can be lucrative farming opportunities or heavy penalties to incentivize good actors in the airdrop protocol. Considering these can lead to better rewards.

## Motivation

The rationale for this proposal is motivated by the following objectives:

- Do right by the vault's depositors. In principle, airdrops belong to whoever holds the private key. Practically, many vault depositors expect to benefit from airdrop proceeds. Yearn should do right by them, which in turn does good for Yearn's reputation and attracts more users of its products.
- Set expectations straight. At the moment, it is unclear what will happen in airdrop situations. Vault depositors should have clarity about what they should expect to happen.
- Do not overload Yearn's resources. Yearn's vaults are different, and airdrops are different. Subjective judgement about which airdrop to claim, and what the best way for realising it, is unavoidably going to be required. Airdrops should not end up becoming an effective Denial-of-Service attack on Yearn teams and distract them from delivering on existing roadmaps and priorities.
- Keep it simple. Yearn is meant to make DeFi simple, and should try to live up to that. Depositing a token into a Yearn vault shouldn't come with expectations of potentially having to deal with the handling of other unrelated tokens, possibly even accessible from other blockchains.
- Keep it composable. Yearn vaults are being used by end users, defi protocols, businesses, and other intelligent life such as smart contracts and robots. They should benefit from airdrops automatically, without no additional effort, letting rewards compound. This avoids unexpected behaviour and edge cases, making Yearn's vaults easier to integrate with.

## Specification

1. A decision is made whether the effort to claim a specific airdrop is worth while given other current priorities.
1. Specific claiming, farming, and token exchange strategies are determined on a case by case basis, depending on prevailing airdrop terms and market conditions, with the objective to maximize risk-adjusted returns.
1. Returns are used to boost the returns of the affected vault for the benefit of its current depositors. This is done by converting the returns into `want` tokens, and donating them to the vault in question, boosting the returns of each current tokenholder as a result.
1. Decisions on the details of the above steps are left to be taken by the Operations, Engineering, and Finance teams with the instruction to meet these instructions as best as possible. Decisions can be overruled as usual through the existing Multi-sig and Governance processes. Both groups should be kept up to date on airdrop claims as they progress.

## Information

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/QmNqAqRKMFcoRjaRYAKCVETij6sjJ4S1293kbpYDMVvcjB)_

| Name          | Value                                                                     |
| ------------- | ------------------------------------------------------------------------- |
| Snapshot Space | [ybaby.eth](https://snapshot.org/#/ybaby.eth)                            |
| Strategie(s)  | erc20-balance-of, erc20-balance-of-delegation                             |
| Author        | 0x7A1057E6e9093DA9C1D4C1D049609B6889fC4c67                                |
| IPFS          | https://ipfs.fleek.co/ipfs/QmNqAqRKMFcoRjaRYAKCVETij6sjJ4S1293kbpYDMVvcjB |
| Voting System | Single choice voting                                                      |
| Start date    | Apr 7, 2021                                                               |
| End date      | Apr 12, 2021                                                              |
| Snapshot       | https://etherscan.io/block/12196456                                      |

## Results

| Result | Value           |
| ------ | --------------- |
| Yes    | 1005 YFI (100%) |
| No     | 0.05 YFI (0%)   |


text:
---
yip: 8
title: Halving YFI weekly supply the same as bitcoin
status: Rejected
author: steamer.eth
discussions-to: https://gov.yearn.finance/t/proposal-8-halving-yfi-weekly-supply-the-same-as-bitcoin/263/
created: 2020-07-22
---

## Simple Summary

Currently the weekly supply increase of YFI is 30,000 per week. Vote under proposal #0 is if more YFI tokens should be minted.

I’m voting “FOR” on proposal #0 16 as continuous incentivization of LPs is important for growth of the platform. Most of reasons are the same with proposal 5.

**More Reasons:**

1. The YFI mining will be end in 3 days, while the whole crypto community needs more time to understand this complex mechanism. In such a short period of time, YFI cannot generate an effective market pricing.
2. To stop the YFI mining will instantly result to a huge amount remove of the liquidity, this will be a huge negative to the YFI price because of the decreasing of fee rewards.

This is a proposal for reducing the weekly issuance rate with a model the same as BTC. Two months is enough to educate the crypto community while finishing the YFI generate event.

**The pros of the bitcoin halving model:**

1. Halving every week is quite easy to be understood in the crypto community, and effective.
2. Easy to make memes of YFI - “ YFI is the Bitcoin in Defi ” for virus spreading.
3. Enough time for the markets to reach the equilibrium. (liquidity provider’s YFI revenue is halved every week while taking the same risks, will result in a steady change in liquidity)

[Modeling of 3 Pools](https://docs.google.com/spreadsheets/d/1ORG5UJUc2kKyjkemeskbpfpAfbDZ9Wk7GSEUc4RG2O0/edit?usp=sharing)

![Model](assets/yip8.png)

In summary. If proposal #0 passes the issuance model should be altered as described above.

**FOR**: Support the new issuance model.

**AGAINST**: Do not support the new issuance model.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0xe2ca7390e76c5A992749bB622087310d2e63ca29 |
| Total for votes     | 3527868.1621 (80.25%)                      |
| Total against votes | 867838.6309 (19.74%)                       |
| Quorum              | 9.73% 𐄂                                    |
| Start block         | 10508388                                   |
| End block           | 10525668                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 68
title: Rotate multisig signers
author: banteg
discussions-to: https://gov.yearn.finance/t/yip-68-rotate-multisig-signers/12582
status: Implemented
created: 2022-06-16
---

## Summary

Replace the three least active multisig signers with new people. After an [open call](
https://twitter.com/bantg/status/1533222650838908928
) and careful consideration, we've selected three candidates: 0xngmi, monoloco, and lefteris.

## Motivation

The multisig has been effectively operating as 6 of 6-7 with two signers being inactive and another one too busy with his own project. We appreciate their service, but we got to a threshold where we need another rotation. Here are the signing rates over the last two months, since 2022-04-13 till 2022-06-13.

```
owner
klim       100.0
cp0x        99.0
banteg      98.0
daryl       91.0
mariano     88.0
leo         77.0
--- cut here ---
vsh         39.0
devops       6.0
ryan         2.0
```

## **Specification**

Replace vsh, devops, ryan with 0xngmi, monoloco, and lefteris.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

## Information

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0xc5386b7237f6c90359c56ac6dcb942b99a56a4de8ca60d109f4b999716148734)_

| Name          | Value                                                                           |
| ------------- | ------------------------------------------------------------------------------- |
| Snapshot Space| [ybaby.eth](https://snapshot.org/#/ybaby.eth)                                   |
| Strategie(s)  | YFI, delegation                                                                 |
| Author        | wentokyo.eth                                                                    |
| IPFS          | https://snapshot.mypinata.cloud/ipfs/QmbrqfCBjE8yYkz1wbsWQu9VxEo3UmPw2oGhb34Mdtqpx6 |
| Voting System | Single choice voting                                                            |
| Start date    | Jun 16, 2022                                                                    |
| End date      | Jun 21, 2022                                                                    |
| Snapshot      | https://etherscan.io/block/14973155                                             |

## Results

| Result  | Value               |
| ------- | ------------------- |
| Yes     | 844 YFI (100%)      |
| No      | 0.000045 YFI (0%)   |


text:
---
BUNDLE_PATH: "vendor/bundle"


text:
### Commercial tools
1. **[Strand NGS] (http://www.strand-ngs.com/)**
  * offers many different tools including alignment, RNA-Seq, DNA-Seq, ChIP-Seq, Small RNA-Seq, Genome Browser, visualizations, Biological Interpretation, etc. Supports workflows
“one can import the sample data in FASTA, FASTQ or tag-count format. In addition, prealigned data in SAM, BAM or Illumina-specific ELAND format can be directly imported for analysis.”
  * Alignment feature: Supports alignment from Illumina, Ion Torrent, 454 (Roche), and Pac Bio
  * DNA-Seq Feature, can annotate with dbSNP
1. **[CLC Genomics Workbench] (http://www.clcbio.com/desktop-applications/top-features/)**<br>
  * (QIAGEN). Features include: resequencing, workflow, read mapping, de novo assembly, variant detection, RNA-Seq, ChIP-Seq, Genome Browser, etc (entire list on website); Main Workbench offers database search (Genbank, Blast, Pubmed); 2000 organizations have invested in CLC
  * Accepts VCF files from 1000 Genomes Project
  * Accepts downloaded tracks from dbSNP
  * Also accepts: FASTA, GFF/GTF/GVF, BED, Wiggle, Cosmic, UCSC variant database, complete genomics master var file
  * Read mapping: “In addition to Sanger sequence data, reads from these high-throughput sequencing machines are supported: The 454 FLX System and the 454 GS Junior System from Roche, Illumina Genome Analyzer, Illumina HiSeq, Illumina HiScan, and Illumina MiSeq sequencing systems, SOLiD system from Life Technologies, Ion Torrent system from Life Technologies, Helicos from Helicos BioSciences”
  * De novo assembly: “In addition to Sanger sequence data, reads from these high-throughput sequencing machines are supported The 454 FLX System and the 454 GS Junior System from Roche, Illumina Genome Analyzer, Illumina HiSeq, Illumina HiScan, and Illumina MiSeq sequencing systems, SOLiD system from Life Technologies, Ion Torrent system from Life Technologies”
  * Annotation tracks from Ensembl
1. **[DNAnexus] (https://www.dnanexus.com/product-overview)**
  * Private cloud repository -- formerly a redistributor of SRA and other NCBI resources; command-line or via web, can fetch data from a URL,  build custom pipeline/ workflow
has sra.dnanexus.com site: data downloads come directly from NCBI
1. **[Ingenuity Variant Analysis] (http://www.ingenuity.com/products/variant-analysis)**
  * (QIAGEN) allows for variant identification and analysis, uses NCI-60 data set for cancer, Supported third part informatin: Entrez Gene, RefSeq, ClinVar; gives contextual details of results instead of just A to B relationship
  * Has own database-- “knowledge base” based on COSMIC, OMIM, and TCGA databases
1. **[Lasergene Genomics Suite] (http://www.dnastar.com/t-products-dnastar-lasergene-genomics.aspx)**
  * Comprehensive NGS software pipeline for assembly, alignment, variant calling and analysis of NGS data
  * Supported workflows include: reference-guided and de novo genome and transcriptome assembly and analysis, metagenomics sample assembly, targeted resequencing, exome alignment, gene panels with validation control, variant analysis, and RNA-Seq, ChIP-Seq and miRNA alignment and analysis.
  * #1 in accuracy: fewer false negatives and better sensitivity compared to results obtained from other aligners
  * Aligns exome data and performs variant calling an average of 3 times faster than alternative pipelines
  * Annotates genomic data with allele and genotype frequency, functional impact predictions, evolutionary conservation scores and pathogenicity
  * Supports all major NGS technologies (Illumina, Ion Torrent, Pac Bio and Roche 454) and project types
  * Available on Windows, Mac OS X, Linux, and the Amazon Cloud
1. **[NextGENe] (http://www.softgenetics.com/NextGENe.html)**
  * “perfect analytical partner for the analysis of desktop sequencing data produced by the ION PGM™, Roche Junior, Illumina MiSeq as well as high throughput systems as the Ion Torrent Proton, Roche FLX, Applied BioSystems SOLiD™ and Illumina® platforms.” runs on Windows, free-standing multi-application package-- SNP/Indel analysis, CNV prediction and disease discovery, whole genome alignment, etc.
  * Data can be imported from Clinvar, dbSNP, Genbank: http://www.softgenetics.com/PDF/NextGene_UsersManual_web.pdf
1. **[Partek Genomics Suite] (http://www.partek.com/pgs)**
  * Cited in over 3,500 peer-reviewed scientific publications
  * Workflows for microarray and PCR data include: Gene expression including alternative splicing, miRNA expression, Genome Wide Association Studies, Mother-Father-Child Trio analysis, DNA Copy number including allele specific copy number and Loss of Heterozygosity (LOH), and ChIP, and methylation. Next Generation Sequencing (NGS) workflows include: RNA-Seq, miRNA-Seq, ChIP-Seq, DNA-Seq, and Methylation
  * Powerful statistics and interactive, publication ready visualizations
  * Supports all commercial next generation sequencing and microarray file format as well as text files
  * Can input GEO SOFT files
1. **[Partek Flow] (http://www.partek.com/partekflow)**
  * Installation can be cloud-based or on a local cluster or Linux server
  * Easy to use point-and-click interface
  * Takes NGS data (.fastq, BAM, SAM), microarrays (Affymetrix, Illumina) and text files
  * Supports custom genome builds and annotation databases
  * Performs base trimming, alignment, quantification, quality analysis, statistics, and visualization
  * Includes ten fully customizable aligners (Bowtie, Bowtie 2, BWA, GSNAP, Isaac 2, SHRiMP 2, STAR, TMAP, TopHat and TopHat 2)
  * Applications for RNA-Seq, Small RNA-Seq, WGS/WES, Pathway enrichment, Fusion detection and Variant calling
  * Allows users to create, save, share, or download analysis pipelines for automated and repeatable analysis
  * Collaborate with others without transferring data
  * Integrates microarray and next generation sequencing data
1. **[Golden Helix: SNP and Variation Suite] (http://goldenhelix.com/SNP_Variation/)**
  * used for managing, analyzing and visualizing genotypic and phenotypic data; Features: Genome-wide association studies, genomic prediction, copy number analysis, small sample DNA-Seq workflows, large sample DNA-seq analysis, RNA-seq analysis.
Supported files: .txt, excel XLS & XLSX, CEL, CHP, CNT, Illumina, Plink PED, TPED, BED, Agilent files, NimbleGen data summary files, VCF files, Impute2 GWAS files, HapMap format, MACH output, + 50 other formats
consumes NCBI data directly
1. **[Genomatix] (https://www.genomatix.de/)**
  * Applications: ChIP-Seq, DNA-Seq, RNA-Seq, DNA methylation; enable personalized medicine,
  * Mining Stations: Supports all established NGS sequencing platforms- SOLiD, 454 Life Sciences, Genome Analyzer, HiSeq, MiSeq, IonTorrent
  * Software Suite: can upload sequence of BED files
  * Genome browser: BED and BAM files, Public data- 1500 BED files available for every user
1. **[Biodatomics] (http://www.biodatomics.com/)**
  * Open source platform (SaaS), analysis and genome sequencing tools, integrates over 400 genomic analysis open source tools and pipelines, have a private and public cloud version. Features: genomic data visualization, drag and drop interface, accelerated analysis, real-time collaboration
  * They have a couple modules to do so, and have enabled parts of the sra toolkit
1. **[SolveBio] (https://www.solvebio.com/)**
  * Software product, for clinical genomics professionals, manage, curate, report genomic variation
  * Has own data library -- data from NCBI


text:
## Other Tools
[SiRen](http://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-159.pdf)
[Stampy](http://www.well.ox.ac.uk/project-stampy)


text:
### External Tools that work with ClinVar

[MacArthur](https://github.com/macarthur-lab/clinvar)

[Abramconnelly](https://github.com/abramconnelly/clinvar-report)

[Agermanidis](https://github.com/agermanidis/ClinVar)

[Ianjw11](https://github.com/ianjw11/clinvarparser)

[Welchbm](https://github.com/welchbm/VisualizeClinvar)

[PersonalGenomesOrg](https://github.com/PersonalGenomesOrg/vcf2clinvar)

[Rbagnall](https://github.com/rbagnall/clinvar_parser)

[ClinGen](https://github.com/ClinGen/clinvar-demo)

[Pidr](https://github.com/pidr/clinvar-rdfizer)

[Alexhnrie](https://github.com/alexhenrie/clinvar-for-nerds)

[Clingendb](https://github.com/clingendb/clinvar_xml_pipe)

[Dakl](https://github.com/dakl/macarthur-clinvar-to-vcf)

[Sephraim](https://github.com/sephraim/convert_ClinVar_XML_to_VCF)


text:
## Variant Identification
### Germline + Somatic  Callers
1. **[VarScan 2] (http://massgenomics.org/varscan)**
  * Description: identify germline variants, private and shared variants, somatic mutations, and somatic CNVs; detects indels
  * Input: SAMtools pileup
  * Output: VCF
  <hr/>
1. **[BAYSIC] (http://genformatic.com/baysic/)**
  * Description: Bayesian method; combines variant calls from different methods (GATK, FreeBayes, Atlas, Samtools, etc)
  * Input: VCF format from one or more variant calling programs
  * Output: VCF file containing integrated set of variant calls
1. **[MSIsensor] (https://github.com/ding-lab/msisensor)**
  * Description: Microsatellite instability detection; C++ program, detects somatic and germline variants in tumor-normal paired data
  * Input: BAM index files (normal and tumor)
  * Output:
1. **[Beagle version 4] (http://faculty.washington.edu/browning/beagle/beagle.html)**
  * Description: software package: genotype calling, phasing, imputation of ungenotyped markers, and identity-by-descent segment detection:unsure if this one is in the right category; genotype calling, phasing, imputation of ungenotyped markers, and identity-by-descent segment detection;
  * Input: VCF
  * Output: VCF
1. **[QuadGT] (http://www.iro.umontreal.ca/~csuros/quadgt/)**
  * Description: software package, SNV calling from normal-tumor pair and two parent genomes; quantifies descent-by-modification relationships; Written in Java
  * Input: BAM files (parsed by Picard/Samtools API)
   * Reference Genome; FASTA
  * Output: VCF
1. **[RAREVATOR] (http://sourceforge.net/projects/rarevator/)**
  * Description: RAre REference VAriant annotaTOR; command line;  “identification and annotation of germline and somatic variants in rare reference allele loci from second generation sequencing data”; Bayesian genotype likelihood model
  * Input: BED or VCF files from GATK
  * Output: two VCF files (one for SNVs, one for Indels)
1. **[Scalpel] (http://scalpel.sourceforge.net/)**
  * Description: Used for detecting indels in a reference genome; performs localized micro-assembly of specific regions of interest; can do single, de novo, somatic reads; requires that raw reads are aligned with BWA
  * Input: BAM
  * Output: either VCF or ANNOVAR
1. **[SOAPsnp] (http://soap.genomics.org.cn/soapsnp.html)**
  * Description: based on Baye’s theorem; calls consensus genotype
  * Input:SOAP short read alignment results
  * Output: GLF, option of flat tabular format
1. **[VariantMaster] (http://sourceforge.net/projects/variantmaster/)**
  * Description: “extract causative variants for monogenic and sporadic genetic diseases”; uses ANNOVAR;
  * Input: BAM or VCF files (from SAMtools, GATK)
  * Output:


text:
## Tool Repositories, Analytical Pipelines, & Workflow Systems
### ToolKits
1. **[bamtools] (https://github.com/pezmaster31/bamtools)**
  * Description: command line tool kit, also API version; for reading, writing and manipulating BAM (genome alignment) files
  * Input: BAM
  * Output: BAM
1. **[Bioconductor] (http://www.bioconductor.org/)**
  * Description: Open source software project, Popular R module library with over 1000 modules, can analyze diverse high-throughput genomic data; options for multiple different workflows; also available on AMI
  * Input: Multiple
  * Output: Multiple
1. **[Galaxy Tool Shed] (https://toolshed.g2.bx.psu.edu/)**
  * Description: Open, web-based platform; Has 3374 valid tools for many different purposes. Looks like this site has a different tool repository for each different data type, They have agreed to support NCBI genomes, and SRA on a limited basis
  * Input: Different tools for different types of data
  * Output: Multiple
1. **[GATK] (https://www.broadinstitute.org/gatk/)**
  * Description: (Broad Institute) Genome Analysis ToolKit; software library including tools (depth of coverage analyzers, quality score recalibrator, local realigner, SNP/INDEL caller), requires Ant and Java, extensive documentation and wiki system, active community, can also be used to identify somatic mutations
  * Input: Multiple
  * Output: Multiple
1. **[picard] (http://broadinstitute.github.io/picard/)**
  * Description: (Broad Institute) Java based command line tools for manipulating high throughput sequencing data in the BAM format; supported through GATK
  * Input: BAM, SAM, VCF
  * Output: BAM, SAM
1. **[SAMtools] (http://samtools.sourceforge.net/)**
  * Description: provides utilities for manipulating alignments in the SAM format, including sorting, merging, indexing, and generating alignments; can be used for calling SNPs and Indels
  * Input: Conforms to the specifications produced by GA4GH File Formats working group
  * Output:
1. **[VCFtools] (https://vcftools.github.io/specs.html)**
  * Description: set of tools written in Perl and C++ for working with VCF files
  * Input: VCF, GZVCF, BCF
  * Output: Multiple, can be piped into another program


text:
### Structural Variant Tools
[ERDS](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3511991/)
[ForestSV](http://sebatlab.ucsd.edu/index.php/software-data)
[GRIDSS](https://github.com/PapenfussLab/gridss)
[inGAP-sv](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3125812/)
[Lumpy](https://github.com/arq5x/lumpy-sv)
[SV-Bay](https://github.com/InstitutCurie/SV-Bay)
[VariationHunter](http://compbio.cs.sfu.ca/software-variation-hunter)


text:
## Variant Identification
### Somatic Callers
1. **[Cake] (http://cakesomatic.sourceforge.net/)**
  * Description: standalone program, “pipeline for the integrated analysis of somatic variants in cancer genomes”; integrates four algorithms; written in Perl; required tools: samtools, tabix, vcftools, VarScan2, bambino, cmake, somaticsniper (User guide; workflow page)
  * Input: tumor and normal reads in BAM files, run through variant calling programs to generate intermediate VCF
  * Output: VCF
1. **[MuTect] (http://www.broadinstitute.org/cancer/cga/mutect)**
  * Description: Broad Institute, identification of somatic point mutations in cancer genomes; requires preprocessing of reads (GATK)
  * Input: same as GATK (FASTA reference genome, SAM read files)
  * Output: call-stats, VCF, wiggle files
1. **[Polymutt] (http://genome.sph.umich.edu/wiki/Polymutt)**
  * Description: calls SNVs and detects de novo point mutations in families
  * Input: GLF or BAM or VCF (must have identical chromosome orders)
  * Output: VCF
  <hr/>
1. **[Bassovac] (http://tvap.genome.wustl.edu/tools/bassovac/)**
  * Description: Improved Bayesian inversion somatic caller; unlike other software packages, treats effects fully probabilisticallys instead of using ad-hoc modeling; effects are integrated at the atomic level and standard probability theory integrates read tallies to the sample level and to the tumor-normal pair level; "pending public release"
  * Input:
  * Output:
1. **[CLImAT] (http://bioinformatics.ustc.edu.cn/CLImAT/)**
  * Description: standalone program; “accurate detection of copy number alteration and loss of heterozygosity in impure and aneuploid tumor samples using whole genome sequencing data”
  * Input: depth file generated by DFExtract and a config file
  * Output: .results file, .Gtype, LOG.txt, also generates visualization
1. **[DeNovoGear] (http://denovogear.sourceforge.net/)**
  * Description: de-novo variant calling and interpretation; standalone program; dependencies C++ compiler, CMake, HTSlib, Eigen, Boost
  * Input: PED and BCF
  * Output: “The output format is a single row for each putative de novo mutation (DNM), with the following fields”
1. **[EBCall] (https://github.com/friend1ws/EBCall)**
  * Description: Empirical Baysian Mutation Calling; standalone program; uses tumor/normal paired reads and non-paired normal reference samples; dependent on samtools, R and VGAM pack for R
  * Input: BAM
  * Output: not sure what exact type of file- “The format of the result is suitable for adding annotation by annovar.”
1. **[HapMuc] (https://github.com/usuyama/hapmuc)**
  * Description: standalone program; “utilizes the information of heterozygous germline variants near candidate mutations”; Dependent upon- Boost, SAMtools, BEDtools; 3 step workflow
  * Input: BAM
  * Output: BED
1. **[MultiGeMS] (https://github.com/cui-lab/multigems)**
  * Description: Multi-sample Genotype Model Selection
  * Input: .txt, pileup (SAM/BAM converted to pileup format)
  * Output: VCF
1. **[MultiSNV] (https://bitbucket.org/joseph07/multisnv/wiki/Home)**
  * Description: command-line program; calls SNVs from NGS data from multiple samples from the same patient; dependent on R, Git, cmake, Boost and compile libraries
  * Input: BAM or pileup
  * Output: VCF
1. **[MutationSeq] (http://compbio.bccrc.ca/software/mutationseq/)**
  * Description: standalone program, somatic SNV detection in tumor/normal samples; dependent on python, bamtools, boost, and LAPACK
  * Input: BAM
  * Output: VCF4.1 consisting of two parts (meta information & data lines)
1. **[qSNP] (http://www.qcmg.org/bioinformatics/tiki-index.php)**
  * Description: standalone program; SNV caller for somatic variants in “low cellularity cancer samples”
  * Input: BAM, dbSNP data, Illumina data, chrConv
  * Output: “qSNP output files are named using a 4-element pattern: <subject-id>.<snp-type>.<description>.<extension>”
1. **[RADIA] (https://github.com/aradenbaugh/radia/)**
  * Description: RNA and DNA Integrated Analysis for Somatic Mutation Detection; DNA only Method(tumor/normal pair, ignores RNA) or Triple BAM Method (uses all three datasets from same patient); dependent upon python, samtoools, pysam API, BLAT, SnpEff
  * Input: BAM
   * Reference Genome: FASTA indexed with SAMtools faidx
  * Output: VCF
1. **[RVD2] (http://genomics.wpi.edu/rvd2/)**
  * Description: sensitive, variant detection for low-depth targeted NGS data; python module or command- line program;
  * Input: tab- deliminted depth chart format (converted from pileup files)
  * Output: three hdf5 files and a vcf file
1. **[Shimmer] (https://github.com/nhansen/Shimmer)**
  * Description: standalone program; detects somatic SNVs with multiple testing correction, uses Fisher’s exact test; dependent on git, samtools, R, R statmod package; for tumor/normal matched samples
  * Input: BAM
  * Output: VCF
1. **[SNV-PPILP] (http://www.cs.helsinki.fi/en/gsa/snv-ppilp/)**
  * Description: Refines GATK’s Unified Genotyper SNV calls for “multiple samples assumed to form a phylogeny”
  * Input:
  * Output:
1. **[SomaticSniper] (http://gmt.genome.wustl.edu/packages/somatic-sniper/)**
  * Description: command-line application to identify SNPs between tumor/normal pairs- predicts probability of difference between two
  * Input: BAM
   * Reference Genome in FASTA
  * Output: VCF
1. **[Strelka] (https://sites.google.com/site/strelkasomaticvariantcaller/)**
  * Description: somatic variant calling workflow for matched tumor-normal samples; detects indels; runs on *nux-like platform
  * Input: BAM (must be sorted and indexed)- Strelka does own realignment around indels-- don’t need to do this type of pre-processing
  * Output: pair of VCF files
1. **[Triodenovo] (http://www.pitt.edu/~wec47/triodenovo.html)**
  * Description: Bayesian framework for calling de novo mutations in trios
  * Input: VCF file with PL or GL fields (recommend using GATK or samtools to generate)
  * Output: out_vcf
1. **[UNCeqr] (http://lbg.med.unc.edu/~mwilkers/unceqr_dist/)**
  * Description: finds somatic mutations using integration of DNA and RNA seq data-- boosts sensitivity for low purity tumors and rare mutations;
  * Input:”can accept a variety of sequencing inputs and configurations”
  * Output: “table of somatically mutated sites and associated information. These somatic mutations can be annotated with predicted transcript and protein effects using third party tools, such as Annovar”
1. **[Virmid] (http://sourceforge.net/projects/virmid/)**
  * Description: Virtual Microdissection for SNP calling; Java based; for disease-control matched samples; uncovers SNPs with low allele frequency by considering alpha contamination
  * Input: BAM (must be sorted and indexed- samtools sort)
  * Output: VCF and report file


text:
## Downstream Analysis of Variants
1. **[PrediXcan] (https://github.com/hakyimlab/PrediXcan https://github.com/hriordan/PrediXcan/)**
  * Description: command-line, standalone package program; available in Perl, Python, and R versions; predicts liklihood of a gene being related to a certain phenotype- “that directly tests the molecular mechanisms through which genetic variation affects phenotype.”; no actual expression data used, only in silico expression; “PrediXcan can detect known and novel genes associated with disease traits and provide insights into the mechanism of these associations.”
  * Input: genotype and phenotype file (doesn’t specify file type)
  * Output:default values: genelist, dosages (file format:  snpid rsid) , dosage_prefix, weights, output
  <hr/>
1. **[ATHENA] (http://ritchielab.psu.edu/software/athena-downloads)**
  * Description: Analysis Tool for Heritable and Environmental Network Associations; software package, combines machine learning model with biology and statistics to predict non-linear interactions
  * Input: Configuration file, Data file, Map file (includes rsID)
  * Output: Summary file, Best model file, dot file, individual score file, cross-validation file
1. **[CCRaVAT and QuTie] (http://www.sanger.ac.uk/resources/software/rarevariant/#t_2)**
  * Description: (Wellcome Trust Sanger) Case-Control Rare Variant Analysis Tool and Quantitative Trait; software packages for large-scale analysis of rare variants
  * Input: PED file and MAP file
  * Output: Five tab-delimited txt files
1. **[GCTA] (http://cnsgenomics.com/software/gcta/)**
  * Description: Genome Wide Complex Trait Analysis; package program, command line interface; estimates variance by all SNPs; 5 main functions: “data management, estimation of the genetic relationships from SNPs, mixed linear model analysis of variance explained by the SNPs, estimation of the linkage disequilibrium structure, and GWAS simulation”
  * Input: PLINK binary PED files, MACH output format
  * Output:
1. **[GenomeComb] (http://genomecomb.sourceforge.net/)**
  * Description: package for analysis of complete genome data; annotation using public data or custom tracks, automated primer desing for Sanger or Sequenom validation; “The cg process_illumina command can be used to generate annotated multisample data starting from fastq files, using tools such as bwa for alignment and GATK and samtools for variant calling. Sequencing data can also be imported from Complete Genomics (cg_process_sample command), Real Time Genomics (cg_process_rtgsample command) and VariantCallFormat (VCF) variant files (vcf2sft command).”
  * Input: Sequencing data from Complete Genomics, Illumina, SOLiD and VCF;
  * Output: standard file format used is a simple tab delimited file (.sft, .tsv)
1. **[Genome Track Analyzer] (http://ancorr.eimb.ru/)**
  * Description: compares genome tracks; allows user to compare DNA expression/binding;
  * Input: multiple: SGR/TXT, BED, BED6, GFF;  if using prealigned sequence data- use MACS peak caller: BAM, BED, SAM, ELAND
  * Output:
1. **[GVCBLUP] (http://animalgene.umn.edu/gvcblub)**
  * Description: animal gene mapping; “genomic prediction and variance component estimation of additive and dominance effects”; standalone program, command line interface, writting in C++ and Java
  * Input:
  * Output:
1. **[HOMOG] (http://www.jurgott.org/linkage/homog.htm)**
  * Description: Analyzes heterogeneity with respect to single marker loci or known maps of markers; Carries out homogeneity test for alternative hypothesis “Two family types, one with linkage betweeen a trait to a marker or map of markers, the other without linkage”
  * Input: HOMOG.DAT - described on website
  * Output: HOMOG.OUT
1. **[INTERSNP] (http://intersnp.meb.uni-bonn.de/)**
  * Description: GWIA for case-control SNP and quantitative traits; selected for joint analysis using priori information; Provides linear regression framework, Pathway Association Analysis, Genome-wide Haplotype Analysis,
  * Input: PLINK input formats (ped/map, tped/tfam, bed/bim/fam) Compatible with SetID files
   * Gene reference file: Ensembl Release 75
  * Output: covariance matrix for regression models
1. **[mtSet] (https://github.com/PMBio/mtSet)**
  * Description: Currently only the standalone version available, but moving to LIMIX software suite; offers set tests- allows for testing between variants and traits; accounts for confounding factors ex. relatedness
  * Input: sample-to-sample genetic covariance matrix needs to be computed; multiple types of input; simulator requires input genotype and relatedness component;
  * Output: resdir (result file of analysis), outfile (test statistics and p-values), manhattan_plot (flag)
1. **[MultiBLUP] (http://dougspeed.com/multiblup/)**
  * Description: Package program, command line interface; constructs linear prediction models; Best Linear Unbiased Prediction; improves upon BLUP involving kinship matrices; options: pre-specified kinships, regional kinships, adaptive multiblups, LD weightings
  * Input: PLINK format
  * Output:.reml, .indi.blp


text:
## Variant Identification
### Germline Callers
1. **[IMPUTE2] (http://mathgen.stats.ox.ac.uk/impute/impute_v2.html)**
  * Description: phasing observed genotypes and imputing missing genotypes uses reference panels to provide all available halotypes, does not use population labels or genome-wide measures; designed to represent variation in one population; Fairly popular
  * Input:
   * Reference Haplotypes: Links to 1000 Genomes and HapMap downloads
  * Output:
1. **[FreeBayes] (https://github.com/ekg/freebayes)**
  * Description: finds SNPs, Indels, MNPs; reports variants based on alignment; haplotype based
  * Input: BAM- uses BAMtools API to parse
   * Reference genome: FASTA
  * Output: VCF
1. **[SOAPindel] (http://soap.genomics.org.cn/soapindel.html)**
  * Description: detects indels from NGS paired-end sequencing
  * Input: files with read alignment can be SOAP or SAM formats, users must also give raw reads in Fasta or Fastq
   * Reference Sequence used to align reads: FASTA
  * Output:
  <hr/>
1. **[2Kplus2] (https://github.com/danmaclean/2kplus2)**
  * Description: algorithm searches graphs produced by de novo assembler Cortex; c++ source code for SNP detection
“2kplus2.cpp is a c++ source code for the detection and the classification of single nucleotide polymorphisms in transformed De Bruijn graphs using Cortex assembler.”
  * Input:
  * Output:
1. **[Atlas 2] ( https://www.hgsc.bcm.edu/software/atlas-2)**
  * Description: specializes in separation of true SNPs and indels from sequencing and mapping errors, last update January 2013
  * Input: takes BAM file,
   * Reference Genome: FASTA
  * Output: produces VCF
1. **[CRISP] (https://sites.google.com/site/vibansal/software/crisp)**
  * Description: identifies SNPs and INDELs from pooled high-throughput NGS, not used for analysis of single samples; implemented in C and uses SAMtools API; latest version should work with diploid genomes
  * Input: requires BAM files (aligned with GATK)
   * Reference Genome: indexed FASTA file
  * Output: VCF files
1. **[Dindel] (http://www.sanger.ac.uk/resources/software/dindel/)**
  * Description: (Wellcome Trust Sanger) calls small indels from short-read sequences, only can handle Illumina data; cannot test candidate indels; written in C++, used on Linux based and Mac computers (not tested in windows)
  * Input: BAM files
  * Output: VCF
1. **[discoSnp++] (http://colibread.inria.fr/software/discosnp/)**
  * Description: detects homozygous and heterozygous SNPs and Indels; software composed of 2 modules (kissnp2 and kissreads)
  * Input: raw NGS datasets; fasta, fastq, gzipped or not;
   * no reference genome required; read pairs can be given
  * Output: FASTA
1. **[FamSeq] (http://odin.mdacc.tmc.edu/~wwang7/FamSeqIndex.html)**
  * Description: family-based sequencing studies- provides probability of an individual carrying variant based on family’s raw measurements; accommodates de novo mutations, can perform variant calling at chrX;
  * Input: VCF
  * Output: VCF
1. **[GeneticThesaurus] (http://sourceforge.net/p/ geneticthesaurus/wiki/Example/)**
  * Description: “Annotation of genetic variants in repetitive regions”
  * Input: Initial variant calling from bam ? vcf output
   * Reference Genome: need to provide own fasta file for hg19 genome,
  * Output: vcf.gz, vtf.gz, and baf.tsv.gz output
1. **[glfMultiples] (http://genome.sph.umich.edu/wiki/GlfMultiples)**
  * Description: command-line, variant caller
  * Input: GLF
  * Output: VCF
1. **[glfSingle] (http://genome.sph.umich.edu/wiki/GlfSingle)**
  * Description: uses likelihood-based model for variant calling, starts from genotype likelihoods that have been computed from other tools (ex. Samtools BAQ), the likelihoods combine with individual-based prior p(genotype) to generate posterior probabilities
  * Input: GLF
  * Output: VCF
1. **[Halvade] (https://github.com/ddcap/halvade)**
  * Description: command-line; written in Java, “to run halvade a reference is needed for both GATK and BWA and a SNP (dbSNP!) database is required
  * Input: FASTQ
  * Output: VCF
1. **[indelMINER] (https://github.com/aakrosh/indelMINER)**
  * Description: identifies indels from paired-end reads
  * Input: BAM (aligned in SAMtools API)
  * Output: VCF
1. **[Indelocator] (https://www.broadinstitute.org/cancer/cga/indelocator)**
  * Description: (Broad Institute): does not perform realignment, relies on alignments in BAM files (BAM files need aligned before put into indelocator); recommended to use GATK prior;
  * Input: 2 BAM files(tumor & normal), annotated as germline or somatic; also has single sample mode
  * Output: “Output of Indelocator is a high-sensitivity list of putative indel events containing large numbers of false positives. The statistics reported for each event have to be used to custom-filter the list in order to lower false positive rate”
1. **[Isaac Variant Caller] (https://github.com/sequencing/isaac_variant_caller)**
  * Description: detects SNPs and small indels from diploid sample; designed to run on “nux-like platforms”
  * Input: BAM
  * Output: VCF
1. **[KvarQ] (http://www.swisstph.ch/kvarq)**
  * Description: in silico genotyping for selected loci in bacterial genome, written in Python and C
  * Input: FASTQ
   * reference genome or de novo assembly not needed
  * Output:
1. **[LoFreq] (http://sourceforge.net/projects/lofreq/files/)**
  * Description: SNV caller, Python language, standalone program, uncovers cell-population heterogeneity from high-throughput sequencing datasets; calls variants found in <.05% of the population
  * Input: BAM file input? suggest running through GATK
  * Output:
1. **[Manta] (https://github.com/Illumina/manta)**
  * Description: Calls indels and SVs from paired end reads; standalone, command line program; Written in C++ and Python
  * Input: BAM (can tolerate non-paired-end reads); a matched tumor sample may be provided as well
  * Output: VCF
1. **[MarginAlign] (https://github.com/benedictpaten/marginAlign)**
  * Description: SNV caller, specifically tailored to Oxford Nanopore Reads, written in Python; Package comes with 3 programs, marginAlign, marginCaller (calls SNVs), marginStats (computes qc stats on sam files)
  * Input: SAM
  * Output: SAM
1. **[MendelScan] (http://gmt.genome.wustl.edu/packages/mendelscan/)**
  * Description: Last release March 2014; for analyzing sequencing data in family studies of inherited diseases; variant calls for a family in VCF file; still in alpha-testing
on github, example data uses 1000 genomes dataset
  * Input:
  * Output:
1. **[nanopore] (https://github.com/mitenjain/nanopore)**
  * Description: UCSC Nanopore group (group at UCSC studying using ion channels for analysis of single RNA/DNA structures) software pipeline; tailored to Oxford Nanopore Reads; command line program
  * Input: FASTQ
   * Reference files: FASTA
  * Output: “For each possible pair of read file, reference genome and mapping algorithm an experiment directory will be created in the nanopore/output directory.”
1. **[Platypus] (http://omictools.com/platypus-s1989.html)**
  * Description: Package program, written in C, Python, Cython;  Can identify SNPs, MNPs, short indels, and larger variants; has been tested on very large datasets (1000 genomes)
  * Input: BAM
   * Reference Genome: FASTA (files must be indexed using Samtools or similar program
  * Output: VCF
1. **[QualitySNPng] (http://www.bioinformatics.nl/QualitySNPng/)**
  * Description: detection of SNPs; “can be used as a standalone application with graphical user interface as part of pipeline system”; does not require fully sequenced reference genome; haplotype strategy
  * Input:SAM, ACE
  * Output: GUI
1. **[ReviSTER] (http://revister.sourceforge.net/)**
  * Description: command line program; automated pipeline; utilizes BWA, BLAT, and SAMTools;  utilizes BWA mapping program;
  * Input: FASTQ,
   * Reference sequence file and list file containing STR locations as inputs
  * Output: SAM
1. **[RVD] (http://dna-discovery.stanford.edu/software/rvd/)**
  * Description: command-line program, detection of rare SNVs, relies upon Samtools, can be run in MATLAB
  * Input: BAM
   * Reference Genome: FASTA
  * Output: “The algorithm output is a call table -- a comma-separated file with one line for each base position and each line in the following format:
   * AlginmentReferencePosition, AlignmentBase, Call ,SecondBase, CenteredErrorPrc, ReferenceErrorPrc, SecondBasePrc”
1. **[SNVer] (http://snver.sourceforge.net/)**
  * Description: calls common and rare variants in pool or individual NGS data, reports overall p-value, operating system independent statistical tool, identifies SNPs and INDELs, written in Java, no dependencies, straightforward command-line
   * (SNVerGUI=GUI version) --SNVerGUI: desktop tool for variant detection
  * Input: chrX annotation, sam.zip, bam.zip
   * reference file must be aligned to the data file
  * Output:
1. **[SNVMix] (http://compbio.bccrc.ca/software/snvmix/)**
  * Description: detects SNVs from NGS, post-alignment tool
  * Input: pileupformat (Maq or Samtools)
  * Output:
1. **[SV-M] (http://www.bsse.ethz.ch/mlcb/research/bioinformatics-and-computational-biology/structural-variant-machine--sv-m-.html)**
  * Description: Structural Variant Machine - predicts indels, uses split read alignment profiles, validated by Sanger Sequencng
  * Input:paired-end Illumina reads from 1001 genomes project (uses ref plant- 1001genomes.org)
  * Ouptut:
1. **[SNPest] (https://github.com/slindgreen/SNPest)**
  * Description: Standalone program, language C++, Perl
  * Input: mpileup (SAMtools)
  * Output: VCF
1. **[TrioCaller] (http://genome.sph.umich.edu/wiki/TrioCaller)**
  * Description:Command line program, relies on BWA and samtools; genotype calling for unrelated individuals and parent-offspring trios
  * Input: BAM (that has been aligned in BWA and Samtools
  * Output: BCF that can be formatted to VCF using bcftools
1. **[Snippy] (http://www.vicbioinformatics.com/software.snippy.shtml)**
  * Description: finds indels between haploid reference genome and NGS sequence reads
  * Input:read files- FASTQ or FASTA (can be .gz compressed), output- .aln, .tab, .txt
   * Reference genome in FASTA or GENBANK
  * Output:
1. **[VntrSeek] (http://orca.bu.edu/vntrseek/)**
  * Description: pipeline for discovering microsatellite tandem repeats with high-throughput sequencing data
  * Input: gzip-compressed FASTA or FASTQ
  * Output: VCF files; one for TRs and observed alleles, another file contains link to viewer