0x6bb4a97b…c1ebsent to0xa0ec2af0…e5fd·#22,495,796·0xb5c38de0…c9be52
# Set Cooler V2 Delegates limit for hOHM
This proposal sets the maximum number of addresses that Origami Finance's hOHM is permitted delegate gOHM voting power to.
## Justification
Origami Finance's hOHM is an OHM derivative that uses Cooler v2 to programmatically leverage OHM to buy more OHM using the increase in Loan to Backing over time. This creates a maximally leveraged position whose health is contractually managed with minimized downside but leveraged upside. It also creates an economy of scale with a perpetual bid on OHM to grow.
* Within Cooler v2's DLGTE module, individual borrowers, as well as platforms building on top of Cooler v2, can assign all or a portion of their gOHM voting power to delegate addresses.
* By default, the maximum number of delegates for an account is 10.
* This proposal is to allow hOHM to delegate up to 1,000,000 addresses.
* Given that hOHM is immutable, the number of delegates is intentionally high to allow hOHM to support OHM users well into the foreseeable future.
* Through our extensive audits, we have demonstrated that a very high number of delegates will not present a security risk, but will provide hOHM with necessary and sufficient scalability.
## Resources
hOHm has been well audited by several discrete parties:
- [Nethermind Audit Report - hOHM](https://github.com/TempleDAO/origami-public/tree/main/audits/hOHM/Nethermind_hOHM.pdf)
- [Guardefy (Panprog) Audit Report - hOHM](https://github.com/TempleDAO/origami-public/tree/main/audits/hOHM/Panprog_hOHM.pdf)
- [Electisec Audit Report - hOHM](https://github.com/TempleDAO/origami-public/tree/main/audits/hOHM/Electisec_hOHM.pdf)
- [Electisec Audit Report - hOHM Migrator](https://github.com/TempleDAO/origami-public/tree/main/audits/hOHM/Electisec_hOHM_Migrator.pdf)
## Liquidation Risk Mitigations
In order to liquidate an unhealthy Cooler V2 position, all delegations for that account must be rescinded first. Block gas limits need to be considered to ensure positions can still be operationally liquidated.
hOHM's economic design ensures it will not become unhealthy. However mitigations are in place to ensure hOHM can still be liquidated if there is an unforseen issue, even with the increase in allowed delegations:
- hOHM: Users of hOHM may only delegate their gOHM voting power to one single address, all or nothing.
- hOHM: Minimum gOHM to delegate: Users of hOHM must have a minimum effective gOHM balance of 0.1 gOHM. This economically limits the realistic number of delegations which hOHM will be able to delegate within Cooler V2.
- hOHM: Auto delegation removal: If a hOHM user which has previously delegated > 0.1 gOHM then redeems their hOHM and reduces their effective gOHM balance below 0.1 gOHM, the delegation will automatically be removed. This prevents hOHM from having any 'dust' delegations.
- Cooler V2: Unhealhy positions can have their delegations permisionlessly removed in batches. Once the number of delegations are reduced, the liquidation can proceed as normal.
## Assumptions
- The DLGTE module has been installed into the Kernel
- The LTV Oracle, Treasury Borrower and Mono Cooler policies have been activated in the Kernel
- The Treasury Borrower policy has been set on the Mono Cooler policy
## Proposal Steps
1. Set the maximum delegate addresses for hOHM to 1000000.