# Serpentor Phase 2 Plan

## Context:

The first release of Serpentor or Phase 1 was completed and audited
https://github.com/yearn/serpentor/releases/tag/0.1.0

It contained the following audited contracts:
- Timelock.vy
- SerpentorBravo.vy (on-chain voting and proposal execution)

The first phase had the goal of achieving parity with compound on-chain governance system to be able to replace if necessary the multi-sig ychad for this governancesystem (it requires veYFI to be launched).

Phase 1 will stay as a set of tools and back up plan in case yearns needs to decentralize ASAP and lower any risk pertaining to multi sig and current operational setup.

A secondary goal of phase 1 was to release an OSS governance tool alternative in vyper that is lean and useful to the wider community.

Although phase 1 feature set contains a complete on-chain governance system, if yearn where to migrate to phase 1 setup it would be missing the automation aspect in operational process we currently have.

Having all smart contract changes being a proposal on-chain with 7 days timelock will never optimal for yearn's operational model and many other projects.

## Motivation

Current v2 system has over 100 vaults deployed that require several restricted operations like fee changes, adding strategies, allocation funds, etc that rely to be executed on chain by `ychad.eth`.

`ychad.eth` transactions increase the overhead on signers and very often the queue gets filled up to 7 or more pending transactions that is a risk to security plus increases overhead and reliance on `ychad.eth`. Recently msig signers needed a rotation [here](https://gov.yearn.finance/t/yip-68-rotate-multisig-signers/12582/4) and keeping up with the signers is overall a big overhead for operations.

The current v2 system does not allow granular roles per operation and relies on a global admin role called governance which is now `ychad.eth`.

There are efforts to adjust and experiment with vault settings in a more decentralized way like [yip 69](https://gov.yearn.finance/t/yip-69-reduce-and-cap-fees-through-yrates/12588) and also automate more functionality away from `ychad.eth`, **but without an additional mechanism to handle this in a more automated way the new teams will need to go through current multisig which increases bottle neck and overhead**.

## Goal

To improve Serpentor's feature and match the automation requirements the different contracts and teams in yearn have we need to add features that allow for both fast and slow on-chain changes governed by a single contract to replace `ychad.eth`.

## Description of Solution

Create a new set of contracts for phase 2 that are compatible with phase 1 contracts but can be inter-changed and integrated following the Unix philosophy of minimalist, modular components.

A `DualTimelock` will be the main governance/admin role to replace `ychad.eth`, the features of this contract are described in scope section.

Additionaly we add a system of fast track contracts based on Lido's 'easy track' design that allows to propose on-chain changes without voting. In these system token holders can *only* stop proposals, but don't have to vote on them to be executed.

The proposals are changes made only from pre-approved contracts that work as rules or **scripts** called 'factories' and are limited in functionality. For serpentor we can create a similar concept and these **scripts** can have a lower timelock to execute without needing multi sig signers or holders vote.

Adding a new script to this system needs a normal vote on chain from the slow timelock and security audits, checks, etc. But once these scripts are added execution of the operations defined in them should be much faster.

**Scripts** in these system can be compared to strategies in Vaults, they are well defined and sandboxed and can be interacted more frequently from backend since they have a limited set of functionality

Examples of operations that can be automated with scripts:

- debt ratio managament
- strategy debt allocation
- voting in CRV
- stream management
- fee changes (with pre-approved rules)

ADHOC Operations that could benefit from a timelock with longer delay:

- changing or adding a new contracts to a system (adding a strategy, changing a governance contract)
- operational budget approvals
- extraordinary expense from budget
- migrating to a new voting system e.g veYFI v2025
- mint more yfi
- fund new yteam
- fund tokyo party

By having a `DualTimelock` that can create both slow and fast proposals from different sources it allows any yearn contract to be governed by token holders while being operated and automated by yteams.

## Scope

This solution is intended to be compatible with our current generation of V2 vault/strategies architecture and other contracts which only have one governance role and also be compatible with v3 modular role system.

The design is intended to be rolled out incrementally to be able to lower the amount of operational transactions that `ychad.eth` needs to do in vault, eventually as more contracts with established rules and veYFI governance are attached to serpentor contracts `ychad.eth` transactions in vaults should be lowered to zero under normal circumstances and remain only in guardian and emergency roles.

SerpentorBravo contract that integrate veYFI will be the source of the slow ADHOC proposals and the new fast track contracts will be the source of automated transactions that bypass the slow timelock and have a lower window of execution (should be still enough time to be voted down if holders want to).

## Overview Diagram


## Definitions

**DualTimelock**: A governance contract that can hold two queues of transactions coming from two different sources with different time settings.


Responsabilities:
- Governance of all admin functions of a contract
- Can have a queue that can be written from two different sources.
- The two sources of transactions can create them with different timeout settings so its possible to have a slow and faster source of transactions.

**LeanTrack**: set of contracts based on Lido's 'easy track' system that will handle yearn **scripts** of automated operations. These system will be governed by the `DualTimelock` contract and can be changed through proposals like any contract which means management of **scripts** is done via on-chain voting.

The **scripts** within this system can be paused at any given time to be able to cancel a proposed transaction by an active role `knight` that can be delegated to a multi-sig like `ychad.eth` or SMS (strategiest multi sig). These allows for a quick response process against a faulty or buggy proposal in one of the **scripts**

Responsabilities:
- Registered pre-approved scripts that can create and send proposals to `DualTimelock``
- Pause functionality for scripts and proposals
- Canceling proposals through on-chain voting veto.

## Functional Requirements

1. Solution should be compatible with existing Vault interfaces for both 0.4.3 and 0.3.x and future v3.

2. Should integrate `SerpentorBravo` contract for on-chain voting of ADHOC proposals.

3. `DualTimelcock` can transfer its ownership based on king only role and can accept governance of a vault.

4. Serpentor supports addition through **scripts** for both vaults and strategies. These **scripts** once listed and added can add quickly vaults in permissionless manner. The goal should be to automate permissionless creation of curve pool vaults and other template strategies in a headless manner.

5. Should support addition of current management role to SMS or specialized yteam. Later on as we setup more contracts we can delegate the bishop role to other decentralized teams to propose fees with backing by governance voting like Maker.

* NICE TO HAVE, NOT CRITICAL

1. System should be immutable where possible, any change or possible way to upgrade the contracts should be delegated to `DualTimelock` and by proxy to YFI holders.

## Structural Requirements

### ease of use

1. UX should be similar to current setups and ape-safe scripts should be minimally impacted by this new indirection layer.

2. Contract should have events that can powered and off chain dashboard where we can see addresses and roles matrix for each vault.

### testability

1. The individual components `DualTimelock` and `LeanTrack` can be unit tested separately and vaults be mocked if needed.
2. Integration test with all components and a complete implementation are needed to validate complete functionality e2e.

### maintainability
1. By separating concerns and making components minimal and lean we can bring v3 modular roles and voter governance to v2 vaults in a flexible way, and iterate on different governance mechanism to lower overhead and `ychad.eth` dependency. Finally integrate and make use of veYFI for managing the yearn system.

### Security

- **Scripts** should follow the risk management process we use for strategies and ideally be as simple and limited as possible to lower risk.
- Any new **script** needs to go through slow on-chain voting to keep the system decentralize and rug protected.
- YFI token and veYFI become the key way to defend yearn's system from attackers and protect the value manage by it.

### One possible solution to governance attack

Scenario: potential bad actor holding enough amount of YFI tokens to be able to send malicious proposals to the system.

- Short term solution: voting against any malicious proposal becomes a responsability of token holders.
- Long term solution: `DualTimelock` can allow a change on the source of transactions to replace the SerpentorBravo and veYFI token with new ***forked*** versions of that system where the attacker has no powers to longer send any transactions, either by adding black lists to the voting or nullyfing the veYFI balance for a specific address.

**Note:** having a `DualTimelock` in place before veYFI can also bring the option of readding a gov role to veYFI and a feature be able to burn shares for a given account that is misbehaving that can only be done through timelock and hence on-chain governance to act as a deterrent.

**PHASE 3 DRAFT VISION**:

Expand to multi chain L2 layers via bridges that integrate with this system on Ethereum Mainnet.
See MakerDao's multi chain strategy.
https://twitter.com/MakerDAO/status/1552728122696601600?s=20

References:

- https://medium.com/iearn/yearnv3-motivation-and-design-107840c
- https://github.com/lidofinance/easy-track/blob/master/specification.md