# Owner Privileges & Time-locks ### Governance All upgrades are behind a minimum **48 hour timelock**. ### Exchange Factory All owner calls are behind a minimum **48 hour timelock** . \ Set paused is ready to go in case of emergencies ### Compounder Factory All owner calls are behind a minimum **48 hour timelock**. `setOptimizedReinvest`: // NO affect on users funds. Changing this means that liquidity addition will use Alpha Homoroa Optimal One-Sided Supply algo to add liquidity, which means less liquidity is wasted `setPerformBuyBacks`: // NO affect on user funds. Changing this will make it so that the chosen farm performance fee(something users are charged regardless) won't burn GFI, instead it sends it to a holding address to be distributed in future farms `changeBuyBacks`: // NO affect on user funds, Just changes the address that GFI is sent to, if setPerformBuyBacks is set up `setTxOriginWhitelist`: // NO affect on user funds, The harvestCompounding function uses this bool to either run `require(msg.sender == tx.origin)`, or to check if the caller is on the whitelist. This is in here to protect users harvested rewards from being targeted by flashloan attacks. `adjustWhitelist`: // NO affect on user funds, Whitelist is set up to control what addresses can create compounders, and what addresses can call harvestCompounding if `txOriginOrWhitelist` is true `changeTierManager`: // No affect on user funds, this contract does not approve the TierManager to spend anything `changeGovernor`: // NO affect on user funds. The associated address is only used in `sendEarningsToIncinerator` to interact with our governance contract, it is not approved to spend any user funds `changeIncinerator`: // NO affect on user funds, changing this address changes where the weth earnings the farm earned is being sent(since farms hold GFI, and GFI holders are entitled to platform earnings paid out in weth, farms are earning GFI). So while we could change this address so that the weth earnings are sent to us instead of being sent to an incinerator(where they are used to buy GFI and burn it), these earnings are in no way user funds, and would not be very lucrative for us to do so considering the PR nightmare that would cause. `changeCheckTiers`: // NO affect on user funds, this is a bool that determines whether we should check the users tier before they are allowed entry into the Compounder. Honestly the worst thing I think we could do with this is turn it to true, but leave the TierManager address unset, which would make it so that no one could enter the compounder(which is actually kinda nice if we were phasing out the contract) `changeShareInfo`: // Has an affect on the interest users earn, but no affect on their underlying deposit. I agree that this function needs to be controlled via timelock. `updateSharedVariables`: // None of the addresses are given infinite approval, so the risk to users is low, but these addresses are vital to the CompounderFactory working properly, so they should not be changed unless we really need to. I agree that this function needs to be controlled via timelock. `createCompounder`: // NO affect on user funds, this function creates a compounder ### FarmFactory All owner calls are behind a **48 hour timelock**. `adjustWhitelist`: // NO affect on user funds. The whitelist in this contract is used to control who can create farms without getting prior approval from us(which is done using `approveOrRevokeFarm` ) `setHarvestFee`: // Has an affect on the interest users earn, but no affect on their underlying deposit. I agree that this function needs to be controlled via timelock. `setIncinerator`: // NO affect on user funds. Determines where Farm weth earnings should go, changing this to a malicous contract would mean we could steal the farms weth earnings, but that is a pretty small reward compared to the PR fallout from doing that `setFeeManager`: // NO affect on user funds. Determines where performance fees should go if the farm reward token is not GFI `setGovernance`: // NO affect on user funds. The associated address is only used in `sendEarningsToIncinerator` to interact with our governance contract, it is not approved to spend any user funds `approveOrRevokeFarm`: // NO affect on user funds. Allows us to control who can create farms from our farm factory. Without us requiring them to trust us with depositing their farms reward token. ### Earnings Manager Explanation: Since all GFI token holders earn platform fees, that means that swap pairs with GFI as one of the tokens will earn platform fees in weth. So the earnings manager job is to take that weth, convert it back into the swap pairs two tokens, and then add liquidity to the pair. Once the function call is done, some wei is left in the contract. `adjustWhitelist`: // NO affect on user funds. The whitelist controls who can call the functions that convert weth earnings into a pairs tokens. `adminWithdraw`: // NO affect on user funds. When the function are ran, there is maybe a couple wei worth of weth or GFI left in the contract. So I guess this function could be used to rug that wei? This function will be removed for the next iteration of this contract. `oracleProcessEarnings`: // NO affect on user funds `manualProcessEarnings`: // NO affect on user funds ### Incinerator This contract is NOT handling user funds at all. It is only handling weth that GFI farms earn. `setSlippage`: `adminConvertEarningsToGFIandBurn`: ### ### FeeManager This contract is NOT handling user funds at all. It is only handling swap fees `adjustWhitelist`: // NO affect on user funds, only controls who can process all the swap fees into weth and wbtc `adminWithdraw`: // NO affect on user funds. The contract owner can rug all the swap fees from the contract. Because of this, this function will be removed from the next iteration of this contract `deposit`: // NO affect on user funds `oracleStepSwap`: // NO affect on user funds `manualStepSwap`: // NO affect on user funds --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://inthenextversion.gitbook.io/gravity-finance/audits-security/owner-priv-and-time-locks.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.